Why Serverless Projects Are 5x Faster and 50% Lower Cost

Too good to be true? Cloud tech specialist Andrew Walker explains exactly what makes it possible. 

So it’s time to start a new project. There’s plenty of servers and infrastructure lying around, waiting to be used. It’s certainly tempting to assemble some Architects and start designing new infrastructure on top of what you’ve got. It’s what most companies have always done, after all, and they’ve spent millions in the past setting it all up. 

But what if you ignored all that infrastructure? 

What if taking a leap and building your project on serverless, cloud technologies meant that the project you expected to take two years can be done in just three months? 

And at half the cost? 

So, if you’ve got a “normal” budget of $2,000,000 for your project, you'll deliver it on serverless technologies for $1,000,000 at MOST… and based on my experience, likely for closer to $200,000. 

For the uninitiated, those numbers sound too good to be true. But after a decade of championing cloud technologies, it’s become a pleasure of mine to explain exactly how it’s possible to run projects 5x faster and at half the cost.

1. Infrastructure Is Taken Out of the Equation

Here is a (really basic) infrastructure setup to support a simple, modern digital solution. It’s based on a real client of mine using their own on-premises infrastructure.

I remember setting up data centres 20 years ago. This is what they looked like then, too.

All that hardware, software, cabling, and integrations certainly comes with a cost. But there’s an even higher cost that’s very human: Meetings. Endless meetings. 

The time goes into:

• Finding and resourcing 20+ architects and infrastructure engineers
• Scheduling and holding 50+ meetings, many with large numbers
• Resolving and signing off every aspect of the architecture

Hundreds of hours of meeting over months and years just discussing and planning infrastructure. And none of that effort is focused on solving the problem that kicked off the project in the first place.

Let’s look at an alternative. 

Here’s the infrastructure for the same project, this time deployed on AWS SERVERLESS. It looks like this:

Super simple, right? 

If the goal of infrastructure is to create an environment in which the developers can start coding, well, we’ve just got to the same result with ZERO effort. When you shift to serverless, you AVOID a whole bunch of thinking, choices, meetings, people, decisions, signoffs, and licenses.

It’s one choice that needs to be made, which then means every subsequent project is infrastructure ready.

Serverless is like the TL;DR or the Ctrl-Alt-Del of infrastructure.  

Take 50% of the work you normally do and just DELETE it. Don't do it.

A client of mine used to spend 40 million dollars every year just building data pipelines from source systems to “business intelligence” platforms. Most of her money went on humans in meetings. It’s not the infrastructure that costs money — it’s the humans THINKING about the infrastructure that costs money.

2. Release Early and Release Often (I mean actually early and often)

Typically, projects are deployed regularly into a test environment during the build. But even if we’re doing Scrum or Agile or XP, we’ll still only deploy in test, even though those philosophies have always been about getting software truly live as early as possible. 

So the reality for most projects with budgets of over $1 million, you’re still going live at the end of that project, not at the beginning. 

So you get teams saying, “We’re doing Agile, but we’re just not deploying into production” — which just isn’t Agile. It's not what the founders of Agile meant.  They meant “release early into PRODUCTION.”  

Here’s the rub: It's impossible to “release early” if it takes six months to design, provision, build, and test the infrastructure (even if it’s cloud infrastructure) before you can deploy a single feature. 

With serverless, the infrastructure only requires an hour of configuration, and then we can start coding. That means it’s only hours between the project kickoff and the first pilot, which can be live with a real user. 

From there, it’s easy to expand the core central product so it can cater to more people. And that means every stage of development is based on real, raw feedback — essential for a successful project.

3. Smaller Teams Result in Even Leaner Projects

In the olden days of managing big infrastructure-based projects (like when I helped Walmart create their first ecommerce platform), a “standard” team was around 15 to 20 humans, all kept very, very busy.

With projects built on serverless technologies, my teams can achieve the same total feature output with only 5 to 7 people. My teams ran 300 projects over the last 10 years, often experimenting with even smaller teams where the same output was delivered with a total team size of three.

That’s right, just three people. So how was that possible?

In the first instance, around half the work is avoidable by avoiding infrastructure (and the people who think about infrastructure).

The second reason it’s possible is that we eliminated overheads. In particular, communication and governance overheads. 

For every additional person on a team, there’s an exponential increase in the number of people who need to be “in the loop.” Who needs to be managed. Who needs to be kept compliant with policies.

Smaller teams are exponentially more efficient simply by having fewer people to coordinate with.

Most people will have experienced this already at some point in their career: “Oh yeah, there was this one time a few of us just smashed it out the park…”

One way to keep teams small is to have “multi-functional individuals.” If we can get one person to cross-skill in two traditional roles, like having both front-end and back-end developers combined into one full-stack developer, we need fewer people. The project runs faster because there are no communication handoffs just for getting one single feature built.

4.  A Fresh Way to Frame and Solve Problems 

So far we’ve explained maybe a 3x speed improvement through deleting infrastructure and the flow-on efficiency we gain from having smaller teams.

But by removing a whole PHASE of zero-value work from our projects, we begin to ask questions like “What’s stopping us from deploying something useful to real users in the first week?”

The answer is “nothing is stopping us” — except the tendency to follow old rituals like documenting requirements before we start coding.

Documenting requirements comes with its own dangers. It requires crystal ball gazing to predict everything that might possibly be needed to achieve an outcome. So I tell my teams to stop predicting everything, and just start building the one thing they think will make the biggest difference to the business outcome the project was set up to achieve. 

All the team needs is a common vision of the business outcome, or the business case. Instead of a list of features, that’s an outcome like “reduce the time to approve insurance claims by 50%” or “double the number of cases the call centre can resolve with the current team.”  

Having clarity on that vision means the teams don’t need to define the solution upfront. Instead, they can figure out with the users what the “biggest bang for the buck” is along the way.

Having the whole team live and breathe a common vision of what the finish line looks like is highly unusual and highly empowering for the team.

This approach to framing problems is easy to train people in over the course of a single day, and it makes a massive difference to the team’s effectiveness because we simply build less than we would using other approaches. Features with an obvious impact on the outcome we’re trying to achieve are given priority over low-value features, and at the end of the project, any remaining low-value features are dropped entirely.

So instead of “we need a workflow system,” the team thinks in terms of outcomes. (For example: “We need to reduce the time it takes to offer a law student a place from 9 weeks to less than a fortnight.”) 

The team builds less, and the solution is more effective and easier to use.  Everyone wins.

Get Started with Serverless

Serverless is the way to build and deploy releases very quickly for a fraction of the price. You won’t need a huge infrastructure team to support the projects, or operate a data centre. You won’t waste time building features you don’t need. 

Indeed, it has unlocked some fascinating opportunities for developers. It has made it easier, faster, and more affordable to build powerful solutions for enterprises. 

Keen to know if serverless projects can solve your business challenges? Reach out to me on LinkedIn, and let’s set a time to chat over coffee.