The promise of running a business on the cloud is that — in theory, at least — you should be able to scale your infrastructure up and down with your customer utilization. This should lead, again in theory, to less maintenance and more opportunity for innovation.
With the growing maturity of on-demand services, like AWS Lambda, which recently announced they’ll now be billing down to the millisecond of utilization, this has never been more possible, as long as you’re thoughtfully architecting your applications to take advantage of serverless.
At CloudZero, we’ve architected our platform almost entirely on serverless infrastructure. This is still fairly unusual, so naturally, whenever I tell other engineering leaders this, they have a lot of questions.
From our perspective, serverless offers two main advantages. The first is reducing the operational overhead in the engineering organization, so that our engineers are focused on core software and not managing things like security patches and upgrades.
The second is the ability to seamlessly scale up and down with customer usage, which in turn allows us to limit the impact of product bets on our COGS. The elasticity of serverless building blocks allows SaaS companies to reduce waste more than any other architecture.
In this blog post, I’ll do a deep dive into how those two factors change our engineering workflow — and give us a competitive advantage because we’re able to rapidly ingest and analyze enormous amount of data from our customers in an economically feasible way.
How Serverless Reduces Overhead
Let’s face it: Our team is never going to be as good at managing virtual machines as Amazon, Google, or Microsoft — nor would I want them to be, since it’s not exactly a strategic activity that delivers value to our customers.
I don’t want my engineers thinking about if they are using the latest, patched version of Ubuntu Linux image. I want them to think about what the best software components are to build a feature that will delight our customers.
If my team were working on managing security patching and upgrades, I would have far fewer engineering staff hours to work on our core product. I’ve yet to see a business that isn’t under pressure to deliver new features sooner. Engineers’ time is the main bottleneck in getting those new features out the door.
Every engineering hour I can move from undifferentiated infrastructure management to feature development is a win, and serverless is the best way to do that. I’d estimate I save around 10% of our engineering payroll just by outsourcing all the undifferentiated tasks to the cloud provider by using serverless.
How Serverless Makes Us More Elastic
No system is completely elastic, including serverless. Nonetheless, serverless is more elastic than other application architectures. It’s also the best way to build an application that can scale both up and down.
However, it’s important to remember that you can’t just lift and shift an application into AWS Lambda and expect it to suddenly run more efficiently — a topic which I’ve written about here. Applications need to be architected for serverless, so there may be some refactoring involved if you’re working to migrate existing software.
One of the ways to optimize your COGS is to ensure you’re not paying for infrastructure when you’re not using it. Most software products have variable loads. For example, B2B products tend to get most traffic from Monday through Friday, while gaming platforms tend to have more traffic on the weekends.
While the ability to scale up to meet demand is critical to providing a good customer experience even under high traffic, the ability to scale back down helps you reduce waste.
In a serverless architecture, you’re only billed when something is running. When architected correctly, there is no “idle” compute cost at all. Realizing this benefit does require a more event-driven architecture, because resources will need to be spun up and down as they are asked to do a job and then complete their function.
Containers can also have event-driven architectures, but doing so still requires an additional infrastructure layer that has to be managed. With serverless, that whole infrastructure layer is the cloud provider’s responsibility.
One of the great things about serverless’s elasticity is it reduces the financial risk of launching new features. When a new feature is launched, it might not be adopted right away, or at least not broadly adopted.
With serverless, we aren’t paying to run the new feature unless customers are actually using it. At CloudZero, we can ship a new feature but we don’t start paying to run it until someone uses it. That lets us experiment with features without worrying that they will take a huge bite out of our margin if they don’t catch on quickly.
How Serverless Helps Us Understand COGS
Using serverless also helps us better understand how our customers are using our product and how much it costs to run each part of our product.
Since we pay for serverless functions by the second, we can get really granular information about what it costs to run individual services, features and applications. That lets us make better decisions about which tech debt to address first, which features to include in each pricing tier and how to improve both customer satisfaction and profitability.
Isn’t Serverless Too Hard?
Sure, serverless is different and requires some new skills. If you try to use the exact same approach to application architecture that you used in a legacy monolith or with containers, you won’t be successful.
But the engineers on my team are smart and chances are the engineers on your team are smart too. They are willing and able to learn the skills needed to be successful with serverless. That said, if you expect them to turn out their first serverless application in record time, without any kind of training or time to learn and experiment in a sandbox, the serverless project will seem like a failure.
Serverless isn’t that different from other application architectures, though, so as long as you have competent engineers on the team they’ll be able to be successful with serverless.
Connecting Technical Decisions With Business Outcomes
Our goal at CloudZero is to help companies connect their technical decisions to their business outcomes and understand the COGS of their software products.
Doing so requires collecting and analyzing an incredible amount of data. One of our key differentiators is the sheer amount of data we’re able to ingest, process, and correlate – which obviously isn’t cheap. Serverless makes it possible to provide the rich analytic capabilities in our platform at a price that makes sense for our customers.
to learn more about the CloudZero Cloud Cost Intelligence Platform — and how we can deliver cloud cost intelligence to your engineering teams.
The Cloud Cost Playbook
The step-by-step guide to cost maturity
