The architecture of microservices or microservices to dry, is a distinctive system of software development that has grown in popularity in recent years. In fact, although its extension in use has not gone as far as its theory has, many developers are discovering how this form of software creation favors the time, performance and stability of their projects. Thanks to its simple scalability, this method of architecture is considered especially appropriate when you have to ensure compatibility with a wide sector of different platforms (IoT, web, mobile, wearables) or simply when we do not know for sure what type of devices are orienting our work If there is no standard or formal definition for microservices, there are certain characteristics that help us identify them. Basically the development of a project based on this method forms an application or tool through the conjunction of various independent services that are deployed as they are needed. Therefore, we will have a modular application based on “small pieces”, which we can expand or reduce as required. And the question that many will ask is how do I communicate one service with another? And it’s like asking what computer bought me? The answer will depend on our skills, preferences or the system that best adapts or requests … Many use HTTP / REST with JSON or Protobuf, but since the developers are you, use what you consider best, although REST it is positioned in extension of use as it is one of the integration methods whose learning curve and use is incredibly fast compared to other protocols.
There is no better way to know the scope that this method of development has had than to see who they have implemented it. Many websites that serve large-scale applications have decided to invest in the evolution towards microservices in view of a future where the maintenance and scalability of their products is much simpler, more effective and faster. We are going to highlight some of these companies, which even sound familiar to you:
Netflix: This platform has a generalized architecture that for a couple of years (coinciding with its “boom” in the USA) was transferred to microservices for the operation of their products. Every day it receives an average of one billion calls to its different services (it is said that it is responsible for 30% of Internet traffic) and is capable of adapting to more than 800 types of devices through its streaming video API, which to offer a more stable service, for each request we ask, it makes five requests to different servers to never lose the continuity of the transmission.
Amazon: It does not support as many devices as Netflix, but neither is it fundamental to cover its sector. It migrated three years ago to the architecture of microservices being one of the first large companies that implemented it in production. There is no approximate figure of the number of requests that can receive daily, but they are not few. Among these we find many applications, the APIs of the web service offered or the Amazon website itself, whose engineers recognize that it would have been impossible for the monolithic architecture with which they previously worked.
Ebay: Of course, one of the companies with the greatest vision of the future, being a pioneer in the adoption of technologies such as Docker or this one that concerns us. Its main application includes several autonomous services, and each one will execute the logic of each functional area that is offered to the clients. Understanding the Architecture of Microservices. But to understand the architecture based on microservices, it is best to consider its opposite, its nemesis , the monolithic architecture. In this, the application is developed as a single unit that will not need any external component to operate. For example, in an application like the one we developed a few days ago in Meteor that has one side of the client and one server side, the “monolith” client will take care of the HTTP requests, execute the logic and receive / update the information from the database. The problem of monolithic applications is that all “change cycles” are linked to each other, so the slightest modification in a remote section of the app would lead to the creation and deployment of a completely new version. , with the corresponding expenditure of resources. Not to mention if we want to scale a specific section of the project or directly the entire application; and this is where developers have seen the potential of microservices.
Characteristics of the microservices software. As I said there is no standard in these architectures, but we can highlight several common characteristics to a greater or lesser extent: The software built on the basis of microservices can be decomposed into several independent functional parts. Thus, each of these services can be deployed, modified and re-deployed without compromising the other functional aspects of the application; and as a result if needed, we will only have to modify a couple of services instead of redeploying the entire application again. The way in which microservices are organized is usually around the needs, capabilities and priorities of the client or business in which it will be implemented. Unlike a monolithic environment where each team has a specific focus on a section of the application, in the microservice architecture multifunctional modules are used, thus adapting a module common to all to offer a specific service. The savings in development time is immense, not to mention the comfort at the time of programming maintenance tasks, where we can review a module while the rest of the work team does not see their work interrupted. The operation of the microservices software may resemble to the classic UNIX work system (a request is received, processed and a consistent response is generated.)
Unlike ESB (Enterprise Service Buses) environments where equipment is used to route messages, redirect traffic, apply access denial rules etc … You could say that the microservices architecture has “intelligent” endpoints that process the information in term and apply the logic established by the developer.
The microservices architecture maintains a system similar to a decentralized government , where each module will have, for example, its own database, instead of everything sa the same overloading it of requests and risking that if this fails, all the application falls.
When several services are communicated with each other, usually will have a warning and action system if any of these services fail (as show a warning, send an email to support, notify users of a temporary failure, etc …), properly filtering the information for this module and favoring the correct management of resources between the remaining functional modules. Pros / Cons. what are microservices, their main features and some examples in which they have been implemented successfully, I leave you some pros and cons of this technology:
Pros: It gives developers the freedom to develop and deploy services independently.
A microservice can be develop with a minimum work team.
You can use different programming languages in different modules.
Easy integration and automatic deployment (for example with Jenkins …).
Easy to understand and modify, so the integration of new members to the development team will be very fast.
Developers can make use of the most current technologies.
The use of containers will make the development and deployment of the app much faster.
Modular functionality, so that modifying a module will not affect the operation of the rest.
Easy to scale and integrate with third-party applications. Cons: Testing or testing can be complicated due to distributed deployment.
A large number of services can lead to large blocks of information to be managed.
It will be the task of developers to deal with aspects such as network latency, fault tolerance, balancing load, number of supported formats, etc … Distributed system can mean double work.
If you have a large number of services, integrate and manage them can be very complex.
This technology usually incur a high consumption of memory.
Application in different microservices can take many hours of planning (and could almost be considered an art)