By Fraser McKay, Head of Product at Cloud Cruiser

logoNow that we have a grip on our nebulous worries about virtualized everything, adoption of cloud services and infrastructure is becoming business as usual. IDC predicts that by 2019, nearly half of all IT infrastructure spending will be on cloud infrastructure, reaching $54.6 billion. That doesn’t mean it’s suddenly simple to set up and manage cloud initiatives. As with any new technology, there are plenty of wrinkles to iron out. One of the primary challenges facing cloud administrators—controlling costs— arises from the decentralized nature of cloud services. There are some common misperceptions about cloud consumption that can lead to management headaches. Moving to the cloud is a big investment of time and resources. Save yourself unnecessary hassle and waste by starting out with a clear-eyed view of the road ahead.

Myth #1: Costs will be self-regulating in a consumption-based model

Many traditional IT organizations allocate costs back to their users based on some type of service costing approach, where they try to assign direct and indirect costs back to their consumers in a fair and defensible way. The first myth related to cloud control is that moving to a ‘pay by the drink’ or consumption-based model will prevent cost overruns, because users will self-regulate when they know their services are metered. The reality is, nothing could be further from the truth. While it’s true that cloud services are much more readily metered and costs tend to be easier to allocate to a user, cloud services are typically also much more readily available, leading to a highly decentralized approach to provisioning. Translation: the red tape that exists in a highly centralized environment acts as a natural governor on excessive spend, but is dramatically reduced in the cloud (particularly public cloud), where cloud spending responsibility tends to be dispersed across an organization. The solution is to have a control plane in place that allows you to get the best of both worlds: a high level of agility for rapid time to value (the promise of cloud) coupled with appropriate controls that enable oversight and management of a highly decentralized environment.

Myth #2: Optimization of Costs and Usage is an ‘IT Finance Thing’

This statement held true in the traditional IT world (IT Finance managed most of the cost controls). In the cloud world, I’m seeing customers demand a single tool that services the needs of both IT Finance and IT Operations. IT Finance is typically more interested in the dollars (cost) and IT Operations is more interested in the units (performance). Ultimately, it’s the same data (usage and cost information coming from the cloud provider) and the only thing that differs is how that information is used. The management and optimization of a cloud requires a much deeper partnership between IT Operations and IT Finance, due to its highly dynamic and decentralized nature.

Myth #3: Your traditional ITFM solutions will work with your cloud

Quite a few companies have attempted to retrofit their traditional ITFM solutions (home grown or purchased) onto their cloud environments, and almost without exception they have failed. The first reason for such failures is data latency. In the old world of ITFM, there would be a tedious accounting exercise at the end of each month to apportion the costs related to IT services delivery to different internal consumers (i.e., show back or charge back models). In the new world of cloud, managers want near real-time usage and spend information so that they can optimize services on a continuous basis. Waiting until month’s end for the information needed to make decisions simply doesn’t make any sense. At that point it is too late to take corrective action to optimize your usage or spend. The second reason traditional ITFM fails in cloud environments is that the highly decentralized nature of cloud usage requires a toolset that is approachable by your average user. Traditional ITFM solutions are typically highly specialized and require a lot of interpretation by an intermediary (e.g., a financial analyst or service manager). In the cloud, many more individuals and departments are making decisions about provisioning and costs, so management tools must have a consumer product ease of use.

Myth #4: You should focus on getting your cloud operational, then invest in building a control plane

Ask anyone who has implemented a cloud project and then tried to go back and retrofit it with appropriate tags to achieve some sort of control plane (reporting by department, project etc.) — they will tell you that it’s about as much fun as getting your teeth pulled. It’s a classic BI problem, where the people responsible for data quality (in this case, the people tagging the resources at the time they are provisioned) are not typically the same people that rely on those tags to be correct (those who need to attribute usage and cost correctly). The result is predictable: bad tags. This ultimately leads to major headaches down the road when you try to get control of your cloud. I highly recommend that you make an investment in a cloud control plane very early in your cloud initiative, so that you can get a clear picture of where any gaps exist. This approach gives you time to come up with solutions before hidden issues become big problems. When your users start seeing reports with actual usage and cost information, they can provide very specific feedback on how things need to improve or change. It’s best to show them these reports as early in the project as possible.

Myth #5: All cloud cost and optimization tools handle multi-cloud environments well

While most vendors claim that they can elegantly handle the management of different clouds in the same tool, the truth is most cannot. It’s actually a very difficult problem to solve because the underlying data from each of the different cloud providers is wildly different, with a whole bunch of different quirks in the way usage and cost is metered and reported. This variability is difficult to grasp; you should take a very close look at the multi-cloud capability claims of different vendors. Even if you are starting your project with a single cloud (AWS, for example) you should always run a proof of concept to test multi-cloud capabilities, or you may be in for an unpleasant surprise after you’ve selected a vendor claiming multi-cloud support. Cloud is all about choice. If you choose a control plane that does a less than stellar job of handling multiple clouds, you are effectively locking yourself into a given cloud providers’ ecosystem—never a great idea. The good news is that most vendor claims can easily be tested with a simple multi-cloud proof of concept or trial. If your vendor drags their feet on this, my advice is to run in the other direction as fast as you can!

In the confusion that rolls along with sweeping waves of technology advancement, the companies that can find out how to keep their heads above water and chart a course for the promised land will reap the benefits while others tread water or drown. Cloud technology is here to stay and it’s high time we learn to swim, not sink. Runaway cloud costs will burden your cloud initiatives, making it harder to plan for success and evaluate outcomes. With a control plane in place, it will be easier to collaborate with stakeholders, align cloud spending with strategic objectives, and navigate purposefully through complex and dynamic environments.

About the Author

As head of product, Fraser applies his expertise in creating and launching successful financial BI products for the enterprise. Fraser most recently worked at Apptio, where he led product management and helped the company achieve consecutive years of explosive growth. Before this, Fraser served as the head of BI strategy for the Microsoft Dynamics ERP group, where he oversaw the development of a product roadmap for corporate performance management solutions. Prior to Microsoft, he held multiple senior management positions at Business Objects and SAP.

Fraser holds a Bachelor of Business Administration degree with a major in Marketing and Management Information Systems from Simon Fraser University in British Columbia.