Microservice architectures: more than the sum of their parts?

There are several ways to build software. Instead of looking at the project as a whole, it may make more sense to divide up tasks and lump others together – these are known as “microservices”. The term does not just have to do with computer application structure, it also plays an important role in planning when it comes to agile project management. What are the advantages of microservice architecture, how does it work, and where is the technology already being used?

There is no clear, uniform definition of what microservices are. It is not just software technology, it is also developer methodology: what is the best way to succeed with a large programming project? As a general rule, projects that are considered to be “microservices” follow Ken Thompson’s Unix philosophy: “Do one thing and do it well”. This can be summarized as: focus on one task, and perfect it. This statement is not just relevant to programming, but also describes the functionality of individual microservices.

In terms of program development, small teams should be created to take care of individual services – this is implementing a microservice. As a project manager, you would need to focus teams and highlight their independence. Instead of being centrally administered, each team is fully responsible for their end product throughout the entire development cycle: from creation to delivery and subsequent monitoring. This method of working has many advantages and results in a modular software architecture.

Microservice architecture is basically a further development of service-oriented architecture (SOA): small services also play a role in this architectural pattern. However, these are still embedded in a large system and are not as independent as you might hope. Just like there is no clear definition for the former, SOA is quite a vague term. Transitions between the two patters are therefore very fluid.

Traditional program development works according to monolith principles: all tasks are undertaken in one large project. All individual services access a large database and are output through a user interface – everything is done in one application. The microservices approach is based on modules: each microservice is responsible for completing a simple task. Each work process is vastly different, as are often the results.

When it comes to microservice architecture, each team is responsible for their own microservice, whereas the structure is very different with monoliths. Teams are organized according to the technology they deal with: one team deals with databases, another one programs the individual services, and a third one deals with the design of a user interface. Other working groups are responsible for publishing updates, maintenance, and analysis. However, all teams in a monolith are interdependent. Dependencies in microservice architecture should be avoided as much as possible.

With microservice architecture, a large project is undertaken through small, mono-functional modules (microservices). The building blocks themselves are developed independently of each other and together form the overall product. This architectural style has several advantages.

When developing a microservice, teams generally operate with complete autonomy. There is no superior authority giving them direction, and each individual project group does not have to coordinate with others. The teams just focus on the given task at hand. There is an advantage to working this way: The development team can choose the solution that best suits their own microservice approach, not the one that others have given. This could even mean that teams use different programming languages, databases, or database management systems for different microservices. Doing this is possible because each microservice has its own runtime environment.

Another advantage of this level of independence is that the complete system becomes more robust. If a microservice fails, the entire application will not crash, just the one aspect that is experiencing issues. Since the process is so straightforward, it also makes troubleshooting much easier: instead of searching for the issue through all the source code of a large, monolith project, you just need to analyze a relatively small, self-contained program.

In this context, continuous delivery also deserves a mention, since software products are constantly being developed and worked on. Microservices give manufacturers the option of not having to update in large stages, instead updating microservice developments continually as they occur, independently of the remaining processes. Making even minor changes to a monolith project can be very expensive. It is much easier to manage a microservice that just has one task, since it consumes far fewer resources.

Continuous delivery also benefits from a flexible working method: the team that is responsible for one microservice are specialists, and can make changes to their project without any major problems. In addition, there only needs to be one change made to the source code (a new feature or a bug fix) per version. This helps keep changes quick and therefore ensures the overall system’s stability in the long term.

In the end, all the aspects come together: as different as microservices are in terms of structure, in the end they must have common points of contact. These should be as simple as possible, so that the connections have little influence on the actual process. That’s why most microservice developers use REST APIs. Uniform, streamlined HTTP methods like GET or POST allow individual microservices to communicate and exchange information easily.

If a monolith project has to be scaled upwards, you are forced to mirror the entire system. Microservice architecture gives developers the ability to scale down to the minute detail. You just need to improve the service in need, not the whole project. This keeps the end product leaner, and saves costs. It also makes it easier to integrate a new service into the system.

Microservices are completely isolated from each other, and operate in their own environment. Individual applications communicate with each other through specific interfaces. There are various ways of isolating different services:

• Container: Perhaps one of the easiest and most common ways to build microservice architecture is to work with containers. Containers are not the strongest method of virtualization, since they do not compete virtual machines. Instead, you build on an existing operating system. With containers, microservices run completely self-sufficiently: everything they need to function is inside the container.
  
  
• Virtual machines: It is possible to create a virtual machine for each microservice. Microservices can operate independently, isolated from each other in this area. However, the disadvantage compared to container technology (like dockers) is that each virtual machine needs its own operating system and therefore requires a lot of resources.

Another possible option is to set up a separate physical server for each microservice. In practice, however, it is likely to be a major waste of resources, which is why virtualization is used instead. However, it is important that isolation is a key feature of whatever option you choose. It is not recommended to run several microservices on one server, nor to put them together in one container, as this could lead to conflicts between the individual applications.

A Load Balancer can be used to prevent overloads in the entire system. These automatically distribute the load among different instances to prevent failures.

Microservice architecture has now found its way into large company systems. The companies have subsequently been able to fix certain problems or optimize their processes. Examples like Netflix, Spotify, and eBay show large companies with established monolithic systems changing to a microservice model. Other major IT companies like Google and Amazon also work like this. Some of them were already using modular systems when there was no term for them.

Like many other companies, Netflix used to be based on a monolithic system (back when Netflix was not an online streaming service, but only sent DVDs through the mail). In 2008, there was an error in a database that caused the entire service to fail for four days. The decision was then taken to break up the old system and split them into microservices. The result was that the company was able to make live changes much faster, and repairs were carried out much more quickly. Since the Netflix system is enormously extensive, a separate program was developed to organize the individual microservices among themselves: Conductor.

Conductor grants Netflix central control to pause, restart or scale their microservices. The core of the program is a service called Decider. It can plan processes automatically and react to events in the workflow. Other programs developed by Netflix to work effectively with their microservices are Mantis (stream processing), Dynomite (data storage) and Vizceral (traffic intuition).

The streaming service Spotify also relies on microservices. Spotify’s main daily development challenge is keeping ahead of the strong competition. The audio streaming services market has some of the largest IT companies in the world as its main players – such as Amazon, Apple, and Google. Due to the increasing number of users, Spotify developers are constantly having to meet higher demands and comply with certain business rules (like licensing rights). Microservices are a good solution for Spotify, allowing them to react quickly to new developments their competitors might make, and publish their own developments faster – forcing the competitors to react in turn.

For example, the Spotify feature that recommends suggestions to users when they type in a search term is a self-contained microservice that has its own dedicated team working on it. Additionally, Spotify benefits from the robust nature of microservice architecture: if a single microservice fails, it does not mean that the entire product becomes unusable. There are more than 800 microservices active within Spotify, and they use Java for a large part of those microservices. However, this has nothing to do with the fact that microservices cannot be written in different programming languages: instead, it has to do with work processes. Developers constantly move from one team to another, and it is easier when everyone uses the same language.

Like many other large systems, the eBay sales platform began as a monolith: eBay had 3.4 million lines of code in just one file. The company then decided to break up the monolith and develop Java microservices instead. Individual eBay services also use REST to communicate with one another.

The fact that eBay and other companies have successfully gone from a monolithic to microservice architecture is a clear sign of the benefits of a more modern approach. While the monolith structure is perfectly sufficient in the early days of a website, with a small number of active users and a manageable range of products, it can become growth-inhibiting when demands start to increase.

Although there is plenty to be said for building systems based on microservice architecture, the modern approach is not necessarily always the right one for every company or website. Microservices can create unnecessary effort for smaller programs, which only have a few tasks to deal with. Not just creating services, but also maintenance, further developing, and monitoring can be comparatively complex. When it comes to monitoring processes (monitoring), you need to carefully consider whether or not they are worse off with microservices: on the one hand, individual microservices are very easy to analyze and measure, but when microservices start to build up, this task grows considerably.

When taking work process advantages into consideration, it becomes clear that microservices are not sensible for every website, especially in the short term. One advantage of working with microservices is independence for each team – you want to make sure that they can work independently and not have to wait on others. However, if the entire development team consists of just a few people, creating this separation doesn’t make a lot of sense. Additionally, if you follow Conway’s law, a small team which is undivided can accomplish a lot and may still achieve a different result.

There is also a need for major change for larger teams: Positions that control development centrally are increasingly being eliminated in favor of development teams organizing themselves. This kind of restructuring is time consuming and costly, and should be taken into consideration before any system changes are made.

Some microservice architecture advocates therefore recommend a monolithic structure first. It makes sense to approach programming a website as a monolith and take advantage of the structure in the early days. Once your website has gained sufficient scope, you can change to a microservice architecture. There is also the intermediary service oriented architecture (SOA), which is a good middle step. This architecture is also modular in structure. Individual services map business processes.