Imagine you have created a company and ordered a website for it. You turned out to be a good businessman: sales are growing, and more and more customers are opening new branches. We have to add more and more new features to the site to satisfy the needs of visitors.
At some point, the volume of the code grew to complete works of art. As a result, updates are taking longer to develop, and testing them is becoming more difficult. This is a standard problem for complex software. You can solve the problem of bottlenecks in the project using microservices: wherever there are “heavy” processes, theoretically they can be moved to a special environment.
In simple words – you take on a difficult and clumsy process. You remove it from the application and run it in a separate container, where it works by itself. And then contact him if necessary.
A microservice (or service, they call it differently) can be both large and minimal – it doesn’t matter. For some programming languages, this is easier to implement, for others it is more difficult.
What is the problem with monolithic architecture?
The monolithic approach is considered classic and implies that all the work of the application is implemented on the same code base. It’s easier to develop that way thanks to dedicated software developers. You can implement the necessary functionality without thinking about the problems of component communication.
Applications built on a monolithic architecture (or simply monoliths) are not necessarily single-function applications. They contain separate classes and functions, but they are tightly coupled to each other. The removal of one module inevitably causes changes in the operation of the entire system. Hence, a number of significant shortcomings:
To make one change, you need to rebuild the entire application.
It is impossible to scale a single module – you have to redo the entire application.
Development is limited to the initially selected set of programming languages, frameworks, and other tools. I would like to use something alternative – sorry, we do not have this, work with what is.
One module is broken – most likely, the entire service will stop working.
The complex structure of links between modules slows down the release of updates. Each requires serious testing for bugs and code regressions (new bugs in already tested functionality). Accordingly, a bunch of changes appear in one update.
At first, the application has a clear structure and quickly develops. And then it started: a long and complex code, the framework of modules is gradually being erased, and more and more non-obvious relationships appear between the components.
Difficulties arise with the project team. Each participant needs to have expertise in all business functions, which becomes more and more difficult over time. It takes much more time to add a new programmer to work – he will need to study the whole kilometer of code.
Why is microservice architecture good?
The spread of cloud services by the beginning of the 2010s led to the disappointment of developers in the classic version of the application architecture. A distributed system of easy-to-replace modules known as “microservices” was suggested as an alternative. They ought to carry out one simple task before passing it on, much like conveyor workers. At the same time, Microservices are constructed symmetrically rather than hierarchically..
Each individual service can be programmed in a language that will be convenient by the team of Peiko.space. This independence makes it possible to divide the development of system components between independent teams. A developer who joins the team masters the functional features of only the microservice with which he has to work, and does not study the entire system.
