A translation of the article was prepared for students of the DevOps Practices and Tools course in the OTUS educational project.

When the first tutorials started using AWS Lambda and the Gateway API in 2015, it was not surprising that they mainly focused on copying the microservice architecture. But for those who used AWS Lambda on a large scale, it became clear over time that there were significant limitations to applying the microservice approach to AWS Lambda ... At least there were limitations regarding what most people meant by the proper construction of microservices.

Let's talk about the why for microservices

Microservices appeared primarily due to 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 on the server you were deploying part or all of the application.

Also, deploying a monolith meant that you had to be sure that you won’t break anything. Very often, small changes lead to the failure of the entire server and the entire application.

Therefore, when clouds appeared with the ability to provide instances with one click in a matter of minutes (rather than days or weeks), the possibility of separation of 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 connect them together using some kind of lightweight protocol - usually an HTTP API.

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

Although, I wonder why? The value of this approach is that when editing the code you change the code base of not the entire application, but the microservice - only the component part of the application. This means that you cannot break the entire application.

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

A key element for every service is ...

Service interface

This is often some form of HTTP interface (at least this is the most common approach). As a rule, this is not a problem, except when you have a large number of services and there may be a problem of their coordination.

Moving towards serverless architecture

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

This meant creating a Gateway API with the Lambda function behind it and a switch statement that acts as a router.

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

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

Except that it makes no sense when you realize that the AWS Lambda and FaaS functions in general should not be considered 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 no one says “S3 still has servers” or “BigTable still has servers” or “Azure Active Directory all still has servers ”...), there is an opinion that you should treat the FaaS function the same as the service ...“ minilith ”, as some call it.

The problem is that here is missing what, in my opinion, is the key to serverless architecture:

Serverless architecture is all about events

Serverless architecture, events, and triggers

Serverless systems are inherently event driven systems, and therefore are representatives of event driven architecture. It changes your approach to design, management and architecture.

In the case of microservices, the bottom line is to respond to an interface - this is the main mechanism for interacting with logic.

The serverless solution is about responding to 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 seen as the primary interface. Events are much more important.

And that is why there are about 50 events that can trigger the Lambda function from other AWS services.

The tip is that if you can run the Lambda function without going through the Gateway API, it will be much faster and more efficient than using the Gateway API, 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 design microservices.

First of all, unidirectional functions. Most microservices typically use a request-respone architecture because most web applications work this way. Functions in a serverless application, as a rule, are unidirectional, and queues are used as a “circuit breaker”, so request-response becomes less common.

The data layer is also managed and understood in different ways. Best practice is to have multiple functions, rather than one proxy function with a switch statement.

The idea of ​​multiple functions also provides additional advantages over microservices. If a function throws an error, then this will only affect this function, and 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, although the experience in building microservices gives you some advantages when designing serverless solutions, in reality you can miss most of what makes serverless applications valuable.

Microservices typically differ from a well-designed serverless application in several ways. This means that although it is possible to create microservices with a serverless backend, in reality there is no direct path from microservices to a 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 the other, since microservices are widespread?

I think this is what the serverless world is puzzling over. Recently, there was a big discussion on Twitter in which we talked about 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 will be told to facilitate the creation of serverless applications, but in the end they will become the platform on which you have to build everything. I don’t think it will benefit or help someone better understand the architectural style.

As a community, we understand that serverless architecture is the 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 is not so easy to change a person’s thinking. It is easy to build a Lambda function. But creating a well-designed serverless application is not easy. Because it requires a change in thinking, and it is relatively difficult.

And as I have said several times, we must stop teaching people “hello world” applications and stop at 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 on 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 completely suitable for these purposes. These tools are imperfect, but we are trying to explain and make them as good as possible.

What do we need from you

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

So we, as a community, need your questions:
- What are your difficulties?
- 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, CTOs and CEOs to help determine what value a company creates using a serverless approach, and I am happy to help other companies.

I am very happy to help. Contact LinkedIn here .