What is Mi­croservice 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­croservices”. The term does not just have to do with computer ap­plic­a­tion structure, it also plays an important role in planning when it comes to agile project man­age­ment. What are the ad­vant­ages of mi­croservice ar­chi­tec­ture, how does it work, and where is the tech­no­logy already being used?

There is no clear, uniform defin­i­tion of what mi­croservices are. It is not just software tech­no­logy, it is also developer meth­od­o­logy: what is the best way to succeed with a large pro­gram­ming project? As a general rule, projects that are con­sidered to be “mi­croservices” follow Ken Thompson’s Unix philo­sophy: “Do one thing and do it well”. This can be sum­mar­ised 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­ity of in­di­vidu­al mi­croservices.

In terms of program de­vel­op­ment, small teams should be created to take care of in­di­vidu­al services – this is im­ple­ment­ing a mi­croservice. As a project manager, you would need to focus teams and highlight their in­de­pend­ence. Instead of being centrally ad­min­istered, each team is fully re­spons­ible for their end product through­out the entire de­vel­op­ment cycle: from creation to delivery and sub­sequent mon­it­or­ing. This method of working has many ad­vant­ages and results in a modular software ar­chi­tec­ture.

Mi­croservice 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­pend­ent as you might hope. Just like there is no clear defin­i­tion for the former, SOA is quite a vague term. Trans­itions between the two patters are therefore very fluid.

Tra­di­tion­al program de­vel­op­ment works according to monolith prin­ciples: all tasks are un­der­taken in one large project. All in­di­vidu­al services access a large database and are output through a user interface – everything is done in one ap­plic­a­tion. The mi­croservices approach is based on modules: each mi­croservice is re­spons­ible for com­plet­ing a simple task. Each work process is vastly different, as are often the results.

When it comes to mi­croservice ar­chi­tec­ture, each team is re­spons­ible for their own mi­croservice, whereas the structure is very different with monoliths. Teams are organised according to the tech­no­logy they deal with: one team deals with databases, another one programs the in­di­vidu­al services, and a third one deals with the design of a user interface. Other working groups are re­spons­ible for pub­lish­ing updates, main­ten­ance, and analysis. However, all teams in a monolith are in­ter­de­pend­ent. De­pend­en­cies in mi­croservice ar­chi­tec­ture should be avoided as much as possible.

With mi­croservice ar­chi­tec­ture, a large project is un­der­taken through small, mono-func­tion­al modules (mi­croservices). The building blocks them­selves are developed in­de­pend­ently of each other and together form the overall product. This ar­chi­tec­tur­al style has several ad­vant­ages.

When de­vel­op­ing a mi­croservice, teams generally operate with complete autonomy. There is no superior authority giving them direction, and each in­di­vidu­al project group does not have to co­ordin­ate 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­croservice 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­croservices. Doing this is possible because each mi­croservice has its own runtime en­vir­on­ment.

Another advantage of this level of in­de­pend­ence is that the complete system becomes more robust. If a mi­croservice fails, the entire ap­plic­a­tion will not crash, just the one aspect that is ex­per­i­en­cing issues. Since the process is so straight­for­ward, it also makes troubleshoot­ing much easier: instead of searching for the issue through all the source code of a large, monolith project, you just need to analyse a re­l­at­ively small, self-contained program.

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

Con­tinu­ous delivery also benefits from a flexible working method: the team that is re­spons­ible for one mi­croservice 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­croservices 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­croservice de­velopers use REST APIs. Uniform, stream­lined HTTP methods like GET or POST allow in­di­vidu­al mi­croservices to com­mu­nic­ate and exchange in­form­a­tion easily.

If a monolith project has to be scaled upwards, you are forced to mirror the entire system. Mi­croservice ar­chi­tec­ture gives de­velopers 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­croservices are com­pletely isolated from each other, and operate in their own en­vir­on­ment. In­di­vidu­al ap­plic­a­tions com­mu­nic­ate 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­croservice ar­chi­tec­ture is to work with con­tain­ers. Con­tain­ers are not the strongest method of vir­tu­al­isa­tion, since they do not compete virtual machines. Instead, you build on an existing operating system. With con­tain­ers, mi­croservices run com­pletely self-suf­fi­ciently: everything they need to function is inside the container.
  
  
• Virtual machines: It is possible to create a virtual machine for each mi­croservice. Mi­croservices can operate in­de­pend­ently, isolated from each other in this area. However, the dis­ad­vant­age compared to container tech­no­logy (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­croservice. In practice, however, it is likely to be a major waste of resources, which is why vir­tu­al­isa­tion is used instead. However, it is important that isolation is a key feature of whatever option you choose. It is not re­com­men­ded to run several mi­croservices on one server, nor to put them together in one container, as this could lead to conflicts between the in­di­vidu­al ap­plic­a­tions. A Load Balancer can be used to prevent overloads in the entire system. These auto­mat­ic­ally dis­trib­ute the load among different instances to prevent failures.

Mi­croservice ar­chi­tec­ture has now found its way into large company systems. The companies have sub­sequently been able to fix certain problems or optimise their processes. Examples like Netflix, Spotify, and eBay show large companies with es­tab­lished mono­lith­ic systems changing to a mi­croservice 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­croservices. 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 enorm­ously extensive, a separate program was developed to organise the in­di­vidu­al mi­croservices among them­selves: Conductor. Conductor grants Netflix central control to pause, restart or scale their mi­croservices. The core of the program is a service called Decider. It can plan processes auto­mat­ic­ally and react to events in the workflow. Other programs developed by Netflix to work ef­fect­ively with their mi­croservices are Mantis (stream pro­cessing), Dynomite (data storage) and Vizceral (traffic intuition).

The streaming service Spotify also relies on mi­croservices. Spotify’s main daily de­vel­op­ment challenge is keeping ahead of the strong com­pet­i­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­velopers are con­stantly having to meet higher demands and comply with certain business rules (like licensing rights). Mi­croservices are a good solution for Spotify, allowing them to react quickly to new de­vel­op­ments their com­pet­it­ors might make, and publish their own de­vel­op­ments faster – forcing the com­pet­it­ors to react in turn.

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

The fact that eBay and other companies have suc­cess­fully gone from a mono­lith­ic to mi­croservice ar­chi­tec­ture is a clear sign of the benefits of a more modern approach. Whilst 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­hib­it­ing when demands start to increase.

Although there is plenty to be said for building systems based on mi­croservice ar­chi­tec­ture, the modern approach is not ne­ces­sar­ily always the right one for every company or website. Mi­croservices can create un­ne­ces­sary effort for smaller programs, which only have a few tasks to deal with. Not just creating services, but also main­ten­ance, further de­vel­op­ing, and mon­it­or­ing can be com­par­at­ively complex. When it comes to mon­it­or­ing processes (mon­it­or­ing), you need to carefully consider whether or not they are worse off with mi­croservices: on the one hand, in­di­vidu­al mi­croservices are very easy to analyse and measure, but when mi­croservices start to build up, this task grows con­sid­er­ably.

When taking work process ad­vant­ages into con­sid­er­a­tion, it becomes clear that mi­croservices are not sensible for every website, es­pe­cially in the short term. One advantage of working with mi­croservices is in­de­pend­ence for each team – you want to make sure that they can work in­de­pend­ently 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­ar­a­tion doesn’t make a lot of sense. Ad­di­tion­ally, 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­ingly being elim­in­ated in favor of de­vel­op­ment teams or­gan­ising 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­croservice 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­croservice 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­vidu­al services map business processes.