I’ve been trying to think about Serverless in different ways in the past few weeks. My last post on Serverless and Event Architectures has got me reviewing a number of development tenets I thought were key to all development.
The biggest thing I have realised though is less to do with the idea of tiny and loosely bound function-compute instances, but much more to do with the surrounding infrastructure.
In recent months, we have seen a large number of other players trying to catch up with AWS and it’s Lambda offering. We’ve had Google release Cloud Functions and IBM and OpenWhisk (which I really like as an idea) to provide a form of “nano-compute” infrastructure to users. Note: This is an incomplete list of competitors. There are loads of them.
So the idea of single, event driven compute is definitely here to stay. Lambda has obviously hit a nerve and competitors are trying to catch up.
But the part that is being missed in the discussion of serverless, is the same thing that often gets missed when discussing a technology.
The key is not the technology
It never is.
The technology is a facilitator.
It’s an enabler to allow people to do clever things (or stupid things in a different way).
Whenever a new technology comes along, someone, somewhere will produce a copy of it, or a duplicate of the service. I remember when Twitter exploded that the first thing that happened was we had an “open source” version of it, then a bunch of copycats, and then a bunch of others saying that it was so simple, it would never last.
The same thing has happened here.
But everyone has focussed on AWS Lambda. The belief is that that is the key to all of this.
But it isn’t.
Nano functions are the glue — Serverless is about *much* more
The more I have built on top of Lambda, the more the other services I bring in matter.
The majority of the functions that get built around a Serverless architecture are relatively simple. They often follow a mainly CrUD pattern of some sort and I utilise a lot of NoSQL (via DynamoDB) which is interesting and fun.
But the key for me is always the events.
And the triggers.
And the integration with multiple other services.
It’s the other services that matter. It’s the integration and the simplicity of that integration that makes Serverless work. The nano-compute is glue between events.
The problem with frameworks
We’ve been conditioned to look at frameworks as a time saver. They often are, in prototype, and certainly initial maintenance is relatively simple. Frameworks change though, and adapt and evolve. This can often lead to problems and refactoring.
If you put everything on top of the framework then your code can become unwieldy more quickly than you would like. It relies on the framework being able to cope and that nobody has coded badly and got it into the repo (this never happens in open source does it?).
The Serverless idea is that you are aiming to reduce maintenance. The more I look back, the more I see that the frameworks are part of the maintenance problem. It’s not that they were bad, it’s just that we didn’t have the paradigm of Serverless to change the way we did things.
So, moving to Serverless should reduce the long term framework issue, but may be more complicated to build. Also, refactoring code is easier when you can do one function at a time, but the system may be more complex.
Serverless is about events and nano maintenance
I’m still developing my ideas, and if I’m honest, finding it a lot harder to code some of the things that are simple when you have a “framework”.
But the keys coming through at present are:
Try as much as possible to trigger everything from an event
reduce maintenance (nano maintenance) as much as possible throughout the entire system
If you do those two things, you should be able to build a system that delivers high scalability, and high maintainability and your TCO changes massively.
As techies we often look at the cost of a build, but what we often miss is the cost of ownership over the long term. A good PM will do this, but the reduction of maintenance is probably the biggest cost saving you can make in a long term tech project.