Best architecture for MVP: monolith, SOA, microservices or serverless? .. Part 2

In November, OTUS launches a new educational program, “Software Architect,” in connection with this we continue a series of publications for future students of the course and readers of our blog.

Read the first part

Microservice architecture

Microservices are a type of service-oriented software architecture that focuses on creating a number of stand-alone components that make up the application. Unlike monolithic applications created as a whole, microservice applications consist of several independent components that are glued together through the API.

The structure of microservices and monolithic architecture in comparison

The microservice approach focuses mainly on business priorities and opportunities, while the monolithic approach is organized around technology levels, user interfaces, and databases. The microservice approach has become a trend in recent years as more and more enterprises become more flexible and switch to DevOps.

Microservices are important simply because they add unique customer value by simplifying systems. By breaking down your system or application into many smaller parts, you are implementing a way to reduce duplication, increase consistency, and reduce communication between parts, which makes your common parts of the system more understandable, more scalable, and easier to change.
Lucas Kraus, author of Microservices

There are many examples of companies that have evolved from a monolithic approach to microservices. Among the best known are Netflix, Amazon, Twitter, eBay and PayPal. To determine if microservices are appropriate for your project, let's identify the pros and cons of this approach.

Pros of microservices

Easy to develop, test and deploy

The biggest advantage of microservices over other architectures is that small separate services can be created, tested, and deployed independently. Because the deployment unit is small, it makes development and release easier and faster. In addition, the release of one unit is not limited to the release of another, which is not yet complete. And the last plus here is that deployment risks are reduced as developers release parts of the software, not the whole application.

Increased flexibility

With the help of microservices, several teams can work on their services independently and quickly. Each individual part of the application can be built independently due to the isolation of microservice components. For example, you may have a team of 100 people working on the entire application (as in a monolithic approach), or you may have 10 teams of 10 people developing various services.
Let's imagine it visually.

Increased flexibility allows developers to update system components without shutting down the application. In addition, flexibility provides a more secure deployment process and increased uptime. New features can be added as needed without waiting for the entire application to launch.

The ability to scale horizontally

Vertical scaling (using the same software, but on more powerful machines) may be limited by the bandwidth of each service. But horizontal scaling (creating more services in one pool) is not limited and can work with microservices dynamically. In addition, horizontal scaling can be fully automated.

Cons of microservices


The biggest drawback of microservices is their complexity. Separation of the application into independent microservices entails more management artifacts. This type of architecture requires careful planning, tremendous effort, team resources and skills. The reasons for the high complexity are as follows:

  • Increased demand for automation, as each service must be checked and controlled
  • Available tools do not work with service dependencies
  • Data consistency and transaction management is getting harder as every service has a database

Security concerns

In a microservice application, every functionality that interacts through an external API increases the likelihood of attacks. These attacks can only happen if the proper security measures are not taken when creating the application.

Different programming languages

The ability to choose different programming languages ​​is a double-edged sword. Using different languages ​​complicates deployment. In addition, it is more difficult to switch programmers between stages of development, when each service is written in a different language.


Microservices are good, but not for all types of applications. This template is great for developing applications and complex systems. You can think about choosing a microservice architecture when you have some experienced teams and when the application is complex enough to break it down to services. When an application is large and needs to be flexible and scalable, a microservice architecture is beneficial.

Now we can compare these three software architectures to visually identify the differences between them.

Monolithic applications consist of interdependent, indivisible blocks and have a very low development speed. SOA breaks down into smaller, moderately related services and is slow to develop. Microservices are very small, loosely coupled independent services that are characterized by rapid development and continuous integration.

Serverless architecture

Serverless architecture is a cloud computing approach for building and running applications and services without the need for infrastructure management. In serverless applications, code execution is platform-driven, allowing developers to deploy code without worrying about server maintenance and maintenance. In fact, serverlessness does not mean "no server." The application still runs on the servers, but a third-party cloud service such as AWS is solely responsible for these servers. Serverless architecture eliminates the need for additional resources, application scaling, server maintenance, and storage and database systems.

Serverless architecture includes two concepts:

  • FaaS (Function as a Service) – A cloud computing model that allows developers to upload parts of functionality to the cloud and allows these parts to be executed independently
  • BaaS (Backend as a Service – backend as a service) – A cloud computing model that allows developers to outsource aspects of the backend (database management, cloud storage, hosting, user authentication, etc.), as well as write and support only part of the external interface.

Here's how a serverless structure looks like

Using a serverless architecture, developers can focus on the product itself without worrying about server management or runtimes. This allows developers to focus on developing products with high reliability and scalability.

There are many cloud providers on the market. Here are some of the leading serverless computing providers:

Leading serverless computing providers

To find out if this type of architecture is needed for your project, let's determine the advantages and disadvantages of implementing a model without a server.

Pros of serverless architecture

Easy to deploy

In serverless applications, developers do not have to worry about infrastructure. This allows them to focus on the code itself. Serverless architecture allows you to quickly deploy an application, since deployment takes only a few hours or days (compared to days or weeks with the traditional approach).

Cost reduction

The move to serverless architecture reduces costs. Since you do not need to process databases, some logic and servers, you can not only create better code, but also reduce costs. When using a model without a server, you only pay for the CPU cycles and memory that you actually use.

Enhanced scalability

Many business owners want their apps to be powerful and scalable like Google or Facebook. Serverless computing makes scaling automatic and smooth. Your application will automatically scale when the load or user base increases, without affecting performance. Serverless applications can handle a huge number of requests, while traditional applications will be overloaded with their sudden increase.

Disadvantages of serverless architecture

Supplier binding

Supplier binding describes a situation where you give the supplier complete control over your operations. As a result, changes in business logic are limited, and migration from one provider to another can be difficult.

Not for long-term tasks.

The serverless model is not suitable for long operations. Serverless applications are good for short processes in real time, but if the task takes more than five minutes, the serverless application will require additional FaaS features.


Serverless software architecture is useful for solving one-time tasks and supporting processes. It works great for client-rich applications and applications that grow rapidly and need unlimited scale.

Finally, let's look at the following image to find out when to choose each of these four types of architecture:

Choosing the right architecture for your MVP is challenging, but RubyGarage has many years of experience to help you with your choice. The author of the article will be happy to answer all your questions on this topic.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *