Microservices are a way of breaking a large application into loosely coupled modules that communicate with each other through a simple API.
Lately, only dumb people haven't talked about microservices. This is becoming more and more popular. The modular architectural style seems particularly well suited to cloud-based environments and is growing in popularity. Before we get into the details, let's take a bird's eye view of everything . Therefore: Microservices are a way of breaking a large project into small, independent and loosely coupled modules. Independent modules are responsible for clearly defined and discrete tasks and communicate with each other through a simple and accessible API. In other words, microservices are simply a different architectural style for designing complex, mostly web applications. But what's so bad about existing architectural solutions such as SOA (Service oriented architecture)? Most modern enterprise solutions written using SOA seem to work quite well. This might be a great time to talk about some of the challenges the industry is facing these days... Let's start with a simple example. Let's say I need to run a classic application written in Java. First I will develop the User Interface, then the business logic layer, with several components that will interact with the UI, and finally the database layer, which will be accessible to the persistent database. Now according to the fact that I want to run the application, I will create a WAR/EAR/JAR and mount it on a server (such as JBoss, Tomcat or WebLogic). Since this is done all in one, I get a monolithic application, which means that all the components are in one place... Example in the picture:
Most likely, you are already familiar with this approach and have used it, but the idea is to use this example to show what challenges developers will have to face using this architectural solution. Monolithic application: challenges challenges
As the application grows, so does the amount of code written, which may well overload the development environment every time you need to open it. This definitely reduces the developer's efficiency.
Since everything has to be mounted in one place, this leads to the fact that switching to another programming language or switching to other technologies is a big problem. For example, you wrote an application in Java, and after a while Kotlin came out and you were eager to rewrite it to it, because it was promoted as cooler, better, faster. With a monolithic application, even thinking about refactoring will cause real pain, not to mention the process itself. There are currently many applications that are made this way and the number of lines of code is simply incredible.
If any of the components stops working for any reason , the entire application will also crash. Just imagine that there is a web application that has modules such as authorization, payment, history, etc. And for some reason one of them breaks. This is simply a shock for business and, as a result, for developers.
Scaling a monolithic application can only be achieved by raising another application of the same type. But what if you only need to scale one component, and not the entire application. How many resources will be wasted?...
This can have a big impact on the development process and the installation process of the application. The larger the application, the more important it is that developers can divide the application into smaller working parts. Because all the modules in a monolithic application are connected to each other, developers cannot work/mount these modules independently of each other. Since developers depend on each other, development time increases.
At the same time, we are ready to consider and understand the meaning of microservices, namely how they can be used to restore the flexibility that was lost with the SOA style. God Microservices to the rescue One of the most important characteristics in any architectural solution is scalability. While I was learning microservices for the first time, I saw that everything was so similar to quotes from the book “The Art of Scalability”. This is a great start and place for discussion. This book defines the so-called "Scalability Cube" model, which describes a three-dimensional scalability system:
As you can see, the X axis describes "horizontal scaling" (which we have seen is also available for monolithic architectures), the Y axis represents scaling in the sense of separating different service components . The idea of the Z axis is understood when the data is divided and the application sends requests to exactly where the data is located. That is, they are not all in one place. The idea of the Y axis is the one we will focus on in more detail. This axis represents a functional decomposition . In this strategy, different functions can be considered as independent services. Therefore, by mounting the entire application only when everything is done, developers can mount individual services independently of each other and not wait for others to finish working on their modules. This will not only improve development time, but also offer the flexibility to change and rewire without having to worry about the rest of the application components. Let's compare this diagram with the previous monolithic one:
Microservices: Benefits The benefits of microservices seem to be quite sufficient to convince enterprise developers such as Amazon, Netflix, Ebay to start using this approach. Unlike monolithic architectural applications, microservices:
Improves component failure isolation: Large applications can continue to run efficiently even if a single module fails.
Eliminates the application's commitment to one technology stack: if you want to try a new technology stack on some service, go ahead. Dependencies will be much lighter than with a monolithic one, and it will also be much easier to roll back everything. The less code in one application, the easier it is to work.
Makes it much easier for new employees to understand the functionality of the service.
Microservices: features of mounting and virtualization Now we understand what microservices are. And the greatest advantage is that it is mounted by more than one WAR/EAR/JAR archive. But how is it installed? The best way to mount microservices inside containers. A container is a fully configured virtual operating system with the necessary environment configured, which helps isolate access to the resources of the hardware system on which the container is installed. The most famous solution on the market is of course Docker . Virtual machines from IaaS (infrastructure as a service) such as AWS can also work fine for mounting microservices, but relatively lightweight microservices may not use all the resources that are in the virtual machine, which can reduce the profitability of use. You can also mount your microservices using the OSGI (Open Service Gateway Initiative) package. In this case, all microservices will run in a single JVM, but this involves trade-off issues between control and isolation. Microservices: Disadvantages Just because “this is all cool” and “we haven’t seen this before” does not mean that there are no disadvantages. Below is a list of possible areas of pain that microservice architecture brings with it:
Developing distributed systems can be difficult. By this I mean that all components are now independent services - you need to very carefully handle requests passing between modules. There may be a scenario where one module is not responding, forcing you to write additional code to avoid crashing the system. This can be more difficult if the remote calls are latency sensitive .
Multiple databases and transaction management can be a real pain.
testing microservice applications can be cumbersome. Using a monolithic application, we only need to run the WAR/EAR/JAR archive on the server and make sure it is connected to the database. And in microservices, each individual service must be started before testing can begin.
Mounting applications can be tricky. They may require coordination around multiple services that may not be as easy to mount as a WAR container.
.... Of course, with the right tools and approaches these disadvantages can be avoided. But they themselves require support and do not completely solve all problems. The article was translated from the CloudAcademy website . Free translation. Everyone is free to express all their thoughts in the comments. They will definitely be read. Original article My Github account
GO TO FULL VERSION