Microservices

The affirmation of the cloud computing model and the lessons learned in the management of distributed software led to the creation of an architecture style based on microservices, in which the concept of web services, flows and message exchange is not used only in large systems, but it becomes common practice in all types of applications, even the smallest ones, leading in fact to the end of the monolithic application.

Microservices: an overview

Something is boiling in the pot. Something that will revolutionize the way we are used to thinking and designing software. Something apparently marginal and sectoral but that will slowly acquire space to the point of reversing everything, up to the point of upsetting the habits. I’m talking about microservices, that is the architectural style introduced, or otherwise made known, by Fowley in the now famous post “Microservices “. What is it about? At the moment there is not much literature about it, except for many blog posts and some first books that are appearing on the market.

Distributed software

It is therefore not possible to provide very precise definitions although the central idea seems clear: microservices shift the emphasis on the distribution of software rather than its concentration in so-called monolithic applications. In reality, the design of distributed systems is certainly not a novelty that is introduced for the first time by the microservices approach, but without a shadow of a doubt microservices seem to want to apply for recognized practice and above all for software design, any type of software.

And this is where I believe that “something” is boiling in pot, that element that has the potential to undermine the normal processes of software production: I speak of the idea of ​​making “normal” the use of distributed software for the realization of even small-cut systems. In fact, distributed systems are generally used where it is impossible to use them, where the implementation scenario is such that we are forced to adopt a distributed profile in system design for the simple reason that the monolithic one can not be used.

The scenarios that immediately come to mind are, for example, the typical ones that a system integrator must face: having different applications interact with each other. Just think of a scenario of integration between a SAP ERP and an e-commerce created by a third party. The scenario is distributed as both the SAP ERP and e-commerce reside and are executed on different machines and, probably, on different platforms. It is clear that in these scenarios, the choice to adopt a distributed solution to achieve integration becomes mandatory.

Microservices: distributed approach always

With microservices, on the other hand, a distributed approach is always used. No matter the scenario, the goal does not matter: the solution is always distributed. It is clear that if this way of developing software will spread, in the future programmers could reason normally thinking of distributed software as something normal and not “exceptional”, as the obvious choice and not as a choice dictated by particular needs. Indeed, the vision could even be reversed: the choice to proceed with a monolithic rather than distributed software will become the particular case rather than the norm.

From this observation we understand why I speak of a possible “revolution” in the title; yes, because if the distributed paradigm ever became a concrete thing in the near future, well then it would mean that the way of thinking of programmers will be changed and that the references and models to be used will be changed within their design imaginary. A revolution with a capital R in short. Information technology, on the other hand, is not new to this kind of revolutions; on the contrary, information technology is perhaps more than the science of revolutions, the science of the continuous change of paradigms and habits. We must not therefore be amazed at this possibility, but we must try to understand it and take advantage of the great opportunities it offers.

The features of the microservices

Let’s start with the name, which already provides some information on the origins of microservices. The word microservice is obtained as a two-word composition: micro and service. Of the two the most important is the second, service, since it represents the historical process from which the microservices come, that is the service world; the first, micro, represents the innovative element that is going to renew the service approach. The service approach as it is intended here is that coming from the world of SOA (Service Oriented Architectures), that is, the set of international specifications, together with some technologies, which led to the definition of Web Services. The latter were born essentially as a solution to the problem of integration between macrosystems operating on different platforms; they were born with the aim of making organic and non-occasional systems interoperable with each other.

Service

The Web Services-related technology families have grown a lot over the past decade and have also spread to large-scale projects up to the current situation where they are also used for smaller projects. In all these cases, the functions of an information system are divided into services and then organized in turn with higher level services generally called orchestrators. Each service, each Web Service, is a software artifact capable of providing functionality to the outside and independent of the context in which it is inserted. These characteristics make it distributable, that is executable on any machine and on any platform.

The important thing is that its features are always available when needed, that is always when they are called up. Therefore, from a software design point of view, Web Services have introduced a real methodology for thinking and creating systems distributed to services. It is useless to deny, however, how Web Services technologies are often difficult to manage and do not always meet those initial requirements to facilitate the integration between different systems in a simple and fast way. Entirely based on XML, they pay the price of an overhead linked to this standard which is very widespread, but which leads to high costs both in terms of design and maintenance.

Micro

On this state of the art we now see the meaning of the word “micro” and enter the world of microservices. The micorservices are born with the intention of maintaining a design based on services but with a much lighter technological load compared to that of Web Services. In microservices, therefore, we tend to use technologies that are lighter and easier to manage than the SOA world, so that we can create services quickly and easily and, above all, easier to deploy or “move” from one machine to another.

Below I will try to briefly illustrate what I believe are the salient concepts of microservices, how they apply and how they alter software design.

Compability

All those who try daily in the design and development of software, know very well that the basis of any sufficiently complex system is the subdivision into parts of the system features also called modules, components or libraries depending on the context . Each part offers specific functionalities that can be used within the more general whole, which is then our final application. The way we organize, control and compose the parts allows us to achieve a more complex and richer final result than the individual parts put together.

In general, in monolithic applications a component or library is first and foremost represented by an artifact, a file, which contains the library sources and which at the time of compilation or execution is appropriately linked to the rest of the project for be able to be usable within the executive stream. Leaving aside the aspects of dynamic import of the libraries that do not alter the basic principle that I am going to illustrate, the feature that is always satisfied is to enter the code of the library within the code developed by us, so as to obtain as a final result a unique executable code, monolithic.

 

 

Figure 1 – The monolithic application.

 

It is clear that in such a scenario the malfunction of a single library could compromise the functioning of the whole application, just as the modification of one of them necessarily entails the recompilation of the whole application.

The microservice application

In a microservice scenario, the final architecture is very similar to the monolithic one just illustrated but different in its essence. In figure 2 we report what would be the same system formed by a single application that makes use of three libraries Lib A, Lib B and Lib C, in a microservice scenario.

 

 

Figure 2 – The microservice scenario (μS).

 

Where are the differences and where are the similarities? In this case the libraries instead of being software artifacts to be imported and linked to our sources are real and prerogical services performed autonomously and independently of each other: μS A, μS B, μS C. These microservices are recalled if necessary main application here called μS Main, also a microservice, also performed autonomously and independently of the others. In both cases there is certainly a dependency relationship between the code of the main application and that of the libraries; but, in the first case, the dependency relationship occurs through an exchange of data in memory, while in the second case the tuto is expressed through an exchange of messages via network between the microservices (Main with A, B and C).

Reusability

The properties of modularity derive different properties as regards the reusability of the components. For example, consider two different A and B applications that use both the same libraries.

 

 

Figure 3 – Monolithic applications that use the same libraries.

 

In the monolithic case, applications use different instances of equal sources. This means that a change in the source of a component will result in a recompilation of all the applications that use it.

 

 

Figure 4 – With microservices, the same instances are used for different applications.

 

In the microservice case, instead, the instances of the microservices used are the same for both applications. This means that a code change of a microservice spreads immediately to everyone who uses it.

Scalability

Also from the properties of modularity descend those related to scalability.

 

 

Figure 5 – Microservices have their positive effect even when it comes to scalability.

 

Simply by looking at Figure 5, we understand the difference between what it means to scale a monolithic system and do it with a distributed system. In the first case, the whole system must be replicated and balanced depending on the load, while in the second case only the microservices that need to be replicated and balanced.

Deployment

Also with regard to the deployment of applications the difference jumps to the eye simply by observing figure 6.

 

 

Figure 6 – Deployment is more flexible with microservices.

 

In the case of the monolithic application, obviously there is not much choice but to make the deployment on a dedicated machine. In contrast, in the case of microservices, the deployment can be performed both on the same machine and on multiple machines depending on the performance requirements.

Monitoring

A very important topic is the monitoring and debugging of applications. In the monolithic case, the application generally generates files called log files in order to signal malfunctions or particular activities of the application. In some cases the application itself has an interface that can consult these logs.

As far as a microservice system is concerned, the concept of monitoring must necessarily be extended. Parallel to a system monitoring that can be carried out with products already on the market, it also becomes necessary to monitor the flows and the exchange of messages between the various microservices. The topic is still the subject of discussion and there are different ways to tackle the problem. Below I propose the solution we generally adopt in simplematter.io for our systems.

 

 

Figure 7 – Microservices require the adoption of adequate solutions to monitor not only the system but also the exchange of messages and flows.

 

As you can see, activity logging is solved on an architectural level by introducing a further microservice able to gather all the activities coming from the varimicroservizi.

Cloud

My opinion is that the advent of microservices is deeply connected to the adoption and dissemination of cloud computing. The essential theme that is introduced by the cloud is indeed that of the deployment of applications that are hosted on the machines of the cloud service provider without the end customer knowing where they are.

The push of the cloud as a standard support for the deployment of applications necessarily leads to rethinking the way in which they are designed and developed. Microservices are the new and ideal way to face the development of applications oriented to cloud computing. In fact, if we consider what we have already said on the theme of deployment, Figure 8 does not refer to anything other than the same scenario with the simple difference that instead of the real machine we have a “cloud”.

 

 

Figure 8 – With the emergence of the cloud as a standard “support” for application deployment, microservices are the natural consequence.

 

The market

Finally, let’s see how the software market could change and the application market in general. The software market is basically characterized by two segments: that of products and services. If the model of the microservice should firmly establish itself as a paradigm of reference for software development, the first of the two segments, that of products, could undergo a not insignificant change.

The concept of software products is linked to the idea of ​​developing an application able to respond to a set of functionalities linked to a specific area of ​​problems. For example, think of products for CMS or products for document storage, and so on. Because they have to be attractive to a broad market, products tend to be developed to cover as large a range of needs as possible in a given work area: this implies that in products there is often a large number of functions that could serve, but then many users who buy that product will never use in reality. In practice, customers typically buy a set of features in excess of those they really need by paying the service to customize the product to their needs.

 

 

Figure 9 – Microservice architecture allows customers to choose and purchase only the features they need, choosing from the shelves.

 

If the microservice-oriented development model were to take hold in massive and capillary form, then the client would only be looking for the minimum set of features he really needs. He would go in search of the microservice, or the microservices, which serve to satisfy his needs.

In Figure 9 I try to show this intuition by placing the current model on the left and the hypothetical future of microservices on the right. In the current case around the product you can develop entire companies that deal with the development, maintenance, marketing and after-sales services. The idea is that there is a shop for every product. In the microservice scenario, the idea is closer to that of a large supermarket that exposes all the possible microservices that can be used both in local SaaSche, buying the executables. It will be the client himself, or those who work with him, to compose the microservices according to his needs and requirements.

What really awaits us with microservices?

Microservices are currently the subject of intense debate on the web. There are those who claim to be yet another “buzzword”; and there are those who, like me, believe that they are a real revolution. My propensity for the second hypothesis rather than the first one arises from the observation of some phenomena that, among them combined, lead me to deduce that in the next years we will see a growing use of microservices.

These phenomena are: growing awareness that the economic exchanges of the future will take place prevalently, if not exclusively on the Internet, the need to have highly flexible and scalable ICT systems with business needs, increasingly widespread use of cloud computing.

Internet as a marketplace

The first phenomenon is the one that will see the all-encompassing affirmation of the Internet as a privileged place for commerce, any type of commerce. Despite the increasingly widespread dissemination of the network in fact, we are still in a transition phase where traditional trade is combined with the digital one. I believe that the latter is destined to prevail and if this is true, it will be mandatory for everyone to have an ICT platform, no matter if minimal, with which to operate within the global and local economic center. Hence the primary need to be appropriately equipped with a suitable software infrastructure.

Need for flexible and scalable ICT systems

The second phenomenon is linked to the fact that by its nature the network is liquid and changeable, it is strongly dynamic and its “humors” change quickly. This means that to ride the waves you will need to have fast, flexible and scalable tools. What works very well today may not work very well tomorrow and vice versa. For this reason, the investments must be commensurate and proportionate to the level of business generated and, for this reason, the software platforms must follow, in terms of management costs, the trends of the developed business.

The affirmation of cloud computing

Finally, there is an increasingly important spread of cloud computing. Precisely to try to make infrastructure costs scalable with the level of business generated, the first technological response that offers these opportunities is precisely cloud computing where the infrastructure cost of software is spread annually with the purchase of solutions in SaaScosì to reduce the commitments and internal infrastructure investments to move them on the outside. Cloud is therefore the infrastructural response to the first two requirements, which, in addition to actually offering these opportunities, also offers constraints and dangers.

The highest of all is the vendor lock-in. Yes, because if it is true that I can buy at a reduced price a license for a SaaS software that resides somewhere, it is equally true that, in the vast majority of cases, I can not access and view the data of this software, nor I can handle them at my leisure; just as I do not have the possibility of entering into the merits of many flows and processes that however concern me. So I do not have access to parts of the system that could be extremely important to me. The missing link in the chain is therefore precisely the application world.

What you need is a flexible and effective way to create, move and redefine your own processes in the cloud; in other words, the need is to have total freedom to manage one’s own processes and data.

Conclusions

We have seen the characteristics of an architecture based on microservices and the differences with the traditional model based on monolithic applications. The microservices offer undoubted advantages and can really be configured as a revolution in the ICT world. Microservices are the last link in an evolutionary chain of software development that has taken place since the arrival of the Internet and goes hand in hand with the affirmation of cloud computing.

Besides the many advantages inherent in this architectural style, there are also some “dangers”, linked more than anything else to some of the natural ways in which the vendors manage their cloud services. For this reason, in addition to the fact that it will become essential to understand the features and data we need, it will also become essential to have a concrete modus operandi to do it, and do it quickly.

The core of their action in the network will be software architectures: they will be our feet, our hands and our heads in the Internet arena.