Design Thinking and the Question Serverless Should Be Asking

Published:

“At the heart of any good story is a central narrative about the way an idea satisfies a need in some powerful way.”

“What’s the story of serverless?” What need does it satisfy?” Not the technical need. The human need. Why does it resonate so well with some people and not so well with others?

I believe that serverless is the #1 way for anyone to get started building something new. Whether you believe the hype or the haters, it is irrefutable that if you have an idea and you want to get it in front of users as quickly as possible, serverless is the way. By using the word serverless here, I am referring to all managed services, including things like Azure Container Apps, Amazon ECS/Fargate, Google Cloud Run, not just functions.

When most people talk about serverless, me included, they lead with the technical stuff. No servers to manage. Pay per invocation. Auto-scaling. All true, all useful. But none of that is a story. The emotional connection just isn’t there.

Maybe the Story Is Wrong?

Design thinking has this concept of always starting with a human-centred question. Not “how do we build a better voting machine,” but “how might we enhance the democratic experience.” The focus shifts from the noun to the verb. From the thing to the feeling.

So what does that look like for serverless?

Those questions feel very different to “how to run your app in a way that means it will scale automatically, and mean you don’t need to care about servers”. We are all humans talking to other humans, and as humans we love stories.

Homo Sapiens by Yuval Noah Harari is a book I refer to often. And one of the core ideas in that book is the importance of stories. Stories are fundamental to the success of the human species. From the obvious stories our ancestors will have told “don’t go down to the watering hold, there’s a lion that will eat you” to the not so obvious example of things like the modern financial system. The modern financial system, like many things in our lives, are built on a shared story. A shared belief. A shared idea.

It’s stories and shared beliefs that allow us to operate together at massive scales. Whether it’s the financial system, the company you work for, your nationality, your religion, your political leaning or anything in between. Our ability to connect, and to share stories, is what sets us apart as a species.

Yet all too often, not only in tech, we start with the technical details not the human-ness.

The Container Story is Already Written

Looking away from serverless for a moment, containerisation and Kubernetes in particular have a compelling story, even if it’s not always the right one.

Build your application using a well-documented, well-understood web framework. Package it into a container, which everyone knows and understands. Ship it to an orchestrator that everyone in the industry says is the way to run large scale applications.

Nobody got fired for buying IBM, right? And no CTO got fired for doing what everyone else is doing… Which in this case is deploying the app to Kubernetes. The safe choice maps to the existing mental models which makes the story easier to tell.

That’s a genuinely hard thing to compete with when you’re trying to get someone to shift their thinking toward a new paradigm. The serverless story needs to be just as easy to tell. And right now, I’m not sure it always is.

Prototyping as a First-Class Citizen

One of the other ideas from design thinking that really resonated with me was this: “A vibrant design-thinking culture will encourage prototyping — quick, cheap and dirty — as part of the creative process, not as a way of validating finished ideas.”

That’s exactly what serverless should be. There is no better tool available for moving quickly. You have an idea, you write some code that focuses purely on the business logic, you deploy it, and it scales when it needs to. No infrastructure setup beforehand. No cluster to configure. Just your idea, running in the cloud.

That’s a story worth telling. An early career developer who wants to learn fast. A founder with a weekend and an idea. An experienced developer who wants to prototype something without spinning up a bunch of infrastructure first. You’ve just vibe coded something into existence, now what? It certainly isn’t go and spin up an EKS cluster, provision an ingress controller and write a Helm chart.

Every single one of us now has the power to go from idea -> working product -> running in production in an afternoon. The aha moment of having the app created is great, and serverless technologies allow you to productionise it. But also to do that in a way that has low financial risk whilst also being scaleable if you do happen to go viral.

The fundamental starting point of most applications is a web app and an API. What does the customer journey of building and shipping a web app on serverless look like compared to doing the same thing on a container orchestrator? I think if you map those two journeys out honestly, the serverless path is significantly shorter and significantly less painful for the person just trying to get their idea in front of real users.

Granted, if you have an entire platform team around you to build and run the container orchestrator for you then great. The journey to shipping the POC is probably equally as simple in that case. I once spoke with someone at a conference who said “My company uses Kubernetes, but all I do to is push a container image, the rest just happens and it scales automatically. Does that mean I’m serverless?”.

Yes, yes it does my friend. Not everyone is that lucky though.

To be clear, I’m not suggesting that you can’t run proof of concepts on Kubernetes. And equally, I know of hundreds of companies running large scale production workloads purely on AWS Lambda. As I’ve argued before, framing this as ‘serverless vs. containers’ misses the point. The real question is: What’s the fastest path to delivering value to users? https://blog.jameseastham.co.uk/blog/on-factors-of-modern-compute/.

Maybe you’re reading this an you’ve heard all about serverless. And you’ve heard the naysayers. Frankly, some of them are right. Yes, your serverless functions will have cold starts (they probably aren’t as bad as you think). Yes, you may be locked into a specific vendors managed service (thinking about code design prevents this. Kubernetes has lock in too ya’know).

But if you’re trying to get anything you build in front of actual real people, in a way that will scale alongside your business with next to 0 effort on your part, that’s a worthwhile trade off to make.

Shifting the Focus Outward

A lot of the conversation in the platform engineering and infrastructure space is inward-facing. How do we run our systems better? How do we manage our clusters? How do we reduce operational overhead for our internal teams?

All valid questions. But design thinking pushes you to zoom out. To think about the organisation and their customers. To think about the users of the software that teams are building.

What are the benefits to them? Does your user care whether their request was handled by a Lambda function or a container on a Kubernetes node? Absolutely not. They care that it was fast, reliable, and that the product keeps improving to meet their changing needs.

Spending a huge amount of time and money on platform engineering is not innovating. It’s not human-centred. It’s not solving the needs of your users. There’s a version of it that enables teams to move faster, sure. But a lot of the time it’s just undifferentiated heavy lifting dressed up as strategy.

Eventually, maybe Kubernetes is on the horizon. If you start with a serverless function, and 18 months down the line you realise your workloads better suits a long running container then amazing. The answer still isn’t Kubernetes, but maybe you start to head down that road.

At each specific moment in time you made a pragmatic architectural choice about how you want to get your application in front of users in the best possible way.

It’s another reason why I think the ability to adapt your system over time as it’s needs change, is the most important consideration for any software system. Things will change, it’s inevitable. Have you designed your system to be able to deal with that change? The #1 problem I see with AI generated code is that, without careful prompting, evolvability goes out the window.

A Few Practical Things I’ve Taken From This

Design thinking has some really simple habits that I think are worth stealing regardless of what you’re working on. Be it serverless, be it something else in tech, or not in tech at all.

Stop regularly and ask yourself five whys. Why do I do this thing this way? Why has this always been the default? It’s a surprisingly effective way to challenge assumptions that have just been sitting there unchallenged.

Sketch things out. Not as polished diagrams, just rough sketches. Customer journeys, system flows, the path from idea to production. Drawing forces clarity in a way that writing often doesn’t.

And reframe your questions as verbs. Don’t ask how to build a better serverless platform. Ask how you might enhance a developer’s ability to quickly prototype and ship. Don’t ask how to improve adoption metrics. Ask how you might make the getting started experience so good that people just want to rave about it to their colleagues.

That last one feels like the real opportunity to me. If anyone who has a positive experience with serverless can communicate its essential elements in a way that encourages others to try it — that’s how you build momentum. That’s the story worth telling.

Next time you’re talking about serverless, or in fact, any decision. Think about the human-centered side of things. Think less about the technology, and more about how is this going to positively (or negatively) impact another human being. That will inevitable lead you to building better software.