In this article, I am not going to define what serverless is. I am not even going to expand on the economic and architectural benefits of serverless that we have all heard about — reduced infrastructure ops, event-driven instant scale and low costs.
Instead I want to make a case for why serverless is the thing that all developers should care about, whether or not their bosses care for it, YET.
Starting with a personal story of course…
I have never done any “web development”. The double-quotes here are not meant to poke fun at the concept but to signify my ignorance about what it actually means. For the longest time I didn’t know the difference between a service, tier, Apache, IIS, ASP, JSP, JS, CSS or any of those other acronyms. As a software developer, I had either written C++ code building desktop applications for Windows or C code building server management applications for Linux. I always thought that is what the cool kids ought to do and all the “web stuff” was for lesser programmers.
The more I stayed away from web, the more enigmatic it became for me. Things like REST, JSON, WebAPI etc. popped up in every second internet article. People building mobile apps were talking of building “web services backends” for their apps, which confused me. It didn’t help that the next hottest thing in town — “the cloud” — borrowed almost all its characteristics from the “web stuff”. If you wanted to build applications in “the cloud”, either you had to understand the “web stuff” really well or you had to be deep on Virtual Machines, Containers and those other virtualization related technologies. I had avoided both of them long enough that they had acquired a certain aura in my mind. Till I landed in a job where I was forced to learn all of that. THANKFULLY!
But what has any of that got to do with Serverless?
I am sure despite the massive popularity of “web development”, there is an army of developers worldwide who build software for desktops, servers, embedded devices, mobile devices and never deal much with the “web” aspects (much like me). Many of them no doubt are anxious about “the cloud” and what it means for them — whether it is about having employable skills for future or figuring out how to connect/transition their existing applications to the cloud (having seen the corporate memos to that effect already).
These developers can take heart from the fact that all they need to do, to have applications running in “the cloud”, is to just write their business logic. Before serverless, their transition might have meant learning a lot of technologies which were all logistical in nature, mostly just doing undifferentiated heavy lifting. With serverless, their programming skills are all they need. What programmer doesn’t like the prospect of focusing on programming only?
In the desktop world, building small console applications or command-line utilities, to test out a theory or an idea, is an everyday thing. In “the cloud” however, sometimes the accompanying procedure around trying to prototype a very basic idea, is full of several friction points — configurations, setups, SDKs, integrations and so on. Serverless reduces that pain significantly for developers, by handling much of that procedure behind the scenes. Easy prototyping, quick experimentation, learning from mistakes and pivoting based on lessons, are key tenets of modern software development. A much under-appreciated quality of serverless is its ability to provide just that.
Early in my career, the cool-kid syndrome I mentioned previously (the one that kept me away from “web stuff”) also kept me away from Visual Studio for too long. I persisted with vim and gdb on Linux, even when all the code I worked on, was cross-platform C/C++ code which could be easily handled in Visual Studio on Windows. All of this, just because it was cool to diss anything not command-line. Don’t want to start a debate on this topic but suffice to say that at least I felt that I lost countless hours of productivity doing this.
The bigger point I am trying to make here is that there are competing technologies even in the cloud, that allow you to do similar things. There are multiple scenarios in which VMs, containers, or serverless will provide similar outputs. However serverless will probably be the only one that optimizes for developer productivity by providing an experience focused on developer’s currency — which is not virtual machines, containers, orchestrators, or instances, but CODE. The problem of productively handling code (even the code meant for cloud) has been solved by world class IDEs like Visual Studio.
Is serverless a panacea? No. Does it have issues? Sure. We have all heard of cold-start, lack of state, limits on duration, memory and so on. Are these deal-breakers? In most cases, No. The productivity benefits outweigh these issues already. Are these problems insurmountable? Not at all. The cloud vendors have seen enough merit and promise in this technology that they are sufficiently motivated to fix these issues soon.
In summary, serverless presents a great tool that all developers need to have in their toolbox.