The translation of the article is prepared for students of the “DevOps practice and tools” course in the OTUS educational project.

When the first tutorials began to appear in 2015 using AWS Lambda and API Gateway, it was no wonder that they were mainly focused on copying the microservice architecture. But those who used AWS Lambda on a large scale, over time, it became clear that there are significant limitations to the application of the micro-service approach to AWS Lambda ... At least, there were restrictions on what most people meant by the proper construction of microservices.

Let's talk about "why" for microservices

Microservices appeared primarily because of frustration with monolithic applications. Monolith is an application in which all the logic is in one logical code base.

There were times when, due to the high cost of servers, it was common to deploy the entire application on a single server. Deploying a monolith meant that you deployed part or all of the application on the server.

Also, deploying a monolith meant that you had to be sure that you would not break anything. Very often, small changes caused the failure of the entire server and the entire application.

Therefore, when the clouds appeared with the ability to provide instances with one click of the mouse in a matter of minutes (and not days or weeks), the possibility of sharing tasks became clear.
The destruction of the monolith became an obvious idea, and the idea of ​​microservices was born.

Instead of creating a monolith with all the logic on one server / instance, you can place parts of the application on different servers and link them together via some kind of lightweight protocol - usually the HTTP API.

Thus, the application architecture has moved from monoliths to microservices.

Although I wonder why? The value of this approach lies in the fact that when you edit the code, you change the code base not for the entire application, but for microservice - only an integral part of the application. This means that you cannot break down the entire application.

Although this is only theoretically, but this theory is better than a monolith, although it is not perfect.

The key element for each service is ...

Service interface

Often this is some form of HTTP interface (at least this is the most common approach). As a rule, this is not a problem, unless you have a large number of services and you may have a problem of their coordination.

Moving towards serverless architecture

Therefore, the initial approach to building serverless applications (serverless) on AWS was “let's create microservices” ...

This meant creating an API Gateway interface with a Lambda function behind it and a switch instruction that acts as a router.

Each API Gateway became a service interface, and it seemed logical.

You can make several services that are scaled separately from each other, which in some cases can be very important.

Except that it does not make sense when you understand that the AWS Lambda and FaaS functions in general should not be treated as an instance / server.

Because, although they have servers under the hood (hey, there are servers under most of the things that work on the Internet, but nobody says “S3 still has servers” or “BigTable still has servers” or “Azure Active Directory everything still has servers ”...), there is an opinion that you should treat the FaaS functions the same way as the service…“ minilith ”, as some call it.

The problem is that there is not enough of what, in my opinion, is the key to serverless architecture:

Serverless architecture (serverless) is all about events.

Serverless architecture, events and triggers

Serverless systems are in their essence event-driven systems, and therefore are representatives of event-driven architecture. It changes your approach to development, management and architecture.

In the case of microservices, the point is to respond to the interface - this is the main mechanism of interaction with logic.

In a serverless solution, we are talking about responding to current events, and the API is actually just a mechanism for generating events.

As part of the AWS ecosystem, which is the most mature of serverless solutions, the API is not considered as the main interface. Events are much more important.

And that's why there are about 50 events that can run the Lambda function from other AWS services.

The advice is that if you can run the Lambda function without passing through the API Gateway, then it will be much faster and more efficient than using the API Gateway, especially if you run it from another AWS interface.

Take a look at Serverless Best Practices , you will see a number of points that differ from how many microservices design.

First of all - one-pointedness of functions. Most microservices, as a rule, use the “request-response” architecture (request - respone), because this is how most web applications work. Functions in serverless applications, as a rule, are unidirectional, and queues are used as the “circuit breaker”, so the request-response becomes less common.

The data layer (data layer) is also controlled and understood in different ways. The best practice is to have multiple functions, not just one proxy function with a switch expression.

The idea of ​​several functions also provides additional advantages over microservices. If the function causes an error, it will only affect this function, but not the rest of the application, because the function has no state (at least it should be!). And this is a very good reason not to do “minilith”!

Therefore, the experience of building microservices, although it gives you some advantages in designing serverless solutions, in fact, you can miss most of what makes serverless applications valuable.

Microservices, as a rule, differ from a well-designed serverless application in several ways. This means that, although it is possible to create microservices with serverless backend, in fact there is no direct way from microservices to serverless architecture.

The path from microservices to serverless architecture

So, what is the path from microservices to serverless solutions? Is there a quick way to learn the basics to simplify the transition from one to another, since microservices are widespread?

I think this is what the besserverny world puzzles over. Recently, there was a great discussion on Twitter in which we spoke on this topic. Here it is worth referring to it, if only to see what the community is talking about (look at the various answers and you will see numerous opinions on this topic, although no one directly mentions microservices).

They talk about some tools that, as they say, make it easier to create serverless applications, but ultimately they will become the platform on which you have to build everything. I do not think it will benefit or help someone better understand the architectural style.

We, as a community, understand that the serverless architecture has a future. But the transition from old architectural styles will not always be easy, even when serverless architecture is the right (and sometimes not the right) choice.

There is a reason for this. It’s not so easy to change a person’s thinking. Easy to build lambda function. But creating a well-designed serverless application is not easy. Because it requires a change in thinking, and this is relatively difficult.

And as I have said several times, we must stop teaching people “hello world” applications and dwell on this because many people think that this will be enough for them.

The reason I wrote Serverless Best Practices was to help people understand that they should not make assumptions about how to build serverless applications based on current knowledge.

The tools that we now use to create serverless solutions are the same tools that we use to create “cloud 1.0” applications, but they are not fully suitable for these purposes. These tools are not perfect, but we try to explain and make them as good as possible.

What we need from you

I think that the community is, in fact, very open to help people in their training and development in creating serverless solutions.

So we, as a community, need your questions:
- What is your difficulty?
- Where are the gaps?
- What tutorials are missing?

And something like that.

I am ready to help companies make this transition. I worked with senior management, CTO and CEO to help determine how much value is being created in a company using a serverless approach, and I am happy to help other companies.

I am very happy to help. Contact LinkedIn here .