Reflecting on Serverless: Current State, Community Thoughts, and Future Prospects

Lately, I’ve seen many serverless outtakes and mixed opinions online. They stirred up the community and started a discussion, which is always good.

In this post, I will reflect on the current state of serverless, share my thoughts about serverless articles from the community, and discuss the future of serverless.

This blog post was originally published on my website, “Ran The Builder.”

Table of Contents

1. Intro

2. Serverless Reads on the Web

3. Clickbait Articles

4. Serverless & AI

5. Serverless as a Halo Product

6. Serverless Challenges

7. Serverless isn’t a Silver Bullet

8. Developers Doing DevOps & Platform Engineering

9. A Lacking Developer Experience and Too Many Options

10. It’s Solvable

11. The Serverless Community

12. The Future of Serverless

13. Summary

Intro

Even though it has been almost five years since I started using serverless, it still feels like magic to me. Deploying code without managing the underlying infrastructure is freeing.

In addition, the ability to create event-driven architectures built from AWS-managed resources or direct integrations that replace containers’ code is mind-boggling. You can build services that would otherwise take years in just minutes. I’m still amazed at DynamoDB’s global tables’ cross-region replication performance.

The reality is that Serverless is not the newest cool kid on the block anymore (yes, GenAI, I’m talking about you). Lambda has celebrated its 10th anniversary this year. It’s crazy — 10 years already! And you could also argue that the first serverless service was SQS, which was launched two decades ago! The hype has moved, and that’s normal.

Any technology matures over time. Kubernetes is not “new” anymore. Heck, even ChatGPT is not “new” anymore. I wrote a post about it a year ago about how my grandmother wanted to use it.

At some point, technologies and products reach maturity, which is where we are currently. My take is that Serverless has matured into a true cloud “workhorse” — an amazing scalable and reliable technology that solves many problems but (like any other) comes with its own set of limitations and learnings (more on that later).

Serverless Reads on the Web

Lately, I’ve seen many serverless outtakes and mixed opinions online. They stirred up the community and started a discussion, which is always good.

I’d like to share my thoughts on some serverless outtakes I’ve seen in the last few months.

Clickbait Articles

Lately, I’ve seen many serverless outtakes and mixed opinions online. They stirred up the community and started a discussion, which is always good.

I’d like to share my thoughts on some serverless outtakes I’ve seen in the last few months.

Clickbait Articles

This is a generalization of a trend of articles I’ve seen: “Team X stopped using serverless, and now they are 1000% better”.

There’s a lot of misinformation and misconceptions about serverless. Usually, in these articles, they refer to Lambda alone.

It’s 2024, and for some reason people still view serverless as just Lambda **(facepalm**).

There’s a beautiful serverless world out there with staple services: S3, SNS, SQS, DynamoDB, EventBridge and many more, that you can (and should!) use with your K8S cluster. Why operate Kafka when you get the same, if not better, experience with MSK or SQS without the maintenance cost?

Second, like any other technology, Lambda isn’t a magic solution to all problems. There are problems for which Lambda doesn’t fit (gasp) or make sense, and that’s okay!

Sometimes you need long-running sessions lasting more than 15 minutes. Or use GPU. Or you want to handle predictable traffic patterns and OK with building on ECS Fargate. Containers are awesome, and not having to manage the underlying infrastructure is even better.

The main point these articles miss is that just because Lambda was not used in a specific use case does not mean that Lambda is a flawed technology. It just means that it didn’t fit that specific service’s requirements.

BTW, it’s okay to mix. I designed a service where part of it is Lambda and part containers. Don’t choose a solution because that’s what you know and have always done. Werner Vogels discussed it at AWS re:Invent 2023. Choose the solution that fits the problem requirements and constraints the BEST, period, and don’t be afraid to do things differently from what you are used to.

Serverless & AI

Unless you’ve lived under a rock in the past month, you’ve probably read Luc van Donkersgoed’s post about serverless and AI. If in case, you missed it, I asked ChatGPT to summarize it for you:

Luc expresses concern that AWS’s intense focus on Generative AI (GenAI) overshadows traditional cloud engineering and core infrastructure. He highlights how AWS’s recent events and announcements have been predominantly centered on GenAI, leaving less attention and resources for other essential areas like databases, scalable infrastructure, and maintainable applications. Luc argues that while GenAI has its benefits, it cannot replace the foundational elements of cloud engineering and urges AWS to balance its focus to better support developers and existing business needs. — ChatGPT 4o

As an engineer and an architect, I agree that I’d rather see fewer AI features and more serverless or infrastructure features. I’m sick of hearing of new AI features, but I can’t ignore that GenAI has made me a better and faster engineer. I can’t deny that some of it is genuinely cool and has amazing potential, like Bedrock agents calling APIs (see my post and impressions here).

Now, taking on AWS’s customer obsession aspect and their business needs. I’m not an AWS customer; my company is, and that’s a significant distinction. CyberArk’s enterprise customers — want us to build AI features and plenty of them. There’s a real demand, and some of the implementations are improving our customers’ lives. So from that perspective, AWS is doing what their customers wants. However, since AWS was late to the game we’re seeing this never-ending wave of AI features.

Looking forward, I believe the AWS AI madness will calm down in a year or two as they close the gap, at least until the next hype comes along.

Serverless as a Halo Product

Gregor Hohpe published another interesting read titled: “Is AWS Lambda a Halo Product? — Shiny, advanced, a strong fan following, but lack of mainstream adoption — the trademarks of a Halo product. Sounds like AWS Lambda?”.

There are some solid points and some that that I personally have a different opinion on.

Let’s discuss the mainstream aspect. What does it really mean? Is it publicly known and used, or are these just pure market share numbers?

Lambda will not completely replace ECS or EC2. It wasn’t supposed to.

As I’ve mentioned above, they each have their place. Is it mainstream? Yes. People know of it and use it in large-scale enterprise companies.

I can say that with confidence because when I interview for developer positions at CyberArk, I get resumes of engineers who claim to know Lambda, SQS, DynamoDB, and other serverless services — and they actually know them.

Let’s continue.

I disagree with sentences like “I use serverless mainly for demos” or “EC2s are reliable” (hinting that Lambda isn’t?); well, like I wrote in the beginning, serverless is more than just Lambda. Other serverless are helpful even if you are running EC2s or K8s.

In addition, many enterprise companies use serverless in production, and it’s highly reliable. In fact, the AWS post-failure-event summaries from the last 13 years show that EC2 had four specific outages the previous year, with Lambda having just one.

Let’s talk about the following quote:

Those EC2 instances aren’t quite as sexy, but they are well-understood, reliable, and have predictable cost

According to DataDog’s state of cloud costs report item number 4, and I quote:

More than 80 percent of container spend is wasted on idle resources. About 54 percent of this wasted spend is on cluster idle, which is the cost of **over-provisioning **cluster infrastructure.

Let’s read that again: 80%! Wow, what a mind-boggling waste of resources and money. Perhaps the EC2s that host container-based solutions and Kubernetes aren’t that understood after all?

With serverless, you don’t pay for idle resources and don’t need to manage their infrastructure which reduces dramatically your costs — a massive win for serverless.

Let’s discuss ongoing maintenance.

Securing EC2s over time is not easy. Handling OS and library upgrades is sometimes not straightforward at all. We literally had one of the biggest outages in years just last week — thanks, CrowdStrike! Talk about having a predictable maintenance cost.

Take a look at K8s, too. You hear many horror stories about version upgrades, setting up a cluster or service mesh, and other issues. So why is serverless getting so much heat? That’s because, with K8s, the infra team handles that.

With serverless, every developer needs to learn and understand the concepts and write IaC that builds serverless architecture moving parts.

Let’s expand on this point.

Serverless Challenges

Gregor makes good points, too. Serverless, and Lambda as part of it, is unique (halo-ish), and as such, you need to learn the tech; you need to REALLY understand to make the most of it. I stumbled across an article by Sheen Brisals that discusses whether serverless is hard or not. I highly suggest you read it.

Let’s discuss in detail the current state of serverless struggles. I want to clarify: any technology comes with it’s own set of challenges. Every serverless challenge I mention is solvable; it’s just a matter of cost, knowledge, and having the right people to drive the technology inside your organization.

Serverless isn’t a Silver Bullet

The great power of serverless is that starting with and becoming productive is much easier. Just think how long it would take a developer who has never seen either Lambda or Kubernetes to deploy a Hello World backend with public API on both. As you start building more realistic production applications, the complexity increases. You must take care of observability, security, cost optimization, failure handling, etc. With non-serverless, this responsibility usually falls on the operations team. With serverless, it usually falls on developers, where there is considerable confusion.

Let’s go back to the interview example I was using.

The developers knew serverless concepts. However, most of them fumbled and failed the second I asked about testing techniques or failure handling with DLQ and retries.

Serverless is not a silver bullet that removes the complexity of building and running cloud applications. It can help you significantly reduce the complexity of infrastructure maintenance and focus on the application layer. However, that also comes with the new complexity of understanding and applying serverless application patterns, such as using DLQ, event driven architecture concepts, and more.

Developers Doing DevOps & Platform Engineering

Some companies fear change or want to avoid putting in the cost to make the change. Serverless requires a culture shift, better developer onboarding, and someone leading the way in best practices and governance. In my company, it’s been the platform engineering responsibility. That’s been part of my job. However, many companies don’t connect platform engineering with serverless. At scale, it’s a must; you need governance, security, FinOps optimizations, general best practices, and someone to own it.

If there’s no concrete owner, it falls on the shoulders of every single developer, and it’s just too much.

A Lacking Developer Experience and Too Many Options

If using serverless was so easy and obvious, I wouldn’t have needed to write over 50 articles or share my serverless pragmatism views at AWS re:Invent 2023 with my partner in crime, Heitor Lessa.

Issues like serverless testing, serverless observability, learning to write a proper Lambda handler, dealing with tenant isolation, working with infrastructure as code tools (too many AWS options — SAM, CDK, Chalice, which one to choose and why?), and learning all the best practices overwhelm developers and managers alike.

AWS has published articles on most topics, but there are many opinions, too many ‘hello world’ projects that get deprecated within six months, and not enough advanced use cases.

AWS must provide a better developer experience so developers don’t need to worry about these topics and focus on writing business logic.

It’s Solvable

It’s solvable but adopting any new technology always, always, always (!) requires investment. At CyberArk, we’ve reduced these challenges by creating self-service blueprints and codifying architectural blueprints and patterns so our developers get all the best practices right out of the box. Add internal workshops and knowledge sharing to that, and you will get on the right path. We’ve scaled from 10 serverless developers to hundreds.

It can be done.

I’ve shared many insights on AWS serverless office hours webinars and an AWS article and will share our journey at AWS Community Day DACH this September in Munich.

The Serverless Community

The serverless community is nothing short of amazing.

There are global events, serverless days, CDK day, AWS community days with tons of severless content, AWS serverless developer advocates, AWS community builders specializing in serverless, AWS serverless heroes, serverless newsletters, and so on.

Experts are sharing knowledge like never before. Even AWS’s documentation has gotten better. And with the AI revolution, writing serverless code is easier.

Four years ago, it wasn’t like that.

Open-source libraries like Powertools for AWS Lambda have changed the industry. They recently crossed 100 billion API integrations per week. Powertools is making customers’ lives a lot easier worldwide.

There’s even a new serverless community on Discord called ‘Believe in Serverless ‘, where you can easily connect with serverless experts and engage in discussions about the technology. This is unprecedented access to pragmatic advice from those who actually use the tech.

The Future of Serverless

Let’s clarify this section. I’m not a prophet; this is a mere wish list.

The serverless future will be bright; serverless is not going anywhere, and it’s not dying.

However, if AWS wants to increase its adoption, it needs to improve the following issues:

1. Focus on developer experience for current and new features. Don’t release service without debugging logs (I’m looking at your EventBridge pipes, which took a year to bring in failure logs).

2. More AWS Powertools, please! More runtime supports (RUST, Golang) and make them all feature parity with the Python variation, and extend it to containers, not just Lambda. Please invest in this amazing AWS DevEx team.

3. Don’t put the ‘serverless’ tag on services that are NOT genuinely serverless. If I need to set up a VPC or pay for idle time, it’s not serverless. Newer services, such as Verified Permissions that uphold these requirements, are encouraged.

4. All new non-compute services MUST be serverless. I don’t want to manage infrastructure ever again, so serverless should be the standard.

5. Focus on one IaC tool and make the best possible you can. For me, the obvious choice is CDK. Focus on releasing better CDK L2, and L3 constructs that implement best practices and security to turn constructs into productized patterns, as Jeremy Daly says.

6. Step function testing and definition — this is still too hard to do. Let’s change it. It’s a mandatory service that gets hate from developers due to poor DevEx.

7. Maintain GitHub sample projects for at least two years after publication and deprecate projects that are not maintained anymore.

8. Be more pragmatic. It starts with AWS Summit sessions and goes all the way to AWS re:Invent. Please bring more technical customer use cases. We want to learn from actual production environments, not just theory.

9. Provide production-grade ready and secure blueprints and recommended project setups, similar to what I created, the AWS Lambda handler cookbook. Maybe even endorse community projects if you don’t have the capacity to build them.

10. Help us tackle tenant isolation in a more generic and safe manner. Every company handles it differently, and it’s very error-prone.

11. We’re going to see AI creep into serverless, especially in the IaC domain, and that’s okay. I’ve yet to try AWS App Studio. Please don’t over do it (like Luc wrote).

12. Strive to make features transparent — Lambda insights, for example, instead of having me as a user attaching a Lambda extension and managing its version (which is not a great experience; see my Lambda layers post), let me provide a CDK flag to the Lambda construct, and you will attach the extension behind the scenes and manage it for me.

13. Cross-account access at scale with serverless and EDA is challenging; we can and should simplify it. These are challenges that come with this architecture. I discuss it in my security post.

Summary

There have been many serverless outtakes and mixed opinions online. They stirred up the community and started a discussion, which is always good. It made me take a moment to think about the current state and organize my thoughts.

I hope you enjoyed reading my vision. Time will tell whether I was right or not.

Thank you Anton Aleksandrov, Bill Tarr and Johannes Koch for reviewing this post and offering insights.