Thread by @PaulDJohnston

I am 99% certain most people still don't understand serverless.

For context this is one of the best posts on #serverless you will find:

adrianco.medium.com/platform-engin…

Why?

(1/n)

"We wanted AWS to grow its ... functionality, and to continually eat away at the bottom of the thin layer of rapidly evolving Netflix specific ... code that we had built"

This. This is what serverless is all about.

(2/n)

Custom code is a liability for everything *except* delivering your core business deliverables.

In other words, if you can run your business without any custom code (programming language, infrastructure as code, templates, HTML, scripts, everything!) then *do it*.

(3/n)

At present the best way I know of doing that is using AWS and AWS Lambda/API Gateway/DynamoDB/SQS etc with AWS SAM/CloudFormation. Using one of the git providers to manage code repositories and a simple project management tool and...

You can build a unicorn on that.

(4/n)

Let me repeat a small part again:

"to continually eat away at ... the ... rapidly evolving ... code that we had built"

That's what serverless always was to me.

It was always about doing far more with much less.

(5/n)

So when someone says "we need open source serverless alternatives" which happens *a lot* my response is generally "you've misunderstood serverless".

AWS Lambda is built on Firecracker.

There are open source API Gateway, DynamoDB, SQS etc equivalents.

They exist.

(6/n)

Do you know what's missing?

Do you know the piece that everybody has ignored?

SAM/CloudFormation

Probably not CF if I'm honest (amazingly)

And don't say "terraform". If you think that does the same thing you don't understand.

(7/n)

The importance of SAM/CF to serverless is immense.

It's not perfect. In fact it's a pain quite a lot of the time.

But once it's working it's a absolute dream.

Because *that* is your application definition.

(8/n)

Once you start to think in terms of SAM/CF instead of code, you start to build applications in a compasable way.

You also build things in a much more distributed and reproducible way.

All of a sudden applications generally become highly scalable, transferable and secure.

(9/n)

When it comes down to it, most applications don't actually do much processing.

Which is why FaaS is so powerful.

And most solutions don't need too many open API routes either.

And when you start building distributed systems using events...

(10/n)

AWS has built this incredible solution that just *does* everything for you.

And anytime anyone says "but only for specific circumstances" really doesn't understand how it works.

Those use cases are vanishingly small now and reducing.

(11/n)

Side note: if you can't code your process to fit into the length of time of a Lambda function *or* work out how to parallelise it or similar then you are in the "very small" set of use cases.

(12/n)

The future beyond serverless is already starting to arrive.

Services built on top of this where you can simply sit in a room and say what you need and a *fully distributed, scalable and secure solution* gets spun up without any need for you to touch anything.

(13/n)

Anyone saying "but open source" at this point is going to wonder what's happening.

When I started out in tech the open source movement was about trying to stop Microsoft and others having a monopoly on the server market.

We did that.

(14/n)

The unintended consequence was that any company in the world could then take linux and... become a web host, then a provider of VMs, and so on.

The open source movement built web frameworks and programming languages too to democratise those worlds too.

(15/n)

But you *can't* stop the innovation on top of open source without breaking open source.

That's what serverless is.

It is an innovation where open *source* cannot go.

If you're not prepared to accept that then don't complain.

Where *open* can go is "open interface".

(16/n)

Just like with S3 the de facto storage API is essentially the S3 API.

If you want to do "open serverless" then you have to replicate the innovation that AWS have done. Maybe not exactly but...

Create the interfaces for FaaS, API Gateway etc...

*AND* SAM/CF.

(17/n)

Because it was never just about the tech.

The ability to deploy and evolve rapidly was always a part of the solution.

That's why SAM/CF matters.

That's why simply building a FaaS with Kubernetes is only about 5% of the solution, and why people misunderstand serverless.

(18/n)

Going back to the original post:

"to continually eat away at ... the ... rapidly evolving ... code that we had built"

You need to be able to rapidly evolve.

All code is a liability.

Removing code is hard.

Have as little code as possible.

Make removing it easy.

(19/n)

I know this started from sharing a post about Platform engineering.

The idea of a Platform team is interesting to me. I think it's useful to a point. But it's not new.

What most people in tech really do not grasp is how to genuinely avoid creating future liabilities.

(20/n)

That's what serverless was all about for me.

When I started using Lambda in 2015 I was literally wanting to avoid running any EC2 instances for the back end of an Android app.

I'd run apps and teams before and maintaining EC2 instances was painful to say the least.

(21/n)

I remember in 2014 when the announcement happened that my first thought was how I could literally never have to run an EC2 instance again.

That never happened with Docker or Kubernetes. They have always just looked like a lot of extra work over Lambda for no benefit.

(22/n)

And that's the point.

The first talk I ever did on serverless, the last slide was of cocktails on a beach.

Because that's what serverless is like for me in comparison to every other way of doing it.

And even 8 years later, nothing has changed.

(23/end)