Well obviously: Frugality, security, and elasticity. But I want more, I want better software.
[This is part of the Serverlessness series.]
Frugality · The core idea is that when your workload goes to zero, so does your bill. You might save big; Financial Engines is the first case study that Google popped up for me, but I’ve heard muttered stories in the hallways about way bigger savings than that. And then there’s my co-worker who took his school-photographer wife’s Website billings from $10/month down to a few cents.
And we’re not just talking about Lambda. When there are no messages flowing through your SQS queue, you’re not paying anything. When your Step Functions workflow is waiting, it’s just a row in a database. And so on and so on.
Disclosure: I lobbied to get that soundbite into that keynote.
Security · When you can’t see the servers, that means we’re taking care of them. And since servers fail, our services have to be designed to survive restarts. Which means that we can (and do) bounce them whenever they need patching. So whatever hosts your DynamoDB table or your SNS topic is running on, they’re likely freshly-enough patched to cut the number of known vulnerabilities to just about the minimum possible. [Urgh, upon typing this, it occurred to me to check the uptime on the Linux box hosting this blog, and it’s like a year. The box generating the bits you are now reading is probably a soft target for all the bad guys out there. Ahem.]
Anyhow, there’s no perfect security in this bad old world, but freshly-patched instances really do help a lot.
Elasticity · When we deliver serverless services, what we’re really trying to do is get you out of the business of capacity forecasting. That business sucks. It’s hard, and easy to get wrong; the penalty for estimating low is lousy performance for your customers, and estimating high is throwing away money. So go serverless and let us take care of that for you.
(By the way, I’m not claiming that we’re any smarter about capacity management than you are. When you aggregate all the AWS customers’ traffic, the lumpy local variations even out. So it’s a much easier problem if you’re a public-cloud provider. Of course you have to not mind billions in capex.)
What about software quality? · As I’ve blogged before, that “Frugality, Security, Elasticity” pitch operates at a more or less pure business level. But I’m a technologist and engineer, so I have to ask, are serverless application designs better designs? I think the only honest answer is “We don’t know yet.”
Having said that, my gut is saying “yes”. It helps that I’m an old functional-programming bigot, and the notion of stateless functions in the cloud responding to events gives me a warm glow. There are things we do know: microservices that are connected asynchronously with messaging systems (e.g. SQS, 100% serverless) are more robust and flexible than those that aren’t. But… Can I say we have a basis of experience sufficiently strong to say “Serverless software is better”? Nope.
But I’m pretty sure that going serverless isn’t going to give you a worse design. So you should bloody well go ahead and do it, because: Frugality, Security, and Elasticity.
But wait… · Look at that picture above from Werner Vogels’ keynote at the 2017 re:Invent.
Then consider the fact that you have a finite time budget for software design. If you go serverless, then you you don’t have to design Kubernetes flows or Auto Scaling policies or fleet-health metrics or any of that other stuff. All your design time can be dedicated to, like Werner’s slide says, software that directly addresses business issues. So, given more design time, you’re probably gonna get a better design with serverless.
My feeling is, the why of serverless is pretty obvious. It’s the how that’s interesting.
Comment feed for ongoing:
From: Bram (Dec 16 2018, at 08:31)
Isn’t AWS already metered?
So if your instance is idle, you pay less than what you would pay for one that burns 100% cpu?
[link]