I never used to care about the cost of the systems I built. As an engineer, why would I?
Especially in the days before the cloud, infrastructure resources were purchased and procured by somebody who worked many levels above me. Even when I first started building on the cloud, I had to submit requests (again, to somebody many levels above me) for my resources.
However, somewhere along the way, companies realized they could get products out the door much more quickly when developers can access what they need on the spot, without all the red tape. As a result, today, I have the keys to the kingdom when it comes to making purchasing decisions. I can spin up a fleet of instances, a NoSQL database capable of millions of transactions per second, or even a flock of lambdas with instant scaling, as I please.
So, why, you might be wondering, do I now suddenly care about cost? Well, I will admit that I do work for a company whose main mission is to provide engineering teams with feedback about AWS costs, so… you could say it’s kind of our thing.
More importantly, I work for a growing SaaS software company—and like any company, maintaining strong margins is important. Especially in the early days at CloudZero, we had conversations during our design process about how we could build a product that was affordable enough to run even as we added more customers.
This kind of thinking continues to pervade our engineering culture and today, we think of cost as a key non-functional requirement of anything we’re building.
Making Cost A Non-Functional Requirement
So, how do you make cost a non-functional requirement? On our team, we start with a cost constraint, and then force ourselves to decide how we can build the feature with those resources.
If you think about it, it’s no different than back in the day, when we used to have to figure out how to build software using the resources that had been allocated to us for the year. We used non-functional requirements like performance, memory usage, cpu usage, etc. Today, engineering teams have unlimited resources on cloud providers like AWS, which is great for shipping products—and potentially harmful to your margins.
I’ve found that working with my team to set daily cost constraints (i.e., this feature should cost $X per transaction, customer, or day to run) has actually forced me to be more creative in the way I architect my applications and systems. I’d suggest any team give it a try!
Even if you don’t ultimately stick to the constraint, I promise it will at least force you to think through different ways to solve a problem. Ultimately, the process isn’t about finding the cheapest way to build a product; it’s about making conscious tradeoffs about cost— and making sure you’re not choosing the most expensive way just because it’s the first thing you came up with.
Cost Constraints In Action
Interested in seeing this process in action? I also wrote a follow up post about a project I did to productize a Machine Learning pipeline. Read that here.
The Cloud Cost Playbook
The step-by-step guide to cost maturity
