Hybrid Cloud Migration 101: The Importance of Creating a Single Enterprise Pipeline
By: Vincent Lussenburg
Tags: DevOps, Software Development, Cloud Computing, Hybrid Cloud, Cloud

Like many in the DevOps industry, I’ve seen a steady increase in enterprises moving their applications to cloud-based infrastructure in an effort to deliver software faster than ever before. In today’s competitive landscape, in which everyone is a software company, slowing down is not an option. And while cloud migration can bring tremendously innovative benefits, it’s not something that is achieved overnight in a straight line. Therefore, the most important thing an organization can do is to create an organized enterprise pipeline that can handle a hybrid state to ensure stability all the way from Development to Production, wherever the organization is in its transition.

D efine a Single Enterprise Pipeline for Hybrid Environments

The idea of an “enterprise pipeline” is all about visualizing, managing, and orchestrating the entire path from Development to Production. Your pipeline should be able to handle a wide array of steps, like embedded security and compliance approvals, which helps you get buy-in from the necessary stakeholders. Without everyone on board, your pipeline won’t extend all the way to Production.

It’s also important to understand that an enterprise pipeline should be built for all applications so that it is reusable yet amendable. One approach that can allow you to switch over to a container and cloud architecture in a stress-free, step-by-step way is to create an enterprise pipeline that abstracts away from the underlying technology that you use to host your applications. By doing so, the mechanics of your release process won’t change as you incrementally modernize your environments.

Also keep in mind that, while a migration strategy may work great for one application portfolio, it might not for another. The way you go to Production will vary across releases, and the environments may differ as well, but the backbone of the pipeline should look the same.

Avoid Big-bang Migrations

Defining a migration process that assumes “big-bang” migrations are the answer automatically sets you up for failure. If you have 300 applications, migrating each of these in one go is not possible. What you really want is a pipeline that enables you to take baby steps towards the desired state.

It’s also worth remembering that not all applications are created equal. Your migration strategy for application portfolio one may not work for application portfolio two. Try to make things as generic as possible, but do not assume everything is going to be the same and that you can migrate everything in one take — that is a recipe for disaster.

Reuse Legacy Infrastructure for Container and Cloud Environments

A common misconception I’ve run into is that if you use containers, you’ll no longer have configuration concerns. That’s just not the case. If you’re running an application in a container, you’re going to have to set up similar, or possibly identical, database connections. The entity behind this database connection is still the same, so it doesn’t make sense to maintain another set of configurations in a second format. Instead, build a single ‘source of truth’ that documents your entities and how you can apply them automatically to the various runtime styles of your application.

Ultimately, it’s quite important to reuse configurations in order to make the process of embedding cloud and container technology effortless. Why should you create extra steps if they aren’t needed?

Don’t Forget to Reassess Existing Architecture

As you’re going through your migration, it’s essential to realize that not every application is going to lend itself well to cloud environments, so you need to assess the architecture behind that application.

Look into how well your applications adhere to certain standards like TwelveFactor — I like to call this “Twelve Factorifying” your existing applications. These different factors lay out principles and practices for how your application architecture should ideally look if you want to make optimal use of cloud-native capabilities, such as elastic scaling.

One of the biggest advantages that going to the cloud gives you is the ability to sunset the homegrown management interfaces you’ve built for your applications, which tend to be organization specific. Cloud providers such as Google Cloud, Azure, and Amazon AWS offer services that can address your management concerns more generically and effectively than any homegrown interface you’ve likely built yourself.

So, as a part of your migration strategy, look for “low-hanging fruit” opportunities where you can sunset these legacy interfaces instead of migrating them.

Key Takeaways

In summary, when migrating applications to the cloud, I recommend the following:

Define and build a reusable enterprise pipeline for all applications that allows you to manage the entire path from Development to Production, satisfies the concerns of all stakeholders, is highly auditable, and is the single source of truth for your overall process.

that allows you to manage the entire path from Development to Production, satisfies the concerns of all stakeholders, is highly auditable, and is the single source of truth for your overall process. Define and build deployment automation that can be invoked non-interactively, regardless of whether your target is on premises or to the cloud, as a container or as a legacy app. This will allow you to incrementally change your environments without impact to all the other steps in your enterprise pipeline.

that can be invoked non-interactively, regardless of whether your target is on premises or to the cloud, as a container or as a legacy app. This will allow you to incrementally change your environments without impact to all the other steps in your enterprise pipeline. Use a single source of truth for your configuration , and reference to that configuration from your configuration templates for both your old and new architecture. Don’t duplicate your configuration or you’ll end up dealing with synchronization issues. By avoiding synchronization problems, you can reduce the overhead that comes with migrating to the cloud incrementally.

, and reference to that configuration from your configuration templates for both your old and new architecture. Don’t duplicate your configuration or you’ll end up dealing with synchronization issues. By avoiding synchronization problems, you can reduce the overhead that comes with migrating to the cloud incrementally. Do not try to migrate all apps at once . Every application may not be a unicorn, but you don’t want to assume that and set yourself up for failure. Big bang migrations tend to be messy!

. Every application may not be a unicorn, but you don’t want to assume that and set yourself up for failure. Big bang migrations tend to be messy! When looking to bring an application to the cloud, assess its architecture to make sure that you identify opportunities for leveraging cloud-native management interfaces and reducing your footprint of homegrown management interfaces.

There’s no doubt that more enterprises have begun the process of accelerating their migration to the cloud and are already defining their cloud migration goals for 2020. Creating a single enterprise pipeline to support an iterative way of moving to cloud-based infrastructure is the best road to success. Make sure to reassess and reuse any existing architecture and legacy infrastructure in the process, so you don’t create more work than is needed.

Vincent Lussenburg serves as the Director of DevOps Strategy for XebiaLabs.