Within IT Project Development there are a few things people see as evident. Having the right engineering skills to build the capabilities your application, solution or service needs is something no one would think twice about. Having someone in place to manage the project or team, is also a no brainer for many people working in the technology landscape. Over the past few years, we have seen practices like issues, scrum, agile planning, sprints, demo’s, continuous integration & continuous development, SAFe development, and many others make their way into the IT project lifecycle. Why is making a plan for the cost evolution of your cloud-based workloads not one of those widespread innovations?
As a former project manager, I can tell that even in my 5 years of project management I have seen so many changes for the better in how we get ideas delivered into value-providing production workloads. The more I think of it however, the more it bothers me that there seems to be one glaring missing link in the project methodology that is common in IT. Almost never is it a DOD (Definition of Done) requirement to deliver a Cost Evolution Plan for the new workload or application. It makes sense that this is something that is being completely overlooked, as it used to be the case that any developed solution would just land on servers and hardware that was already paid for by the company. Workloads would also not have a dynamically evolving cost model as auto-scaling, request driven solutions in the cloud do today.
The Cloud Cost Evolution Plan
What I would like to advocate for is to require each project delivered in the cloud to have some form of a Cost Evolution Plan. Here is why:
- First of all, we all know that costs of cloud-based workloads will evolve over time. There is absolutely no excuse to have a look upfront and see what that evolution should look like in order to have cost remain in a healthy relation with the provided business value.
- Secondly, when you build something, you have the clearest view of what components drive which cost that there will ever be. Whether you like to admit it or not, the view on an application only grows blurrier and blurrier over the years and you want to avoid having to bring in an expensive consultant to tell you things you could have known if you had taken more care.
- Finally, if you want to build a budget each year and forecast your cloud cost as accurately as possible, wouldn’t it be wonderful if you had a document for each delivered workload that went into detail about how costs are incurred and how cost should evolve for the infrastructure?
In your Cost Evolution Plan, try to include things like:
- Percentage split of services in your architecture: what services generate what percentage of the total cost
- Most flexible/volatile cost drivers: your EC2’s won’t suddenly become more expensive, but those lambda’s you have running might, or the way you have configured your KMS or other request-based components.
- Cost Optimization Targets: what components are prime suspects for rate optimization (Savings Plans for your Fargate, RIs for your RDS and EC2’s…)
- Cost Evolution Horizon: Do you expect your solution to grow in cost as you onboard more clients to it? How does it scale? Per user? Per multi-user tenant? You don’t necessarily have to dive deep in numbers here, but make sure that you have an idea how your application grows cost wise.
- List up the stakeholders you need to bring together if you need to make cost-based decisions in the future. It can help you save a lot of time getting the right people around the table.