Microservice architecture
Читати це саме на Укрїнській
The term “Microservice Architecture,” also known as microservice, appeared in the middle of 2010 to describe the special architectural style of software development. This development style has been spread due to the development of flexible development practices and DevOps. At the moment, the micro-service architecture is paying a lot of attention: articles, blogs, discussions in social networks and presentations at conferences. When it comes to providing flexible development and delivery of complex enterprise applications, this development method has significant benefits.
In short, the architectural style of the microservice is an approach where a single application is built as a set of small, self-sufficient, independent, not closely related services communicating with each other with the help of light mechanisms like HTTP, gRPC, AMQP. These services are built around the business needs (each responsible for a particular process) and deployed independently of using a fully automated environment. There is an absolute minimum of centralized management of these services. Services themselves can be written in different languages and use different data storage technologies.
Causes of use
One of the reasons for using microservices is that companies want to be able to quickly change something in order to respond faster to changes in business requirements, ahead of competitors. The micro services help developers deliver faster, safer, and higher-quality changes, that is, keep the product’s development speed even when it’s immensely large. After all, not closely connected services allow to make changes with a greater frequency of iterations, minimizing the effect of changes on the rest of the system.
With all this, one should not forget that such an approach adds additional complexity to the project as a whole. We need DevOps for monitoring and management, with both developers and developers there should be close relationships and good interactions. When working with microservice, we have to deploy more, the monitoring system is complicated, and the number of possible failures is greatly increased. Therefore, a strong DevOps culture is very important to the company.
Microservice vs monolith
In order to make it easier to get acquainted with the micro-server architecture, you need to compare this development style with the so-called monolithic style.
Monolith is built as a unit. Any changes, even the smallest, need to be rebuilt and deployed throughout the application. Over time, it’s more difficult to maintain a good modular structure, changing the logic of one module tends to affect the code of other modules. Monolithic programs can also be difficult to scale up when different modules have conflicting resource requirements. For example, one module can implement the processing logic with intensive use of the processor. Another module may be demanding to use RAM. However, since these modules are deployed together, you will have to compromise with the choice of hardware. The whole application needs to scale up, even if it is required only for one module of this application.
Microservice, on the contrary — each microservice is deployed separately. So if you change something in one of them, you can deploy these changes without touching other microservices that can continue to work.
Therefore, increasingly web projects are developed as separate services that can be deployed and scaled individually.
But the micro-service architecture is constantly criticized from the moment its formation, among the new problems that arise when its implementation is noted:
- network delays: if the modules that perform several functions, the interaction locally, then the microservice architecture imposes the requirement of atomization of modules and their interaction over the network;
- message formats: the lack of standardization and the need to match the exchange formats actually for each pair of interacting microservices leads to both potential errors and complexity of debugging;
- load balance and fault tolerance;
- the complexity of operating support — requires competent DevOps-engineers, continuous deployment and automatic monitoring. Without all this, the micro-service should not be used;
- testing of microservices can be cumbersome. Using monolith, we only need to run the application on the server and be sure of the database. And in microservices, every single service must be started before you start testing.
Advantages and disadvantages of microservice
The advantages include:
- The services run faster, which makes developers more productive and accelerates deployment.
- Each service can be deployed independently of others. So if you change something in one of them, you can deploy these changes without touching other microservices that can continue to work.
- Each service can be scaled individually.
- A bug in one micro-service will not undermine system operation. Problems with the microservice should not break the entire application. Most likely, they will not significantly affect the work of the application, especially the large one.
- Eliminates any long-term commitment on technology. When developing a new service, you can choose a new technology stack. Any service in the system can be replaced. It can be rewritten from scratch within a reasonable time and budget without the need to rebuild the entire system.
- Microservice, as a rule, are better organized, since each microservice has a very specific job and is not engaged in the work of other services. They are therefore potentially easier to understand, support and test.
- Separate services are also easier to rebuild and reconfigure to perform tasks for different applications (such as serving web clients and public APIs).
Disadvantages of microservice:
- Developers should deal with the added complexity of creating a distributed system.
- The complexity of deployment. The production also has the operational complexity of deploying and managing a system consisting of many different types of services.
- When you build a new micro service architecture, you will probably find many of the many problems that you did not expect during development.
Microservice as overcoming complexity
Many well-known companies have solved the monolith problem by adopting the architecture of the microservice, instead of building a single monstrous monolith. Among them, we have Amazon, eBay, Walmart, Netflix, SoundCloud, Spotify, Twitter, Stripe, PayPal, Uber and Medium.
By the way, I found the article by one of the developers of Medium on the transition from monolith to microservice just recently.
Implementation of Netflix was so successful that they discovered a lot of software tools that developed their architecture of microservices. Today, Netflix can be considered the pioneering development of microservices, and their approach has become the subject of research for many other companies around the world.
Conclusion
Creating complex applications by its very nature is difficult. The monolithic architecture makes sense only for simple, lightweight applications. Ultimately, you will fall into the world of pain if you use it for complex applications. The micro-service architecture, despite the drawbacks and implementation problems, is the best choice for sophisticated, ever-expanding products.
From my own experience with the micro-service architecture I can add. If the monolith is divided into separate parts and does not take into account the key principles of designing an architecture oriented to the micro-service, this can create problems, not an elegant solution.
As a full stack developer interested in Docker and Kubernetes technology, I share the principle of “Under each task is a suitable tool”. Microservice architecture is very impressive.
