Often, I’m asked by non-technical people about technical terms. I try to answer them, because I feel non-technical people need to understand technical things as well as technical people need to understand non-technical things as accounting or how to fill out travel expenses forms.
Last time in this series, I explained certain file formats and promised to explain microservices. What I will do in this post.
Services in General
When you want to understand, what microservices are, you might be well recommended to understand what a service is. Service is a term widely used in information technology. And interestingly enough, the term is not misleading. It is a service to someone else. Someone else might be another technical service or some a human user clicking in his browser or e-mail client.
Services in General
It means a service serves a client (e-mail or browser for example) to deliver or to get data.
Monoliths
When we look a little more into one service, we can see that such a service is split up into components. Those components can be tailored quite differently. In the 80s and 90s a so-called n-tier architecture were introduced and widely used. It tries to separate data, functions, and presentation and so it comes to layer (or tiers): presentation layer, business logic layer, and data layer.
Monolith – N-tier Architecture
Such n-tier architecture tends to become a monolith. Whereas monolith means here, something which cannot be structured anymore. That happens, because a consequent separation of business logic and user interface (presentation layer) cannot be held, and sometimes it makes even no sense. E.g. to valid a user input only in the business logic is quite user unfriendly, because the user has to wait for the validation before he can go further with his/her data input. On the other hand, sometimes it is easier (and in this way cheaper and faster) to put certain business logic to the data layer in form of triggers and stored procedures.
Those monoliths have a lot of disadvantages. One of the greatest is that the deployment of them is complex and time consuming. If I want only to change something small – e.g. I want to add to an address input an additional field for a street, I have to change the presentation layer, the business logic, and the data layer. All of them need to be deployed and more often than not those deployments require a downtime. But downtimes of modern web applications are not acceptable anymore. Because those downtimes need to be seldom, changes can only be shifted to production and insofar are available to the users quite seldom – e.g. 4 times a year. But these days we need to react to changes in requirements more often and insofar we need more production changes and we need them without downtime. Moreover, if one of the layers fails, the entire application is not available anymore.
One Solution but Not the Answer to Everything: Microservices
Microservices were first thought of 2011/2012 by a group for software engineers who faced the problems with large, monolithic applications as described above. They want an architecture style which is more appreciate to modern web applications which need to be highly performant, available, and stable. Moreover, they need something which is robust to changes where a small change remains a small change even during deployment.
To fulfill those requirements, you need
- Fine-grained services where one service fulfills exactly one business function e.g. shopping cart
- Microservices cannot be handled anymore manually, therefore deployment needs to be automated by 100%. The deployment needs to be done online. (Let me explain something about online deployment in one of the next posts.)
- Only a first acceptance testing can be done manually. All other testing – contract testing, integration testing, regression testing – needs to be automated. (OK I see, I need to post something about testing strategies as well J).
- A service in itself is complete in regard of the business function. It doesn’t need any other component outside of itself such a database to fulfill its function.
- A service is resilient. That means, it does not go down if a service, it communicates with goes down.
- The service is highly scalable. That means, if I add an additional instance of the service to my already existing service node, my entire system becomes more performant.
- Several of those business functions can be composed to one larger function, which in itself can work as a service to the outside world.
Let us see how it could work using some sample. We had in our monolith some shopping application. If you separate this shopping application into business functions you probably get the following picture.
Sample of Microservices in a Shopping Application
The shopping application aggregates a lot of business functions like shopping cart or even compare products. But even some shared functions can be identified like Access Management or Monitoring and Logging. The important point here is to identify the independent business functions and where the independence is needed out of business requirements e.g. different scaling requirements or different availability requirements. The Find Product function need to be up 365×24 whereas the Catalog Management needs only to be up during normal business times because the catalog content is provided to the shopping system by the Catalog Provider service.
All those services are seen as one service to the outside world. Especially the user of the shopping platform sees “one” user interface even though the content is delivered by quite different services. Even more, even for other services outside of the shopping application, the shopping application works as one via the Backend Frame.
Because microservices are small, they allow fast changes in the code and on production; but to communicate those changes throughout an entire organization takes too much time. Therefore, the team who have developed the software, needs to run and operate the software as well (DevOps organization). This is a great culture change.
Summarization
Microservices allow good structured, highly available, stable applications. They require high automation level and a great cultural change. Applications with less complexity can be developed and deployed as one monolith, because the internal business functions don’t have different requirements in regard of availability and stability. But when you have business functions, which need to be developed in several teams and which have quite different requirements in regard of scalability and stability, you need to apply microservices to your application.
ANNEGRET'S ARCHITECTURE 