Run a transformed supply chain–see how at Google’s Digital Supply Chain summit
March 25, 2021
Check, please! Billing in Cloud Storage
March 25, 2021
When helping customers plan large-scale migrations of applications to the cloud, we here on the Professional Services team sometimes observe them pouring countless hours into the top-down evaluation of their application estate and categorizing them into discrete migration strategies like “rehost”, “replatform”, “refactor” and so on. It’s a well1 established2 industry3 practice4 in which the only open point for debate, it seems, is whether there are 5, 6, 7 or 8 distinct “R’s”.
In practice, the popular “R” migration strategies aren’t really strategies at all–they’re placeholders for all the things you don’t yet know about your applications. We find that an IT organization’s policies and capabilities do more to determine the migration path than anything else and ultimately override any architect’s prior top-down planning.
What’s more, almost no application falls squarely into any one of the migration strategies across all of its layers. The database might get replatformed from self-hosted PostgreSQL to managed Cloud SQL while the application layer might get rehosted as the same VM on Compute Engine, while the load balancer might get replaced with Google’s Global Load Balancer.
What most organizations usually need is a more holistic approach to migration. That’s why when our Professional Services teams engage with customers, we pay little attention to these semantics. In this early planning stage we’re more interested in people and processes before we focus on the technology. First, we may recommend you consider the Google Cloud Adoption Framework, and determine whether your cloud migration needs to be tactical, strategic or transformational. Then, armed with that insight, it’s time to consider three fundamental migration approaches:
Migration factory
The migration factory approach, in which we laterally copy or deploy virtual machines or containers in bulk, works well if the applications are simple and similar enough and if the team handling the migration can execute it autonomously without needing to coordinate much with individual application teams. This scaled approach is well suited for initiatives that are infrastructure-led rather than application-led, in particular wholesale data center exits, and can be expedited with solutions like Google Cloud VMware Engine or specialized tools like Migrate for Compute Engine or our Database Migration Service.
By the same token, the migration factory approach doesn’t lend itself well to a change management process (through internal policy or external regulation) in which each application must individually undergo a manual review. The effort of reviewing and controlling for the inevitable changes outweighs the time saved from the automated migration of the code and data itself. The same is true if you need to make material changes to your CI/CD tool chain before you can deploy to your cloud environment. And once you factor in the change process, the commercial case for an as-is migration to the cloud becomes less compelling.
In summary, there are some specific scenarios in which the migration factory approach is the best option, but there are many other scenarios that don’t meet the criteria.
Greenfield software development
At the other extreme of a migration factory approach, there’s the option not to migrate an existing application at all, but rather to develop a new “greenfield” or “cloud-native” application instead. This approach essentially follows textbook agile software development practices. While there is nothing specific to the cloud about this approach, the cloud’s managed and serverless services lend themselves particularly well to accelerating the development of such a software solution.
A newly developed application must be treated as a product and not as a project, meaning the team does not abandon its work after the last milestone has been reached. Rather, it remains dedicated to the application and continuously refines and expands its functionality in perpetuity (or until the application is deprecated). In this regard, the approach is fundamentally different from any kind of migration. There are no predetermined schedules and the architect does not unilaterally dictate requirements–there are only sprints of incrementally feature rich, usable software. The team tasked with developing the application must be small, cross-functional and long-lived. It also takes considerably more time to develop a new application than to migrate an existing one.
Modernization factory
The majority of migrations that we see our customers engage in involve some degree of modernization on an application by application basis.
Software modernization falls on a wide spectrum, involving a multitude of independent tactics and best practices to improve the scalability, availability, security and durability of the application itself while also reducing the amount of toil in deploying and operating the application.
It’s through these incremental modernizations that customers usually realize their true TCO savings–and it’s also the reason why improving their DevOps capabilities naturally goes hand in hand with cloud adoption. In the cloud, because everything is an API, everything can be automated.
For example, provisioning consistent project environments with the help of infrastructure as code can constitute a noteworthy modernization. Decoupling state from stateless logic can have great scaling benefits. Removing shell access from all servers and allowing only for changes to be pushed through a CI/CD pipeline can be a game changer for your security posture. There are a hundred more examples of incremental software modernizations and none of them squarely fit into a migration strategy “R”.
