In this article, I am not going to define what serverless is. I will not even expand on serverless's economic and architectural benefits 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 means. I didn’t know the difference between a service, tier, Apache, IIS, ASP, JSP, JS, CSS, or other acronyms for the longest time. 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 the 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,” you either had to understand the “web stuff” really well or be deep in Virtual Machines, Containers, and 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 a job where I was forced to learn all of that. THANKFULLY!
But what has any of that got to do with Serverless?
Lots.
Serverless makes the cloud accessible to all developers by taking away its aura
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, etc. 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 the 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 just to write their business logic. Before serverless, their transition might have meant learning a lot of technologies that were all logistical in nature, mostly just doing the undifferentiated heavy lifting. With serverless, their programming skills are all they need. What programmer doesn’t like the prospect of focusing on programming only?
Serverless provides a canvas for easy experimentation
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.
Serverless focuses on developer productivity, not on sophistication
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. I 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 competing technologies, even in the cloud, 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 developer productivity by delivering an experience focused on a developer’s currency — not virtual machines, containers, orchestrators, or instances, but CODE. The problem of productively handling code (even the code meant for the 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, etc. 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 to be sufficiently motivated to fix these issues soon.
In summary, serverless presents a great tool that all developers need to have in their toolbox.