I Don't Know What Serverless Is Anymore
The definition of serverless is changing and nobody seems to agree on what it actually is
Something you probably wouldn't expect an AWS Serverless Hero to say is "I don't know what serverless is."
I'm not proud of that statement, in fact I'm a little upset about it. I used to have a firm grasp on what serverless was, but that seems to have been shaken up recently.
More and more people slap the word "serverless" on their projects, services, and repos, dampening the definition we used to have.
Serverless is hard enough as it is. Getting started takes a significant mindset shift from what many developers are accustomed to. Couple that with the dozens of tutorials out there that teach you to build in the AWS console and you've got a recipe for a bad time.
We need to agree on what serverless actually means. Taking it a step further, we need to agree on what serverless development is - which is a completely different story.
What Is Serverless?
When I say serverless, I am generally referring to the services that developers use to build applications. Examples are AWS Lambda, EventBridge, DynamoDB, and Step Functions. But what makes these serverless compared to services like Amazon Aurora or ECS?
Momento has a great litmus test that I think hits the nail on the head for what defines a truly serverless service.
Source: Momento blog
Developers should be able to pick up and use a serverless service. To say it succinctly, these services just work. Think about the last time you created a Lambda function. You made a single call to the CreateFunction endpoint (or preferably declared it in IaC), then were immediately able to start invoking it.
Compare that to something like Neptune Serverless where I need to configure a VPC, choose capacity units, and select multi-AZ deployment settings. It doesn't really feel like it just works.
Beyond the developer experience of serverless services, you also have the impact to an organization. How well can the service elastically scale? If you have bursty traffic, will the infrastructure automatically scale to handle it without requiring an internal SRE team?
What about when the application is not in use? Does it scale to zero? Nobody wants to pay for over-provisioned resources that aren't in use. The pay-for-what-you-use model with no minimum payment is a huge indicator you're consuming a serverless service.
Serverless is a paradigm where consumers pay only for what they use. Services are backed by reliable, scalable infrastructure that automatically expand and contract with incoming traffic - taking the burden completely off the consumer. These services are simple to use with minimal to no configuration to get started.
With this in mind, let's talk a little bit about what it means to be a serverless developer.
What Is Serverless Development?
Those of us who consume serverless services as part of building an application are doing serverless development. But that's not as straightforward as it sounds.
Serverless developers build with a serverless-first mentality. This means they approach development seeking to take advantage of the benefits of serverless services, like infrastructure management, availability, and scalability (among others). It does not mean they must use Lambda or Step Functions for every workload.
It's not about the specific services that compose your applications, it's about the benefits you get as an organization when taking advantage of a shared-responsibility model.
Many of us get bogged down in the detail of what serverless development is. Yes, knowing how to build direct integrations or optimize performance by using Step Functions over Lambda is important detail when building an application, but that isn't what serverless development is at its core.
It's about focusing on satisfying a business problem wholly and efficiently. It's about bringing stable software to the market in record time. It's about finding the right product-market fit without breaking the bank.
Does It Really Matter?
Hopefully some of you are nodding your heads in agreement. I know others will think I'm crazy and have different opinions on what is or isn't serverless. But at the end of the day, does it really matter?
Not for long.
Serverless is a stepping stone for a faster, more sustainable, and more robust future of software. As Sheen Brisals mentioned in his recent recap of AWS re:Invent 2022, the core concepts of serverless development have been around for a long time. Cloud vendors like AWS are just making it easier to take advantage of them. But it takes a world stage to drive home the message that it is the way modern applications need to be built.
ELI5 serverless from ChatGPT
What we need to push for right now is the adoption of not only the cloud, but cloud best practices. Use event-driven architectures, design NoSQL data models, go asynchronous when you can.
With Infrastructure from Code (IfC) making a big push into the cloud market, serverless services are abstracted away from developers completely. You aren't building Lambda functions, SQS queues, or DynamoDB tables. Instead, you're using your knowledge of architecture patterns of distributed systems to build applications.
Is IfC serverless? Maybe.
What if we considered it something entirely different? All this back and forth on what is or isn't serverless might eventually become moot and we refer to the entire paradigm as native cloud development.
Final Thoughts
A couple years ago we were having light-hearted flame wars on Twitter about Kubernetes vs serverless. Today we're having heated debates on what is or isn't serverless.
AWS has started blurring the lines on their definition of serverless with the release of Aurora Serverless, Neptune Serverless, and OpenSearch Serverless.
But maybe that's part of the cloud journey we're on. Maybe "serverless" simply isn't what it used to be.
Serverless developers are going to turn into "native cloud" developers. We're going to design software that relies on established architectural patterns and not rely heavily on specific managed services.
There's a lot of motion in our industry right now. Lots of opinions, lots of software, lots of ideas. It all changes so fast, it shouldn't come as a surprise that we are scrambling to redefine what serverless means.
Whenever we finally land on something, it's just a matter of time before it changes again.
Happy coding!