Over the past couple of weeks, I was getting back into the normal life of Cloud Engineering (the #BuildWithAI global hackathon isn’t the only thing that I focus on – check this article out #BuildWithAI Announces Winners). And something that I was doing was actually less about technology but more about budgeting – Cloud Estimations.
This is an interesting puzzle because of a couple of different elements.
Cloud is supposed to be elastic. But budgeting is typically not. Nor are project estimations and costs. Nor are approval processes. Nor are procurement processes. There are so many things in a business that are not elastic.
The people provisioning are not necessarily in charge of the costs. And I know as a developer, these overarching cost discussions aren’t necessarily the one you get invited to.
I look at this problem and I refer back to a diagram that Peter Laurie drew alot when we were running a Developer Experience series a few years ago. And it goes something like this. We compare and contrast the different ways that projects are run and the value (ie the “real” value) comes not when we deliver the project into production but crossed the line after we recouped the cost of delivering the project. Not all projects do that. And some as Peter said, some go up and value is created, some go flat and take a long time, and then there are some that don’t and go down from there.
That pivot point (ie when the project gets delivered) is important because it is based upon many different factors. There are things that we can control – development, quality of development, requirements. There are things that we can’t control like the quality of the requirements to achieve such “real” value. We don’t really know once we try.
The point about this (in the context of Developer Experience) was about agile and lean methods and the benefits of DevOps to enable this. This is all great in principle but there are factors that constrain this. And the main one that we talked about was contracts and the procurement process.
Do I have the flexible in my contracts to support this agile behaviour?
The scenario that we talked through is the change request process. And the story goes like this:
Scene: The project is completed and code is delivered into production. The customer and the implementation partner are sitting in the meeting room.
Customer: Thanks for delivering that project. But there is one thing that isn’t right. What do you think?
Partner: I agree. It doesn’t look right. That would have been a change request.
Customer: Oh. I don’t like change requests.
Partner: That’s right. That’s why kept on going. We discovered this issue about that a few months ago.
Customer: Could that have been fixed then? Would it have been an easy fix?
Partner: Yes. But it would have been a change request.
Customer: Oh. I don’t like change requests.
This is not exactly real however this is not too far from the truth either. Contingency, fixed-price, service level agreements and change requests are processes in place to protect the organisations. However, do these processes reduce the risk or increase the chance of gaining that “real” value?
So what does this have to do with Cloud Estimations?
What I’ve been working on is estimation of a new platform for a customer. During that time there were workloads that were going to be put into the Oracle Cloud Infrastructure over a period of time.
So, all I needed to do was to map it out and estimate it right? … Wrong …
There are variables in terms of the estimate and the biggest variable is time. When will contracts sign? When will project start? When you each phase of the project start end? What if there is a change in resource that impacts the speed of the project (time)? All of these can’t be estimated. This is what I did.
Estimate the workload. This needed to happen. Using the Oracle Cloud Cost Estimator, I determined a cost per month. In some cases, I needed to align to the project plan based upon the week-by-week approach. This helped with a consumption baseline of what was needed to be consumed and gave me an overall shape. – https://www.oracle.com/cloud/cost-estimator.html
Model the workload. This is needed because nothing is constant. There is always an adoption curve to technology whether you call it a project or build process. In the project that I was estimating, there were multiple environments for Dev, Test and Production and DR. And each of these were done at different milestones of the project and we also scaled up and down the resources for different activities, eg. we minimises the resources for the build but maximised the resources for the stress testing (and then back down again). What eventuated was a series of calculations that created a wave of consumption.
Consider your baseline. This is where it becomes different as well. From a “traditional” costing perspective, you do something like this. Measure the consumption; Understand the cost; Contract to the cost with some fudge factor to allow for some contingency. However, its different with Oracle Cloud Infrastructure and our consumption model called Universal Credits. The main thing about UC is that there are two things about it.
PAYG is the same price as a UC contract and
pay the same rate for overages as to what you contract.
There are advantages for how you contract and how you consume.
Because of this, you can look at what is being consumed and look at the best way to contract. Is a contract even needed? Does the first year look like the second year? With what I did for this customer was look at the total consumption and the base consumption and looked at what would create the best value and flexibility.
This is what the total consumption vs a baseline might look like.
Here is an example if the customer contracted at the baseline value and then budgeted for overages.
In addition, the Annual Flex model is great for these ups and downs where it is measuring on the yearly consumption so whether you have peaks or uniform workloads or highly variable, then the model caters for that.
It’s really simple with Oracle Cloud Infrastructure and the Universal Credits model where you have the flexibility of the way you contract, how much you consume and how you control the spend. If you do need to pivot half way through the project, that’s ok because there is nothing to do but change.