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 first stage is simple. Complete lack of understanding. Mainly due to everybody having a mindset of requiring a server, and the “Serverless” name being very unhelpful.
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
The first time you create a Serverless solution of some sort, most people seem to have some sort of epiphany (especially with FaaS).
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
This is the fun stage. Playing with the technology. This is the point where people tend to ignore what other people have been saying in blogs and on conference videos for well over a year now (it’s the beginning of 2017) and think that they know how this tech works best.
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
After the common mistakes have been made, what generally happens is that something “clicks” in the person’s mind.
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
Once you’ve created the first set of FaaS (or similar) and utilised some sort of event based system or API Gateway or somesuch solution, the realisation hits that you have to deploy it and maintain it.
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
Then once you’ve mastered this deployment scenario what tends to happen is that a team of people need to collaborate on the project.
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
This is where the realisation that Serverless is imperfect comes out.
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
I’m not sure if these stages are particularly how everybody goes through it, but I do recognise them from my journey. I reckon that some of the newer tools may help resolve some of these issues (I can’t say as I’m not going to utilise a lot of them as my first interaction with the issues) but similar thinking still has to happen.
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!
