Microservice architectural style

e term microservice is not clearly defined in the literature yet. e British software engineer Martin Fowler (2014) describes it as follows:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and com-municating with lightweight mechanisms, often an HTTP resource API. ese services are built around business capabilities and independently deployable by fully automated deployment machinery. ere is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

According to this, an application based on microservices is—as opposed to a large monolith—

split into small pieces acting in concert to serve a larger purpose. Each of these pieces is developed, maintained, and deployed independently. Microservices have the following characteristics:

Size and focus. Each microservice typically serves one specific purpose. For example, a distrib-uted system used in a supply company may contain a service for customer management, one for stock management, and another one for the processing of orders. e boundaries between mi-croservices are often drawn along so-called Bounded Contexts which are identified while specifying the application’s architecture using Domain-driven Design as described by Evans (2003).

Independence. Microservices are separated from each other or autonomous (Newman, 2015).

ey run in their own processes—often even in separate virtual machines or containers. ey offer interfaces to other services and communicate through lightweight protocols such as an HTTP API as described above. e fact that they run in their own processes also means they are sepa-rated programs and projects. ey are developed independently and often by different people or teams. ese teams use the technologies and programming languages they are familiar with but not necessarily the same as other teams working on the same distributed application. One of the biggest advantages of this separation is the fact that microservices can be deployed to production independently. is means new features and bug fixes can be made available to customers in a short amount of time and without affecting the overall availability of the distributed application.

Scalability and fault tolerance. Modern distributed applications need to be scalable to be able to handle large amounts of users and data. ey also need to be resilient to external influences such as a quickly growing number of customers (e.g. on busy shopping days such as the Black Friday in the U.S. or before Christmas), as well as failing components (e.g. broken hardware, unstable network connection or crashed software components). Microservices can help implement a scal-able and resilient system. ey are deployed in a distributed manner and typically redundantly.

Peaks in demand can be handled by adding more service instances. If one of them should fail or become unavailable—for whatever reason—other instances can take over. In any case, even if all instances of a microservice should fail, the impact on the rest of the application is minimized.

Organisational patterns. According to Conway’s Law, “organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations” (Conway, 1968). is means the architecture of any software mirrors the structure of the organization developing it. For example, if you assign five teams to develop a distributed application you will most likely get an architecture consisting of five different services communicating with each other. Microservices match this concept very well. As described above, they are developed independently by different teams. Each team is responsible for one or more microservices, but one service never falls into the responsibility of more than one team. In projects where many parties provide services, this approach helps keep responsibilities clear and enables distributed collaboration.

Composability. Microservices are composable and replaceable. Multiple microservices act in concert and make up a larger application. Single services may be reused in different applications or in different areas of the same application. In addition, since microservices are small and serve only one purpose they can be easily replaced, for example, if they are updated to a new technology stack, or if a newer service version provides an improved algorithm or better security.

e microservice architectural style is quite similar to the approach of a Service-Oriented Ar-chitecture. ere are subtle differences, particularly in terms of the actual implementation of a distributed application and guidelines for how to design the architecture. Sam Newman (2015, p. 9, first paragraph) summarises the differences as follows:

e microservice approach has emerged from the real-world use, taking our better understanding of systems and architecture to do SOA well. So you should instead think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.

A microservice architecture is therefore a Service-oriented Architecture. e difference is most apparent in the way services are deployed and executed. While SOA defines that an application should consist of services, it does not define how they should be run. In an SOA services may still be part of a single monolithic application (often running inside an application container such

as Apache Tomcat) whereas the microservice architectural style demands that these services must run in separate processes and be deployed independently. e microservice approach therefore goes one step further and gives guidance and concrete instructions in areas where SOA is lacking clarity (Newman, 2015).

In a microservice architecture a middleware layer does not play such an important role as in an SOA. If necessary, an ESB can still be used—but it is not required—which allows developers to create more flexible and arbitrary networks of services. e microservice architectural style also does not specify policies and business processes that enterprises must follow. It is therefore a more lightweight approach than a full-fledged SOA and mostly applies at the technical level without impinging on the way companies conduct their business.

While the microservice approach has many advantages, it also comes with a couple of draw-backs. For example, the application’s complexity increases with the growing number of services.

is problem is known from monolithic applications whose complexity increases with the num-ber of classes or components, but is further aggravated by the fact that the services are distributed and have to communicate over a network that may be unreliable (see Deutsch, 1994).

e complexity can be tackled by decomposing an application vertically according to bounded contexts. Figure 2.2 compares a typical monolithic application to a software architecture based on microservices. e standard way to implement a monolithic application is to divide it into three tiers, namely the data tier, the logic tier and the presentation tier (Figure 2.2a). An application based on Microservices is a set of loosely coupled services communicating with each other (Fig-ure 2.2b). e larger the application becomes, the more important it will be to order the services.

Figure 2.2c shows how an application can be decomposed vertically along bounded contexts. at means that services belonging to the same context (such as those managing customers, stock and orders, as well as those dealing with employees and internal accounting) should be grouped and only a couple of services are allowed to communicate with services from other bounded contexts.

For our work, the microservice architecture style is beneficial as it allows us to create a system that is very flexible, scalable and fault-tolerant. As we will show in Section 2.3.1, services in our architecture can be developed by teams distributed over multiple countries. e microservice ar-chitectural style allows these teams to work independently and yet integrate their services into a single system. Furthermore, microservices can be reused and composed in different ways in order to satisfy varying requirements. is property is essential for our work, because it allows us to orchestrate services to complex spatial processing workflows.

Presentation tier

a) A monolithic software with a standard three-tier architecture

b) A pure microservice architec-ture with a complex deployment

c) A microservice architecture de-composed along bounded contexts Figure 2.2 Comparing a monolithic software architecture with

two approaches to system decomposition based on microservices