by Tyukavkina Ekaterina (entiukavkina@edu.hse.ru)
A monolithic architecture is a traditional model of a software program, which is built as a unified unit that is self-contained and independent from other applications. The word “monolith” is often attributed to something large, which is not far from the truth of a monolith architecture for software design.
А monolithic architecture is a singular, large computing network with one code base that couples all of the business concerns together. To make a change to this sort of application requires updating the entire technology stack by refactoring the code base and building and deploying an updated version of the service-side interface. This makes updates restrictive and time-consuming [2].
Monolithic architecture applications are common in the information technology industry because of the simplicity of its development but also because “many companies have already got running monolithic systems which are still great value in business”.
Over time the monolith tends to increase its complexity making it hard for the developers to fully understand the system thus slowing development cycles and consequently the delivery of value to the clients. The increase of complexity will also make the components of the system easily become tightly coupled, hindering the evolvability of the code, and the reliability of the application may also decrease since one bug can turn the application unavailable [1].
When the number of in-house custom applications started exploding and there was a need for data standardization, a common language to describe enterprise objects and de-coupled services with standards requests and responses.
Some organizations like IBM started developing their own XML based engines around message queues and JMS standards while others adopted the early service bus products from vendors. Thus Service-Oriented Architecture (SOA) was born with lofty goals to build canonical enterprise data models, reduce point-point services (Java applications had a build-time dependency to services they consumed, other Java services), add standardized security, build service registry [3].
SOA is an architectural style that focuses on creating and organizing software systems as a collection of loosely connected and interoperable services. In SOA, each service represents a specific business function or piece of functionality and may be developed, deployed, and maintained independently. These services communicate with one another via well-defined interfaces, generally utilising standardised protocols like HTTP or SOAP.
Here are five prevalent design patterns used in Service-Oriented Architectures (SOA):
Microservices Architecture (MSA) was first introduced in 2011 at a software engineering workshop in Venice. This type of architecture evolved from SOA, but unlike it, they allow to develop applications that are a set of services, rather than a single monolithic code. Each of them is independent software with its own functionality and database. This approach simplifies application modification and maintenance. It is assumed that refactoring and redeployment of several services will be enough, rather than redesigning and releasing a new version of the monolith.
This is a much simpler architecture than SOA. Today, SOAP has been largely replaced by the REST protocol, which works with a simpler data exchange standard, JSON. Microservices present itself as a solution to solve some of the problems presented by the MA. Lewis and Fowler define MSA “as an approach to developing a single application as a suite of small services, each running in its process and communicating with lightweight mechanisms, often an HTTP resource API”. By breaking the application on a set of services the deployment process becomes easier because code changes only require the deployment of the corresponding service, reducing the complexity making it easier to understand the code and consequently to develop and maintain it. By reducing the complexity, the development cycles become faster turning the continuous integration also easier. Independent services enable the independent scaling and better implementation of the agile process, for instance, a company can have a set of teams working independently with their development cycles and technologies of their choice [1].
Here are five famous design patterns used in microservices:
Monolithic approach may be one of the best approaches for smaller applications that are not expected to grow. In applications where maintenance and scalability is irrelevant, the monolith can be a more optimal choice.
It is not always possible to predict at the start of the project that the project will not grow. Many projects have the ambition to have only small changes and fixes and their scaling and growth are not considered. Later on, the need to scale appears and the project's architecture is already a large-scale complex monolith. This happens very often as the future is always unpredictable and it is impossible to read the minds of all possible potential customers. As the monolith grows it brings problems with maintainability and scalability to the point that the system is almost unable to efficiently evolve under current architecture. And in this case, an option to migrate to microservices might be a solution.
However, its disadvantages should be carefully considered, incorrectly implemented microservices can have fatal impacts. For instance, if a service built with different technologies is maintained only by one person who later leaves the company and the person is the only one in the company who can work with the technologies used in the service, it becomes impossible to maintain or extend the service.