What is Serverless?

Its just a buzzword people say to feel clever right? Well yes and no. Its definitely a word that has caused some heated discussions. Primarily by those who realise that, of course, there are servers back there somewhere doing the things and they get upset because “Serverless” seems like a silly, unnecessary phrase.

Problem is that “Serverless” is a contextual description aimed at developers; guys and gals who write code. Not the dev ops elite who could spin up some Nginx clusters, load balanced and auto scaled. No, not them. Serverless talks directly to that person over there, sunk eye balls deep in JavaScript/Java/Go/PHP/Ruby that when they come up for air and realise they need to make this stuff run somewhere they shrug their shoulders, throw it over the wall at that dev ops elitist, or worse, hack together a web server themselves in an effort just to get their work into that magical state known as “in production”.

Serverless architectures are what we used to call Platform as a Service (PaaS). That part I mentioned about the code happy dev just chucking stuff over a wall at a dev ops guy? Well Serverless solutions essentially try to be what catches the code on the other side of that wall and make it “in production”, and this kind of thing has actually been happening for a while.

All that serverless means is that, as a dev, I throw code at some service, maybe there’s a configuration file in there that helps that service figure out what I am trying to do, and the service will automatically provision my code and give me a URL endpoint for it. No need for the developer to know how to SSH onto a server or how to install and setup web servers, firewalls, caches, databases, etc. The service would intrinsically understand how to do that for you.

Whilst there were one or two early starters the first real Serverless success, back before “Serverless” was even a thing, was Google App Engine; a platform that literally let you upload a zip file of code and it auto deployed and scaled your infrastructure for you. Amazon soon followed with its similarly powerful, yet less well known, Elastic Beanstalk product. But then along came Heroku to be the hipster darling of the scene and PaaS (as Serverless was known at the time) become popular.

The idea of Serverless truly came to the for when, in 2014, Amazon debuted AWS Lambda, a Serverless Functions as a Service (FaaS, just to confuse us) product that was essentially PaaS but for microservices. Fast forwarding in time a little we now also have Azure Functions on Microsoft’s Azure Cloud, and Google Cloud Functions which, at the writing of the post, was still very much in a pre-production beta phase. Not to mention Open Whisk, Iron Functions and innumerable other Serverless ways to spin up your own servers to run your microservices, and the plethora of Serverless frameworks for every language and none of them at the same time crawling out of the woodwork.

Currently, if you sit back and take a look at the landscape … what do you see? Well there is Google App Engine and Amazon Elastic Beanstalk and the like to provide me serverless capabilities for my monolith. And there is AWS Lambda, Azure Functions, Google Cloud Functions and innumerable others to provide serverless capabilities to my microservices.

When should I use Serverless, though?

People seem stumped by this question. Its actually a very easy answer. If infrastructure is what is going to give your app the edge, then Serverless is not for you. What does that mean? Well, consider an obvious example like Netflix. They serve a lot of data .. a lot. So for them, relying on the very generic settings of some Serverless product to serve their earth shattering quantities of content at reasonable speeds with awesome reliability is not an option. The success of their business relies very heavily on how well tuned their infrastructure is.

Take, on the other hand, my employer, Expat Explore. We are a tour company. Our infrastructure needs are vastly different and we, in fact, don’t really care what the efficiencies of the underlying systems are like. We need a cost-effective, reasonably performant (HTTP request performant, not video streaming performant) and reliable system. We are not a tech company per se, but we rely on technology for our business to succeed. We may build some exciting things, but we don’t produce technology as the goal, but rather to serve our business needs. We are the perfect candidates for Serverless computing, and so are many, many other companies.

To finish this off with a final thought; Serverless may be mocked as a nonsensical buzzword, but it does have some value as a way to describe an innovation designed to make developers lives easier by appealing to the one part that a lot of devs dread; working with servers.

Like what you read? Give Gareth McCumskey a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.