I’m going to go off on a bit of a tangent here. I spend most of my day talking to people about serverless security, how it’s different, what to worry about and what to feel good about. But I find it’s often difficult to communicate around the challenges of serverless, and I’ve come to the conclusion that a big part of the problem is that people use the word serverless in different ways.
So I spent some time trying to wrap my head around everyone’s shifting definitions of serverless, and I had an epiphany. Or at least a moment of clarity. “Serverless,” like many hyped-up buzzwords, means different things to different people. Part of the confusion is that it’s more than one thing. Yes, serverless is a revolution, but it’s actually three different revolutions with three different core values:
As serverless is a big part of the shift to true cloud-native applications, I think it’s important that we recognize these different parts of the revolution. Once you have embraced the more nuanced meaning of each piece, discussions about security, operations, and monitoring in the cloud native world start to make much more sense.
Serverless Infrastructure is the revolution in the way we consume and pay for cloud resources.What are you renting from your cloud provider? This is about “scales to zero,” “don’t pay for idle,” “true auto-scaling,” etc. The serverless infrastructure revolution proposes to stop leasing machines, and start paying for the actual consumption of resources.
For example, AWS defines S3 as serverless. This is because it is a resource that the AWS infrastructure provides, where consumers don’t need to think about how many readers and writers might come along in the future, and how much data might end up being stored there. Consumers simply create an S3 bucket, and AWS scales resources as needed. And, of course, customers are billed only for what they actually consumed. (If only DynamoDB, the AWS serverless NoSQL database, was actually that “serverless.”)
Serverless architecture is the revolution in how software is architected to enable horizontal scaling. Most serverless platforms require code to be stateless and ephemeral. To accommodate this, serverless architectures have a few key design principles:
Put another way, serverless architecture applications have a large number of stateless functions, connected to a small number of serverless databases, queues, and storage.
Serverless operations is the revolution in how cloud native applications are orchestrated, deployed, and monitored.
On the deployment side, typically each microservice function is owned and operated by a single dev or DevOps team, and has its own private life-cycle. This supports the high-velocity deployment of features and fixes, as there is no need to wrap up, test, deploy, and scale a container or VM. Developers write some code, run some simple command to deploy that to a CI/CD environment for testing, and once the testing process completes successfully, the code can be rolled into production immediately. In many organizations I’ve spoken to, this is fully automated. If it passes staging, it goes right into production.
On the operations side, there is less to operate. Since you don’t have to think too much about scaling, and there is no notion of “is my server up?,” you’re mostly limited to keeping track of error rates on your resources, and making sure nothing strange pops up. This is mostly a blessing, and some people I’ve spoken with claim that the real savings in the move to serverless didn’t come as much from the “pay only for what you use” as they did from the ability to shrink the operations part of the team significantly, freeing up resources for more valuable endeavors.
Wait, let me climb down from my soapbox. Just kidding, I’m still on it. My point is that each of these revolutions in how to build, deploy and operate cloud native software keys in of different values and benefits. That’s why some people talk about “going serverless” in their on-prem data centers. That’s serverless architecture and operations without the serverless infrastructure. And that’s a legitimate technological shift, if that’s what makes sense for your business.
Or why others can talk about the fact that they’ve been serverless since the invention of movable type, since they run applications of Google App Engine. Maybe not so much a serverless architecture, but pretty close to serverless infrastructure and operations.
Here’s the thing: identify what the key values your organization is trying to get at, and make sure the technology changes you’re embracing will give you that. If you’ve moved over to Azure Functions, but you haven’t really rearchitected your software, that’s ok, if you came here for the cost savings. But if you came for the application velocity, you might not get what you’re hoping for.
Here are a few links that will help you get up to speed on serverless security. Our webinar, which you can watch on demand, “Serverless Security Step by Step,” will help focus on what serverless security is, and how you can do something about it today. Download our eBook, “Serverless Security Primer: Top Risks and How to Mitigate.” if you’re ready to read a little more.