The many stages of serverless

It’s enjoyable to watch many new people come to the Serverless way of thinking over time. Some were early adopters (waves at new Serverless friends) and others are particularly late in arriving, but still very welcome.

I came across a blog post from Hootsuite

This is a really interesting blog post and well done to them for having a go and finding that logic in a Serverless stack seems to generally be a better way to go than trying to make a single front end code for an app.

In the spirit of this post and others, I thought I’d share some “Stages of Serverless” that I reckon most people go through.

Stage 1: What is this “Serverless” weirdness?

The way forward? Call it Jeff, and explain that it’s about not needing to manage servers, not that there are no servers (although there can be… no servers I mean… if you go down the thick client route)

Stage 2: The OMG moment

That step of actually having a go means that you realise pretty quickly that you can get a lot closer to writing logic and further away from having to combine multiple things together into a “whole”.

It also means that people start to see how it fits into their projects/ideas and what might happen.

The way forward? Encouragement.

Stage 3: Mistakes aplenty with frameworks

So they pick up their favourite blog post about how to deploy django into Lambda or their favourite node.js framework or some behemoth from Java, and then try it, and find it genuinely sucks.

This is the point where you give them some real pointers. Explain about technical debt and how it works in open source projects (you’re adding technical debt — be careful!) and then watch them reduce their dependence on it until they realise that it‘s a lot easier to write logic than they first thought.

The way forward? Walk them through an example, and remove all the unnecessary libraries (most of them).

Note: It’s this stage that generally people either jump straight into Serverless or fall away in my opinion. For some people, actually coding the logic becomes too big a leap. Fair enough, but I think they’re missing out.

Note: Has anyone else noticed that for a lot of developers, frameworks are an addiction? Ask them to do something outside of it, and it’s like they can’t type any more…

Stage 4: Another epiphany and possibilities

Once that “click” happens they start to play with it in a real world scenario and find that the approach can save time, money, maintenance and resolves a bunch of other problems.

It’s this stage when someone generally starts to advocate their approach over the “old school” ways of doing things. It’s ok to let them have their fun. It’s not quite plain sailing from here on in but it’s alright.

This epiphany means that they may well start to think of every solution as a Serverless solution first. This is a good thing, although there will be opposition, and people will pretty much ram the “There are always servers” line down you a lot.

Learn to ignore it!

The way forward? Give them a project. A real one.

Stage 5: The woe of deployment

For those of us who’ve done devops in some form, this is tricky, but not massively hard.

For those who’ve never done it, or have limited experience of it (and that’s surprisingly many) this is a step that all of a sudden feels like jumping off a cliff. It’s a lot harder to go from no deployment to Serverless deployment, than it is to have a background somewhere in it.

Because Serverless kinda needs a deployment strategy due to the nature of the uncoupled logic.

The way forward? Help them to simplify the problem. Suggest to them a tool (e.g. terraform) and hold their hand where needed. Infrastructure management is the key.

Stage 6: Many hands make… well it’s more complicated

When more than one person does this stuff, it becomes a little more complicated to manage.

Which seems a little counterintuitive but does make sense, since everything is less coupled, and therefore changes need to both be more and less collaborative at the same time.

More: changing stuff can mean information flow changes in unexpected ways

Less: changing stuff is far less likely to affect logic elsewhere in the system

The way forward? Bring forth your favourite CI/CD platform and learn to test properly. This is probably the most important step.

Stage 7: Seeing the (imperfect) light

Serverless is imperfect

But you also realise that it’s much less imperfect than a large majority of previous approaches.

It is very easy to understand why Serverless is an improvement for the majority of systems once you reach this stage. It’s not perfect for every scenario of course and that’s ok.

The Serverless evangelist at this point will become more guarded in their comments too. They will often caveat their “it’s the best thing ever” comments with a bit of “but you have to be prepared to work at it”.

But that’s ok.

This is where reality bites and it can bite quite hard, but it bites a lot less hard than the other approaches.

It’s also where you realise that the community of people doing this stuff is not as big as you first thought, but it’s generally a bunch of very clever early adopters who make you feel inadequate, but are also very very good at being positively critical and helping each other out.

The way forward? Get them to teach it to the next generation. Teaching it means that good practice goes forwards. This is a vital step — don’t miss it out!

Final thoughts

A lot of these issues are covered in my Serverless blog posts:

I think it’s worth reading those, as you can see both my ideas and the evolution of them.

Would love you to comment your own stages, just in case I’ve missed some (I’m sure I have). The comment box is just below!

Written by

ServerlessDays CoFounder (Jeff), ex AWS Serverless Snr DA, experienced CTO/Interim, Startups, Entrepreneur, Techie, Geek and Christian

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store