What is the essence of the serverless approach?

Question

Service Oriented Architecture

In general, Lambda recently rolled out support for PHP, which is quite joyful.
But I have some questions about the architecture of projects using it.
In the Lambda + PHP context, I see the following use cases:
1. Implementation of a microservice architecture (where each microservice acts as a function)
2. Implementation of a monolithic architecture (for example, throwing a monolithic Laravel as a single function)
How optimal / correct / logical is this approach in the context of serverless and AWS Lambda in particular?

Answer 1

To begin with, if you are still an active developer and can not really understand this principle, perhaps you simply do not need it. And this does not mean that you are a bad developer, just that you have not intersected with this type of problem.
As for serverless, the name reflects not the fact that there is no server and working with it as such, but rather even less fuss with setting up and maintaining the server environment (even less than with docker after everything is configured and up). Those are the next step after conditional microservices.
It is often more convenient to call it a function as a service, since it is often the de facto implementation of running a function on demand.
If we briefly describe what this is for, then imagine that we have a microservice whose costs of maintaining its constant uptime are somehow too high relative to the operating time / live resource consumption. And in general, the service comes out as something too micro even for a microservice.
This is where we come up with such a thing that will be VERY quickly (relative to the start of a minimal virtual machine / image and something else) start up, quickly do its little work and turn off.
Of the key features, I note that the function should generally not care about its state, it does not initially know about the previous launch, etc. (they should be stateless). Everything you need comes in the request.
Lie means if you have a task that satisfies these conditions, you can use this convenient service for scalability, and for savings, and for a bunch of other features.
Examples:
image resizing.
Statistical site generator (we update statistical files through the admin panel, this does not happen often).
Chat bots
Different special informers with certain logic.
And so on and so forth, which fits well into a certain relatively simple function with a simple input of data (or no) and a simple result of the work.
In general, this solution is not a panacea, moreover, you need to clearly understand how profitable / unprofitable it is to redo your function on the serverless platform, because we definitely sacrifice the same performance (remember that the service does not hang and does not wait for us all the time, but even very quickly, but it starts ), the transparency of execution decreases and debugging becomes more complicated, etc.
But in any case, quite often the pros outweigh the cons, this principle has popularity. people actively use it, so a lot of cones are already stuffed, in general, a mature thing.
And yes, about your specific question.
PHP AWS Lambda does not natively support everything through crutches, however, with almost sane performance.
And since AWS Lambda is still closer to the most popular serverless principle today - a function as a service, I'm not sure if this is the right idea to run Laravel's atm.
Those we have disadvantages: the lack of native support for PHP and such sharpness for something simple, in the end .. well, I don’t know.
I think serverless goodies in the form of no hassle with setting up a server / cloud can be solved by many other services. However, it may not be so beneficial in your case, you need to proceed and calculate according to your scenario of your application. And then decide what works best.

Answer 2

Serverless is a very stripped-down docker container with its own API and a lifetime of up to 5 minutes. At the same time, 1 container serves 1 request. Within 5 minutes after execution, the container remains "hot", i.e. contains all data since the last execution. Accordingly, if your memory is leaking, then under load the memory will not be released, because. containers are reused.
In addition, if you want to serve external requests, you also need to use an api gateway shim (you also have to pay for this).
There are also troubles with the settings. Monitoring lambdas is also a task with its own nuances. If you just have a website / api and more or less regular downloads, then I would not recommend serverless. Elastic beanstalk is actually more convenient and practical. But for tasks like selenium testing, when you need to run 1000 tests in parallel and then you don’t need power until the next build - serverless is very good.