In the first article, we discussed the three stages of MNC (multinational company) entry into China and the process of cloud migration.
When it comes to cloud migration, there are two core issues:
1) How to better work with the business units to ensure the smooth progress of the change
2) Who will update and maintain the migrated system? What is the impact of this on the existing architecture? What changes need to be made?
In the rest of the article, we’ll discuss how to respond to each of those issues.
Think of cloud migration as a continuous learning process
Much of the cloud migration implementation process is about communication and collaboration with the business units, so having a good grasp of the context of the systems owned by the business units, and recommending migration solutions and plans based on that context, can better drive things forward.
The context of a service includes all aspects related to that service, from the language in which it is written to the way it is deployed, from the way it communicates to the libraries or services it relies on, from business importance to compliance constraints. Every metric in the service context affects the complexity and priority of the migration to some degree. Therefore, in the process of developing a migration strategy, we should not only prioritize services for migration from a macro perspective, but also look at all services from the context of the services themselves and classify them from a micro perspective to develop a service migration plan from simple to difficult, turning cloud migration into a learning process that gradually increases the confidence of both the platform team and the business team.
A cloud migration approach based on automated service classification
At Thoughtworks, we’re exploring an automated service classification approach that can help cloud migration. By collecting metrics that impact cloud migration (such as dependencies, communication method, DevOps maturity, architecture style, business criticality etc), the platform team is able to gain a panorama of the status of the system. They can treat those data as input to cluster the services that need to be migrated, pick up the easiest ones and start the migration from there. Cloud migration is then a learning process, the learnings can then feed back to the clustering method, help the platform better understand what’s next and adjust the plan accordingly.
Evolution to parallel multi-cloud architecture or portable multi-cloud architecture
What is not quite the same as cloud migration in the general sense is that the cloud migration brought about by the entry of MNCs into China will give rise to a multi-cloud environment. For most multinationals, ownership of migrated systems is a complex political topic that depends not only on Global's long-term plans, but also on the maturity of the business and IT teams in China. But in most cases, the migrated services are maintained by the Global team for a long time, upgraded and updated along with the services deployed at Global, before differentiated customization is actually implemented. During this time, the question the platform team needs to consider is how to help the business team better maintain the services deployed on the two clouds and what multi-cloud architecture strategy should be chosen.
Drawing on Gregor Hohpe's five types of multi-cloud architectures, we believe that Parallel Multi-Cloud and Portable Multi-Cloud are viable multi-cloud architectures for MNCs entering China. Parallel Multi-Cloud refers to the "develop once, deploy to multiple clouds" model, while Portable Multi-Cloud refers to applications that can be switched between multiple cloud services because they are portable enough. Compared to portable multi-cloud, parallel multi-cloud architecture is less invasive and easier to be adopted by business teams. Parallel multi-cloud can be achieved by abstracting the cloud services on which the service depends and replacing the dependent libraries in the compilation and packaging phase based on the target environment. The portable multi-cloud architecture, on the other hand, completely isolates the cloud services and relies on solutions like OAM and KubeVela to implement them, making extensive modifications to the services.
Many of the MNCs that want to enter China face challenges of one kind or another, mostly focused on compliance constraints in the early stages, product localization strategies in the mid-term, and migration and architecture as they enter the implementation phase of their product localization strategy, with a more profound impact. It is worthwhile to explore how to give professional advice from a third perspective to alleviate the pain caused by large-scale migration and service ownership battles.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.