Cost of resources in virtual environments

Question

In planning hardware costs, considering the distribution of the product in virtual/cloud environments, where the cost is derived from the use of resources, considering the following points:

1. The minimum hardware architecture is defined;
2. Hardware provider have not yet been chosen, but there is a list of preferences given by the team;
3. Obviously is impossible to consider what will be the expansion (and hence the effective use of the minimal hardware resources);
4. All providers allow the analysis of costs, through the use of simulators of resources, and is therefore predictable the maximum cost (24/7);

How to communicate this type of variable costs? In order to define the true cost of the hardware infrastructure, A) it is appropriate to consider the maximum use of hardware resources, B) or there are different methods to determine the cost of resources in virtual environments?

Option A is the one that I took into account when projecting costs. One of the requests of the client, is to reduce the cost of infrastructure. The market analysis and consultations with the representatives of the different hardware providers, push the client to consider virtual environments. But when planning costs, option A, it does not seem to respect what the analysis offers. So I'm wondering if this type of variable costs, must be projected as a maximum.

Answer 1

TL;DR

Your problem here appears to be that you are trying to budget third-party services as if they were equipment costs. You'd be better off treating virtualized services as a service or utility, and estimating those costs the same way you would electricity usage or shipping costs.

Cloud Services Aren't Capital Investments

If you buy a server or build a server room, that is a capital cost. You then have some tangible asset subject to first-sale doctrine, depreciation, and all the other ins and outs of owning material equipment.

Cloud services (regardless of type) aren't something you own. They are a service you rent by time (e.g. X dollars per calendar month) or usage (e.g. Y dollars per minute of use). You don't own the equipment, you haven't bought anything tangible that you can sell or depreciate, and most support is outsourced to the cloud services provider.

In other words, cloud services aren't hardware from a customer's point of view, so calculating hardware or hardware-maintenance costs for a cloud service (unless you are running the cloud service) is a no-op.

Projecting Costs for Cloud Services

Calculating costs for cloud services can be difficult, as the market is largely a confusopoly. Nevertheless, you can certainly evaluate the service terms and make projections about your project's intended usage.

For example, if you plan to run 20 minimalist Digital Ocean droplets for your project, you can estimate your server costs at $100/month and your labor costs at whatever you think it will take your team to perform systems administration on the droplets. That's your total cost of ownership (TCO).

If you're using a service where you pay by the megabyte or the minute, then you'll need to estimate your project's intended levels of utilization. That may be a bit less straightforward, but it should still be possible to come up with an expected range for planning purposes. Just don't forget to add in your team's administration and support of the service to calculate TCO.

Estimates Express Expectations

If you want a hard target, just go with your upper bound. For example, if a service costs $0.05/minute, then the service (exclusive of your other administrative and support costs) will come to $504.00/week at full utilization.

Maybe you expect to only use 50% of that capacity. Or maybe your usage will vary between 30-60% from week to week. You can express those sorts of figures as a range, a statistical average over time, or whatever else makes sense to report or budget for in your organization.

You can always refine your estimates as you gain knowledge of the project and its resources. Continuous refinement is essential for effective project management.

Answer 2

Forget about the fact the actual platform is virtualised- that is a red herring. You still need to forecast your resource usage and growth just as if it was real tin. Pretend it is for the purposes of estimation and make sure you analyse, project and forecast your resource usage such as disk space, network bandwidth and backup requirements. If it was real tin you would have to do this as it is more difficult to change later.

Having got to your resource usages analysis and other technical analysis such as machine type (CPUs, memory etc) you can cost it out from the suppliers and present the costs just as you would for a non-virtualised environment.

The key differences will be the virtual will have a smaller upfront cost as the project doesn't have to buy tin outright, but higher year-on-year costs as you rent the space. You will also have other justifying factors in the mix relating to cost of ownership of tin etc. but there is no need to take a different path in terms of presentation of costs- it's just costs.

It gets different if you are indeed buying in tin and setting up your virtualisations on that hardware as then the root hardware does indeed become a project cost, as well as the VM licenses etc., but you won't have year on year rental costs (other than renewal license costs). But if the kit you buy and install is then used by another project to host their VMs you are into a completely different cost game. If that is the case I would recommend you have a separate project to purchase the kit and set up the virtualised environment, and then your project (and others) share the cost of the hosting. But this probably needs to be ironed out by your CFO equivalent as it goes beyond the scope of your project (unless I read it wrong and that IS your project :)