Creating a new product is always risky. And choosing the right architecture is an important step towards success. If you choose between a monolithic, service-oriented, microservice and serverless architecture, this post will help you make the right choice.
Monolith – This is an ancient word denoting a huge stone block. Although the term is widely used today, the view remains the same in all areas. In software engineering, a monolithic model refers to a single indivisible unit. The concept of monolithic software is that the various components of the application are combined into one program on the same platform. Typically, a monolithic application consists of a database, a client user interface, and a server application. All parts of the software are unified, and all its functions are managed in one place. Let's look at the structure of monolithic software in detail.
Monolithic architecture is convenient for small groups, so many startups choose this approach when creating an application. Components of monolithic software are interconnected and interdependent, which helps the software to be self-sufficient. This architecture is a traditional solution for building applications, but some developers consider it obsolete. However, we believe that monolithic architecture is an ideal solution in some circumstances.
Although we have had positive experience using microservices at Google, we [в Scaylr] We went along a monolithic route, because having one monolithic server implies less work for us as two engineers.
Stephen Cherwinski, Head of Design, Scaylr
To find out if this solution is suitable for your business, let's look at its pros and cons.
The advantages of monolithic architecture
Simplified development and deployment
There are many tools that you can integrate to facilitate development. In addition, all actions are performed with one directory, which simplifies deployment. Thanks to the monolithic kernel, developers do not need to deploy changes or updates separately, as they can do it right away and save a lot of time.
Less cross-cutting issues
Most applications depend on many cross-component tasks, such as audit trails, logging, speed limiting, etc. Monolithic applications are much easier to take into account these issues due to their common code base. It is easier to connect components to these tasks when everything works in one application.
When properly assembled, monolithic applications are usually more productive than microservice-based applications. For example, an application with a microservice architecture might need to make 40 API calls for 40 different microservices to load each screen, which obviously leads to poor performance. Monolithic applications, in turn, provide faster communication between software components thanks to common code and memory.
Cons of monolithic architecture
The code base becomes cumbersome over time
Over time, most products continue to be developed and expanded, and their structure becomes blurred. The code base begins to look really bulky and becomes difficult to understand and change, especially for new developers. It is also becoming increasingly difficult to find side effects and addictions. As the code base grows, the quality worsens and the IDE gets overloaded.
Difficult to introduce new technologies
If some new technology needs to be added to your application, developers may encounter obstacles to implementation. Adding new technology means rewriting the entire application, which is expensive and time consuming.
In monolithic applications, every small update requires a full redeployment. Thus, all developers must wait until this is done. When multiple teams work on the same project, flexibility can be greatly reduced.
The monolithic model is not outdated, and in some cases it still works great. Some giant companies, such as Etsy, remain monolithic, despite today's popularity of microservices. The architecture of monolithic software can be useful if your team is at the initial stage, you create an unverified product and do not have experience with microservices. The monolith is ideal for startups who need to get the product into operation as quickly as possible. However, some of the problems mentioned above go hand in hand with monolithic architecture.
Service-oriented architecture (SOA) is a style of software architecture that involves a modular application consisting of discrete and loosely coupled software agents that perform specific functions. SOA divides components into two main roles: service provider and consumer. Both of these roles can be played by software agents. The concept of SOA is this: an application can be designed and built in such a way that its modules are easily integrated and can be easily reused.
Pros of SOA
Reuse of services
Due to the autonomous and loosely coupled nature of functional components in service-oriented applications, these components can be reused in several applications without affecting other services.
Because each software service is an independent unit, it is easy to update and maintain without affecting other services. For example, large enterprise applications are easier to manage when they are broken down into services.
Services are easier to debug and test than huge chunks of code, as in monoliths. This, in turn, makes SOA-based products more reliable.
Because service-oriented architecture is layered, it supports concurrency in the development process. Independent services can be developed in parallel and completed at the same time.
Cons of SOA
Difficulty in managing
The main drawback of service-oriented architecture is its complexity. Each service should provide timely message delivery. The number of these messages can exceed a million at a time, which makes it difficult to manage all services.
High investment costs
SOA development requires significant upfront investment in human resources, technology, and development.
In SOA, all input is validated before one service interacts with another service. When using multiple services, this increases response time and reduces overall performance.
SOA is best suited for complex enterprise systems such as banking. The banking system is extremely difficult to divide into microservices. But a monolithic approach is also not suitable for the banking system, since one part can damage the entire application. The best solution is to use the SOA approach and organize complex applications into isolated, independent services.
This concludes the first part of the translation, and we will talk about microservices and serverless architecture in the second part of the material.