Getting the balance right in microservices development
Source:- cloudcomputing-news.net
Choices, choices, choices. User requirements and non-functional requirements are just the beginning of the balancing act of services development. New development paradigms usually take a few years before their practitioners get a handle of the factors that they need to balance.
In the case of microservices, this balancing act comes down to three things: granularity, data consistency, and performance. The most usable and best-performing services built on the microservices architecture will find a balance of these three factors that work for the developers, users, and the business. Let’s start by defining these three factors in the context of microservices architecture.
Granularity
To be more specific: how many microservices and how granular the functionality of the services. The ultimate goal is to have the most granularity possible. Microservices architecture calls for the creation of a set of distinct functions that run on demand and then shut down.
The purpose of the granularity is twofold. Firstly, granularity enables rapid deployment of fixes and updates without lengthy and expensive testing cycles. Secondly, by execution on demand in a ‘serverless’ construct, the right level of granularity can help reduce cloud based infrastructure costs.
Data consistency
Since the microservices architecture calls for a discrete set of small functions defining an application or service the question arises as to how data will be passed between and acted upon by multiple functions while remaining consistent. Also, the question needs to be asked as to how multiple services built on microservices will access common data.
Think about a logistics system where multiple services, booking, confirmation, insurance, tracking, billing, and so on, each consist of multiple microservices functions and also need to pass information between them. Although the intent of this article is not to explore persistence technologies, some examples are: DBMS, journals and enterprise beans. The function of all of these and many others is to have data outlive the process that created it.
Performance
The starting and stopping of a process, even a microservices process, takes time and processing power. That may seem like an obvious statement but it requires some thought. If a process starts once and remains idle waiting for an input to run, there is no start-up delay except for the original startup or starting additional processes to handle the load.
In a microservices scenario, each time an input is received a process is started to handle the request. Then once the process ends its execution the process is shut down. This is an area where pre-provisioning of microservices servers (as in Microsoft Azure’s container based microservices solution) could be of benefit.
Balancing act
Granularity, as defined above, is the ultimate point of balance in a microservices architecture. While trying to make their services as granular as possible, if a team makes their microservices too granular, problems arise in the data consistency/persistence and performance realms. If the services aren’t granular enough you might get performance gains but you lose resiliency, flexibility, and scalability.
If a service is built in too granular a form, data consistency can become difficult simply because of the rise in the number of data connections and elements that need to be kept consistent. Performance suffers, in an overly granular scenario, due to the processing requirements of startup and shutdown, as described above.
The balance between the various functional requirements, non-functional requirements and the will to utilise new paradigm capabilities can lead to many different balancing scenarios. Realistically, creating a solid microservices based environment comes down to basic application architecture principals.
Understanding the needs and architecting the solution based on all the functional and non-functional requirements. When developing in a microservices architecture we need to resist the temptation to go too granular in order while also introducing the scalability and flexibility that the microservices architecture is known for.