Today’s posting steps out of my core skills a bit. I’ve always been an infrastructure guy. I build systems. I help my customers with storage, infrastructure, networking, and all sorts of solutions to solve problems in the data center, cloud, etc. I love this “Puzzle” world. However, there’s an entire category of IT that I’ve assisted for decades, but never really have I been a part of. Developers, as far as I’m concerned are magicians. How do they start with an idea and simply by using “Code” that they generate, in a framework, language, etc.? I simply don’t know. What I do know, though, is that the applications that they’re building are undergoing systemic change too. The difference between where we’ve been, and where we’re going is due to the need for speed, responsiveness, and agility in the modifications of the code.

In the traditional world of monolithic apps, these wizards needed to put features into applications by adjunct applications, or learn the code on which some “Off the Shelf” software was written in order to make any changes. Moving forward, the Microservices model, that is: code fragments each purpose built to either add functionality, or streamline existing function.

Companies like Amazon’s Lambda and Iron.IO, Microsoft Azure, (and soon to be Google) have upped the ante. While I feel that the term “Serverless” is an inaccuracy, as workloads will always need somewhere to run. There must be some form of compute element, but by abstracting that even further from the hardware (albeit virtual hoardware), we are relying less on where or what these workloads depend on. Particularly when you’re a developer, worrying about infrastructure is something you simply do not want to do.

Let’s start with a conceptual definition:  According to Wikipedia, “Also known as Function as a Service (FaaS) is a cloud computing code execution model in which the cloud provider fully manages starting and stopping virtual machines as necessary to serve requests, and requests are billed by an abstract measure of the resources required to satisfy the request, rather than per virtual machines, per hour.” Really, this is not as “Jargon-y” as it sounds. You, the developer, are relying on an amount of processor/memory/storage, but you don’t have any reliance on persistence, or particular location. I feel it’s designed to be a temporary sandbox for your code.

In many ways, it’s an approach alternate to traditional IT infrastructure modes of requesting virtual machine(s) from your team, waiting for them, and then if you’ve made some code errors, once again waiting for those machines to be re-imaged. Instead, you load up a temporary amount of horsepower, load it with a copy of your code, then destroy it.

In the DevOps world, the beauty of this kind of ephemeral environment is very beneficial. Functionally, the building of code in a DevOps world means that your application is made up of many small pieces of code, rather than a single monolithic application. We have adopted the term “MicroServices” to apply to these fragments of code. Agility and flexibility in these small pieces of code is critical. In fact, the whole concept of DevOps is all about agility. In DevOps, as opposed to traditional code development, rollouts of code changes, updates, patching, etc. can take place with a level of immediacy, whereas full application type rollouts require massive planning. In this case, a rollout could potentially take place instantaneously, as these pieces tend to be essentially tiny. Potentially, code updates can take place and/or be rolled back in minutes.

While it is completely certain that DevOps, and the agility that it portends will change the dynamic in Information technology, particularly in companies that rely on home-grown code, what is truly uncertain is whether the concepts of serverless computing will ever grow beyond the Test/Dev world and enter into production environments. I find it difficult, and maybe due to my own lack of coding skills, to envision deploying workloads in a somewhat piecemeal approach. While putting pieces together inside a single workload feels to me far more approachable.