Datadog's yearly report on the "State of Serverless" is out.
It's good and interesting, as always.
Also, there are no surprises there. The report tells us nothing new.
This is probably good news, as it means that serverless is becoming more and more normalised and standardised (despite the occasional bad press).
Overwhelmingly, it seems that those who are, in fact, using serverless, are happy with it and don't see a world where they would want to go back to the way things were before.
The report quotes Andy Warzon (CTO at Trek10), neatly highlighting this point:
"In 7 years of running production workloads on AWS Lambda, across Node, Python, Java, and custom runtimes, I can't think of one time where our client has regretted the decision. The operational burden is dramatically lower and—after an initial learning curve—developer and DevOps productivity much higher."
But there is one piece of data about which I have mixed feelings.
Fact #2 in the report tells us that Google Cloud is leading on “container-based” serverless adoption growth. No surprise there given that we’re talking about the creators of Kubernetes.
AWS is apparently growing in that category too (up 20% from last year), with AppRunner gaining more and more traction.
I have been very appreciative of AppRunner myself. It’s a great service, and I’m glad that increasingly AWS users are preferring it over, for example, more complex container-based products such as ECS, EKS, and even Fargate.
What I have mixed feelings about, though, is what seems to me to be the end game of these different cloud providers.
Now, I’m not sure that AWS even has an end game. Their whole culture has always been about building as many services as possible, catering to as many different customers and use cases as possible, leaving us with the choice of what to use based on our business requirements.
But I like to think that, if they were to have an end game, it would be to push people to use more and more AWS-native products such as Lambda and DynamoDB.
In reality, as I said, I think AWS is quite neutral there. They are more than happy to offer all these different building blocks and letting us, the customers, choose what works best for us.
But it’s hard for me not to see Google as having an end game here. They are the creators of Kubernetes and there is a clear (at least perceived) benefit to running a Kubernetes workload on Google Cloud.
So, it’s easy to see how the thinking would go there. First, start with container-based functions (or Cloud Run). Then, as soon as you need some help making your application feel more enterprise-y we’ll show you the natural path for Scaling Containers Up™️ which, surprise surprise, has got to be Kubernetes on Google Cloud.
I’ve heard some Google Cloud employees say things along similar lines in the past (although not as explicitly) so I know I’m not just imagining this.
Generally speaking, this would be anathema in the AWS serverless world and community. Of course Lambda can scale for you! And no, you don’t need to migrate to Kubernetes or even ECS to go to the next level.
The line of thinking according to which serverless functions are the “play thing” that you build small apps and prototypes with, but Kubernetes is the serious, grown up solution for mature products, simply doesn’t exist in AWS serverless circles (if it does, it’s a very small minority).
Serverless is growing and almost everyone is using it to at least some degree. This is excellent news.
Those of us who are further along the journey (and have big serverless apps in production) can help those who are just starting to appreciate serverless not to get fooled by the “serverless is a toy, containers are the real deal” mindset.
To paraphrase Andy Warzon (quoted above): those who fully embrace serverless (i.e. exclusively or mostly running workloads on Lambda) usually don’t regret it.