Monolith vs Microservices vs Serverless and what to choose for your business needs

Every tech company of any size sometimes wonders about how to build their server-side architecture and what approach to choose. Let's not talk about trends, but about tech and how to make the right decision for our business needs.
Let's discuss the 3 server-side building architectures.

Monolith

A monolith server-side app — also known as a monolith, is an application delivered via a single deployment, it is also available in one single endpoint and all required logic exists there.

Pros:
The biggest pro of monolith architecture is the development speed: This architecture can be realized faster than a microservices architecture.
It is highly recommended to use a monolith architecture for:

• MVP projects — you don't really want to spend a lot of configuration and connection time between services, in this type of project the goal is to check your business concept as soon and as cheaply as possible and using monolith architecture, your company can save money and time.
• Projects with small potential traffic — for example, an internal company system with a small number of employees.

But do yourself a favor — always try to be as modular as possible in your monolith projects — this can really help you migrate your monolith to other architectures.

Cons:
The biggest drawback of monolith architecture is that in a monolith development life cycle the beautiful and modular monolith that you dreamed about becomes “spaghetti”, because the architecture rules were broken (and you can’t get away from it), and it can be really painful to refactor it.
In a monolith, there is no isolation between the logical layers, and a simple architectural problem can slow the team.

Micro Services

A microservice server-side app — also known as microservices, is an application that is structured as a collection of services where every service has its unique responsibility, and to complete the full business logic the services connect to each other.
The name “micro”, is about the business logic capability of a single service and not about the actual serving size.
In comparison with a monolith architecture, every service is deployed, and lives, separately.

Pros:
With a microservice architecture it is easy to stay modular, because we achieve real logical borders between layers. In large size companies, every service can be developed and maintained by another team, and modularity allows teams to work on services mostly on their own.
Microservices are smaller, this makes them easier to understand and test.
The smaller size makes:
1. The compilation of each service faster.
2. The CI/CD process for each service to be faster and easier than a monolith architecture.

Other advantages include:

• You can mix technologies by choosing suitable programming languages and frameworks for each service.
• Better scalability — each service can be scaled independently according to its traffic.

These factors make the product development process more agile.

Cons:

• The latency because of the network connection between the services.
• The e2e tests between all the services can be harder because of service availability and connection.
• The transactions between services can be harder, but it can be fixed by the SAGA pattern.

Choosing this architecture is recommended for stable and verified business concepts with a lot of traffic.

Serverless

A serverless architecture — also known as serverless computing or function as a service (FAAS), is a software design pattern where our function (a part of the microservice responsibility) is hosted by a third-party (AWS Lambda functions, Azure functions, Firebase cloud functions, etc…), this architecture eliminates the need for server software and hardware management by the developers, the third-party service provides this automatically.
As mentioned, the one microservice responsibility is divided amongst many functions, which can be invoked and scaled individually.

Pros:

• Developers don’t need to care about scaling, the third-party software does it automatically.
• Faster development — less configuration is needed.
• Triggerable — There are a lot of triggers in third party ecosystems, for example it’s very easy to run a Lambda function as a cron job in AWS, or execute a function when a new file is added to S3.
• Many languages are available, and every function can be written in a language suitable for it.
• Pay as you go — you pay just for your executions’ accumulated time.
• No Ops — no infrastructure or OS to maintain.
• Deployment and maintaining — can be easier if you are using a Serverless framework.
  
  Cons:
• No state — in a serverless architecture, your team doesn’t really have a server, therefore you can not save your global state (you can get around this problem by adding an in-memory database to your infrastructures like Redis or Memcached to save the global state and each execution can get the global state from there).
• Max run time — for example, an AWS Lambda function can run at least 15m for each execution.

This architecture is recommended for small companies or startups that want to grow faster and cheaper than an alternative architecture, without bothering with too much configuration.

Summary
Sometimes it is very hard to choose the right architecture, but try to think what your real business needs are.
If you are looking for just checking a concept — choose between monolith or serverless, you don't really want to spend a developer's time on configuration, synchronization between the services, etc…
But if your business concept is verified and you are sure about that, do your best with microservices — reasoning about this architecture will be easier for your developers and naturally create isolated and modular software.

Happy coding=)