Serverless is dead. Long live serverless!

Does serverless still matter? No.

Serverless is grown up. What’s next?

Now that serverless is here for ten years, where is it heading next?

Several curiosity-creating phrases and articles about serverless have recently appeared in the tech media.

While I agree that things and trends reach a peak before slopping down, I struggle to understand how, why, or where all these recent concerns originated.

This article is about my observations of serverless over the last few years and where I see it heading.

Warning: It’s a long read with the following topics:

• The two events
• サーバーレスとは何か？
• The growing phases of serverless
• Technology landscape of the corporate world
• Is serverless mainstream?

Two Events Almost A Year Apart

- butterfly effect?

The speed of the modern tech industry’s evolution and expansion is astronomical—it feels faster than our daily spin with the Earth. With this speed, a tiny disruption can quickly cause collateral damage.

Technology has become so delicate these days. Gone are the days when you chose a tech stack and stuck with it for decades or forever.

Adoption, migration, refactoring, and deprecation are now part of daily team conversations. It is no shame. This is how modern engineering teams cope with change.

Given the vulnerability of modern tech, the two events that rocked the serverless boat in the AWS ocean are,

• Last year’s Prime Video story and
• The recent re-org of the Serverless Developer Advocate (DA) team

Let’s explore whether these events caused the tech advisories to sway opinions and sing the long-live-serverless song.

The infamous Prime Video Story

Do these phrases sound familiar to you?

• Shoot yourself in the foot.
• Score your own goal.
• Dig your own grave.

That’s precisely what the poorly worded microservice to monolith article from Prime Video published in March 2023 did to AWS. I have no clue how it slipped out of Amazon’s ever-cautious editing hands.

The intention of that article is clear. Unfortunately, media outlets blew it out of proportion for blame games and self-advantage.

However, I find two important things in that story — a question and a lesson.

Question: How did they miscalculate cost and scale?

With all the expertise and the AWS Well-Architected Framework by their side, how did the architecture brains behind the original Prime Video solution not consider the cost and scaling limits before building?

Even in an average serverless team, cost analysis and identifying hotspots are some of the basic things engineers do while performing solution designs.

Prime Video missed these, and technology gets the blame.

If you try to fit a square peg in a round hole, it’s not a technology problem; it’s human stupidity.

Lesson: Refactor and evolve the architecture

When the Prime Video team realized the mistakes, they rearchitected and made the necessary changes. Modern teams should not hesitate to refactor and evolve their architecture.

This is a good lesson for everyone.

However, that does not imply we must refactor all the microservices to monoliths. That’s not the point.

The refactored Prime Video solution includes containers and managed serverless services, and there is harmony.

The disbanding of the Serverless DA team

Developer Advocacy (DA) is an impactful role. Due to DAs’ close association with the tech communities, any change to their position, role, or responsibility spreads speculation in the industry.

While it is sad to see friends leaving AWS, it does not necessarily relate to any sweeping changes in technology at AWS.

As you will see in the next section, AWS has the most popular and widely consumed serverless building blocks. Given their customer obsession, AWS will never jeopardize this.

The ongoing technology alignment at AWS

If you’ve observed AWS strategy for a while, you would’ve noticed the signs of tech alliance, as highlighted below.

• Promotion of event-driven architecture. It is deliberate. As an architectural concept, it bridges serverless and container workloads.
• Combined community relations. The compute community relations team at AWS is responsible for serving serverless and container communities.
• Serverless Containers. As the demand for running heavy workloads on Lambda pushes its boundaries, an unrestrained approach to choosing the right service for the right job is becoming the norm.
• Better together slogan. Embracing serverless and containers. You are likely to hear this tagline at future AWS and serverless gatherings.

So, the signals were there, but most of us didn’t notice.

The question is, what impact will this tech alliance have on serverless?

We will explore this after checking on the origin of serverless.

So, what is serverless anyway?

Read these facts first:

• Amazon Simple Queue Service (SQS) beta was released in 2004
• Amazon Simple Storage Service (S3) was launched in 2006
• Google App Engine (GAE) was released in 2008
• Serverless as a term appeared first in 2012
• AWS Lambda came into service in 2014
• Amazon API Gateway became available in 2015

According to Mike Roberts in his article “Serverless Architectures”, the first uses of the term Serverless seem to have occurred around 2012.

Assuming you are familiar with SQS and S3, do you consider them serverless services?

• If you do, they existed before serverless was even a term!
• If you don’t, what do you call them? (Fully) managed services?

The mistaken identity of (early) serverless

The widely accepted serverless concept is based on the fact that you do not need to manage a server when you consume a service.

Build and run applications without thinking about servers. — AWS

The above is the most straightforward definition of serverless.

The notion of serverless, however, took a turn with the release of AWS Lambda—compute as a managed service, better known as Function as a Service (FaaS).

FaaS liberated engineers from the pain of setting up network boundaries, provisioning servers, patching, scaling, load balancing, etc. The ease and acceleration brought mesmerizing accomplishments in the industry.

In the early days of serverless, it felt every engineer carried a Lambda hammer to fix every problem with a function!

With FaaS’s overnight popularity, the then almost unheard-of term serverless took off — along with its mistaken identity: Serverless = FaaS!

The emergence of definitions (and expectations) of serverless

With the acceptance of serverless and the increase in its adoption in the industry, our understanding of how to differentiate serverless from FaaS got better.

Based on everyone’s experience working with serverless, there was a rush to define serverless! There were two main reasons for this.

1. Make serverless technology understandable to everyone.
2. Propose guardrails for serverless for the attention of AWS and other cloud providers.

To learn about some of the early definitions of serverless, I recommend watching Jeremy Daly’s great talk ‘Stop calling everything serverless’ at Serverless Days Milan, 2019.

With the influence of AWS Lambda (FaaS) and other managed services, the definitions and guardrails implicitly compiled an unofficial serverless specification containing the following core tenets.

• Pay-per-Use (later became Pay-per-Use and Storage)
• Scale to Zero
• No server management

Any cloud service with a serverless tag that violated the above has become a topic of debate in the industry.

The early release of Serverless Aurora, as it didn’t scale to zero, thus became an argument in the community, questioning whether it was serverless.

This sanity check still happens with every new managed service released with a Serverless tag.

The recent Serverless tagged variant of Amazon OpenSearch also caused an uproar as it does not fit within the strict pay-per-use pricing category.

The lack of a universally agreed-upon serverless specification in the industry means nobody can control what comes from the cloud providers.

The changing face (growing phases) of serverless

While the serverless service naming convention remains a source of confusion, conflict, and criticism, the industry’s adoption of serverless has progressed rapidly.

With less care in architectural principles and implementation patterns, many teams took advantage of the harmless single-purpose Lambda functions to achieve everything. The number of Lambda functions exploded astronomically.

The explosion of unmanageable amounts of Lambda functions led to three main problems.

1. Tangled Lambda pinball architecture
2. Skyhigh cloud bills, in some cases
3. Function fatigue

The industry often makes noise about the complexity of serverless. In the article Is Serverless Hard to Adopt? I addressed some of the reasons why.

Some technologies are complex by nature. And then, we create complexity with technology.

The function fatigue, however, led to an exciting serverless movement!

The functionless paradigm

More functions mean more maintenance headaches. Code is a liability. So, reducing custom code (i.e., Lambda functions), thinking of low code, and using codeless patterns became the advisory phrases.

It’s not new. I wrote about functionlessness in 2019 and have spoken about it at conferences.

Thus, within a few years of being serverless, the compulsion to do everything with functions has changed to doing many things without functions!

As several native service integration patterns evolved, engineers learned to look for innovative ways of implementing business logic.

The two software patterns and two AWS services that took service integration to newer territories were,

• Service choreography with Amazon EventBridge, and
• Service orchestration with AWS Step Functions

These two will form the foundation for further changes to come to serverless on AWS!

The spread of distributed architecture

Although the distributed architecture is not new, serverless presented a few development challenges regarding resource connectivity, cross-account access, violation of domain boundaries, etc.

With Amazon EventBridge as the choreographer of services and AWS Step Functions as the orchestrator of business workflows, there is now a new way of building serverless microservices.

With features such as API Destinations, Task Tokens, SDK integration, HTTP Endpoint, etc., engineers have the means to distribute orchestrations and interact with non-serverless tech stacks in organizations.

Asynchronous communication and event-driven architecture were about to become mainstream for serverless. The industry required approval from someone of the stature of Dr. Werner Vogels, and that’s precisely what Werner did in his keynote at AWS re: Invent 2022!

The world is asynchronous. The world is event-driven. — Dr. Werner Vogels, CTO, Amazon.com

The continuing demand for more computing power

- exclusivity of doing everything in serverless means many use cases that traditionally relied on always-on containers with abundant CPU and GPU power had to find a match in the serverless world.

FaaS, with its ephemeral nature, has limits. Though Lambda upped its resource power and duration, it is no match — and never will be — for some durable high computing needs in organizations.

To find a middle ground, AWS Lambda underwent changes, such as more memory, an Elastic File System (EFS), a container image option, etc.

Inevitably, with the current pricing model, more power to Lambda in a high-volume situation can only mean one thing — higher cost!

Though product teams at AWS are evaluating several improvements (that I cannot share here), this constant industry demand has opened up inclusivity in tech conversations.

The right tool for the right job.

The ever-so-difficult act of balancing competition, demand, and purity

While many AWS services are on top of the cloud world, naming services has never been AWS’ strength. No, I am not talking about the Amazon と AWS prefixes! That’s for another day.

Due to competition and the urgency of grabbing industry attention, deliberately calling a service (or its variant) サーバーレス has become a practice that annoys many.

Serverless has evolved enough that we don’t need such naming tricks. Keeping true to a service’s capability will make many in the community happy.

However, the lines often get blurred when an existing non-serverless service evolves to offer serverless characteristics such as on-demand scaling, pay-per-use, etc.

Besides the service naming, to understand where AWS is heading (in my opinion), to find answers to the organizational changes at AWS, and to the future of serverless, we need to first look at the technology spread in a typical enterprise.

An ecosystem is a geographic area where plants, animals, and other organisms, as well as weather and landscape, work together to form a bubble of life. — NationalGeographic.org

The interconnected technology ecosystems

Serverless is a technology ecosystem!

Serverless Development on AWS (O’Reilly, 2024) calls serverless a technology ecosystem and relates it to a natural ecosystem. Like an earthly ecosystem, which contains living and nonliving parts, the serverless ecosystem includes technical and nontechnical elements.

In a serverless ecosystem, managed cloud services such as S3, SQS, EventBridge, Lambda, Step Functions, etc., are the fundamental building blocks. You compose your serverless application with these building blocks and their characteristics.

You use the infrastructure definition to wire them and operate on the cloud platform — the enabler.

Engineers who build solutions for business stakeholders — the nontechnical elements of the ecosystem.

Varying demands of the corporate world

Enterprises have several parts—i.e., domains—with different responsibilities and capabilities, which demand different technology.

• Efficiently responding to customer queries.
• Handling predicted and unpredicted traffic patterns.
• Ingesting a high volume of data.
• Running data science and machine learning (ML) models.
• Classifying and storing several categories of data.
• Securing corporate assets and protecting customer data.
• Providing platforms and tools to enable teams to achieve fast flow.
• Hype or not, allocating space for GenAI LLM,
• and so on.

While serverless can handle most, some use cases and workloads require capabilities beyond what serverless can offer.

Understanding and assessing such requirements is essential to avoid the Prime Video team’s mistake. Be receptive to what works best. Don’t be the one who tries to fit a square peg in a round hole!

In the book Serverless Development on AWS (O’Reilly, 2024), the chapter dedicated to evaluating an enterprise’s readiness for serverless has a section titled Assessing Workloads for Serverless Suitability, which discusses several use cases on the suitability of serverless.

Here is a quote from the book Serverless Development on AWS.

When you assess the suitability of serverless technology with serverless-first thinking, you consider serverless as your first technology choice. This does not mean you overrule other technologies with a serverless-must mindset.

Dependent and connected technologies

In an enterprise, different technology ecosystems support a diverse set of business capabilities, serverless being one of them.

If you apply the ecosystem analogy to an enterprise’s technology landscape, you will notice it is formed of different technology ecosystems—serverless, containers, on-prem, etc.

Many organizations require more than one ecosystem to be competitive. To be effective, these technologies must work together like the connected ecosystems of the natural world. The technology ecosystems complement each other.

Here is a simple example:

Say an enterprise’s domain is data analytics/science. Its serverless ecosystem ingests and stores data. The container ecosystem processes massive amounts of data and runs algorithms and data science models.

The serverless ecosystem then handles the output of those models and prepares and serves the data to other business domains (and other technology ecosystems).

But how do these distributed ecosystems work together?

By employing proven industry patterns and practices!

• Synchronous and asynchronous communications
• Event-driven architecture
• Orchestration
• Choreography
• and so on.

Making those technology connections work for the betterment of the industry is an area in which AWS cloud strategy is pressing ahead (in my opinion).

Serverless passion led us here. Practicality will lead us ahead.

Serverless is mainstream and thriving

In this treacherous world, nothing is the truth nor a lie. Everything depends on the color of the crystal through which one sees it.

Pedro Calderón de la Barca

To understand the reach of serverless (or lack of it), skip AWS and serverless-themed conferences and speak to the audience at more generic technology conferences.

Serverless — even cloud — is unheard of in several industry segments.

Being part of a close-knit tech community such as AWS and Serverless, we learn, share, demand, criticize, and evangelize what we are passionate about. We become emotionally vulnerable to changes in this community ecosystem.

However, we should look at technology from an overall and long-term perspective.

For most organizations that have yet to benefit from serverless, it hasn’t mattered to them yet, but it will soon.

AWS will continue to enrich its managed services

As I mentioned earlier, managed services are the building blocks of serverless.

Even after two decades in service, SQS continues to receive new features and capabilities.

Many core serverless services, including FaaS, are constantly updated with capabilities to support integration, improve observability, ensure cost-effectiveness, promote sustainability, etc.

I do not see this slowing down.

AWS will continue to launch new serverless services

Those in the AWS community know the long list of AWS Wishlists. Working closely with customers and gathering input via AWS Heroes and the Community Builders, AWS will launch new services as necessary.

The service name may become an industry-wide debate, but hey, there is always room for improvement!

The serverless ecosystem will evolve outside of cloud providers

Whether we notice it or not, the serverless ecosystem is growing outside the leading cloud platforms.

The industry has successfully developed and adopted several new offerings, such as FaaS, cache, datastores, edge computing, GenAI/LLM, etc.

Momento Cache, for example, is utilizing cloud capabilities to offer the industry a seamless serverless cache solution.

Exciting new concepts such as Infrastructure from Code (IfC) have now brought undifferentiated heavy lifting to serverless — like how serverless lifted us from server management.

Jeremy Daly and the team behind Ampt is an example of how the industry innovates on top of serverless.

The industry adoption of serverless will grow with maturity

As many echoed, the initial mad (gold) rush to grab a piece of serverless is over. The early excitement of building a hundred different image transformation solutions on serverless is no longer exciting.

But that is no way to say Serverless is Over!

As several enterprises adopted serverless, teams became busy building business capabilities at never before speed. Along with the experience came the quest for

• Better developer tooling
• Better architecture patterns and practices
• Better pricing models
• Better observability options
• etc.

These are the signs of a community caring for a growing ecosystem, not abandonment.

The meaning of serverless-first, which does not imply serverless-must, is now well understood in the industry.

Evolving technologies embrace change. Serverless is no different

I have written a few articles and delivered several talks on serverless. Like many in the industry, I have always acknowledged not all business needs can be addressed by the serverless ecosystem or a particular technology alone.

As with the ecosystem analogy, serverless will ally with other technologies and ecosystems to bring better business value.

This is where AWS is heading — break the siloes and become technology-inclusive with the new slogan — Better Together!

Serverless has already started…

Around five years ago, during an online chat with Jeff Barr, I was curious to know whether the next evolution of the cloud beyond serverless has started.

Thoughtfully, Jeff replied, Sheen, we are just getting started with Serverless, and it has decades of life ahead of it.

With its adoption and growth over a decade or so, we can now proudly say that,

Serverless has already started!

It is no longer a sidekick but mainstream.

More transparency between technology ecosystems will bring more partnerships and mutual respect to promote the right tool for the right job.

Serverless is for everyone!

For over a decade, serverless has evolved.

I once wrote an article, Serverless is for Everyone, to echo the community tagline and argue it’s fit for enterprises.

When it became a discussion point about its adoption difficulties, I answered with an article Is Serverless hard to adopt? that concluded with the beautiful theme of Momento’s AWS re: Invent 2023 party, Believe in Serverless!

So,

Serverless is not dead!

Serverless does matter to the industry!

The serverless ecosystem is evolving! and

Serverless has decades ahead of it!

Serverless is here for everyone who believes in it!

What about the Serverless Fairytale?

Well, it’s not over. The story continues with new exciting chapters!

The title picture is a modified version from my blog Serverless Adoption: Is Cost Still The Main Factor?