Why the Serverless Revolution Has Stalled

To me, Serverless is the new Stored Procedures.

I feel like the opinions in this article are based on one type of serverless offering - the serverless function ("Lambda" in AWS). How do you feel about serverless containers, like AWS Fargate? How about serverless data stream processing - like AWS Kinesis Data Analytics? I agree with many arguments made here, in the context of serverless functions. But, I think that some generalizations were made, which aren't generally true.

Also, I feel that the argument about vendor lock would apply in many cases when using hosts. If you're developing a hosted service on AWS, you are likely interacting with other AWS components via the AWS SDK, and that will be true on servers as well as serverless.

Any thoughts?

I'm not sure if we can call AWS Fargate as Serverless, because you still need to understand about the operating system in your container, what is not in your control is the linux kernel in the host instance.
But if it is or not Serverless, I agree with you that the "malleability" from containers are the biggest advantage here and I feel more comfortable or capable of tuning my system environment.

About the vendor locking, it is very tricky indeed. We could say a well done app could have its outer shell easily replaced to another cloud provider.

But I cannot say much because we found so many limitations in the AWS Lambda that pushed us back to the AWS ECS. Our conclusion was: It is possible and effective to make a POC with Lambda, but when it has to be cost optimized and stable… It will need to be placed in a container. In the end we just stay in containers for the applications.

You cannot do a lot more then that. Entire frameworks become impossible to use, even if in theory they could run with the concept of per request runtime, the fact that you have to on a fundamental level redefine what input means, breaks most of them.
Serverless is ok, if you have to right a little glue code or wrap something else, but in most full projects you don't start from scratch, nor are many projects worth designing a custom solution for. In the vast majority of cases, what we see, is just use standard webshop/cms/blogplatform/etc. and then import a few images, stylesheets, fonts and articles, and your done. No programming necessary.
And if we really do program something new, the extreme simplicity of serverless has you yearning for all the capabilities of Kubernetes within the first hours of a project.

Making a weak aproach, serverless is similar to UNIX utils. In UNIX we have serverless apps like grep, sed, awk, sort, uniq, ... that do not consume recurses until used. They take input from STDIN and write to STDOUT. This is quite similar to serverless where input is read from an "HTTP" request and written back as an HTTP response. The core diference is than in UNIX there have been standard tools for decades, while in the serverless cloud there is nothing similar.
We need a "GNU text utils" for the cloud era. Some standard serverless services that anyone can use with the same freedom that we can use GNU tools in Linux/Mac OSX/UNIX/POSIX systems. We can not expect for companies to create their own serverless utility apps from the scratch as is the case at this moment.

Since micro services became popular we still live with the false premise that our applications can be completely stateless, and that they can be scaled by simply adding service instances or running more parallel serverless functions.
As this assumption proves to be false, we usually need some kind of caching mechanism to keep performances at a decent level and we end up with something very similar to old 'server session'.
So in the end all the benefits of these new 'revolutionary' architectures just turn to be impossible to fully achieve.

We have effectively had this since the 1990s ( See en.wikipedia.org/wiki/Common_Gateway_Interface ) This used to run almost all of the dynamic content on the web, but it has a lot of issues, not least ones of performance, security, and the difficulty of keeping any kind of context between requests. These days that space is mostly filled by PHP, which would also count as "serverless" according to this article.

We have effectively had a standard "serverless" platform since the 1990s ( See en.wikipedia.org/wiki/Common_Gateway_Interface ) This used to run almost all of the dynamic content on the web, but it has a lot of issues, not least ones of performance, security, and the difficulty of keeping any kind of context between requests. These days that space is mostly filled by PHP, which would also count as "serverless" according to this article.

If you look at mostly any technology, it never completely replaced what was before it. New technologies evolve from new needs, but this usually doesn't make old needs go away very quickly, therefore old technologies stay in use for an old time. Some, like C for system code, for decades. Potentially for centuries, who knows? Therefore, considering all limitations of serverless, it should have been obvious to any technologist from the get go that it won't be a replacement for all that was before it.

I'm not sure this is a valid analogy. The big problem with serverless for server applications is state. You can't reduce all computations to simple stream processing. Oftentimes, just setting up the stream processing pipeline is a tedious task - loading a custom function is not as fast and easy as it is to start a process from a binary in *n*x shell. Other times, even if the input is simple, producing the output requires fetching data from multiple sources - which may not be already prepared to provide it. A microservice using a transient cache to speed up things is a better solution, in such cases, regardless of how well optimized a serverless approach might be.

Serverless becomes a widely usable approach only with data locality. Depending on the data, this approach might be difficult or outright impossible to implement.

Microservices, even when they employ caching, are a far cry from server session based old style web applications. Session is managed on clients nowadays. Microservices, when caching, cache data which isn't session specific.

Also the notion of stateless as employed by microservices is different, I believe, from what you understand by stateless. You always need state as something that's persisted independently of any use in some ongoing operation. You need to persist bank account balances, log files and whatnot. These might never ever be used in session state. Session state typically contains things like items added to a shopping cart, payment orders as they are edited, query results on indexed logs and the like. Microservices never cache or persistently store such typical session contents. Such contents, in microservices-based applications, are maintained by the client. Microservices just perform one-off operations, such as performing a query and returning the results - and then completely forgetting about it. If queries have a good chance of being repeated, results might be cached. But such cache contents are not state - that state being lost only causes a performance hit for one request, until the cache is rebuilt. Nothing gets lost, as is the case with typical session information.

I agree on the fact that microservices cache has a different content compared to server session, but I still see two main false premises about microservices:

- you can not simply scale by adding service instances. Cache still crucial for performances and as the traffic grows you will need to scale cache, which means scaling its state to be consistent and replicated, otherwise your cache will be useless. And scaling such kind of cache is not so different from scaling a server session.
-nearly every non trivial application need to authenticate its users.This requires to keep a state about users, especially if you want to log out a previously authenticated user.
Off course you can rely on a third part service for authentication (for example an OAuth service) and keep your microservice stateless, but in this way you've just delegated someone else to handle your application state.

You obviously can't scale beyond the hard limits of the universal scalability law.

There's a very popular mechanism for avoiding delegating state management, very specifically for authentication/authorization: JWT.

Caches maintained by stateless microservices usually contain data which doesn't change frequently, and which, if the microservice crashes and needs to restart, can be rebuilt from scratch, without much performance impact overall.

Proper user sessions, OTOH, always need to be synchronized and consistent. They have completely different requirements than typical caches used by microservices, which are most often neither replicated nor consistent.

In terms of the universal scalability law, user sessions maintained server-side make much too much of the data require synchronization, whereas microservices reduce the data that requires synchronization to a minimum, don't cache it in any way, but cache all other data that isn't local. You gain more, with regard to both performance and scalability, this way.

The problem with serverless is that it makes the kind of simple, local, inconsistent caching that microservices employ, impossible. A vast array of applications are served well by a microservices-based approach, serverless doens't fit that many.

We have already tried procedural coding style. Function calling another function, now distributed! :)

That is true Michael but mainly due to the vendors themselves and the maturity of these solutions.
For vendor lock-in, you are correct but it is a risk. Many of us work in hybrid env with multiple cloud providers.
Two major steps backward for me:
First, they painfully ignore the importance of efficient data processing. Second, they stymie the development of distributed systems. This is curious since data-driven, distributed computing is at the heart of most innovation in modern computing. This latest point is paramount for me and difficult to sell inside a large enterprise. The cost saving for infra will have repercussion on productivity for product teams.
This is well explained in this paper: Serverless Computing: One Step Forward, Two Steps Back
Joseph M. Hellerstein, Jose Faleiro, Joseph E. Gonzalez, Johann Schleier-Smith, Vik

You rightly wrote "Caches maintained by stateless microservices usually contain data which doesn't change frequently, and which, if the microservice crashes and needs to restart, can be rebuilt from scratch, without much performance impact overall."
If we consider that Serverless Functions have a certain lifespan (about 15 minutes now for AWS) we can still consider to use these types of cache in our FaaS implementations. Whether this makes sense or not depends on the specificity of the application logic, the type of load curve and so on. But caching is still possible, at least up to some extent, also with Serverless Functions.