Source: Enterprise IT can move up or out (or both) from Google Cloud
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.
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.
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.
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:
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.
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:
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.
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.
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:
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.
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.
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.
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.