Nowadays, developers at pretty much every company require quick IT response time, self-service deployments, and a good user experience. And when it comes to line of business (LoB) activities, they don’t hesitate to bypass IT if they’re not satisfied with their current options. The result is that the past several years has seen the shift of applications and workloads deployed to a hybrid cloud model, with a mix of traditional on premise, private and public cloud platforms.

Yet the integration and orchestration of workloads between these various platforms means that there are factors companies must be aware of if they are to realise the cost and efficiency benefits they’re looking for from cloud services.

Which applications and workloads to which cloud?

A good approach is to keep in mind the three main cloud buckets as options within a hybrid cloud environment: traditional, private, and public clouds.  Which applications and workloads belong in which bucket?

Since the first step is to know what questions to ask, here are a few to start with.

  • Should it stay in the “vault”? When hybrid cloud and multi-cloud were new concepts, integrating cloud environments posed security and privacy concerns. There’s an old joke that the formula for Bush’s Baked Beans and Coke always stays in the vault. Companies may still want to keep their secret sauce — critical applications and workloads — in traditional environments on prem and designate low criticality, low complexity workloads to public clouds. Overtime, we’re seeing less and less of that thinking, but it’s still a consideration
  • Which workload to which cloud? Due to incentives and potential license costs savings, it may be more cost effective to run legacy Oracle workloads in Oracle Cloud, Microsoft workloads in Azure, and so on. New applications may make sense to develop and deploy on AWS because of the rich set of DevOps tools available in AWS
  • What’s the most efficient way to handle fluctuating workloads? When applications have computing and storage requirements that are highly variable for whatever reasons, say a website is extremely busy only during certain periods, “cloud bursting” may make sense.  Use an on-premises private cloud to handle normal workload and automate the scale-up to burst peak workloads to a public cloud
  • Will a do-it-yourself cloud migration work? Many companies start off attempting cloud migration themselves, especially if they are currently managing their own legacy environment and want to move to a hybrid cloud environment. Perhaps they’re currently using Azure and have employees trained on Azure. However, a business case justifies moving or creating new applications on AWS. Some companies attempt to take that same Azure-skilled workforce, expecting that knowledge to apply to AWS, and handle the integration between the two environments. It isn’t that easy.

There are tools, technologies, frameworks, and processes specific to Azure and vice versa, those that are unique to AWS. There’s a steep learning curve between them and companies have two options. If they don’t want to rely entirely on the skills of in-house staff, they can seek help from a partner or a systems integrator. Another option is to reach out directly to cloud providers who typically have some level of consulting built into the cloud platform in the form of tutorials, knowledgebase articles, training classes or training videos that can make the migration easier.