What is Mi­croser­vice Ar­chi­tec­ture?

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 “mi­croser­vices”. The term does not just have to do with computer ap­pli­ca­tion structure, it also plays an important role in planning when it comes to agile project man­age­ment. What are the ad­van­tages of mi­croser­vice ar­chi­tec­ture, how does it work, and where is the tech­nol­o­gy already being used?

There is no clear, uniform de­f­i­n­i­tion of what mi­croser­vices are. It is not just software tech­nol­o­gy, it is also developer method­ol­o­gy: what is the best way to succeed with a large pro­gram­ming project? As a general rule, projects that are con­sid­ered to be “mi­croser­vices” follow Ken Thompson’s Unix phi­los­o­phy: “Do one thing and do it well”. This can be sum­ma­rized as: focus on one task, and perfect it. This statement is not just relevant to pro­gram­ming, but also describes the func­tion­al­i­ty of in­di­vid­ual mi­croser­vices.

In terms of program de­vel­op­ment, small teams should be created to take care of in­di­vid­ual services – this is im­ple­ment­ing a mi­croser­vice. As a project manager, you would need to focus teams and highlight their in­de­pen­dence. Instead of being centrally ad­min­is­tered, each team is fully re­spon­si­ble for their end product through­out the entire de­vel­op­ment cycle: from creation to delivery and sub­se­quent mon­i­tor­ing. This method of working has many ad­van­tages and results in a modular software ar­chi­tec­ture.

Mi­croser­vice ar­chi­tec­ture is basically a further de­vel­op­ment of service-oriented ar­chi­tec­ture (SOA): small services also play a role in this ar­chi­tec­tur­al pattern. However, these are still embedded in a large system and are not as in­de­pen­dent as you might hope. Just like there is no clear de­f­i­n­i­tion for the former, SOA is quite a vague term. Tran­si­tions between the two patters are therefore very fluid.

Tra­di­tion­al program de­vel­op­ment works according to monolith prin­ci­ples: all tasks are un­der­tak­en in one large project. All in­di­vid­ual services access a large database and are output through a user interface – every­thing is done in one ap­pli­ca­tion. The mi­croser­vices approach is based on modules: each mi­croser­vice is re­spon­si­ble for com­plet­ing a simple task. Each work process is vastly different, as are often the results.

When it comes to mi­croser­vice ar­chi­tec­ture, each team is re­spon­si­ble for their own mi­croser­vice, whereas the structure is very different with monoliths. Teams are organized according to the tech­nol­o­gy they deal with: one team deals with databases, another one programs the in­di­vid­ual services, and a third one deals with the design of a user interface. Other working groups are re­spon­si­ble for pub­lish­ing updates, main­te­nance, and analysis. However, all teams in a monolith are in­ter­de­pen­dent. De­pen­den­cies in mi­croser­vice ar­chi­tec­ture should be avoided as much as possible.

With mi­croser­vice ar­chi­tec­ture, a large project is un­der­tak­en through small, mono-func­tion­al modules (mi­croser­vices). The building blocks them­selves are developed in­de­pen­dent­ly of each other and together form the overall product. This ar­chi­tec­tur­al style has several ad­van­tages.

When de­vel­op­ing a mi­croser­vice, teams generally operate with complete autonomy. There is no superior authority giving them direction, and each in­di­vid­ual project group does not have to co­or­di­nate with others. The teams just focus on the given task at hand. There is an advantage to working this way: The de­vel­op­ment team can choose the solution that best suits their own mi­croser­vice approach, not the one that others have given. This could even mean that teams use different pro­gram­ming languages, databases, or database man­age­ment systems for different mi­croser­vices. Doing this is possible because each mi­croser­vice has its own runtime en­vi­ron­ment.

Another advantage of this level of in­de­pen­dence is that the complete system becomes more robust. If a mi­croser­vice fails, the entire ap­pli­ca­tion will not crash, just the one aspect that is ex­pe­ri­enc­ing issues. Since the process is so straight­for­ward, it also makes trou­bleshoot­ing much easier: instead of searching for the issue through all the source code of a large, monolith project, you just need to analyze a rel­a­tive­ly small, self-contained program.

In this context, con­tin­u­ous delivery also deserves a mention, since software products are con­stant­ly being developed and worked on. Mi­croser­vices give man­u­fac­tur­ers the option of not having to update in large stages, instead updating mi­croser­vice de­vel­op­ments con­tin­u­al­ly as they occur, in­de­pen­dent­ly of the remaining processes. Making even minor changes to a monolith project can be very expensive. It is much easier to manage a mi­croser­vice that just has one task, since it consumes far fewer resources.

Con­tin­u­ous delivery also benefits from a flexible working method: the team that is re­spon­si­ble for one mi­croser­vice are spe­cial­ists, 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 mi­croser­vices 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 con­nec­tions have little influence on the actual process. That’s why most mi­croser­vice de­vel­op­ers use REST APIs. Uniform, stream­lined HTTP methods like GET or POST allow in­di­vid­ual mi­croser­vices to com­mu­ni­cate and exchange in­for­ma­tion easily.

If a monolith project has to be scaled upwards, you are forced to mirror the entire system. Mi­croser­vice ar­chi­tec­ture gives de­vel­op­ers 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.

Mi­croser­vices are com­plete­ly isolated from each other, and operate in their own en­vi­ron­ment. In­di­vid­ual ap­pli­ca­tions com­mu­ni­cate with each other through specific in­ter­faces. There are various ways of isolating different services:

• Container: Perhaps one of the easiest and most common ways to build mi­croser­vice ar­chi­tec­ture is to work with con­tain­ers. Con­tain­ers are not the strongest method of vir­tu­al­iza­tion, since they do not compete virtual machines. Instead, you build on an existing operating system. With con­tain­ers, mi­croser­vices run com­plete­ly self-suf­fi­cient­ly: every­thing they need to function is inside the container.
  
  
• Virtual machines: It is possible to create a virtual machine for each mi­croser­vice. Mi­croser­vices can operate in­de­pen­dent­ly, isolated from each other in this area. However, the dis­ad­van­tage compared to container tech­nol­o­gy (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 mi­croser­vice. In practice, however, it is likely to be a major waste of resources, which is why vir­tu­al­iza­tion is used instead. However, it is important that isolation is a key feature of whatever option you choose. It is not rec­om­mend­ed to run several mi­croser­vices on one server, nor to put them together in one container, as this could lead to conflicts between the in­di­vid­ual ap­pli­ca­tions. A Load Balancer can be used to prevent overloads in the entire system. These au­to­mat­i­cal­ly dis­trib­ute the load among different instances to prevent failures.

Mi­croser­vice ar­chi­tec­ture has now found its way into large company systems. The companies have sub­se­quent­ly been able to fix certain problems or optimize their processes. Examples like Netflix, Spotify, and eBay show large companies with es­tab­lished mono­lith­ic systems changing to a mi­croser­vice 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 mono­lith­ic 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 mi­croser­vices. 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 enor­mous­ly extensive, a separate program was developed to organize the in­di­vid­ual mi­croser­vices among them­selves: Conductor. Conductor grants Netflix central control to pause, restart or scale their mi­croser­vices. The core of the program is a service called Decider. It can plan processes au­to­mat­i­cal­ly and react to events in the workflow. Other programs developed by Netflix to work ef­fec­tive­ly with their mi­croser­vices are Mantis (stream pro­cess­ing), Dynomite (data storage) and Vizceral (traffic intuition).

The streaming service Spotify also relies on mi­croser­vices. Spotify’s main daily de­vel­op­ment challenge is keeping ahead of the strong com­pe­ti­tion. 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 in­creas­ing number of users, Spotify de­vel­op­ers are con­stant­ly having to meet higher demands and comply with certain business rules (like licensing rights). Mi­croser­vices are a good solution for Spotify, allowing them to react quickly to new de­vel­op­ments their com­peti­tors might make, and publish their own de­vel­op­ments faster – forcing the com­peti­tors to react in turn.

For example, the Spotify feature that rec­om­mends sug­ges­tions to users when they type in a search term is a self-contained mi­croser­vice that has its own dedicated team working on it. Ad­di­tion­al­ly, Spotify benefits from the robust nature of mi­croser­vice ar­chi­tec­ture: if a single mi­croser­vice fails, it does not mean that the entire product becomes unusable. There are more than 800 mi­croser­vices active within Spotify, and they use Java for a large part of those mi­croser­vices. However, this has nothing to do with the fact that mi­croser­vices cannot be written in different pro­gram­ming languages: instead, it has to do with work processes. De­vel­op­ers con­stant­ly 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 mi­croser­vices instead. In­di­vid­ual eBay services also use REST to com­mu­ni­cate with one another.

The fact that eBay and other companies have suc­cess­ful­ly gone from a mono­lith­ic to mi­croser­vice ar­chi­tec­ture is a clear sign of the benefits of a more modern approach. While the monolith structure is perfectly suf­fi­cient in the early days of a website, with a small number of active users and a man­age­able range of products, it can become growth-in­hibit­ing when demands start to increase.

Although there is plenty to be said for building systems based on mi­croser­vice ar­chi­tec­ture, the modern approach is not nec­es­sar­i­ly always the right one for every company or website. Mi­croser­vices can create un­nec­es­sary effort for smaller programs, which only have a few tasks to deal with. Not just creating services, but also main­te­nance, further de­vel­op­ing, and mon­i­tor­ing can be com­par­a­tive­ly complex. When it comes to mon­i­tor­ing processes (mon­i­tor­ing), you need to carefully consider whether or not they are worse off with mi­croser­vices: on the one hand, in­di­vid­ual mi­croser­vices are very easy to analyze and measure, but when mi­croser­vices start to build up, this task grows con­sid­er­ably.

When taking work process ad­van­tages into con­sid­er­a­tion, it becomes clear that mi­croser­vices are not sensible for every website, es­pe­cial­ly in the short term. One advantage of working with mi­croser­vices is in­de­pen­dence for each team – you want to make sure that they can work in­de­pen­dent­ly and not have to wait on others. However, if the entire de­vel­op­ment team consists of just a few people, creating this sep­a­ra­tion doesn’t make a lot of sense. Ad­di­tion­al­ly, if you follow Conway’s law, a small team which is undivided can ac­com­plish a lot and may still achieve a different result.

There is also a need for major change for larger teams: Positions that control de­vel­op­ment centrally are in­creas­ing­ly being elim­i­nat­ed in favor of de­vel­op­ment teams or­ga­niz­ing them­selves. This kind of re­struc­tur­ing is time consuming and costly, and should be taken into con­sid­er­a­tion before any system changes are made.

Some mi­croser­vice ar­chi­tec­ture advocates therefore recommend a mono­lith­ic structure first. It makes sense to approach pro­gram­ming a website as a monolith and take advantage of the structure in the early days. Once your website has gained suf­fi­cient scope, you can change to a mi­croser­vice ar­chi­tec­ture. There is also the in­ter­me­di­ary service oriented ar­chi­tec­ture (SOA), which is a good middle step. This ar­chi­tec­ture is also modular in structure. In­di­vid­ual services map business processes.