Chapter 15. Getting Started with Microservices

As a conclusion to the book, this chapter helps you think about how to get started with microservices. Section 15.1 enumerates the different advantages of microservices once more to illustrate that there is not only a single reason to introduce microservices but several. Section 15.2 describes several ways for introducing microservices—depending on the use context and the expected advantages. Section 15.3 finally follows up on the question of whether microservices are more than just hype.

• Microservices make it easier to implement agility for large projects since teams can work independently.

• Microservices can help to supplement and replace legacy applications stepwise.

• Microservice-based architectures make possible sustainable development since they are less susceptible to architecture decay and because individual microservices can be easily replaced. This increases the long-term maintainability of the system.

• In addition, there are technical reasons for microservices such as robustness and scalability.

To prioritize these advantages and the additional ones mentioned in Chapter 4 should be the first step when considering the adaptation of a microservice-based architecture. Likewise, the challenges discussed in Chapter 5, “Challenges,” have to be evaluated and, where necessary, strategies for dealing with these challenges have to be devised.

Continuous delivery and infrastructure play a prominent role in this context. If the deployment processes are still manual, the expenditure for operating a large number of microservices is so high that their introduction is hardly feasible. Unfortunately, many organizations still have profound weaknesses, especially in the area of continuous delivery and infrastructure. In such a case continuous delivery should be introduced alongside microservices. Since microservices are much smaller than deployment monoliths, continuous delivery is also easier with microservices. Therefore, both approaches have synergies.

In addition, the organizational level (Chapter 12, “Organizational Effects of a Microservices-Based Architecture”) has to be taken into account. When the scalability of agile processes constitutes an important reason for introducing microservices, the agile processes should already be well established. For example, there has to be a product owner per team who also decides about all features as well as agile planning. The teams should also be already largely self-reliant—otherwise in the end they might not make use of the independence microservices offer.

Introducing microservices can solve more than just one problem. The specific motivation for microservices will differ between projects. The large number of advantages can be a good reason for introducing microservices on its own. In the end the strategy for introducing microservices has to be adapted to the advantages that are most important in the context of a specific project.

• The most typical scenario is to start out with a monolith that is converted stepwise into a multitude of microservices. Usually, different functionalities are transferred one by one into microservices. A driving force behind this conversion is often the wish for an easier deployment. However, independent scaling and achieving a more sustainable architecture can also be important reasons.

• However, migrating from a monolith to microservices can also occur in a different manner. When, for instance, resilience is the main reason for switching to microservices, the migration can be started by first adding technologies like Hystrix to the monolith. Afterwards the system can be split into microservices.

• Starting a microservice-based system from scratch is by far the rarer scenario. Even in such a case a project can start by building a monolith. However, it is more sensible to devise a first coarse-grained domain architecture that leads to the first microservices. Thereby an infrastructure is created that supports more than just one microservice. This approach also enables teams to already work independently on features. However, a fine-granular division into microservices right from the start often does not make sense because it will probably have to be revised again later on. Introducing the necessary profound changes into an already existing microservices architecture can be highly complex.

Microservices are easy to combine with existing systems, which facilitates their introduction. A small microservice as supplement to an existing deployment monolith is rapidly written. If problems arise, such a microservice can also be rapidly removed again from the system. Other technical elements can then be introduced in a stepwise manner.

The easy combination of microservices with legacy systems is an essential reason for the fact that the introduction of microservices is quite simple and can immediately result in advantages.

However, the interest in microservices is more than just a fashion or hype:

• As described in the introduction, Amazon has been employing microservices for many years. Likewise, many Internet companies have been following this approach for a long time. Therefore, microservices are not just fashionable but have already been used for a long time behind the scenes in many companies before they became fashionable.

• For the microservice pioneers the advantages associated with microservices were so profound that they were willing to invest a lot of money into creating the not-yet-existing necessary infrastructures. These infrastructures are nowadays available free of cost as Open Source—Netflix is a prominent example. Therefore, it is much easier nowadays to introduce microservices.

• The trend towards agility and cloud infrastructures is suitably complemented by microservices-based architectures: They enable the scaling of agility and fulfill the demands of the Cloud in regards to robustness and scalability.

• Likewise, microservices as small deployment units support continuous delivery, which is employed by many enterprises to increase software quality and to bring software more rapidly into production.

• There is more than one reason for microservices. Therefore, microservices represent an improvement for many areas. Since there is not a single reason for the introduction of microservices but a number of them, it is more likely that even very diverse projects will really benefit from switching to microservices in the end.

Presumably, everybody has already seen large, complex systems. Maybe now is the time to develop smaller systems and to profit from the associated advantages. In any case there seem to be only very few reasons arguing for monoliths—except for their lower technical complexity.

• There is a plethora of advantages (discussed in section 15.1 and Chapter 4).

• The way to microservices is evolutionary. It is not necessary to start adopting microservices for the whole system from the beginning. Instead, a stepwise migration is the usual way (section 15.2). Many different approaches can be chosen in order to profit as quickly as possible from the advantages microservices offer.

• The start is reversible: If microservices prove not to be suitable for a certain project, they can easily be replaced again.

• Microservices are clearly more than a hype (section 15.3). For being just a hype they have been in use for too long and have been too broadly adapted. Therefore, one should at least experiment with microservices—and this books invites the reader to do just that in many places.