This is an introduction to serverless architecture for entrepreneurs, innovators, consultants, anyone working on building a product which uses those magic light screens in our hands or on our desks.
Serverless can be difficult to understand, it’s awash with words such as PaaS, IaaS, FaaS, or containerisation. You shouldn’t have to have five wikipedia tabs open to understand whether one of the most important developments in cloud computing is a viable option for your next app.
Ergo, we’ve written an explanation on the workings and commercial opportunities for serverless architecture, jargon free, through the medium of burgers.
We're also exploring new serverless opportunities ourselves, so get in touch if you want to try out serverless on your own project.
It saves you money on hosting. It saves you time on development. It shortens time to market. It aids continuous delivery. It gives you flexibility. (It’s even good for the environment so you’ll be making Sir David Attenborough happy.)
Best of all, it enables automatic scaling that works like a dream.
Serverless architecture actually does not mean architecture which does not use a server.
There is very much a server involved. The -less bit means that you yourself do not actually have a server. It is you who are serverless, not the app.
A little bit of history:
Servers were big machines which stored data, ran programs, and served "clients", aka computers and smartphones. E.g., you click on a button on a website, the browser, which is the client, contacts the server, the server tells it what to do next with what information when.
Back in the day, these machines lived in cold rooms in warehouses. They were expensive to buy and run, and time-consuming to set-up and run.
In the burger analogy, this was the computer equivalent of 1850s housewives having to tour several shops to buy the individual burger ingredients, make do with what’s available locally, then carry coal to the oven, heat it up, construct the burger, cook it in the oven, then choose which of her eighty children got to eat that day.
So, expensive, time-consuming, cold, and full of unpleasant compromises.
And then we invented the cloud. The cloud is nothing more than servers hosted on the internet. This means that the same one server can service lots of different systems all at once as people pool this resource and drink from the same pond thanks to the connectivity of the internet. But, the physical machine still exists, somewhere, on a server farm.
In burger world we called Cloud an All You Can Eat Buffet. No more did the proud housewife have to make her own burgers, she could outsource this to a restaurant kitchen which specialised in burgers and made hundreds a day, achieving economies of scale, and leaving Mrs Housewife free to do things like vote.
A non-burger example of the cloud is Dropbox as compared with your computer storage. Dropbox is hosted in the cloud, you can access it via the internet from any device anywhere. It is not tied to a particular computer.
Whereas if you save a doc directly to your computer, you can only access it via that specific computer. That's how non-cloud servers work too.
The thing with All You Can Eat Buffets is you pay a set fee regardless of what you actually use. Sometimes the company will make money because your grandma eats like a bird, sometimes they’ll lose money because your dad completes The Twenty Burger Challenge. You’ve outsourced your burger-making, you can choose to have one burger or a hundred, but it’s one-price-fits-all.
But what if you went to an All You Can Eat Buffet, except, you actually only paid for the amount of food you actually ate.
AKA, a restaurant. McDonalds.
Or imagine using Dropbox and paying only for the few seconds you use it for, not the yearly subscription.
That’s how serverless works for enterprise. It’s still the cloud, it’s still a restaurant making burgers for you, but you pay as you go. Oh and you can now order 10 million burgers in 10 seconds too. That's how good at scaling Serverless can be.
So in summary, if we named our burger-making services like we name serverless architecture, McDonald’s would be called a kitchenless restaurant. It has a kitchen, but you don’t. Therefore, you don’t need to manage the kitchen, you just use what comes out of it.
However, in order to achieve this PAYG facility, you’re not just outsourcing your servers, you’re actually also sort of outsourcing your backend developers and DevOps teams who manage and code on those servers. You’re outsourcing the chefs.
By extension this changes how you build products, manage them, and optimise them.
We may have the power to outsource kitchens and chefs and still get bespoke burgers while only paying for what we eat, which works wonderfully for cases such as IoT or mobile, but it does have several important drawbacks which mean that serverless is not for every product every time.
You probably mainly buy your burgers from McDonalds in two ways: randomly, or in bulk. You go to a fast food restaurant when you don’t expect it but need food quick. Or, you’ve got twenty kids at a birthday party to feed once a year. In those two cases, it does not make sense to cook from scratch your own burgers. In Use Case 1, you’ve not got time. In Use Case 2, you don’t have the tools or skills for bulk cooking.
Serverless works well in a similar way: when you need to serve low levels of traffic quickly, or when you need to serve a sporadic massive spike in traffic way beyond what you normally get. Serverless is fantastic in these two cases.
Serverless is not yet recommended for consistently high levels of traffic.
For example, if you regularly eat twenty burgers a day, then the All You Can Eat Buffet is best for you because it’s cheaper and easier.
Serverless needs a lot of integration testing for complicated reasons to do with granularity.
To a person using the self-serving machine in McDonald’s, all they need to see is "pick chicken nuggets". But your backend needs to translate that into “take chicken out of freezer, dump in flour, fry for twenty minutes”. The machine has to break down every order into very granular instructions to get the machines to actually make the nuggets, so there’s a big margin for error.
I hope this has helped you understand serverless as a concept, and whether to explore it for your project.
I’ve used burgers here to keep things simple. But if you want to read more, you’re going to need to learn the new words. Here’s a quick list of the serverless basics to get you started.
Interested in more practical insights into technical innovation, straight from the devs' mouths? Sign up to our monthly Issue down below.