Identify and reduce multicloud integration costs

App integration costs in multicloud

An application in the cloud is a kind of matrix, with different components connected via workflows. Some parts of the application may continue to reside internally within a company's own data center, while the rest resides in the cloud. If an organization uses multiple cloud providers, the application may be hosted on several different cloud platforms.

Multicloud deployment and integration is a three-step process. First, apply policies to determine the best place to host an application component. Second, deploy the component in the selected cloud -- a private cloud or one of your multiple public clouds. Finally, provide the necessary IP address information to tie the new hosting location into your application workflow.

Because every public cloud service manages IP addressing a little differently, it's often necessary to customize deployment steps for the target cloud. This means it's easy to make a mistake, and potentially expensive to recover from it. In some cases, adding a cloud provider can increase deployment and redeployment costs by over 50%.

And that's not the worst of it. Most multicloud configurations connect to a company's VPN. If application workflows pass between different cloud providers, they'll do so via the company VPN, increasing traffic load and costs. And, since most cloud providers charge for traffic that crosses between the user and the cloud, every time work passes cloud provider boundaries, it incurs another charge. Poorly planned multicloud deployments can more than double the cost by weaving workflow traffic in and out of various public clouds.

Minimize multicloud integration costs

The easiest way to minimize multicloud integration costs is to not deploy components of an application in multiple public clouds. However, this might be necessary to accommodate differences in user geography, or if a primary provider suffers an outage. In these cases, carefully plan application workflows and relationships to reduce the traffic that crosses cloud boundaries.

If you have an application that works best on Azure and another on Amazon Web Services, run the applications on those respective platforms and link them to your users and data center. This eliminates the need to pass work between cloud platforms, which doubles the traffic costs.

Some users adopt multiple cloud providers for geographic reasons, such as  needing to host applications in a certain location. In this case, treat each of the multiple cloud instances of an application as a separate application, linking each back to the company VPN -- but never exchange work across cloud boundaries. This means those applications would look like a star configuration, with the center being the company's data center and the points being the various multicloud, front-end processes. All workflows would cross only one cloud provider boundary, and the cost of this topology would be comparable to that of a single provider's cloud.

This configuration raises a point for users who want multiple cloud providers for resiliency or scaling: unless your cloud provider doesn't charge for inbound and outbound traffic, never move a single component of an application from one cloud to another -- move the whole application to avoid multiplying traffic charges.

Deployment and redeployment efficiency is also important to control multicloud integration costs. Cloud deployment is complicated and error-prone, and multicloud deployment -- especially ensuring you don't violate traffic policies -- is even more complicated. Don't undertake multicloud application integration without DevOps tools to automate the process.

When you add multiple providers into a cloud deployment, you add complexity to the financial implications of any application topology. If you don't see clear benefits to offset that complexity, multicloud may not be an answer for you. If you do, then plan deployment carefully to ensure those benefits are achieved.