$100,000 - for FREE. That’s what you get when you sign up for the AWS startup program. Microsoft will see and raise at $150,000 and GCP will go all-in at $350,000. That’s at par with the seed round funding of quite a few startups.
It is not a joke! These cloud platforms really want you to succeed. They want you to scale, and be a cheerleader in that journey. Until, they can penalize you for your success.
As your start-up begins to grow, the cost of being on cloud, which felt like a never-ending grant once, quickly becomes the reason why your Head of Finance doesn’t want to hang-out with you anymore.
It pinches you too, but you haven’t laid the foundations of managing cloud costs, and now you want to look at it at a later date.
That date is now.
For analytics and data processing apps, your cloud spend typically accounts for about 15% of the revenue. For your regular Saas apps, the spend should be below 7%. So you should read this article if your cloud spend is above these benchmarks.
We are going to talk about some of the overlooked (and yet super-effective) opinions and frameworks to keep the cloud costs in check. Ready to take off? (pardon the pun).
1. Agreeing to a Single Metric, a North Star
The cloud cost affects all the teams - Tech, Finance, and Sales. It's vital to have a common key measure, or a "North Star" metric, that everyone in the company understands and uses to make decisions. The North Star metric should reflect what's most important to your business and could be something like the cost for each user, each user action, or each page view. For simplicity, we'll talk about the 'cost of a single transaction'.
Let me share an example from my own experience, a CRM (Customer Relationship Management) SaaS company. In this case, 'retail transactions' were used as the key metric. However, instead of just calculating the cloud cost based on total transactions, it was divided into two categories: a) active cost and b) holding cost.
Active Cost per Transaction: This is the cost for each transaction as it happens in real time. For example, it might be $0.1 for every transaction.
Holding Cost per Transaction: This is the cost for storing transaction data for future analysis, like $0.001 for each transaction.
This method was effective because the company managed new transactions (for immediate processing) and old transactions (for analysis later) in different systems.
This approach had several benefits:
For Sales Teams: They could price new accounts by considering the expected number of monthly transactions and how long transaction data needed to be retained for analysis.
For Finance Teams: They could calculate the gross margins per account more accurately.
For Tech Teams: They had specific goals (or OKRs) to work on improving the system to reduce both the active and holding costs per transaction. This gave everyone a clear idea of the costs associated with each transaction, leading to better decision-making.
You would argue that tech teams will be hesitant to engage in these discussions if their systems aren't directly linked to transactions. And that's okay. An approximate model that roughly matches the cost model is often good enough, and it can include various factors as long as they align with the overall cost model.
2. Private Cloud? Why not!
In SaaS, the standard approach is to use multi-tenant architectures, where a single deployment of the software serves multiple customers. This setup is popular because it offers agility and cost-effectiveness. However, there are compelling reasons to consider private cloud deployments, especially for certain types of clients and situations.
Reasons for Considering Private Cloud Deployments
Handling High-Volume Accounts: When you begin to attract bigger clients with high transaction volumes, mixing these high-load workloads with lower-volume accounts in the same cloud environment can lead to inefficiencies. For instance, a large customer may need more resources (over-provisioning), faster response times, and a more robust disaster recovery strategy. This can increase costs and complexity for all clients sharing the same environment.
Cost of Cloud Services: The cost of cloud services typically rises with the number of transactions. Although you can try to optimize resource utilization, you can't entirely prevent costs from scaling with usage due to the pricing structure of cloud providers. This aspect becomes critical when your pricing model as a SaaS provider differs from that of the cloud providers. For example, if you offer volume discounts or enterprise deals, there could be a mismatch between what you charge your customers and what you pay your cloud provider, potentially reducing your gross margins.
Offloading Cloud Spend to Customers: By deploying a private cloud on a customer's account, SaaS startups can offload the cloud expenditure to the customer. This approach can be more attractive to high-end customers who expect a certain level of service and performance. It also aligns the customer's expenditure with their actual usage, potentially leading to more efficient and satisfactory outcomes.
Data Security and Compliance: For many large companies, data security and regulatory compliance are critical concerns. Deploying on a private cloud can give them the assurance that their data remains within their controlled environment. This can be a significant selling point for early-stage SaaS startups trying to compete with larger enterprises.
Challenges of Private Cloud Deployment
Private cloud deployments have been less popular due to the higher maintenance costs and complexity they bring, especially for tech teams managing multiple environments. However, modern DevOps tools and practices have evolved significantly, making the management of multiple environments more feasible. Automation, containerization, and infrastructure as code can help manage these complexities much better now.
3. Be at a ‘Striking Distance’ from Cloud Optionality
Cloud optionality for SaaS startups is about maintaining flexibility in their cloud strategy. It's about being prepared to switch providers if needed, choosing services that allow for easy migration, and staying adaptable to take advantage of the best offerings from cloud providers.
Reasons for Considering Cloud Optionality
Customer Preferences: Customers might favor certain cloud providers for their unique features, existing setup, or data laws.
Regional Cost Differences: Some regions offer lower cloud costs, important for startups managing expenses.
Potential Partnerships: Flexibility for future cloud provider partnerships can bring financial and support benefits.
Avoiding Single Provider Dependence: Diversifying providers prevents lock-in, improves negotiation power, and prepares for unexpected changes.
What Cloud Optionality Means
Not Necessarily Multi-Cloud Deployment: Cloud optionality doesn't imply deploying on multiple clouds simultaneously. Instead, it means being prepared and capable of switching to another cloud provider if needed.
Maintaining “Striking Distance”: This approach involves being ready to switch clouds without significant delays or disruptions. It requires a good understanding of the different cloud environments and ensuring that the application architecture supports such flexibility.
Using “Blue-Collar” Services: Startups should prefer using managed services that have equivalents in other clouds. For example, using PostgreSQL Aurora offers the benefits of managed services while retaining compatibility with PostgreSQL, making it easier to switch clouds if necessary.
The approach requires careful planning and understanding of the cloud landscape but can offer significant advantages in terms of cost, performance, and strategic positioning.
4. Decentralized Governance of Cloud Costs
Decentralized cost governance in SaaS startups is an approach that, though less common, can be more effective over time compared to centralized cost governance.
Although centralized cost governance can provide immediate results, decentralized governance offers a more sustainable approach by involving developers directly in cost management, thus fostering a culture of cost awareness and responsibility across the organization.
Let’s take a comparative look:
| Parameter | Decentralized Cost Governance | Centralized War Room-Based Cost Governance |
| Approach | Distributes cost management responsibilities across developer teams. | Concentrates cost management in a dedicated expert team. |
| Cost Visibility | Each development team has visibility and accountability for their specific costs. | Cost visibility is limited to the central team, with less transparency for other teams. |
| Responsibility | Developers are directly responsible for the costs of the systems they manage. | A smaller group of experts is responsible, leading to less ownership among other teams. |
| Cost Attribution | Fine-grained, with specific costs attributed to respective services. | Broader, with costs managed at a higher, more centralized level. |
| Involvement in Decision-Making | Developers are empowered to make cost-related decisions for their systems. | Decision-making is typically top-down, with less input from individual developers or teams. |
| Metric Inclusion in Sprints | Cost is treated as a key metric alongside performance and availability in development cycles. | Cost management is often separate from regular development sprints. |
| Long-Term Sustainability | More sustainable due to widespread ownership and continuous involvement. | Less sustainable as it depends heavily on a small group of experts. |
| Optimization Opportunities | Greater opportunity for cost optimization due to direct developer involvement. | Optimization may be limited to the expertise and capacity of the central team. |
| Cultural Impact | Fosters a culture of cost-awareness and responsibility across the organization. | Can lead to a disconnect between cost management and other organizational functions. |
| Suitability | Better suited for organizations aiming for long-term, sustainable cost management. | More effective for short-term or immediate cost control needs. |
5. A Culture of Service Resource Requirements Documentation
While teams often use tools to analyze cloud bills and identify resource-intensive services, they frequently miss an important step: formally documenting the specific resource requirements of each service. This oversight can lead to missed opportunities for cost optimization.
Here’s a condensed version of what this approach involves:
Determine if a service must always be running, or if it can be scheduled as a job.
Assess whether the service can handle restarts, to balance the use of on-demand and spot instances.
Define how the application should scale according to varying demands.Define what resources are needed for each service
This approach helps get a better grip on what cloud services are costing, going further than just what you see on the basic reports. It digs into smarter ways to save money.
Sure, it takes a bit of work at the start to document everything, but it pays off. In the long run, you end up saving money and running things more smoothly. It's a smart move for any organization that wants to get better at managing their cloud costs and improve their financial health.
6. Focus on Optimizing Low-Risk, Non-Production Environments
In SaaS startups, it's usual to charge the costs of non-production stuff to tech teams and the costs of production to the company's main financial records (PnLs). Production costs are generally bigger and more linked to the business. So, when trying to cut these costs, you need to be careful because there's more at stake.
But, cutting costs in non-production areas is less risky and a good place to start. Here are some easy ways to do this:
Go for Spot Instances: Use spot instances for non-production tasks to cut down costs a lot.
Control Resource Usage: Put limits on how much resources your non-production setups can use.
Separate Testing Areas: Have different places for different kinds of testing, like checking functions or load testing.
Shut Down When Not Needed: Turn off the non-production setups when nobody's using them, like on weekends.
It’s also important to keep a budget-friendly local development environment. For a typical SaaS company spending about $1 million on the cloud, non-production stuff can be up to 20% of all costs. With smart steps, this can often be brought down to less than 8%.
By starting with non-production areas, SaaS startups can save money quickly without messing with their main production systems. This way, they can get better financially without taking big risks.
7. Applying Budget Constraints on experimental Data Workloads
In recent years, SaaS startups have greatly benefited from the big data trend, using advanced tools like Apache Spark and Snowflake for fast data processing. These technologies, more resource-intensive than traditional data warehouses, have enabled diverse queries, leading to higher cloud costs, often over half of total expenses.
While reverting to older systems isn't ideal, finding a balance is crucial. Commonly, data products start with trial queries in notebooks and are then productized if the return on investment (ROI) justifies it. We propose cloud cost should also be considered when deciding on the next set of productization when the budget is hit for the experimental data workloads.
The experimentation phase is costliest, but productization focuses on cost-efficiency. By budgeting wisely and deciding when to convert experiments to products, companies can manage costs. The aim is to create efficient reports, dashboards, or datasets, reducing the need for expensive queries. Keeping spending within limits, like 20% of the total budget, is essential.
Overall, while advanced data processing has advantaged SaaS startups, managing and optimizing cloud spending in this big data era is equally crucial. A strategic approach to productization, mindful of cloud costs and resource use, ensures a sustainable balance.
Final Thoughts
The cloud isn’t going anywhere. Neither are the bills. But we need to find ways to keep the costs in check or else, we will defeat the purpose of moving to the cloud, at least when it comes to the overall costs.
Let me know your thoughts and practices you might be implementing at your organization for better cloud-cost optimization.
