Cloud cost management tips for working with multiple vendors
Using more than one cloud has its benefits, but can also get expensive. To manage costs, examine your providers' data access charges, as well as your application design.
Nearly every enterprise and most midsize businesses will deploy public cloud computing for some of their applications. Larger companies -- particularly those with extensive operating geographies -- are likely to use multiple public cloud services, and, in some cases, this results in eye-popping charges. It's critical for any prospective multicloud user to understand how costs can get out of control, and what to do to save the budget.
To control multicloud costs, understand what your cloud providers charge. Their charges generally fall into four broad categories: CPU resources, storage, access and special Web services. If providers' cloud pricing models were similar, dividing applications among multiple cloud providers wouldn't impact overall costs. Sadly, that is not likely the case. Most of the challenges with multicloud costs arise from two factors: storage costs and access charges. When creating a cloud cost management plan for applications that span multiple clouds, start by examining those two areas.
How multicloud costs add up
Access charges, or the traffic charges associated with moving information in and out of your cloud apps, are the biggest challenge when working with multiple cloud pricing models. Moving an app or component from your primary cloud platform to another often means work has to flow between clouds. A simple transaction might go from a user to Cloud A, from Cloud A to Cloud B, from Cloud B back to Cloud A, and then back to the user. This workflow could double the access charges -- which wouldn't be the case with a single cloud provider.
Storage charges can also explode and increase access charges in multicloud deployments. If the same app runs in two different clouds, or if it's split between them, and all its pieces need access to data, you're faced with a difficult choice. If you host the database in your data center or only in one cloud, you'll have to pay access charges to get to it. However, database access across different clouds can involve a lot of data movement and a lot of cost. The alternative is to host a copy of the database in all the cloud platforms you use, but that can introduce additional data storage costs and create synchronization issues.
Access charges, or the traffic charges associated with moving information in and out of your cloud apps, are the biggest challenge with multicloud cost management.
Special Web services can create a similar problem because some of their costs are based on access to features which can be difficult when dealing with multiple cloud pricing models. For example, if you need a special service for an app, and you distribute the app so that the feature is needed in multiple clouds, you'll pay for the feature in both places. And since usage charges are typically lower with higher usage, you'll also lose out on economies of scale.
Even CPU charges can be higher if you distribute your apps to multiple clouds. One reason, again, is the economy of scale issue; higher usage levels usually mean lower per-minute charges. Another reason is that many businesses buy dedicated instances and, when they distribute apps among multiple clouds, often underutilize them.
Devise a cloud cost management plan
If you plan to move apps dynamically from cloud to cloud it can be difficult to control, or even predict, costs. But you can take measures to keep costs in check.
Cloud cost management starts with mapping workflows and data paths. Every component of every application has inputs, outputs and explicit needs to access databases and special features. It's a bit of a chore, and the resulting charts can be complicated to analyze, but a good way to start multicloud cost management is to draw out these relationships for all the apps you plan to host in the cloud. This will help you identify the border crossings within your multicloud deployment, where you'll incur charges or will need to duplicate the hosting of data and features.
This map often shows an important truth in multicloud deployments, which is that developers often build applications in distinct layers. The highest layer is the front end, which is responsible for device support and GUI creation. This layer passes work to a middle layer that adds in things like basic data editing and that, in turn, hands off to traditional transaction processing components. Knowing the structure of your apps can save money in a multicloud deployment.
New public cloud pricing models sweep the enterprise
David Linthicum talks with Joel Davne, founder and CEO at Cloudnexa, an AWS Premier Partner based in Philadelphia, about evolving cloud pricing models, as well as other topics, including AWS Scheduled Reserved Instances.
Front-end layer application components are relatively easy to distribute across multiple clouds because they rarely require database features, are designed to be instantiated in multiple copies for performance and often hand off work to a single partner layer. Using multiple clouds versus a single cloud might impact your economies of scale in pricing, but you probably won't see major increases in access or storage costs.
Some applications will integrate basic databases with middle-layer components for editing and validation. When you get to this layer, don't forget the cost of replicating data in multiple clouds. The more complex the processing in this middle layer, the more difficult it will be to have an application and its components cross cloud provider boundaries. If you want to assess the impact, draw a circle around the components you plan to use in a multicloud environment, and see what workflows and data paths are cut. That tells you where you will incur additional costs.
Because the bottom layer of the application -- actual transaction and query processing -- likely involves a lot of real-time database access, avoid spreading this layer across multiple cloud providers. Today, and in the near future, most companies will keep this mission-critical processing in-house.
When building a cloud cost management plan for apps that run on multiple platforms, don't overlook potential issues with integration and lifecycle management. There are strong reasons for a user to deploy on multiple public clouds, but there are also risks, including increased cost and complexity. Understand the cloud pricing models and address any complexities early to make your experience a positive one.
