People have been arguing about the meaning of serverless since the term came into vogue nearly a decade ago, and it seems to be quite active recently as well. Today, “serverless” as a term is close to meaningless. I won’t name names here, but we’ve all seen services get called “serverless” when they don’t scale to zero, when they are charged by hourly rates, when they still have maintenance windows. As a hardline proponent of serverless, I’d like to say: It’s fine. Don’t get worked up about it.
Every term that refers to something useful will become meaningless. Precisely because the original thing is useful, the term becomes valuable for marketing. This means that stretching the term to include things not quite under the original definition allows them to benefit from the perceived value of the original thing. And that establishes a precedent, allowing things even a little further away to get the label, and the scope creeps ever outward.
This has happened with terms like “cloud”, “DevOps”, “agile”…all of them referred to at least a reasonably well-scoped concept originally, and now are regularly applied to products and practices unrecognizable under the original definitions. You can stand like King Canute trying to stop the tide*, demanding people use a narrow definition, but you’re never going to succeed — and that’s okay!
So what’s important to focus on is the functional characteristics, what you’re trying to accomplish and how those characteristics aid in accomplishing the goals. I’ve been saying this for a long time. When it comes to actual technologies, I said serverless is a spectrum. I said that it’s not even about the technologies, it’s about the mindset. The serverless mindset is still the most important thing: it’s about how you choose technologies when solving a business problem under your particular constraints, not about the specific technologies you choose. The technologies serverless purists call “serverless” are the technologies you end up choosing when you have the fewest constraints.
While we can’t stop the march towards meaninglessness for “serverless”, we can insist on the value of serverless concepts. When AWS calls something “serverless” that doesn’t scale to zero, we can continue to push them for that feature, and make sure people understand the tradeoff of using particular services.
Another way to retain meaning is to fully lean on the spectral nature. Instead of arguing about the line for where “serverless” ends, insist on talking comparatively. What services are more serverless than others? This not only reduces the problems of supposedly mislabeled services, but also provides people with a guide for what to choose when their constraints prevent them from using things at the far end of the spectrum.
In general, labels often aren’t the important thing. First, almost nothing in our industry (not to mention life in general) fits under strict binary labeling. There are few bright-line boundaries. Everything is a continuum. Embracing that means understanding terms based on their usefulness to the discussion you’re having, understanding that the utility of terms changes over time and that while you can shape those changes you can’t fully control them. “Serverless” may be close to meaningless, but the underlying concepts are more important than ever.
* Not coincidentally, the original story, which was about humility, has been generally coopted to be a metaphor for futility, because there’s lots of situations where it’s useful to employ such a metaphor.
