Over a million developers have joined DZone.

Capacity Planning For The Cloud – A New Way Of Thinking Needed

DZone 's Guide to

Capacity Planning For The Cloud – A New Way Of Thinking Needed

Prpperly planning is the key to making a cloud migration a success, but are you thinking of the right factors for migration.

· Cloud Zone ·
Free Resource

Based on IDC research, the CAPEX-OPEX drive has created an environment whereby in 2018, the typical IT department will have a minority of their apps and platforms residing in on-premises data centers.

The traditional mode of capacity planning focuses on obtaining servers funded by applications able to achieve capital investment. Application groups had to obtain the capital needed to fund compute resources to operate the application. CAPEX-OPEX simplified is like choosing between purchasing a car on full payment with yearly depreciation benefits, or leasing a vehicle on a monthly cost with some limits on miles.

In terms of an analogy, spending in the cloud is similar to that of a sushi-train, where there is a nearly unlimited/infinite set of choices. Your consumption is billed at the end of your meal for what you actually consumed. On the other hand, if you went to a fine dining restaurant, where there was a 30 minute preparation time for the food, if you didn’t plan your meal properly, it could mean you either ordered too little or too much under time constraints. Yet in the cloud, it seems like people still use the old style planning patterns.


A workload is a term referred to when running a set of resources in the cloud. This term usually refers to some characteristic of computing, memory, storage, or networking, typically around an application profile run in the cloud.

A lift-and-shift style migration is a frequently used method to move infrastructure to the cloud. Capacity planning at its core when applied to compute, storage, memory, and networking aspects with the traditional mindset creates tremendous wastage and opportunities. This mass migration to the cloud has made it possible to highlight cost savings opportunities on top of the cost savings gained from migrating from traditional colocation data centers to the cloud.

If a customer has come to the cloud through this lift and shift style migration, chances are that there is somewhere between 30-70% savings attainable. Remember, in the cloud, capacity is nearly infinite, almost available on demand when you need it.

Image title

The ease of creating capacity on demand creates the scenarios of idle capacity—for example, the spawn of some infrastructure or test and the failure to turn it off (“by the time of day” or “shut down”). An example of underutilized capacity is having 100 TB storage when 30 TB is needed now, 50 TB next year and possibly more the next year.

Misappropriated allocation is choosing the wrong type of infrastructure – for example, newer classes of infrastructure may do far more than the infrastructure one is currently on. Lifecycle management involves choosing the right class of storage. Volume discounts or reservations can be used to reserve capacity for 1 or 3 year periods and take advantage of lower price points in terms of committing to a longer duration of use. When a reservation is used prematurely, one can find themselves with excess capacity, if underutilization levels are not resolved first.

Choosing to reserve capacity in the cloud prior to applying the earlier steps can limit your cloud cost reduction ability. You can get some cost savings from reservations but may be forced to pay for a resource irrespective of your ability to use it.

Image title

The three key metrics when optimizing a workload for the cloud comes down to:

1. At Rest Capacity

Simply put, if no one is using this service/application, what is the absolute minimum necessary for its availability? For example, typical public cloud solutions may require a web server, database, possibly some middle-tier service. Did you know entire single page apps (SPA) built on Angular, React can be deployed fully inside an S3 bucket? No servers to manage – simple storage that can be made available globally using CloudFront or Akamai like caching solutions. The lowest level of at rest capacity is something that should be considered with applications, irrespective of the number of infrastructure components needed.

The rest configuration of applications can be reduced dramatically when S3 buckets are used to leverage functions previously reserved for application servers.

2. Response Velocity

Or scale up to demand velocity. How soon can the application respond to an increase in load? One such scale out architecture involves spawning application servers by the time of day or based on increased load. The key question one has to look at is, how quickly can the response needs be handled?

3. Termination Velocity:

How quickly after the burst can the application scale back down to as close to the “at rest state” as possible?

By combining tagging mechanisms, cost allocation for compute resources in the cloud can be attributed down to each application, visitor, or geographic region, introducing new paradigms for capacity planning and cost allocation.

amazon aws ,aws marketplace ,devops tools ,cloud management ,ec2 ,cloud ,cloud migration ,migration planning ,capacity planning

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}