Today´s IT development is more and more driving towards faster development cycles, scalable software performance, and flexibility in terms of development and deployment. To meet those requirements, developers increasingly prefer microservices architectures. Today, microservices have become a common approach for enterprises to ensure an agile and continuous delivery of software. Moreover, they are used to meeting the growing demand of users that expect quick software improvements and differentiating new features.

 

What are Microservices?

Microservices are small and modular software programs that are designed to fulfill a particular purpose. They may be deployed independently, as a group of microservices, or as part of a platform. Although there is no common definition for what a microservice is, there are a couple of common characteristics that definitions of microservices share. Those are:

1) Microservices are small, individual, and independent components of the software that, together, make an application.

2) Microservices are business-oriented, which means that the software architecture focuses on business purposes, such as a business capability, a particular product, or service.

3) Every microservice provides a small piece of software for a greater purpose. Therefore, microservices regularly communicate with each other when in operation.

4) A major purpose of microservices is that they can be developed and deployed independently from each other. This leads to a decentralization of development teams in practice, which enables them to develop and deploy faster and with fewer dependencies and constraints.

5) Due to the modular architecture and the increased amount of communication interfaces between the microservices, errors and failures can be analyzed more precisely. In addition, microservice architectures are usually designed in such a way that they still function in the case that single microservices provide errors.

6) A microservices architecture is often used in areas that are continuously developed further. In such environments, the advantages of independent development and deployment, as well as failure tolerance are of the highest importance.

 

Advantages of Microservices

• Microservices can be reused in different contexts: A major advantage of microservices is their reusability in different contexts and environments. As every microservice provides a small and dedicated functionality, it is likely compostable in a different context and usable as a basis for different larger services.
• A microservice architecture can be easily modified: Because microservices work independently, they can easily be replaced, modified, or additional microservices can be added to the architecture. This is particularly helpful in environments where continuous changes are necessary.
• Legacy IT will not emerge: Microservices are designed to be replaceable. While many of us are aware of those old monoliths in the legacy IT that can only be replaced with big efforts and are therefore never replaced, something similar will not happen in a microservices architecture.
• True scalability is enabled: Everymicroservice is deployed individually. Therefore, they can be scaled individually according to the individual demand.
• Agility is supported: Microservices enable an organization to work with independent, flexible teams, where each team is responsible for the development of its part of the modular architecture. This allows teams to align less on internal development efforts and therefore reduces development times.
• Continuous integration and delivery are supported: Because every microservice can be deployed individually, other microservices do not fail if a new service does not work. This allows for easier testing of new concepts and functionalities, which in return reduces the time-to-market.
• Different microservices can be developed with different technologies: As microservices are deployed in containers that provide clear APIs to their environment, the microservices themselves can be developed in different tools and program languages allowing to choose the best tool and language for every task. Also, new microservices can be developed with new technologies while they can still communicate with the older microservices. With today´s pace of technological changes, this is a huge advantage.
• Microservices are tighter aligned to business capabilities: Microservices usually provide individual capabilities that the business needs. As microservices can be developed, prioritized, and managed individually, they enable a greater alignment with business strategies.
• A microservices architecture is less likely to experience a complete service failure: As microservices can flexibly communicate with different microservices and can still be deployed if other microservices fail, a microservice architecture as a whole is less likely to experience a complete failure. If, for instance, the microservice to sell a product on a bidding platform fails, the microservice for submitting a bid might still work.

 

Disadvantages of Microservices

• Higher complexity: An architecture of microservices shows a much higher complexity compared to traditional architectures. Every microservice is designed in a way that it can be deployed independently from other services, leading to functionalities that are duplicated for every microservice. Also, integration and communication into the modular architecture need to be managed and tested. Compared to traditional monolithic architecture, this leads to overhead and complexity that is exponentially increasing with the number of microservices in an architecture.
• Must be integrated with existing architecture: Most microservice architectures emerge in new, digital programs that have the goal to transform an organization. At first, these programs assume that they can start on the green field, i.e. without any existing architecture to consider, but usually, they recognize later during the program that there are required interfaces to the existing architecture. That integration into existing architecture remains a very common challenge that can also reduce the benefits of microservices, such as the flexibility and agility of a microservices architecture.
• Lower stability: Individual microservices have a narrow functional scope and are usually well tested and work quite stable. However, as microservices are usually deployed in groups and as an environment of different microservices interacting with each other, the number of possible interactions and communications increases exponentially. With that exponential increase, the testability also decreases. Hence, while a single microservice will be quite stable, an environment of microservices might be less stable.
• Lower security: An environment of microservices is full of APIs that ensure that the microservices can communicate with each other – in contrast to a monolith that has only a few to no interfaces to the outside world. The high amount of APIs, however, also provides hackers with an increased potential for penetrating the environment. This threat even increases if the location of the microservices is not always clear, if they do not follow the same development principles, or if they have very different quality levels.
• High effort to transform existing architecture into microservices: Microservices might be a great way to start building new software architectures. However, transforming an existing, monolithic architecture into a modular, microservices-based architecture requires a lot of effort and resources. Because many monolithic applications were not built to be modularized one day, it can even be easier to build them from scratch in a modular way instead of cutting the existing software into pieces of modular software and enabling communication between them via microservices.
• Requires excellent API management and documentation: Microservices can only add value to architectures if they can communicate with the other microservices and if they can be well integrated into existing microservices architectures. To enable this, a common, managed and maintained set of principles and standards for the Application Program Interfaces (APIs) is a must. Also, all APIs of all microservices must be documented and provided to teams working on other microservices.
• Higher maintenance costs due to potentially different programming languages: While microservices can be coded in different programming languages, this also requires that organizations maintain the resources and skills for every programming language that they once used for developing a microservice. Generally, this is expected to lead to higher maintenance costs.
• Requires more computing resources: As microservices run independently in their containers and every container inherits all necessary functionalities for the microservice to be deployed, a microservices architecture needs a higher amount of memory and GPU. Given that modern cloud providers usually apply a pricing model based on pay-per-use, a microservices architecture will produce higher operational costs compared to traditional architecture.
• The number of microservices and connections increases the response time: As the amount of software, the required computing resources, and the communication between the microservices is increased, the total response time of a microservice architecture also increases.
• It is a rather new approach, but requires experienced developers: Due to the mentioned complexity, the continuous development, integration, and operation of software also becomes more complex and requires well-aligned and experienced DevOps teams. However, as microservices architectures are a rather new concept, there are only a few people with deep experience.

 

When should someone build a microservices architecture?

Given the advantages and disadvantages of microservices, it seems that there are environments in which it makes sense to apply them and environments in which it does not make sense. It is therefore important to note that a microservices architecture is not the best solution every time. Let´s summarize in which cases microservices architectures are beneficial:

1)  It is expected that the demand for the services of architecture and in particular for single services is varying a lot or it is expected that a large scaling is required in the future.

2)  A fast delivery of new features is required, such as implementing new services that help to react to market changes.

3)  The architecture will need to be regularly changed in the future, adding, modifying, or removing features and services.

4)  Continuous improvements are necessary as the technology in that area is currently not matured and still rapidly evolving.

5)  Security is not a top priority. For instance should a microservice architecture not be applied to services that deal with sensitive health data or even unsecured passwords.

6)  Operating speed is not a top priority. For instance should a microservice architecture not be applied to services where milliseconds can decide about success or failure such as selling or not selling a service.

The long-term integration need with traditional architecture is reasonably low. Remember that the integration of microservices architecture with traditional architecture is a tedious task, based on how microservices communicate. That can require a lot of effort and that can reduce the benefits of the actual microservices architecture. One should therefore first analyze what a realistic to-be state would look like.