I’ve heard many conversations about the limitations of “serverless technology” ever since the concept was widely known. They often focus on how specific implementations of serverless are limited by certain aspects that the user doesn’t have control of. This seems odd to me because serverless isn’t a technology.

Furthermore and with even greater frequency, I’ve heard that serverless as a product is dangerous because of the problems with that vendor. For example, the fact that AWS Lambdas are a ‘lock in’ to AWS-as-a-service, or that AWS is inherently bad (possibly because of a 2-minute outage in a single region three months ago). These arguments have their (limited) merit but they’re not really arguments for or against serverless. Because serverless isn’t a product.

Okay hold on a minute, I hear my reader say, “if serverless isn’t a technology, and it’s not a product, and I know it’s not a standard, _or _a codebase, is serverless anything? Why am I even here?” In this theoretical situation, I’m imagining, you are still reading for reasons possibly related to procrastinating on your real work and it’s my pleasure to offer you a platform for educated procrastination

Serverless is a goal; it is a vision for how large vendors should deliver hosting and computer power to you their customers. It’s also a vision for how you should be able to build services without your primary focus being occupied by understanding hosting technology. Instead, you get to focus on the real challenges of your business.

Ben Kehoe spoke eloquently on how serverless is a change in business mindset rather than a single practice. Serverless is about focusing your engineers’ time and attention on business problems rather than cool operations technologies.

Serverless is no more a single thing, no more a single tool or product, than is DevOps. DevOps, as you’ll recall, is an ideal state of collaboration between developers and operations. It is decidedly not something that comes in a box.

The last box of DevOps is in a pentagon warehouse

These goals are not things you can buy, no more than you can buy a product to make your team Agile. These goals aren’t boxes you can tick, either. You can approach better Dev and Ops integration, you can approach less and less responsibility within your team for server management, but you can’t just say ‘okay we’ve achieved a serverless model and never have to worry about that again.’

If serverless is a goal, how do we get there?

Serverless is about expanding what your service provider is responsible for. You are only responsible for constructing your function code in a way that is consistent, reliable, and secure. The OS layer of the server can be assumed to be configured correctly every time, and problems of horizontal scale should be a simple configuration for the Ops team.

Serverless is about reducing the “arbitrary heavy lifting” of creating server management tools, container orchestration tools, and managing the connections between components like DB’s, API’s, and business logic.

So wait, what about tools like “self-hosted serverless” and Function-as-a-Service?

Let’s start with the most obvious: self-hosted “serverless functions” might have their uses, but they’re not really serverless at all. Serverless isn’t about “write functions and then make hosting them the Ops team’s problem” and so these tools aren’t really approaching that goal.

What about ‘Functions-as-a-Service’ providers, which offer serverless function hosting with you tasked with figuring out how to make your database, API, and everything else talk to those functions? Again, way too much is still “your problem” so these are more accurately described as Function-as-a-Service than any kind of serverless.

Okay, what does this mean for my workflow?

This means you should become sensitive whenever you find yourself becoming a “tools expert” rather than a developer. Be wary when you are spending days or weeks on:

• Correctly formatting configuration YAML
• Wrangling permissions between your functions and their backing services (DB’s, containers, queues, messaging, etc)

On the other hand, some problems remain your problem with serverless because no vendor or service provider can handle them as well as you can:

• Writing secure code
• Observability
• Consistent performance
• Correctly configured auto-scaling

Whenever you face these problems, take the time to study up! Even with our serverless future, they’ll be “your problem” for years to come.

Allow me to reiterate, ad infinitum

It can be a bit tiresome to encounter the description of serverless as a “technology” so often when it isn’t for the reasons above. But it does reveal a lot about how the world is starting to view serverless. Serverless is important, and I believe many people are calling it a technology to indicates its significance for developers. Calling serverless a “technology” or a “product” speaks to a collective appetite for a real-life use-case, whether the label is coming from naysayers or not.

Reprioritizing your business goals across an entire org, including the software team? With regard to a more streamlined development process? That’s a game-changer (but it’s not a technology).