“Serverless computing,” at the time of this writing, is an emerging ideal that’s past the embryonic stage, yet not quite fully formed. It has a variety of advocates, some of whom make more sense than others.
But what does the term “serverless” mean, exactly? We speak with two such advocates who put forth the most sensible cases thus far: Michael Hausenblas, a developer and developer advocate at Mesosphere, and author of a recent New Stack article entitled, “Making Sense of Serverless Computing”; and Chad Arimura, the CEO of Iron.io and a previous guest of our podcasts.
Our conversations with Hausenblas and Arimura were separate, but they made much the same case: specifically, for eliminating the appearance of dependencies between software currently under development, and its underlying resources and infrastructure. If you remember the era where you turned on your personal computer, saw a “READY” prompt, and everything you’d ever need to reference was on a memory map — it’s like the modern evolution of that.
When we started the whole cloud-native development paradigm, it was with the idea that the cloud could mask the details of deployment and implementation from the developer. Then when we started the whole container orchestration business, it was with this notion that the developer was the person doing the deployment and implementation. Arimura and Hausenblas suggest that, if the details of software implementation can be condensed to a more basic form, a developer could conceivably produce a draft that meets a basic requirement of a service-level agreement. This way, an automated deployment pipeline could test its container, fail it or pass it, and in the latter case, re-attach the necessary details and deploy it to production.
Imagine an operator petitioning a developer for an app that performed a function whose performance rated, say, a 7 on a 10-point scale. The developer wouldn’t need to know why, just that the performance level sits about mid-way between average and maximum. It’s not so much “serverless,” therefore, as “less server-ish.” Maybe we should attach an asterisk to “serverless,” followed by a footnote: “May contain some traces of server.”
The bigger question, though, is whether this is really “DevOps.” That is to say, does server-less-ness suggest that developers and operations professionals collaborate, or just participate in the same pipeline?