\nNotes

1Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley,2003, ISBN 978-0-32112-521-7↩

\n\n\n

",{"_173":174,"_42":43,"_46":47,"_44":45,"_69":70,"_175":176,"_199":171},"previewContent","

\n 1 Introduction\n
\n 2 What Are Microservices?\n
- \n 2.1 Size\n
- \n 2.2 Bounded Context and Domain-Driven Design\n
- \n 2.3\tConway’s Law\n
- \n 2.4 Conclusion\n
\n
\n 3 Why Microservices?\n
- \n 3.1 Scaling Agility\n
- \n 3.2\tMigrating Legacy Applications\n
- \n 3.3 Sustainable Development Speed\n
- \n 3.4 Robustness\n
- \n 3.5 Continuous Delivery\n
- \n 3.6 Independent Scalability\n
- \n 3.7 Technology Freedom\n
- \n 3.8 Conclusion\n
\n
\n 4 What’s Next?\n
- \n 4.1 Microservices: Just a Hype?\n
- \n 4.2 Self-contained Systems\n
- \n 4.3 Examples\n
- \n 4.4 More literature\n
- \n 4.5 Final Remark\n
\n
\n Notes\n

\n1 Introduction

\n\n

Microservices have turned into a hype. Like for every other architecture\napproach there are certain scenarios where the advantages of Microservices\ncan best unfold. Besides, their characteristic advantages\ncome at the price of challenges in other areas.

\n\n

This primer provides a short introduction into the topic of\nMicroservices. It presents what Microservices actually are and which\nadvantages they can have. This overview is meant to facilitate the\nstart into the topic and to help with judging the applicability and\nthe usefulness of Microservices in a certain context. Thereby\nMicroservices can turn from just a hype into a meaningful element in\nan architect’s tool kit.

\n\n\n

\n2 What Are Microservices?

\n\n

The idea behind Microservices is not new. A very similar approach\nis also followed by the UNIX philosophy, which is based on three\nideas:

\n\n

A program should fulfill only one task, and it should do it well.
Programs should be able to work together.
Besides, the programs should use a universal interface. In UNIX\nthese are text streams.

\n\n

The realization of these ideas leads to the creation of reusable\nprograms, which are in the end a kind of component.

\n\n

Microservices serve to divide large systems. Consequently,\nMicroservices represent a modularization concept. There is a large\nnumber of such concepts, but Microservices are different. They can be\nbrought into production independently of each other. Changes to an\nindividual Microservice only require that this Microservices has to be\nbrought into production. In the case of other modularization concepts\nall modules have to be delivered together. Thus, a modification to an\nindividual module necessitates that the entire application with all\nits modules has to be deployed again.

\n\n

\nMicroservice = Virtual Machine

\n\n

Microservices cannot be implemented via the modularization concepts\nof programming languages. These concepts usually require\nthat all modules have to be delivered together in one program. Instead\nMicroservices have to be implemented as virtual machines, as more\nlight-weight alternatives such as Docker containers or as individual\nprocesses. Thereby they can all easily be brought into production\nindividually.

\n\n

This results in a number of additional advantages: For instance,\nMicroservices are not bound to a certain technology. They can be\nimplemented in any programming language or on any platform. Moreover,\nMicroservices can of course also bring along their own supporting\nservices such as databases or other infrastructure.

\n\n

Besides, Microservices should possess their own separate data storage i.e. a\nseparate database or at least a separate schema in a common\ndatabase. Consequently, each Microservice is in charge of its own\ndata. In fact, experience teaches that the shared use of database\nschemas renders changes to the data structures practically\nimpossible. Since this interferes profoundly with software\nchangeability, this kind of coupling should be prevented.

\n\n

\nCommunication Between Microservices

\n\n

Microservices have to be able to communicate with each other. This can\nbe achieved in different manners:

\n\n

The Microservices can replicate data. This does not just mean to\ncopy the data without changing the schema. In that case changes to\nthe scheme are impossible because multiple Microservices use the\nsame schema. However, when one Microservice processes orders and\nanother analyzes the data of the orders, the data formats can be\ndifferent and also access to the data is different: The analysis Microservice\nwill primarily read data, for order processing reading and\nwriting are rather equal. Classical data warehouses also employ\nreplication for analyzing large amounts of data.
When Microservices possess an HTML UI, they can easily use links to\nother Microservices. Besides, it is possible that a Microservice\nintegrates the HTML code of other Microservices in its own web page.
Finally, the Microservices can communicate with each other by\nprotocols like REST or messaging via the network.

\n\n

In a Microservice-based system it has to be defined which communication\nvariants are used to ensure that the Microservices can in fact be\nreached with these technologies.

\n\n

\n2.1 Size

\n\n

The term “Microservice” focuses on the size of Microservices. This\nmakes sense for distinguishing Microservices from other definitions of\n“services”. Nevertheless, it is not so easy to indicate the concrete\nsize of Microservices.

\n\n

Defining the unit poses already a problem: Lines of Code (LoC) are not\na good unit. In the end, the actual number of Lines of Code of a\nprogram does not only depend on its formatting, but also on the\nprogramming language. In fact, it does not seem to make much sense to\nevaluate an architectural approach based on such metrics. Ultimately,\nthe size of a system can hardly be given in absolute terms, but only\nin relation to the represented business processes and their\ncomplexity.

\n\n

Therefore, it makes much more sense to define the size of\nMicroservices with the aid of upper and lower limits. In general, it\nholds true that smaller is better for Microservices:

\n\n

A Microservice should be developed by one team. Therefore, a\nMicroservice should never be so large that more than one team is\nnecessary to develop it further.
Microservices represent a modularization approach. Developers should\nbe able to understand individual modules – therefore modules and\nthus Microservices have to be so small that an individual developer\nis still able to comprehend them.
Finally, a Microservice should be replaceable. When a Microservice\ncannot be maintained anymore or for instance a more powerful\ntechnology is supposed to be used, the Microservice can be replaced\nby a new implementation. Microservices represent therefore the only\nsoftware architecture approach which takes a future replacement of\nthe system or at least of system parts already into consideration\nduring development.

\n\n\n

\"Fig. — Fig. 1: Ideal Size of a Microservice

\n\n\n

This leaves the question why not to just build the Microservices as\nsmall as possible. In the end, the advantages reinforce each other\nwhen the Microservices are especially small. However, there are\ndifferent reasons why Microservices cannot be tiny without creating\nalso a number of problems:

\n\n

Distributed communication between Microservices via the network is\nexpensive. When Microservices are large, the communication occurs\nrather locally within a Microservice and is therefore faster and\nmore reliable.
It is difficult to move code across Microservice boundaries. The\ncode has to be transferred into another system. When this system\nuses a different technology or programming language, rewriting the\ncode in a different language might be the only option for moving a\nfunctionality from one Microservice into another. Of course, it is\nalways possible to turn the respective functionalities into a new\nMicroservice, which can be accessed by the other Microservices. In\ncontrast, within a Microservice refactoring is quite easy with the\naid of the usual mechanisms e.g. automated refactoring in the IDE.
A transaction within a Microservice is easy to implement. Beyond the\nboundaries of an individual Microservice this is not trivial anymore\nsince distributed transactions become necessary. Therefore the best\nis to decide for a Microservice size which allows that a transaction\ncan be entirely processed in one Microservice.
The same holds true for the consistency of data: When for instance\nthe account balance is supposed to be consistent with the result of\nearnings and expenses, this can quite easily be implemented\nin one Microservice, but is hardly feasible across\nMicroservices. Therefore, Microservices should be large enough to\nensure that data which have to be consistent are handled in the same\nMicroservice.
Each Microservice has to be brought into production independently\nand therefore needs its own environment. This uses up hardware\nresources and means in addition that the effort for system\nadministration increases. When there are larger and therefore fewer\nMicroservices, this expenditure becomes smaller.

\n\n

To a certain degree the size of a Microservice depends on the\ninfrastructure: When the infrastructure is very simple, it can\nsupport a multitude of Microservices and therefore also very small\nMicroservices are possible. In such a case the advantages of a Microservice-based\narchitecture are accordingly larger. Already relatively simple\nmeasures can help to reduce the infrastructure expenditure: When there\nare templates for Microservices or other possibilities to create\nMicroservices easily and to more uniformly administrate them, this can\nalready reduce expenditure and thereby enable the use of smaller\nMicroservices.

\n\n

\nNanoservices

\n\n

Certain technological approaches can further reduce the size of a\nservice. Instead of delivering Microservice as virtual machines or\nDocker containers, the services can be deployed on\nAmazon Lambda. It allows the\ndeployment of individual functions written in Java, Node.js or\nPython. Each function is automatically monitored. In addition, each call to a\nfunction is billed. Functions can be called using REST or due to \nevents e.g. data written to Amazon S3 or DynamoDB. Using such an\ninfrastructure makes it possible to create services that just consist\nof a few Lines of Code each because the overhead for deployment and\noperations is so low.

\n\n

A similar approach can be implemented using a Java EE application\nserver. Java EE defines different deployment formats and allows to run\nmultiple applications on an application server. The services\ncommunicate for instance via REST or messaging just like\nMicroservices. However, in such a scenario the services are not so\nwell isolated from each other anymore: When an application in an\napplication server uses up a lot of memory, this will also affect the\nother applications on the application server.

\n\n

Another alternative are OSGi bundles. This approach also defines a\nmodule system based on Java. However, in contrast to Java EE this\napproach allows method calls between bundles so that communication\nvia REST or messaging is not necessarily required.

\n\n

Unfortunately, both approaches are problematic when it comes to\nindependent deployment: In practice, Java EE application servers and\nalso OSGi runtime environments have often to be started again when\nnew modules are deployed. Therefore, a deployment affects also other\nmodules.

\n\n

On the other hand, the expenditure for infrastructure and\ncommunication is lower since OSGi allows for instance to use local\nmethod calls. This enables the use of smaller services.

\n\n

To clearly distinguish these services from Microservices it is\nsensible to use an alternative term like “Nanoservices” for\nthis approach. Ultimately these services offer neither the isolation\nof Microservices nor their independent deployment.

\n\n

\n2.2 Bounded Context and Domain-Driven Design

\n\n

It is one of the main objectives of Microservices to limit changes and\nnew features to one Microservice. Such changes can comprise the UI –\ntherefore a Microservice should also provide a UI. However, also in\nanother area modifications should occur within the same Microservice –\nnamely in regards to data.

\n\n

A service which implements an order process should ideally also be\nable to query and modify the data for an order. Microservices have\ntheir own data storage and can therefore store data in the way that\nbest suits them. However, an order process requires more than just the\ndata of the order. Also the data concerning the customer or the items\nare relevant for the order process.

\n\n

Here, Domain-driven Design ((DDD)¹) is helpful. Domain-driven\nDesign serves to analyze a domain. The essential basis is Ubiquitous\nLanguage. This is like other components of Domain-driven Design also a\npattern and therefore here set in italics. Ubiquitous Language\ndenotes the concept that everybody who participates in the software\nshould use the same terms. Technical terms like order, bill\netc. should be directly echoed in the software. Often enterprises have\ntheir own specific language – this language should then also be\nimplemented in the software.

\n\n

The domain model can consist of different elements:

\n\n

\nEntity is an object with its own identity. In an\nE-commerce application the customer or the item could be\nEntities. Entities are typically stored in a database.
\nValue Objects do not have their own identity. An example is an\naddress which only makes sense in the context of a specific customer\nand therefore does not possess an identity.
\nAggregates are composite domain objects. They enable a simpler\nhandling of invariants and other conditions. For instance, an order\ncan be an Aggregate of order lines. This allows for instance to\nensure that the order of a new customer does not surpass a certain\nlimit. The invariant has to be fulfilled via a calculation of values\nfrom the order lines so that the order as Aggregate can ensure\nthese conditions.
\nServices contain business logic. DDD focuses on the modeling of\nbusiness logic as Entities, Value Objects and Aggregates. However,\nlogic which accesses multiple of these objects cannot be modelled\nin one of these objects. For this purpose there are Services.
\nRepositories serve to access the entirety of all Entities of a\ntype. Typically, some kind of persistence, for example in a database, is what\nis used to implement a Repository.

\n\n

The implementation of a domain model from these components and also\nthe idea of Ubiquitous Language facilitate the design and development\nof object-oriented systems. However, it is not immediately clear which\nrelevance DDD might have for Microservices.

\n\n

\nBounded Context

\n\n

Domain-driven Design does not only provide a guideline for how a\ndomain model can be implemented, but also for the relationships\nbetween domain models. Having multiple domain models initially appears\nunusual. After all, concepts like customer and order are central for\nthe entire enterprise. Therefore, it seems attractive to implement\nexactly one domain model and to carefully consider all aspects of the\nmodel. This should make it easy to implement the software systems in\nthe enterprise based on these elements.

\n\n

However, Bounded Context states that such a general model cannot be\nimplemented. Let’s take the customer of the E-commerce shop as an\nexample: The delivery address of this customer is relevant in the\ncontext of the delivery process. During the order process, on the\nother hand, the specific preferences of the customer matter, and for\nbilling the options for paying, for which the customer has deposited\ndata, are most important – for example his/her credit card number or\ninformation for a direct debit.

\n\n

Theoretically it might be possible to collect all this information\nin a general customer profile. However, this profile would then be\nextremely complex. Besides, in practice it would not be possible to\nhandle it: When the data regarding one context change, the model needs\nto be changed and this will then concern all components which use the\ncustomer data model – and these can be numerous. In addition, the\nanalysis needed to arrive at such a customer model would be so complex\nthat it would be hard to achieve in practice.

\n\n

\nBounded Context and Microservices

\n\n

Therefore a domain model is only sensible in a certain context –\ni.e. in a Bounded Context. For Microservices it makes the most sense\nto design them in a way that each Microservice corresponds to a\nBounded Context. This provides an orientation for the domain\narchitecture of Microservices. This design is especially important\nsince a good domain architecture enables independent work on\nfeatures. When the domain architecture ensures that each feature is\nimplemented in an individual Microservice, the implementation of\nfeatures can be uncoupled. Since Microservices can even be brought\ninto production independently of each other, features cannot only be\ndeveloped separately, but also rolled out individually.

\n\n

The independent development of features also profits from the\ndistribution in Bounded Contexts: When a Microservice is also in\ncharge of a certain part of the data, the Microservice can introduce\nfeatures without causing changes to other Microservices.

\n\n

When for example in an E-commerce system a payment option via PayPal\nis supposed to be introduced, this requires only changes to the\nMicroservice for billing thanks to Bounded Context. There the UI\nelements and the new logic are implemented. As the Microservice for\nbilling administrates the data for the Bounded Context, only the\nPayPal data have to be added to the data of the Microservice. Changes\nto a separate Microservice, which administrates the data, are not\nnecessary. Therefore, the Bounded Context is also an advantage in\nregards to changeability.

\n\n

\nRelationships Between Bounded Contexts

\n\n

In his book Eric Evans describes different manners how Bounded\nContexts can work together. In the case of Shared Kernel for\ninstance a shared Bounded Context can be used in which the shared\ndata are stored. A radical alternative option is Separated Ways:\nHere, both Bounded Contexts use completely independent\nmodels. Anticorruption Layer uncouples two domain models. Thereby it\nis for instance possible to prevent that an old and hard to understand\ndata model from a mainframe has to be used in the remainder of the\nsystem. With the aid of an Anticorruption Layer the data are\ntransferred into a new, easily understandable representation.

\n\n

Of course, depending on the model used for the relationships between\nthe Bounded Contexts more or less communication between the teams\nworking on the Microservices will be necessary.

\n\n

In general, it is therefore conceivable that a domain model also\ncomprises multiple Microservices. Maybe it is sensible in the example\nof the E-commerce system that the modeling of the basic data of a\ncustomer is implemented in one Microservice and only specific data are\nstored in the other Microservices – following the concept of Shared\nKernel. However, in such a case more coordination between\nMicroservices might be necessary which can interfere with their\nseparate development.

\n\n

\n2.3\tConway’s Law

\n\n

Conway’s Law was\ncoined by the American computer scientist Melvin Edward Conway and\nstates:

\n\n\n\n

The reason behind Conway’s Law is that each organizational unit\ndesigns a certain part of the architecture. If two parts of the\narchitecture are supposed to have an interface, coordination is\nrequired regarding this interface – and therefore a communication\nrelationship between the organizational units which are responsible\nfor the respective parts.

\n\n

\nThe Law as a Limit for Architecture

\n\n

An example for the effects of the Law: An organization forms one team\nof experts each for the web UI, the logic in the backend and for the\ndatabase (compare Fig. 2). This organization has advantages: The\ntechnical exchange between experts is relatively simple and holiday\nreplacements are easy to organize. Therefore, the idea to have\nemployees with similar qualification work together in one team is not\nvery far fetched.

\n\n

However, according to Conway’s Law the three teams will create\nartifacts in the architecture. A database layer, a backend layer and a\nUI layer will be created.

\n\n\n

\"Fig. — Fig. 2: Team setup by technical skills

\n\n\n

This architecture entails a number of disadvantages:

\n\n

To implement a feature, the customer has to talk with all three\nteams. He/she has to explain the requirements for the new feature to\neach of the three teams. When the customer does not have detailed\nknowledge about the system architecture, the teams will have to\ndiscuss with him/her how the functionalities can be implemented in the\ndifferent layers.
The teams have to coordinate their work for instance in regards to\ninterfaces.
In addition, it has to be ensured that each team delivers its part\nof the work in time. The backend can hardly implement new features\nwithout changes to the database. Likewise, the UI cannot be\nimplemented without changes to the backend.
The dependencies and the resulting need for communication slow down\nthe implementation of the feature. The database team can only\ndeliver the changes at the end of its sprint. As the work of the\nbackend team is based on the changes introduced by the database\nteam, it has to wait until the other team is done. Likewise, the UI\nteam has to wait for the backend team to finish. Therefore, it might\ntake three sprints until the entire implementation is completed. Of\ncourse, optimizations are possible. However, a completely parallel\nimplementation is practically impossible.

\n\n

The way the teams were created results therefore in an architecture\nwhich interferes with a faster implementation of features. This\nproblem is often not perceived, as the relationship between\norganization and architecture is frequently not considered.

\n\n

\nConway’s Law as Enabler

\n\n

However, it is also possible to deal very differently with Conway’s\nLaw. It is the explicit aim of Microservices to implement a domain\narchitecture where each Microservice implements a meaningful part of\nthe architecture e.g. a Bounded Context. That facilitates and\nparallelizes the work on domain aspects. Therefore, there is another\nway to handle Conway’s Law in the context of Microservices: Instead of\nletting the architecture be a result of the organization, the\narchitecture drives the organization. The organization gets structured\nin the way that best supports the architecture.

\n\n\n

\"Fig. — Fig. 3: Team setup by functionalities

\n\n\n

Fig. 3 shows a possible architecture for a Microservice-based\nsystem: There is one component each for product search, the\nhandling of customers and the order process. For each Microservice\nthere is a team which implements this Microservice. Thereby the\ndomain-based distribution into Microservices is not only implemented\nat the level of architecture, but also at the organizational\nlevel. This supports the architecture: Transgressing the architecture\ngets difficult because according to Conway’s Law the organization \nenforces a domain-based architecture.

\n\n

Nevertheless, the different technical artifacts have to be implemented\nin the Microservices. Accordingly, the required technical skills have\nto be present in the different teams. Within a team the coordination\nof experts is profoundly easier than across teams. For this reason,\nrequirements which have to be implemented across different technical\nartifacts are now easier to implement.

\n\n

\nOrganizational Compromises

\n\n

In practice, even in a system structured as described with a\nsupporting organization there are nevertheless still challenges to\ndeal with. In the end, features are supposed to be implemented in the\nsystem. These features are sometimes not limited to one Microservice,\nbut require changes to multiple Microservices. Besides, sometimes more\nchanges have to be introduced into a Microservice than one team can\nhandle. In practice, it has proven best to have one team in charge of\na Microservice, but to allow also other teams to modify the\nMicroservice. When a feature requires changes to multiple\nMicroservices, one team can introduce all these changes without having\nto let changes be prioritized by another team. Besides, multiple teams\ncan work on one Microservice in order to implement a greater number of\nfeatures. Nevertheless, the team assigned to the Microservice is still\nin charge. In particular, it has to review all modifications to\nguide its development.

\n\n

\nOne Microservice per Team?

\n\n

By the way, it is not really necessary that one team only implements\none Microservice. A team can definitely also implement multiple\nMicroservices. However, it is important that a team has a precisely\ndefined responsibility in the domain architecture. In addition, one\ndomain aspect should be implemented in as few Microservices as\npossible. It can definitely be desirable to implement smaller\nMicroservices so that one team is in charge of more than one\nMicroservice.

\n\n

\n2.4 Conclusion

\n\n

The discussion in section 2.1 about the size of\nMicroservices focuses rather on the technical structure of the system\nfor defining Microservices. For the distribution according to\nBounded Context (section 2.2) the domain architecture\nis the most important aspect. Conway’s Law\n(section 2.3) states that Microservices also have\neffects on the organization. Only together these aspects give a\nfaithful picture of Microservices. Which of these aspects is the most\nimportant depends on the use context of the Microservice-based\narchitectures.

\n\n\n

\n3 Why Microservices?

\n\n

There is more than one reason to use Microservices. Depending on the\ncontext the architectural designs can look completely\ndifferently. Therefore, it is not only important to know the\nadvantages, but also to judge their relevance for a concrete project\nand to implement a fitting architecture.

\n\n

\n3.1 Scaling Agility

\n\n

As mentioned in section 2.3, Microservices can affect the\norganization. Ideally each Microservice should be developed by one\nteam or at least exactly one team should be in charge of the\nMicroservice.

\n\n

This provides options for the scaling of agile projects: Normally all\nteams have to coordinate and concertedly work on features. When each\nteam has its own stream of requirements and can implement them by\nchanges to its own Microservice, the teams can work largely\nindependently of each other on features. This allows to tackle also\nlarger projects in an agile manner. In principle the system is just\ndivided into multiple small projects which each can work independently\nof each other. Apart from supporting a domain architecture it is also\nvery helpful that Microservices can bring features into production\nwithout influencing other Microservices. This allows for a largely\nindependent development. In addition to the independence\nconcerning features, Microservices offer also technical independence:\nTechnology decisions can be limited to individual Microservices. This\nextends the independence the teams have: They cannot only largely\nindependently implement features, but also make their own independent\ntechnology decisions.

\n\n

Thereby Microservice-based architectures enable the independent\ndevelopment of individual Microservices and therefore facilitate the\nscaling of agile processes to larger project organizations.

\n\n

\n3.2\tMigrating Legacy Applications

\n\n

Work with legacy code is often difficult: Systems grown over time are\noften badly structured so that it is difficult to get an\noverview. In addition, the code is often of poor quality, and tests are\nlacking. Besides, the technological basis if often outdated so that\nmodern approaches cannot be used.

\n\n

Some of these problems can be solved by changing the approach for\nmodifying the system: Instead of modifying the code of the legacy\nsystem, the system is supplemented or partly replaced at its external\ninterfaces by Microservices. The advantage: Instead of editing the\nbadly structured and hard to understand legacy code, this code is\npractically left untouched and rather supplemented by external\nsystems.

\n\n

The overall goal is the complete replacement of the legacy system by a\nmultitude of Microservices. However, it is easy to start by\nsupplementing the legacy system by Microservices. This does not\nrequire a lot of preparations and can thus easily be tried\nout. Should Microservices not prove to be a good solution in a\nspecific context, they are also easy to remove again from the system.

\n\n

The easy integration of Microservices are one reason why Microservices\nare so interesting. Replacing a legacy system by a multitude of\nMicroservices is often a very useful approach to rapidly benefit in a\nsystem from advantages like Continuous Delivery.

\n\n

\n3.3 Sustainable Development Speed

\n\n

Microservice-based architectures distribute a system into multiple\nindependently deployable services. The distribution of a system into\nMicroservices is an important architecture decision. It determines the\nresponsibilities of the components.

\n\n

In a deployment monolith there is also such an architecture at the\nbeginning. However, there it is often lost over time since it is very\neasy to incorporate new dependencies into a deployment monolith: It\nsuffices to reference a class somewhere in the code. The architecture of an E-commerce\nsystem might define for instance that the order process is to call the\nbilling. In contrast, billing may not call the order\nprocess. Dependencies which only go into one direction have the\nadvantage that modules remain changeable. In the example it is\npossible to change the order process without having to modify\nbilling. However, changing the billing might affect the order\nprocess since the order process uses the billing.

\n\n

While implementing features in the billing process, a\ndeveloper might after all use functionalities from the order\nprocess. Something like that happens easily. Experience shows that\nthis initial dependency is soon followed by additional ones so that it\nis at some point not possible anymore to go on to develop the two\ncomponents independently since they are using each other.

\n\n

In the case of Microservices it is not so easy to use another\nMicroservice just like that. Microservices have each an interface, and\nit is only possible to use them via their interfaces. This requires to\ncall the interface via technologies such as REST or messaging. This\ndoes not happen just by mistake.

\n\n

If the Microservice intended to be used is developed by another team,\nit can even be necessary to contact this team. Ultimately, the\ndistribution of architecture into Microservices is relatively stable,\nand in contrast to deployment monoliths the architecture cannot easily\nget lost. Of course, similar results can also be accomplished by other\nmeasures enforcing architecture integrity. There are for instance\narchitecture tools which alert developers to their transgression of\narchitecture rules e.g. Structure101 or\nSonargraph. However,\nin the case of Microservices such measures are already integrated into\nthe system.

\n\n

\nReplaceability

\n\n

Another important characteristic of Microservices is their\nreplaceability: Without much effort a Microservice can be replaced by\na new implementation. This solves another problem of legacy systems:\nWhen a system cannot be maintained anymore, it is often also\nimpossible to rewrite it as the expenditure would just be too\nlarge. However, to replace a Microservices is not very difficult.

\n\n

\nConclusion

\n\n

Within a Microservice-based system it should also in the long run be\neasy to implement new features since a Microservice is small. If a\nMicroservice should nevertheless stop to be maintainable at some\npoint, it can be replaced. The architecture of the whole system can be\nexpected to be stable in the long run. Therefore, the long term\nmaintainability of the system can be ensured. In summary,\nMicroservice-based systems promise a lasting good maintainability and\nchangeability of the software system.

\n\n

\n3.4 Robustness

\n\n

In a Microservice-based system there is a high robustness in regards\nto certain problems - in contrast to deployment monoliths: When a\nfunctionality in a deployment monolith uses up a lot of CPU or memory,\nother modules will be affected. If in the worst case a module causes\nthe system to break down, all other modules will likewise not be\navailable anymore.

\n\n

A Microservice is a separate process or even an individual virtual\nmachine. Therefore, a problem in one Microservice does not influence\nanother Microservice since the operating system or the virtualization\nisolates the Microservices from each other.

\n\n

Nevertheless, Microservices are distributed systems. They run on\nmultiple servers and use the network. Servers and network can\nfail. Accordingly, a Microservice-based system in its entirety should\nnot be very robust since it is more affected by these dangers.

\n\n

Therefore, Microservices have to be safeguarded from the failure of\nother Microservices. This is called “Resilience”. Resilience can be\nimplemented in very different ways: When an order process cannot be\nfinished, it might be an option to try again later. When a credit card\ncannot be verified, it might be a possibility to nevertheless perform\nthe order up to a certain upper limit. What this upper limit is, would\nhave to be decided as part of the requirements of the system.

\n\n

Resilience allows to make a Microservice-based system very robust. The basis\nfor this is the strict separation in processes or virtual machines.

\n\n

\n3.5 Continuous Delivery

\n\n

Continuous Delivery is an approach where software is regularly\nbrought into production. The basis for this is mainly a largely\nautomated process as illustrated in Fig. 4:

\n\n

In the commit phase unit tests and static code analyses are\nperformed.
Automated acceptance tests ensure that the software correctly\nimplements features.
Capacity tests on the other hand check whether the performance is\nfine and whether the expected load can be handled.
Manual tests can address new features, but also error-prone areas.
In the end the software goes into production.

\n\n\n

\"Fig. — Fig. 4: Continuous Delivery Pipeline

\n\n\n

Continuous Delivery is hard to implement in the context of deployment\nmonoliths:

\n\n

Automating tests and deployments is complex since deployment\nmonoliths are difficult to bring into production. The database which\ncan be quite large and often contains a lot of data plays for instance\na central role. In addition, many third party systems need to be\nintegrated or simulated.
The tests are laborious. Especially for deployment monoliths\nmodifications can easily have unintended side effects. Therefore a\ncomprehensive regression test has to be performed for each\nchange. This causes a lot of effort and slows the Continuous\nDelivery Pipeline down.
Finally, it is hard to safeguard a release. It would be conceivable\nto create a second environment, to deploy the new version in this\nenvironment and only to switch to the new version when it has been\ntested once more. In such a case it is also possible to fall back to\nthe old version. However, for a deployment monolith such approaches\nare hard to implement because the required environment is too large\nand complex.

\n\n

Microservices are independent deployment units. Therefore, they can\nhave independent Continuous Delivery Pipelines. These Pipelines can be\ncreated relatively easily. In addition, it is comparably fast to bring a\nMicroservice through the Continuous Delivery Pipeline into\nproduction. Moreover, deployments of Microservices are easier to\nsafeguard. All the problems concerning Continous Delivery in the\ncontext of deployment monoliths can be solved by the smaller size of\nMicroservices. Thus Continuous Delivery is profoundly facilitated by\nMicroservices.

\n\n

Of course some measures are necessary to ensure the independent\ndeployment of Microservices. Nevertheless, the advantages in regards to\nContinuous Delivery are for many architects and developers an\nimportant reason to get interested in Microservices.

\n\n

\n3.6 Independent Scalability

\n\n

Each Microservice runs as an individual process, sometimes even in a\nseparate virtual machine. This allows to scale just the concerned\nMicroservice when a certain functionality is used especially heavily\nwhile the other Microservices continue to run with the same capacity.

\n\n

This does not sound impressive at the start. However, in practice this\ncharacteristic of Microservices leads to a number of profound\nadvantages since scaling is facilitated. In general, performance\nrequirements which are limited to certain cases are really\ndemanding. The independent scalability of Microservices allows to\nconcentrate on the ones, which are under heavy load, and to use much\nless resources to deal with the problem than would be the case for a\ndeployment monolith. This can also be a relevant reason for\nintroducing Microservices.

\n\n

\n3.7 Technology Freedom

\n\n

In principle each Microservice can be implemented in a different\ntechnology. Of course, this renders the system overall more\ncomplex. This complexity can be limited by the use of standards for\noperations, monitoring, log formats or deployment. This will ensure at\nleast that the operation is largely uniform.

\n\n

Still the technology freedom allows for example to use an individual\nsearch technology for the product search without requiring extensive\ncoordination with other Microservices and teams. When a team requires\na bugfix in a library and therefore wants to use a new version, this\nchange is likewise limited to one team and can therefore be\nperformed by this one team which then carries also the risk. In case\nof a deployment monolith an extensive coordination would be necessary\nand accordingly also more tests.

\n\n

In the end new technologies can be tested without a large migration\neffort. Risk and expenditure are limited: Initially a single\nMicroservice can be migrated. If the migration does not work, only\nthis one Microservice will fail and, besides, in case of larger problems only\nthis one Microservice has to be newly implemented.

\n\n

A special project for bringing a deployment monolith to another\ntechnology is not necessary for Microservices and the migration is\nmuch easier. This entails also other positive consequences: Developers\nare free to try out new technologies which generally increases\nmotivation.

\n\n

\n3.8 Conclusion

\n\n

Microservices have a large number of advantages. Which advantages are\nin the end the most important, depends on the concrete context. For\nmany projects the focus is on the replacement of a deployment\nmonolith. In such a case the easy handling of the legacy system (see\nsection 3.2) is an important advantage during\nmigration. Reasons to migrate are in such cases often the wish to\nscale agile processes (section 3.1) or for an easier\nimplementation of Continuous Delivery (section 3.5).

\n\n

However, there are also very different scenarios where for instance\nthe objective is to increase the stability of an application in\noperation. In this case robustness (section 3.4) is an\nimportant motivation, and independent scaling\n(section 3.6) can be another important factor.

\n\n

Last but not least Microservices promises to make systems maintainable\neven in the long run (section 3.3) and can use many\ndifferent technologies where they are most useful\n(section 3.7).

\n\n

Therefore, the relevant advantages depend on the respective\ncontext. How Microservices should be used in the context of a certain\nsystem, likewise depends on the specific advantages which are supposed\nto be realized.

\n\n\n

\n4 What’s Next?

\n\n

This primer can only provide a short introduction into\nMicroservices. Therefore, it is an important question how to go on\nafter reading this brochure.

\n\n

\n4.1 Microservices: Just a Hype?

\n\n

Microservices are more than just a hype. Amazon employs the\ndistribution into teams with their own technologies already\nsince 2006. This architecture and this approach is what is nowadays\ncalled Microservices. Pioneers like Netflix rightly expected so great advantages\nfrom this architecture approach that they were willing to heavily\ninvest into the creation of the necessary infrastructures. Nowadays\nthe technologies they created are available for everybody so that the\nintroduction and the use of Microservices are much easier and less\ncostly.

\n\n

In addition, the trends to agility, Continuous Delivery and Cloud are\nreflected by Microservice-based architectures. Even beyond these\ncriteria there are good reasons for Microservices â€“ ranging from\nindividual scalability to robustness. Therefore, Microservices are not\nonly a good supplement for a number of trends, but they represent also\na solution for different problems. The trend to use Microservices is\nthus based on a number of reasons. Therefore it is extremely unlikely that\nit will just be a short-lived hype.

\n\n

\n4.2 Self-contained Systems

\n\n

An approach based on Microservices are\nSelf-contained Systems. They focus on\ncoarse-grained systems which allow teams to work independently. They\nshould be integrated on the UI level and only use asynchronous\ncommunication among each other. This is a more coarse-grained\narchitecture than Microservices. While Microservices can be used in many different\nscenarios and for many different purposes, as explained in chapter 3,\nSelf-contained Systems represent\na more specific approach to Microservices, which is custom-tailored to solve problems\nof large projects.

\n\n

\n4.3 Examples

\n\n

The primer discusses Microservices only theoretically and does not\nintroduce technologies for implementation.

\n\n

http://ewolff.com/microservices-demos.html shows several examples for\nthe different options to implement microservices:

\n\n

\nSynchronous Communication

\n\n

There are several options for synchronous communication between microservices:

\n\n

The Consul demo is written\nin Java with Spring Cloud / Boot. The demo uses Consul for service discovery,\nApache httpd for routing, Hystrix for resilience and Ribbon for load\nbalancing. It also provides a\nPrometheus installation\nfor monitoring \nand an\nELK stack\nfor log analysis.
The Netflix demo uses the\nNetflix stack. The demo is written\nin Java with Spring Cloud / Boot. It uses Netflix Eureka for service discovery,\nNetflix Zuul for routing, Hystrix for resilience and Ribbon for load\nbalancing.
Kubernetes is a system to run Docker containers in a cluster. The\nKubernetes demo\nis written in Java with Spring Cloud / Boot. It uses Kubernetes for\nservice discovery, routing and load balancing. The demo also uses\nHystrix for resilience. The code does not depend on Kubernetes.
Cloud Foundry is a PaaS. It provides an application with an\nenvironment to run in. The\nCloud Foundry demo\nis written in Java with Spring Cloud / Boot. Uses Cloud Foundry for\ndeployment, service discovery, routing and load balancing. The demo\nalso uses Hystrix for resilience. The code does not depend on Cloud\nFoundry.

\n\n

\nAsynchronous Communication

\n\n

Asynchronous communication makes it easier to deal with unreliable\nnetworks and services:

\n\n

\nKafka uses Kafka for\ncommunication. Kafka is a message-oriented middleware and allows\nsystems to send messages to one another.
\nAtom uses REST / HTTP\nfor asynchronous communication with the Atom format.

\n\n

\nUI Integration

\n\n

UI integration provides very loose coupling:

\n\n

\nESI shows how Edge Side\nIncludes (ESI) can be used to integrate the UI of microservices. On\nmicroservice is written in Java with Spring Boot, the other one with\nGo. The Go microservices is built using multi stage Docker containers.
\njQuery shows how jQuery can\nbe used to integrate the UI of microservices.

\n\n

The website for each demo explains how the demo can be built and\nstarted.

\n\n

\n4.4 More literature

\n\n

Additional literature such as the\nMicroservices Book (there is also a\nGerman version) by the same author\nwill be needed to appreciate the full scope of Microservices and to\nlearn how to actually implement them technically.

\n\n

The free booklet\nMicroservices Recipes\ngives an overview of technologies that can be used to implement a\nmicroservices architecture. It explains the demos mentioned above in\nmore detail and illustrates how the technology work and to provide a\nfoundation for the implementation of a microservices architecture.\nThere is also a\nGerman version).

\n\n

The book\nMicroservices - A Practical Guide \ncontains a more detailed description of technologies for the\nimplementation of microservices. In addition, it contains an\nintroduction to microservices and an overview of technologies for the\nmonitoring of microservices. There is also a\nGerman version).

\n\n

\n4.5 Final Remark

\n\n

A final remark: the risk associated with introducing Microservices is very\nlimited: A first Microservice has just to be developed and brought\ninto production. This Microservice can for instance supplement an\nexisting deployment monolith. Should this approach not work out, it is\nvery easy to remove the Microservice again.

\nNotes

1Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley,2003, ISBN 978-0-32112-521-7↩

\n\n\n

\n\n

\n\n","tocStructure",[177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198],{"_80":81,"_42":82,"_74":-5,"_83":84,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":81,"_42":90,"_74":-5,"_83":91,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":95,"_74":-5,"_83":96,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":100,"_74":-5,"_83":101,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":103,"_74":-5,"_83":104,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":106,"_74":-5,"_83":107,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":81,"_42":109,"_74":-5,"_83":110,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":113,"_74":-5,"_83":114,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":116,"_74":-5,"_83":117,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":119,"_74":-5,"_83":120,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":122,"_74":-5,"_83":123,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":125,"_74":-5,"_83":126,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":128,"_74":-5,"_83":129,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":131,"_74":-5,"_83":132,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":134,"_74":-5,"_83":135,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":81,"_42":137,"_74":-5,"_83":138,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":141,"_74":-5,"_83":142,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":144,"_74":-5,"_83":145,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":147,"_74":-5,"_83":148,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":150,"_74":-5,"_83":151,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":94,"_42":153,"_74":-5,"_83":154,"_76":85,"_97":-5,"_98":-5,"_88":-5},{"_80":81,"_42":156,"_74":-5,"_83":157,"_76":85,"_97":-5,"_98":-5,"_88":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nNotes

Table of Contents

\n1 Introduction

\n2 What Are Microservices?

\nMicroservice = Virtual Machine

\nCommunication Between Microservices

\n2.1 Size

\nNanoservices

\n2.2 Bounded Context and Domain-Driven Design

\nBounded Context

\nBounded Context and Microservices

\nRelationships Between Bounded Contexts

\n2.3\tConway’s Law

\nThe Law as a Limit for Architecture

\nConway’s Law as Enabler

\nOrganizational Compromises

\nOne Microservice per Team?

\n2.4 Conclusion

\n3 Why Microservices?

\n3.1 Scaling Agility

\n3.2\tMigrating Legacy Applications

\n3.3 Sustainable Development Speed

\nReplaceability

\nConclusion

\n3.4 Robustness

\n3.5 Continuous Delivery

\n3.6 Independent Scalability

\n3.7 Technology Freedom

\n3.8 Conclusion

\n4 What’s Next?

\n4.1 Microservices: Just a Hype?

\n4.2 Self-contained Systems

\n4.3 Examples

\nSynchronous Communication

\nAsynchronous Communication

\nUI Integration

\n4.4 More literature

\n4.5 Final Remark

\nNotes