I’ve been writing about the Serverless world for a while now (see my collated blogs on the subject), and it’s highly enjoyable knowing that what I’m putting out is making a difference to how people code and how people approach a new topic.
I’ve done a lot of practical work on Serverless, to give hints and updates on where the ideas are going and how you can get the best out of the technologies (primarily AWS Lambda).
So I wanted to give a bit more of a philosophical reason for Lambda, and link it into the way we see Startups moving in the last few years, so as to give a bit more context.
First things first: there are 2 sorts of Serverless. There is the sort that is “we’re going to let other people do everything for us and we’ll just build a client on top” and there’s the “We’ll build around a nano-function based approach and implement logic in tiny chunks” approach. I’m focussing on the second. The reason is that the first means that you build your logic into the client, and you have to build every new client that way. The second puts your logic in a single location, giving all of your clients a standardised approach. This is the way that AWS Lambda works, and this is the topic of this blog.
So, where does Uber come in?
Uber is a taxi service. It’s a very clever taxi service, but it’s just a taxi service. You use an app to get a car to come to where you are, and then it drives you to where you want to go.
The interesting thing about Uber is not the service, but how it is run. These people are not full time employees of Uber. They are contracted to do that job, and are paid on the basis of the work they do.
Uber is essentially per minute renting of a taxi from a third party.
You rent your car for what you need… and no more.
It’s essentially #CarLess Cars. There is still (of course) a car!!!
Which is just like the idea of AWS Lambda.
But what about Easyjet?
When the budget airlines like Easyjet, Ryanair and others came along, they had one simple plan. Pick popular routes (or underserved routes) and provide cheap air travel. To do this, one of the innovations was that they used the same make of aeroplane (mostly) across the whole fleet. Why?
Maintenance. Instead of having to maintain different forms of aircraft across the fleet, they only had to maintain one.
Which meant that they could guarantee having expertise in those aircraft.
But it also meant something else: they knew how many people they could get onto every flight. Every single one was pretty much the same.
So they could plan their routes and number of people to maximise their efficiencies.
Now interestingly, this isn’t the same as Lambda.
It’s probably more akin to auto-scaling containers.
But the problem is, what happens when you have slower periods for air travel?
Well, you have a problem filling your plane don’t you!
What would happen if you had a bunch of small aircraft with different capacities instead? You’d be able to manage the fluctuations more easily.
There is the issue of maintenance though.
But with AWS Lambda, you essentially have a bunch of small aircraft that do very specific routes, and utilise only as much as is needed for that route.
You don’t have oversupply of capacity.
Interestingly, with Lambda, the maintenance changes to not being about the plane (in this analogy), but about whether the plane is right for the route. Instead of maintaining one type of aircraft, each route has it’s own maintenance, but on a smaller scale.
It’s like a fleet of helicopters and microlights instead that are perfect for each route.
Why am I saying this?
Too often, people cannot grasp why Serverless might be “better” or worse. The fact is, as a friend recently said to me, you do exchange one set of problems (maintenance, security etc) with another set of problems (deployment, testing). It’s not that Serverless is perfect, far from it.
It’s that, in my view, those problems you get with Serverless, are better problems to have than the ones you get with instance or larger scale PaaS or Containers.
What is it for?
Uber is on-demand - #carless cars.
Easyjet is all about reducing maintenance - #nanomaintenance planes.
AWS Lambda/Serverless for me is about both on-demand functions and nano-maintenance.
The maintenance is the biggest thing for me. Not having to maintain security on EC2 instances is great. But you can do that with PaaS. The control you get though with each “route” means you can optimise on a function level, which is much harder to do with PaaS (although not impossible). And you never have the problem of over-capacity (unless you code badly).