Starting off with serverless

I’ve recently had a number of different conversations with people who are just coming to serverless technologies. It’s fascinating to see how they start off approaching it.

They usually pick AWS Lambda and usually do one of two things:

  1. Transfer their current paradigm into Lambda, which makes it really hard
  2. Follow a basic tutorial, which often doesn’t cover the “why” of serverless

(In fact, one person said that AWS Lambda is like cocaine. Easy to try, and get hooked. It’s very difficult to stop using it once you start. Once you’ve got hundreds of Lambda functions you do end up with the sense that you can never let go. I would suggest though that as far as addictions go, serverless might be a lot more benevolent and positive!)

I was always told that the choice of technology is dependent on the use case. It’s fascinating to see how many people have simply picked a technology and then used it over and over again in different scenarios, simply because they “know it”.

This isn’t inherently bad. In fact, the majority of times this is perfectly ok, because the underlying systems are practically the same.

Running your own server is like…

… co-locating a server in a data centre which is like…

… a Virtual Private Server (VPS) which is like …

… an EC2 instance (or similar) which is like …

… a container

But the next step into serverless is fundamentally different.

Serverless is much more about switching your thinking from

“all the logic and connectivity is in one place”


“the logic is in the FaaS and the connectivity is in the connecting services”

In other words, switching to a serverless mindset requires that you step away from the old paradigm and into the new one.

So, what does this mean for “Starting off with serverless”?


Your first step is not FaaS, but infrastructure.

The FaaS is simply the logic. The skill in serverless is based around the infrastructure.

This is why the infrastructure as code solutions such as CloudFormation or Terraform are where the primary discussion usually sits.

Because the functions are relatively simple to create and relatively simple to unit test (so long as you mock the services you’re using).

So when we look at the tooling around serverless, one of the big missing pieces is actually decent tooling around infrastructure.

We have terraform (which is great, when you know it) but actually, there is a lot of copying and pasting going on.

Also, CloudFormation is improving but is still relatively complex to write, which is why we all develop abstractions.

And essentially, all these tools are abstractions on the AWS CLI (or the libraries based on it), hence why we’re also seeing gists and code based around how to setup a quick serverless scenario via shell scripts (and the cli).

The thing is, that at present, all those tools simply abstract away from the CLI. There are some common patterns that could be joined up, but then you’d also need to know about other elements in the system, which is why it’s hard.

Simply put, if you have a poor understanding of cloud, and are used to instances and containers, it’s a struggle to get into considering many many services in one system. It feels strange.

But if you can step out of your paradigm, and understand why the services are used in different scenarios, you end up developing much more scalable and robust solution (in my opinion).

It is trading one set of problems (monolithic codebase) for another (complex distributed service based patterns) but having done serverless for over 18 months now, I can honestly say that it’s the set of problems I’d rather have.

But we still need a lot better tooling!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.