Member-only story
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 serverless, 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.
![Michael Bahr @bahrdev @awscommunity.social tweet With every #AWS #Serverless announcement, I’m like [insert Thor from Avengers meme], “Is it, though?”](https://miro.medium.com/v2/resize:fit:560/1*QH_QL5B40lK3OE-lWwv7cA.png)
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 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.

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…