{"id":19686,"date":"2021-08-19T20:07:41","date_gmt":"2021-08-19T13:07:41","guid":{"rendered":"https:\/\/renovacloud.com\/?p=19686"},"modified":"2024-12-02T17:26:12","modified_gmt":"2024-12-02T10:26:12","slug":"how-to-define-and-create-a-realistic-cloud-budget","status":"publish","type":"post","link":"https:\/\/renovacloud.com\/en\/how-to-define-and-create-a-realistic-cloud-budget\/","title":{"rendered":"How to Define and Create a Realistic Cloud Budget"},"content":{"rendered":"

All large projects need clear and thoughtful planning. And a big part of planning involves figuring out how much you\u2019ll need to spend and where your money will go, i.e. a budget. When it comes to creating a realistic cloud budget, things get complex very fast!<\/span><\/p>\n

In the good old days, <\/span><\/h5>\n

IT projects involved a relatively small number of moving parts. The big-ticket items included the purchase and maintenance of servers and networking equipment along with ongoing costs like power, cooling, and facilities security. Building reliable budgets certainly may not have been easy, but there wasn\u2019t a lot of mystery involved.<\/span><\/p>\n

\u00a0All that\u2019s changed with the shift to cloud platform hosting. You won\u2019t be purchasing and installing $100,000 server room racks any more, but working with the virtual tools that have replaced them.<\/span><\/p>\n

Deploying a complex, multi-tiered application in the cloud could leave you with ongoing charges for virtual servers, containers, serverless functions, managed databases, network bandwidth, firewall appliances, data storage, and monitoring software. Consider how this is also configured to scale up or down in response to fluctuating demand or system failure, all while being securely replicated for high availability.<\/span><\/p>\n

To top it all, <\/span><\/h5>\n

AWS is constantly updating both the features and pricing for their existing services. They introduce dozens of new services each year, affecting not only what you\u2019ll pay over time (often to your advantage), but how you do things, too.<\/span><\/p>\n

With so many moving parts in play, the clarity of a solid budget is absolutely critical. Read on to see what\u2019s involved in this process.<\/span><\/p>\n

The Challenges of Building a Realistic Cloud Budget<\/b>\u00a0<\/span><\/h3>\n

\"\"<\/p>\n

So, just what is it that makes the cloud so complicated? A generation ago, an average mid-sized company might have maintained data centers with fleets of servers built with a small handful of hardware architectures. Database servers might have larger drives, while application servers would be given more memory. But for all practical purposes, the available options were few, and the mix would remain largely stable for years at a time.<\/span><\/p>\n

How does that work in the AWS cloud? <\/span><\/h5>\n

There are currently more than 200 distinct services, each offering a unique set of capabilities that can be consumed on their own or, more often, as part of a larger deployment stack. And each service uses its own unique billing model.<\/span><\/p>\n

Virtual server types? <\/span><\/h5>\n

There are, at the moment, more than 40 instance type <\/span>families<\/span><\/i> available for the EC2 service, each one optimized for different use cases. And most of these families include at least a dozen specific instance <\/span>types,<\/span><\/i> with more being added each month. And if that\u2019s not enough, their costs change frequently, like the rest of AWS services\u2014they become cheaper for existing instance classes. Meanwhile newer, better instance classes are introduced with higher price ranges.<\/span><\/p>\n

Also, applications need to change all the time. <\/span><\/h5>\n

New products, new features, customer on-boarding, customer churn\u2014all affect the size of your cloud infrastructure. For example, adding a new microservice to your application stack may look simple from a solution architecture perspective, but it may translate into creating another node for the Kubernetes cluster. How do you define a budget if needs constantly change?<\/span><\/p>\n

To maintain high service availability, <\/span><\/h5>\n

you\u2019ll often configure your services to automatically scale up and down to meet changing demand. But even normal utilization changes due to, say, your customers\u2019 seasonal shopping patterns, can dramatically impact your billing rates for multiple services.\u00a0<\/span><\/p>\n

Cloud budgets are clearly not for the faint of heart.<\/span><\/p>\n

Cloud Budgets: What to Consider First<\/b><\/h3>\n

\"\"<\/p>\n

In order to get started, one thing you need to have handy from the get-go is the organization\u2019s revenue projections or goals. <\/span>This is to ensure your budgeted infrastructure costs are realistic. You can have a budget of any figure, but it needs to be realistic in the sense that it should fit within the overall IT budget, and it should be less than the projected revenue to ensure the company makes a profit.<\/span><\/p>\n

If you are starting with your cloud journey, understanding your deployment strategy can help in having a high-level understanding of costs involved. <\/span><\/h5>\n

For example, if you are doing a lift-and-shift of an application from your on-premise environment, the architecture would most probably be simpler in the cloud, and be less costly. If you are doing a complete re-architecture, it will probably need more services, which will cost more.<\/span><\/p>\n

When moving an existing on-premises stack to the cloud\u2014or even when you\u2019re just comparing your options\u2014it can be helpful to create parallel budgets that can be viewed side-by-side. <\/span><\/h5>\n

The concept of \u201cparallel budgets\u201d will also apply to the multiple infrastructure environments that are often used for larger projects: one for the development team, a <\/span>staging<\/span><\/i> environment for final testing, and then the actual production environment. Each one comes with its own costs as these environments are naturally different in size.<\/span><\/p>\n

Similarly, when you are starting out with cloud, whether the on-premise network will remain in operation for the foreseeable future is another factor to consider.\u00a0 <\/span><\/h5>\n

Having footprints in both environments will increase the total cost of ownership (TCO), and your budget will need to minimize that as much as possible.\u00a0<\/span><\/p>\n

It\u2019s also important to differentiate between your capital expenses (capex) and operating expenses (opex). <\/span><\/h5>\n

Capex is the money you spend up front on compute equipment and physical infrastructure. Opex, by contrast, represents ongoing month-by-month expenses. Pure cloud deployments, since they\u2019re billed incrementally for actual resource use, will qualify as opex. But the infrastructure you might run in your own data center, perhaps as part of a hybrid deployment, will require up-front capex investments. Both, however, are key elements for calculating the TCO of your application. And neither can be ignored.<\/span><\/p>\n

You should also understand the difference between managed and unmanaged services. <\/span><\/h5>\n

Managed services include the AWS Relational Database Service (RDS) and Elastic Beanstalk. They\u2019re <\/span>managed<\/span><\/i> in the sense that you only need to configure some settings and then add your code or data. AWS manages the underlying infrastructure invisibly. Unmanaged services include EC2 instances, where you handle all the update and configuration, at least on the software level.<\/span><\/p>\n

Finally, a complete budget will also take into account any cost-saving elements you may already have in place like Reserved Instances and Savings Plans. <\/span><\/h5>\n

Will you need servers running at full capacity 24 hours each day? Then you\u2019ll probably get the most bang for your buck by purchasing EC2 Reserved Instances. Demand that\u2019s intermittent and rarely stretches for more than a few hours at a time, though, might be best met using On-Demand Instances in order to avoid underutilizing commitments. In-house data processing that\u2019s loosely coupled enough to withstand sudden outages is a good match for Spot Instances. And brief bursts of programming code can often be served most efficiently from Amazon\u2019s \u201cserverless\u201d service, Lambda.<\/span><\/p>\n

The big thing, as we\u2019ve already seen, is understanding what the best practice is for running your workloads and what they are supposed to accomplish. And the bottom line is that the amount of money you spend should accurately and predictably make sense in the context of your organization\u2019s larger goals.<\/span><\/p>\n

To create a useful budget you\u2019ll, therefore, need to understand:<\/span><\/h5>\n