Microservices - Introduction

The big internet companies are often used as an example for effective IT and microservices as their strategy for success. This article is the first article in a series and tries to summarize the benefits and challenges of microservices. Often only the benefits are seen but it is important to know the full story before starting with microservices.

Definition

There is no common clear and strong definition of microservices or microservice architecture. Most definitions refer to some characteristics or benefits which by themselves could be reached with different technologies. But altogether they characterize a special approach of software development. The following definitions cover the aspects important in the article.

In 2014 Martin Fowler writes in his article Microservices: “The term ‘Microservice Architecture’ has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.” He sees microservices as a specialization of a Service Orientated Architecture (SOA).

The Open Groups defines microservice architecture on their web pages as follows: “MSA [Microservice Architecture] is a style of architecture that defines and creates systems through the use of small independent and self-contained services that align closely with business activities.”

On opensource.com there is another definition to be found: “The central idea behind microservices is that some types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together. Each component is continuously developed and separately maintained, and the application is then simply the sum of its constituent components. This is in contrast to a traditional, ‘monolithic’ application which is all developed all in one piece.”

Finally, the microservice architecture is the next step after and the combination of SOA and object-oriented architecture. It brings the independency and message communication to the level of components in the object-oriented architecture. This means the components of a good designed monolith are exposed to the outside world and can be combined more flexibly. Other than SOA it tries to bring the intelligence from a central orchestration into the services as the endpoint of communications. The services itself should know which other services they have to communicate with. Because there is not strict definition of microservices in comparison to services both words are used in this article as synonyms.

The nex chapters will describe the benefits but also the challenges related to a microservice architecture.

Benefits

The following benefits are often mentioned. Altogether they should shorten the time to market for new features. Some of these benefits need additional prerequisites and some of them can be discussed. This is part of the chapter Challenges.

Isolation

One microservice covers only a small portion of functionality. It is separated from other microservices. They only interact via application programming interfaces (API) or messages. It is easy to change the functionality of one microservice. As long as none of the APIs or messages received or sent is not changed, other microservices will not be affected.

Scalability

The scalability is probably the biggest advantage of a microservice architecture. If one functionality is heavily used, you can easily add instances of the microservice covering this functionality on other machines. This means a horizontal scaling instead of a vertical scaling by putting CPU or memory in one machine.

No vendor lock-in

Mostly microservices are custom developed based on open source libraries. There is no dependency to any software vendors. By using cloud platforms and designing the microservices in a such a way as to switch the cloud provider, it is possible to get very independent from any vendors. Currently there are only a few vendors (e.g. eBaoTech) offering ready-to-use service for insurances.

Easy deployment

With the modern container deployment tools and frameworks, it is easy to deploy a microservice. There is no need to put everything for a large application together and deploy at the same time. This leads to shorter release cycles and time to market.

Best technology

Each microservice is an isolated component. This means each microservice can be implemented in the technology best fitting to its purposes. New and innovative technologies can be introduced quickly and easily.

Easier to understand

Smaller components with a limited set of functions are easier to understand than big, complex applications. Thus, it becomes easier to get familiar with the existing components, even for new team members. Maintenance is easier and cheaper.

Relationship to business

Microservices are designed according to business needs. As microservices are smaller and self-confident modules, they better fit to business processes. The microservices can be recombined and reconfigured according to changing business needs.

Isolation and resilience

If one microservice fails, the other microservices are not directly affected and can work on. Another instance of the failed microservice can be restarted and replace the failed one.

Challenges

The list of benefits sounds very impressing. No doubt every organization wants to leverage these benefits. Sometimes microservices are announced as a new technology solving nearly all IT problems. But as is mostly the case, nothing is for free. Beneath the benefits microservices architectures also bring up some challenges. In his presentation Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned at GOTO 2016, Ruslan Meshenberg asked the audience, whether they bought something expensive with focus on the features, but without looking at the costs.

Microservice organization

Most of the benefits are only reachable, if the IT department or even better the entire organization fits in with a microservice architecture. In April 1968 Melvin Edward Conway phrases this in the IT-Magazin Datamation as follows: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” Details about possible approaches will be discussed later but in general you need an organization with small, self-responsible and cross-functional teams, which are end-to-end responsible for their services. The organization has to overcome the separation of development, maintenance and operation and even the gap between business and IT.

Dependencies vs. redundancy

By definition microservice should be loosely coupled and as independent as possible. On the other hand, you always want to implement functionalities only once. These paradigms are conflicting. If you want to implement everything only once this leads to small microservices with much dependencies. If you prioritize the independency you will have to implement some functionalities on several places. Multiple implementations lead to small differences and a high maintenance effort. A tradeoff between these two paradigms needs to be found during the design of each microservice. One way to reduce redundancies is to separate often used functionalities in libraries. But each microservice using one of these libraries is now depending on this library. If the library needs to be changed, all microservices using this library must be considered.

Dependencies by message content

Even if you connect two microservices only with sending and receiving messages there is a dependency by the content of these messages. The receiver must understand the content put in the message by the sender. If you want to replace one of the services independently you have to ensure that the service is still able to send or receive the given content. This is a restriction microservices have in common with their predecessor SOA. Together with SOA several organizations have tried to establish an enterprise data model as a common language for all services. In most cases this approach has failed because it was too complex to bring all aspects of an organization in one consistent data model. Even if the structure of the content stays the same, problems may occur, if the sender stops to send an attribute which is mandatory for the receiver. This challenge remains, if you put a messaging system like Kafka between these two microservices.

Dependencies by interfaces

Because of these performance requirements it will often be necessary to connect microservice synchronously via direct representational state transfer (REST) calls. The resulting dependencies must be managed like the past the dependencies between SOA components. Changes must be organized with different versions of each interface. Teams providing interfaces should talk with teams consuming these interfaces. There should be a clean-up process to reduce the number of old versions by switching dependent microservices to newer versions.

Orchestration

As microservices are small components, the implementation of a complex system quickly results in a large number of microservices. Especially if you design very small microservices to prevent double implementations of functionalities, the number of microservices will rise quickly. With a lot of services and a lot of dependencies it can get difficult to orchestrate them in a way, that they will be working smoothly together. Thus, each issue, already known from independent processes and tasks – like deadlock, concurrency or cascading errors – may arise here as well. In his article Spotify's Journey to the Cloud Ramon van Alteren explains, that a single user request involves 10 to 15 services.

Availability

Possible cascading errors will bring down the system resilience, if each microservice calls up other microservices without an appropriate error handling and default behavior. In his article Mastering Chaos – A netfilx Guide to Microservices Josh Evans explains how dependencies between services influence the overall availability. If there is a main service relying on 9 different complements (App1-9) and each component has an availability of 99,99% this results in 99,9% availability of the main service. This is a big difference.

Latency

As part of the orchestration the overall response time of a microservice must be checked. This is the sum of the response times of all called-up microservices. This may be ok in an ideal test situation. But it needs to be checked in real life situations with all parts of the system under pressure. If a messaging infrastructure is used, this infrastructure and the underlying network must be as well considered. A fine-grained monitoring used in all environments should be used to identify critical situations as early as possible. Because of the response time requirements, mostly synchronous API communication is used instead of asynchronous message communication. But even with API connections the latency must be checked.

Different technologies

It is often recommended that a team responsible for a service can choose the technologies they deem most suitable for implementing their service. As a consequence, you may have a lot of different technologies in your organization. It will be difficult to maintain a repository of all the different technologies including different versions to make sure that the organization is compliant with all licenses. Moreover, in a critical situation it is not possible to move a member of a team not working to capacity to another team because the person in question will most likely not have enough experience in the required technologies.

Infrastructure services

In solution development there are a lot of common infrastructure services needed in nearly every solution. Most prominent are logging and monitoring. But often security and persistence are further examples. If each team solves these tasks differently for their services, there will be a lot of redundancies. But even harder if there are different logging and monitoring solutions, it is very difficult or impossible to build an over-all health monitoring and meaningful error logging.

Unified user experience

According to the microservice approach even the user interface (UI) is composed out of different independent microservices developed and owned by different teams. The UI microservices are not interacting directly with each other. They are coupled by using the same underlying business logic microservices or the same data storage. Under these circumstances special guidelines and tests are needed to gain a seamless unified end user experience.

Testing

Testing a bunch of microservices is a complex task. Testing one microservice with its small portion of functionalities is easy. These tests are like unit tests for classes or components. But the integration tests of multiple dependent microservices gets complex because the information flow comprises so many situations and variances. The combination of the situations and variances leads to a very large number of test cases for a full test coverage. Together with the heavy use of asynchronous communication it is practically impossible to cover all situations which may occur later in production. As a result of independent deployments of different teams, it is practically impossible to maintain a test environment similar to the production environment.

No shared data storage vs. no data duplication

On one hand the paradigm of self-contained microservice means that every microservice should have its own data storage not directly accessed by any other microservices. To fulfill their functionalities some microservices will require a copy of at least some data already stored in the data base of another microservice. Most of the time the microservice needing a copy will build this copy consuming the messages of another microservice. This data redundancies can lead to data inconsistencies and the question what the truth is. This may get worth because of different times the different microservices receive and integrate the messages in their data storage. In some cases, it may be necessary to hold critical data only once and share them between different microservices or at least have a clear master-slave-relation and mechanisms to detect and fix inconsistencies.

Next post: Microservices - Netflix

References

Martin Fowler, Microservices, 25.03.2014, https://martinfowler.com/articles/microservices.html, found 04.07.2019

Martin Fowler, Microservice, 20.07.2014, https://www.youtube.com/watch?v=wgdBVIX9ifA, found 30.07.2019

Open Group, Microservices Architecture – What is a Microservices Architecture?, release date unknown, https://www.opengroup.org/soa/source-book/msawp/p2.htm, found 08.07.2019

opensource.com, What are microservices?, release date unknown, https://opensource.com/resources/what-are-microservices, found 08.07.2019

Ashan Fernando, What I have learned Architecting Microservices, 29.05.2018, https://hackernoon.com/what-i-have-learned-architecting-microservices-cbccc2182530?gi=5b46849d64fd, found 30.07.2019

Christian Posta, The Real Success Story of Microservices Architectures, 26.06.2015, https://blog.christianposta.com/microservices/the-real-success-story-of-microservices-architectures/, found 30.07.2019

Kayalvizhi, Microservices Architecture – An Experience, 10.09.2019, https://blog.imaginea.com/microservices-architecture-an-experience/, found 21.08.2019

Jimmy Bogard, Avoiding Microservice Megadisasters, 06.04.2017, https://www.youtube.com/watch?v=gfh-VCTwMw8, found 21.08.2019

Rodrigue Schaefer, From Monolith to Microservices at Zalando, 08.08.2016, https://www.youtube.com/watch?v=gEeHZwjwehs, found 21.08.2019

Christoph Moser [REWE International], On the road from Monolith to Micro, 02.06.2016, https://www.youtube.com/watch?v=OXRXaPj9Mao, found 05.07.2019

David Schmitz [Senacor], 10 Tips for failing badly at Microservices, 30.08.2017, https://www.youtube.com/watch?v=X0tjziAQfNQ, found 05.07.2019

Christian Posta [Red Hat], The hardest part of microservices is your data, 15.05.2017 https://www.youtube.com/watch?v=MrV0DqTqpFU, found 05.07.2019

Matt, Ranney [Uber], What Comes after Microservices?, 20.10.2017, https://www.youtube.com/watch?v=UDC3kwkBvkA, found 05.07.2019

Sheffi Ben-Hutta [coverage], China Continent Insurance Partners With eBaoTech, 05.08.2019, https://www.coverager.com/china-continent-insurance-partners-with-ebaotech/, found 30.09.2019