Brace yourselves. Serverless is coming.

 
Technology moves quickly. Or maybe it just seems like it moves quickly because new movements, approaches, and architectures are popping up left and right. This month it’s the sudden rise of “serverless” architectures to the fore of everyone’s Twitter stream and consciousness. At least if you’re in the Dev/Ops world.

For those of you who concern yourselves with infrastructure and network architecture and operations and haven’t been inundated with this new architecture, it’s a logical progression preceding from monolith –> microservices –> serverless architectures. It’s a further breakdown of apps from business use –> service –> function.

Literally, it’s about functions. Event-driven, fine-grained, functions.

And every one has a focus on an even smaller scope of application logic than a microservice. Where a microservice might contain all the application logic required to implement a “profile service”, serverless architecture further breaks that down into individual functions. One for login, one for logout, one for changing your password, one for resetting it. Basically, it’s like building a tiny, focused service for every action you might take within an app.

The reason this is called “serverless” is because it’s basically a highly evolved form of PaaS. Which is nice for PaaS, because as a market, PaaS has never really become the behemoth it hoped to be. It’s kind of just hangs out there, getting shout outs from fanbois who love it, but for the most part it’s been ignored, growing at a rate that is nowhere near as exciting as private or public cloud, and certainly not like SaaS. In a serverless architecture, the cloud provider is responsible for everything but the code required to do something when a user hits a button or a checkbox or clicks a link. That’s the event part of “event-driven”: when user hits button do function_in_the_cloud. That function is generally a part of a larger API that is managed by yet another service in the cloud.

The important thing here is that the person writing the function does not provision, configure, or launch a VM or container. They do not worry about operational details like scale. They simply write some code and with the click of a button, voila! Instant functionality.

This is cloud taken to its ultimate extreme, as the stack developers are now responsible for shrinks down to a single layer, the application layer. Nothing else matters, as Metallica would say. Every operational detail is provided for by the underlying platform. It is NoOps, or at least from the perspective of the developer.

Because you know there are servers, and services, and infrastructure, and a network under the platform providing this magical capability. It’s just not something the developer needs to worry about. But you, as an infrastructure or network operations professional, do.

Which is why enterprises are unlikely to be jumping on this bandwagon for a while. Such a feat requires a fully operational cloud computing environment that incorporates not just virtual machine or container provisioning capabilities, but auto auto-scale. In other words, scale without parameters or input from developers. It should just happen, dag nabbit, and that’s all there is to it. It’s not self-service, it’s auto-service. It’s not only scale, it’s auto-provisioning, too. And monitoring, and reporting, and just about everything related to operations today. This is why we’re seeing it largely in well-established cloud provider environments; only they have the underlying infrastructure, automation, and orchestration required to support such a largely hands-off operational model.

So most of the attention on serverless right now is on feeling it out and figuring out how to work with current incarnations available in the cloud: Amazon Lambda, Google Cloud Functions, Microsoft Azure Functions, and IBM OpenWhisk. Not that there aren’t offerings to help on-premise implementations such as Serverless and Iron.io. But right now it’s early (early) days for serverless.

Still, you’re probably going to start hearing rumblings about serverless. For the nonce it’s largely just the engines of a new architecture starting up. It’s unlikely to impact most organizations in the near-term (for the next 12-15 months) but it’s good to understand what it’s all about before it pulls into the on-premise pit stop. 

The NewStack has a great overview if you want to read more about serverless and current benefits and challenges.