Enterprise IT can move up or out (or both)

Much of what we do at Google Cloud’s Office of the CTO, or OCTO, is to help customers plan and execute their cloud migrations, which are often part of a larger transformation effort. Most CIOs see a cloud migration as an essential, but still somewhat daunting task. We have distilled the conversations we’ve had with CIOs, CTOs, and their technical staff into several frameworks that can help cut through the hype and the technical complexity to help devise the strategy that empowers both the business and IT. We called one such framework “up or out.” And we don’t mean some consulting firm’s hard-nosed career philosophy.

The trouble with on-premises IT

While on-premises IT infrastructure has gotten much better over the past couple of decades, e.g. through virtualization or software-defined networks, enterprise IT remains relatively inflexible, labor-intensive and slow to provision or configure infrastructure. In a slow-moving environment, this kind of setup was adequate because business demand could be predicted well ahead of time and sudden workload spikes were rare. However, digital disruptors and cost pressures force businesses and IT alike to move faster, placing significant strain on existing technologies and processes.  

Migrating to the cloud: up, out, or both?

A cloud-based IT operating model has been shown to offer significant advantages in terms of rapid deployment, elastic scalability, resilient operations, and security. However, large enterprises can’t simply wake up one day with all their applications running in the cloud. Thus, every enterprise’s move to the cloud is at least initially a hybrid cloud scenario, where some workloads remain on-premises and other workloads run in the cloud.

Additionally, many enterprises rely on geographically distributed compute capacity and data storage that can’t be simply centralized into a single cloud data center. For example, most retail or manufacturing businesses have a significant IT footprint in branches or plants due to latency considerations or to assure continued operations in case of a network failure. Hence, when planning an enterprise cloud migration, you can’t simply move all your infrastructure overnight, but must take a more pragmatic approach that differentiates between workloads and data more carefully.

One model that we found can help enterprises chart their cloud adoption journey delineates cloud migration along two axes—up and out.

Up the stack

One choice you can make is to move your applications up the stack. As an initial step, you can transition from running monolithic applications on dedicated servers to a Platform-as-a-Service model that deploys applications and services using containers, managed by Kubernetes or Google Kubernetes Engine (GKE). So-called serverless deployment, for example with Cloud Functions, takes it one step further with individual application functions that hide all the infrastructure underneath.

Moving up the stack has several advantages:

• Application deployment becomes automated, making it easy to add or subtract capacity as needed.
  
• Operations also become more resilient because new instances can be rapidly deployed in case of failure, allowing Platform-as-a-Service or serverless platforms to withstand a server failure without visible customer impact.
  
• Thanks to smaller deployable units, hardware can be more efficiently utilized, thus reducing run costs.
  
• Lastly, applications become more portable when they are better isolated from infrastructure details, as their containers may be deployed on a variety of infrastructures. This paves the way for a hybrid cloud scenario that provides a consistent service execution environment across the entire estate, including cloud vendors, on-prem data centers, branch locations, and remote devices.
  

On the flipside, moving up the stack requires you to fundamentally change the way in which you build applications and operate the infrastructure that supports them.

Out into the cloud

The second option is to lift, shift, and replatform existing applications largely unchanged out into the cloud, for example by moving virtual machines to Compute Engine or by replacing on-premise data archiving with cold-line Cloud Storage. Shifting workloads in the cloud can be simplified and even automated, for example by using tools like Velostrata.

Even though the applications don’t change, moving them from an existing on-premises data center to the cloud and shifting the operational model to one that’s more automated also has several advantages:

• Better economies of scale allow for more cost-efficient operations.
  
• Automated patching discipline improves security because it assures that no software with known vulnerabilities is run.
  
• Increased transparency enables more efficient IT asset management, for example by rightsizing servers or detecting and retiring unused IT assets.
  

Moving out into the cloud transforms how an enterprise operates and acquires IT infrastructure from an asset-based model to usage-based model. It’s not a black-or-white scenario, however. Similar to transforming application architectures to move ‘up’ the stack towards cloud-native systems and services architecture, moving ‘out’ to cloud can be seen as a progressive transformation toward cloud-centric operations.

• Lifting existing applications and replatforming them onto cloud infrastructure minimizes initial effort, avoiding the costs of redevelopment, and allowing an enterprise to transform its infrastructure acquisition and scaling processes while minimizing impact to existing operations models.
  
• Adjusting operations models to increase the use of automation and cloud-native tooling accelerates the overall transformation and maximizes the value from abstracted infrastructure services.
  
• Finally, decomposing application elements to take advantage of managed cloud services, such as migrating off of self-managed My SQL databases onto  provider-managed Database-as-a-Service, requires some additional effort but lays the foundation for moving beyond seeing cloud as yet another infrastructure provider.

Not only is combining up and out allowed, it’s encouraged. We think of it as a cloud-native hybrid model, where applications are deployed as containers or functions and can be easily shifted from on-premises to the cloud as needed, all while maintaining a consistent deployment, run-time, and management framework.

Plotting a migration path

There isn’t a single path to the cloud—not for individual enterprises and not even for individual applications. Sadly, inspired by the hope for simplicity, enterprises often assume that all workload migrations will follow a common trajectory. Rather, we recommend that you use a framework that encourages flexibility. The up or out framework can help an IT organization and its leadership characterize how they can best benefit from migrating their services or workloads. The framework acts as a general pattern that highlights the continuum of approaches to explore. Not all components of a single workload will follow the same path, nor should they.

Consider a few questions to ask:

• Which elements of an application or service would benefit most from an event-driven, serverless approach?
  
• Which elements of a service require rapid code releases or the ability to validate new features using A/B testing (meaning that a new version of the software is made available to a percentage of users)?
  
• Which elements change infrequently, but would benefit from automated scaling and deployment?
  

With the answers to these questions, you can begin to decompose workloads (if amenable) and map them against the up or out framework, thus presenting the organization with a pragmatic migration approach that maximizes value.

Applying the model

When a major retailer started migrating to GCP, the up or out model helped them decide which parts of their IT estate should follow which path. 

The retailer’s user-facing front end required frequent feature releases to remain ahead in a competitive retail market to gauge adoption and the user value of new features. A/B testing was needed to meet these needs, while an automated CI/CD pipeline deployed cloud-native applications to Google Kubernetes Engine (GKE), moving these applications both up the stack and out into the cloud.

The retailer’s mid-tier application processing could also benefit from refactoring and re-architecting over time, but more immediate value could be generated by shifting to an automated scale-out model and gaining operational efficiencies in the cloud. These applications were moved to Google Compute Engine.

The retailer’s back-end catalog systems change quite rarely and were hosted on well-understood and easily maintained systems. To focus their initial energy, they decided to keep these systems in place until they can replace them completely in the future.

Taking this approach allowed the retailer to minimize the time and effort required to accomplish their primary goal—rapid iteration of a customer experience that was becoming stale. They also gained operational and capital efficiencies and set themselves in a good position to migrate their catalog data to the cloud when the time and price were right for them.

Conclusion

When planning a cloud migration, plotting a path for individual workloads and architectural elements on the up or out framework helps IT decision makers focus on the benefits achieved by re-platforming, re-architecting, or a combination of the two.  It also communicates migration paths over time in an approachable manner that can be shared with a wide audience in both business and IT. It’s typical and in fact desired that different components take unique paths. Whatever the best path may be, Google Cloud Platform includes the needed products and migration tools, ranging from lift-and-shift to Compute Engine, porting applications to GKE on premises or in the cloud, or deploying cloud-native services to Cloud Functions.

Next steps

Simple but evocative frameworks like up or out can help IT decision makers navigate the inevitable complexity of a cloud migration. Like any good model, simplicity is a feature, not a bug, as it helps keep the focus on the desired outcome and is easily communicated to a variety of audiences.

Plotting the adoption paths for different parts of your IT estate is an important first step. In subsequent articles we’ll dive in a bit deeper and explore some of the technology and architecture transformations that each of these paths implies.