Development of architecture for dummies. Part 2

This is a continuation of the article about architecture development: https://habr.com/ru/post/658145/

Monolite or MicroService?

In fact, quite often I see a situation that in programming it happens exactly like this:

Programmers have often been working with microservices lately and often try to embed them where they are not needed. Microservices are naturally good, but as always, this is not a silver bullet that can solve any problems, but rather, on the contrary, will add them.

Let’s first take a look at what a monolith is and its advantages and disadvantages.

In fact, I think that you don’t even need to describe what a monolith is, everything is clear here. The entire application is in one repository and is essentially a separate, independent project that you can run.

Monolith advantages:

Easy application development and deployment
Fewer networking and server-to-server issues
Better performance
Easy to Prototype

But the monolith also has disadvantages:

SCALABILITY

In fact, scalability is almost the main and only problem of monoliths. And now I’m talking about scalability, both in terms of performance (how many users can use your application at the same time), and in terms of team size, because the larger the project, the more difficult it is to maintain good code quality and remove the relationships between different parts of the project. Now this is more important than ever, especially when services have become giants and almost every application allows you to order a taxi, buy air tickets or just flowers for your girlfriend…

Service-oriented architecture (Microservice)

Microservice architecture implies that we break our application into many small, independent applications that, in theory, can work independently, but still this does not always work out, but in an ideal world, if one service falls, this should not affect our system much and all other services should continue working without interruption. But like I said in the real world it doesn’t always work the way it should. In the following picture, you can see the difference between monolith and microservice architecture.

But why is microservices so difficult?

Complex application deployment (you need to deploy many services and many databases and configure their interaction
We get a new layer like a network (many do not take this into account when designing architecture, but in large systems, it is the network level that can be the “bottleneck” that your system rests on when scaling)
More microservices = slow (do not forget also that data transfer over the network takes time, serialization and deserialization also require processor time, so if we have many microservices that call each other sequentially, this can slow down the final result compared to a monolith)
Complex horizontal scalability (you need to correctly configure the interaction of all your services and their correct linking)
We need to work with Kubernates / OpenShift (of course, we do not plan to deploy everything manually, so we will have to learn how to work with one of these software products)
We want good logs (and even when getting logs, there is a difficulty. Of course, we can collect the logs all together in one place, but in this case, all the logs will be mixed up and it will be difficult to understand them, so we need to learn how to collect the logs correctly)
We need to check our services for uptime (in the case of working with a monolith, we don’t have big problems, we just ping that our service is alive and that’s it, when working with microservices, we need to check each service for survivability)
We need an architect to develop (as already described above, there are many problems, so a good architect is indispensable)
Testing a microservice architecture is harder (testing has long been the standard of the IT industry, and you will need to deploy the system every time, which will require more resources and more time to debug it)
Storage configuration for our services (when we have grown to the scale when the monolith can no longer cope, we will probably need more disk space with which we will work, making a distributed storage system is also not always a trivial task)
Access control (it is also required to keep track of each service and try to understand which service has access to the open world, which works only from other microservices)

As we can see, there are quite a lot of problems when working with microservices and they are not always trivial. Naturally, here I did not indicate all the problems that may arise, but I tried to voice the main ones.

But if it’s so hard, why does everyone want microservices?
Here the answer is quite simple, it is scalability. A well-built microservice architecture can scale almost without limits.

Let’s also look at one of the fairly common architectures that is used in microservice architectures, sorry for the tautology.

API Composer

Let’s say we have some kind of payment service that should accept payments from Qiwi, from cards and cryptocurrency. In this case, we can make an API composer and make a single interface for working with payment data. It will look like this:

As we see in the picture, at the beginning we have a request that goes to the Composer API and after that it goes to the service it needs. There is almost no logic in the Composer API and it will be almost unloaded, for that for us it will be a single entry point for all payment options.

API Composer (Gateway)

Also one of the popular varieties of the Composer API is GateWay. Gateway is usually referred to as a single entry point for your application with minimal logic. It looks something like this:

As we can see in this picture, we have a lot of clients who all access the single Gateway API, and after that the Gateway itself chooses which service it needs to go to. Usually they try not to load API Gateway with logic, but often they put logic there that is responsible for some basic things in the application.

Authorization
Security
Error Handling
Data caching
Compressing and cleaning data before sending it to the client
Specific work with platforms, for the web, for example, we can use HTTP REST (JSON), and for mobile platforms, it may be more beneficial to use protoBuf.
Load balancing between servers

To implement the Gateway, we can use a regular application and write it from scratch on our own, but the market already offers us standard implementations of it, here is just a list of them

Amazon API Gateway
NGinx API Gateway
Netflix Zuul
Tyk
Google API Gateway
Akamai Api Gateway

You can read more about working with API Gateway on the website, there are a lot of interesting things: https://microservices.io/patterns/apigateway.html

But if microservices are so difficult, surely there are already some ready-made tools for this? Yes, I have!

I am a Java developer, so I will give an example from the Java world.

j hipster

In short, JHipster includes everything we need to develop large applications and microservice architecture.

If we look at the picture that I took from the JHipster website, we will see a lot of interesting things

firstly, it is immediately clear that Docker, Spring Boot, Logstash, Consul and other technologies necessary for microservices are used. You can also immediately wrap containers in kubernates there. In general, JHipster is highly configurable and you can choose from many different technologies that will be used in the project. It is possible to choose from various databases and various front-end technologies. The list is really very extensive and within the framework of this article I will not be able to disclose it.

Here is an example of initializing a new microservice application

In general, these hipsters can make the life of a Java programmer a little easier, or vice versa, if they don’t understand the project enough.

But do not forget the basic rule when creating a new project.

There is a classic rule formulated by Martin Fowler, which is MonolitFirst. This rule means that any project that you start developing from scratch should first be developed from a monolith, and then cut into microservices. This rule really helps to launch the project faster and understand in reality what problems the project has and how exactly it should be cut into microservices.

It will also be useful to read various books on the topic of microservice architecture, here are just a few of them: