This paper attempts to answer two questions:
- Clients running on other cloud platforms (such as Ali cloud) applications, how to move to the cloud Huawei, how to assess the feasibility and workload relocation, what specific programs are and what advantages and disadvantages.
- For customers concerned about "how to avoid being cloud vendors" Binding concerns, customers should choose how to better technology infrastructure to deal with.
Answer these two questions is not easy, considering "cloud native", "micro-services" new concept of time, not just a technology-oriented issues, but also to adjust the business, organizational and management aspects. This paper will reduce the problem to the technical aspects. On a legacy transformation, can also draw on cloudy architecture floor plan , carried out step by step.
1 Part I: Migration and middleware platform
Deployment model assumes that the customer's application system is as follows:
The deployment diagram shows the dependencies for the client application platform. Without changing the client application, we first need to collect customers' platform dependent components. In general, if the Huawei cloud provides a corresponding function, then the Huawei cloud migration is feasible, workload migration requires detailed analysis based on actual components depend on the specific situation and dependence, do a simple decomposition below for different situations.
· Reliance on development / operation and maintenance of the platform. This is partially dependent applications are generally irrelevant and can be used without modifying any business logic. Note, however, different cloud vendors, the ability to provide a collection of different, not the same interface operating experience. From one cloud vendor to migrate to another cloud vendor needs to consider the impact of changes in the way the operation and maintenance of customer operation and maintenance personnel to bring.
· Reliance on middleware. This depends in part on the development and application of a strong correlation, the application needs to select the appropriate client / middleware and components interact. Some Middleware is the industry standard, such as relational databases, can be accessed through JDBC drivers, these migrations standard middleware, the average user does not need to modify their applications. Some middleware is not an industry standard, such as object storage, different cloud vendors provide the client interface is not the same, customers need to modify their different applications, adaptation cloud vendors. For middleware dependent transformation effort, to a large extent depends on the customer application development and design time, whether to adopt a rational design patterns to shield the differences middleware, well-designed system, usually only need to develop new adapter, overall the transformation of the workload is manageable.
· Dependence on the field of application. This piece features the industry generally not standardized, different cloud vendors, these functions can be accessed via an external ability to open the way. That can also visit Huawei cloud Ali cloud function, or a function of a variety of possible providers, such as payment services, Ali cloud, cloud Tencent, Huawei's cloud can provide, the user can choose a provider. And non-standardized middleware, like, switch to a new provider, the need to develop new adapter to use the new supplier capabilities.
· Underlying virtual machines, containers, and IaaS layer of the network, computing, storage, industry generally standardized, and migration in different cloud vendors is relatively simple, usually do not need to make changes to the client application. But some special scenes, still need to consider whether the corresponding manufacturers to provide appropriate technical support, such as a dedicated image processor for the big game need. Infrastructure from different vendors differences in reliability, performance, should be considered as a factor in business.
As it can be seen from the above analysis, if the customer is bound to worry about cloud vendors, then during the time of the selection of technology, consider the following factors:
• Select middleware services provide a standard interface. Such as the use of relational databases support JDBC, JMS supports open standards messaging services. Or when developing code, to design a suitable interface to access the middleware adapter mode, users develop different adaptive interface for different cloud vendors.
Consider the availability of the selected function in the market, do not use the cloud vendor unique features as possible. From a business perspective, you can choose the unique characteristics of the cloud vendors to improve product competitiveness. Availability can ensure that when the supplier can not continue to provide unique functionality when business continuity development.
Can also be seen from the above analysis, in the pursuit of customers' characteristics using the most competitive and reduce the workload, "" minimize the cloud vendor lock-in "with these two requirements are contradictory existence. In general, use of the unique characteristics of cloud vendors, customers can reduce development effort and use of the latest and most competitive properties, while enhancing cloud vendors and binding relationship, it is difficult to migrate to other cloud vendors. Corresponding customers achieve their own middleware and business services sector needs to reduce dependence corresponding platform middleware and field services, so customers more easily migrate applications between different cloud vendors, customers also means the development effort and higher technical difficulty.
In any case, the customer's system is well-designed interface reserved for the difference, and make a backup selection key technologies, enabling customers to have a more flexible application systems migration space.
2 The second part: micro-services development framework for migration
Next we need in-depth customer applications, application migration and transformation to explore, analyze workload and binding relationship development framework migration. This aspect of migration with respect to the migration service platform layer, the more difficult to assess and difficult, often require more in-depth exchanges and developers. Similarly, we can reduce the problem to such a technical framework on migration issues, such as the transformation of Dubbo CSE framework, Spring Boot transformed into CSE framework.
Whether you need to migrate 2.1
Prior to assess the feasibility and workload migration, first to answer the question of whether you want to migrate, migrate to the question of which of the frame.
Where migrate to?
· Openness micro-services development framework. First to see if there is a corresponding micro-services development framework open source version. On the one hand the use of open source version can learn from the community, but also to grasp the details by reading the source code, we can more easily be flexibly customized to fit future needs. Then see if micro-technology services development framework is closed, the ability to easily integrate with other open source components developed in this framework, such as the common database access components mybatic, hibernate, spring data such as, for example, whether you can use Spring features, whether you can use Spring Boot, Web technology. Finally, look at the micro-service development framework support for popular industry standards such as micro-services popular use REST communication, it supports HTTP / HTTP2, supports JAX-RS, Spring MVC and other popular interface development rules REST, whether to support the use of RPC way access the REST interface.
· Support micro "cloud native" area. Understand the "cloud native" in terms of micro-services, in essence, is to answer the subsequent use of the micro-services framework, whether to focus on the development of business codes, without the need to consider a variety of issues, "micro-services" of the future brings, such as multi examples of when the service discovery, load balancing, micro service instance fails when isolation and retry, micro-service failures and bound (by calling chain) and location (such as overtime) and other micro-services operation and maintenance problems. Many micro-services framework only provides the functionality modules and tools "How to solve these problems", but does not help users solve these problems. Because in planning their own applications when users do not know what the problem is, when running on-line business, slowly surfaced, user-time to solve these problems cost is usually very high.
Why migrate?
Migrate to where part of the answer why the migration, but these indicators are still not as migration based on. Why or to migrate back to the original business goals up, such as the cost and problems of the existing framework, the future development of the business need to select a more appropriate technology (such as whether to choose containers and micro-fast delivery and services to meet subscriber growth with to challenge), and so on.
2.2 workload and feasibility assessment
A business need to develop a framework for the development frame into another time, is generally desirable to keep the existing business logic, while the frame discard operation. Ideally, the business logic code is intact, without any modifications, a smooth switching over operation, such as the service code war package, switching from Jetty Tomcat container to container.
Application to war, for example, can look at the war dependencies between applications and containers:
Adopt a framework, there must be a place to interact and function framework, where the content is the main part of the service release. Because Tomcat and Jetty container vessel service release are support-related protocols and specifications, so business code can be migrated completely smooth.
For other business code portions, such as process flow, data access, consider the target system supports running these components, if supported, it does not involve modifying the code, you can smooth migration.
If the service code corresponding to the container using a tool provided by the API, then migrate to the scene as Tomcat container Jetty container may also require changes to the code, the switching operations becomes smooth.
当出现目标框架不支持运行依赖的组件，或者服务发布方式没有对等的功能、或者工具API没有对等的API支持的时候，这种切换就会变得不可行。当然实际在选型分析的时候，非常难把握一些细节的不支持情况，不过倒不用悲观，实现一个业务逻辑的方式是有多种可能性的，换一种实现思路去调整实现逻辑，也能够解决单纯从技术上看，无法对等改造的问题。
2.2.1 工作量评估
从上面以war应用在不同运行容器之间的改造可以看出，一个框架改造为另外一个框架的工作量可以从两个维度进行评估：
1. 改造前的业务代码依赖于原来框架/运行时的程度。
2. 目标框架本身对于业务代码采用的技术的支持程度。
再看一下上面例子中，CSE框架的情况。
可以看到，和war应用对比，除了运行时的变化，服务发布的方式变化了，提供的工具API也变化了。 将war应用切换为CSE的工作量主要包含两部分：
1. 将服务发布方式修改为CSE的服务发布方式，即将Servlet定义修改为Spring MVC或者JAX RS或者RPC的方式。
2. 调用工具API的地方，需要分析CSE SDK是否有对等的替换方案，使用CSE SDK提供的API进行修改。
下面表格结合上面的分析，简单的评估了一下各个框架切换CSE的难度对比。这个难易程度只是近似的评估，主要考察可能的改动点多少。工作量的评估的一个很重要要素是原来业务系统本身在处理平台依赖上的成熟度（依赖的多少和程度），这个工作量不再这里评估，尽管这个可能是导致工作量最重要的因素。
上表的难易程度只是近似的估算，没有对应的数据支撑，侧重于服务发布方式之间进行调整适配的工作量，更细粒度来讲，就是数据类型支持方面改造的工作量，仅供参考。正如上面分析的，业务改造的工作量更多的来源于原来业务系统本身的耦合程度。
2.3 对开发者的建议
在上面的难易度评估矩阵中，有一个协议gRPC需要特别提到一下。在所有的框架中，将代码切换到gRPC，都是最难的，但是将gRPC切换为其他框架，都是最容易的。一般的，如果一个框架满足如下特征：
1. 更加贴近业务代码的书写形式，比如采用RPC的方式对外发布服务；
2. 更多的跨语言方面约束；
3. 更少的平台API
那么其他框架改造为这个框架会更加难，但是这个框架改造为其他框架更加容易。因为1，在切换为其他框架的时候，只需要将接口以其他框架的形式包装一次，不涉及任何代码修改；因为2，可以适配更多的接口约束和更多的序列化方式，支持的框架更多；因为3，不涉及平台API的整改和对等切换。
很多业务都会考虑对于平台绑定的问题，特别是那种需要长期发展的业务。因为平台技术日新月异，变化的场景驱动业务采用更加先进的架构技术改善业务的运行状况，比如JAVA技术的从Osgi到J2EE到WEB到微服务架构。那么业务如何去适应这个变化了？上面3个特性实际上给了一个指引。另外就是还需要加上：
4. 尽可能符合标准协议的约束。
这条规则和构造WEB应用时该选用那些功能一样的。在书写HTML的时候，尽可能的遵循HTML4、HTML5规范，能够让网站在更多的浏览器上精彩的呈现。
更好演进的另外一个方面，就是把使用的技术限制在能够跨平台的范围内。这块无疑会增加开发者的成本，需要学习更多的规范和培养更好的编码技能。有些业务场景，还必须使用平台特性去解决。这些复杂性都不会让我们的代码完美，总是在一个权衡和妥协中发展。
下面提供了一个代码设计方面的模式，这种模式解决了发布形式的切换问题。业务代码按照这样的模式进行组织，并且在接口定义上尽可能考虑跨语言数据结构（主要指数据类型），那么这种业务代码在配套平台升级的时候，将会是最快速的。
逻辑结构：
代码示例：
在CSE给的[项目例子中]( https://github.com/apache/servicecomb-samples/tree/master/porter_lightweight)， 采用Spring进行了接口和实现分离的代码结构，这种代码结构实现的代码，迁移到CSE、Dubbo、Spring Cloud、gRPC等框架的时候，只需要修改Endpoint层的定义，而不需要修改任何实现逻辑。因此建议开发者按照这种代码风格组织代码，从而更加方便的切换框架。但是开发者需要注意，历史遗留系统很多不是按照这个方式组织代码的，那么历史遗留代码的重构的工作量，很大程度上决定了改造的工作量。
5. 尽可能选择开源的微服务开发SDK。
选择开源的SDK的好处是即使商业公司不提供SDK的开发支持，或者成本很高的时候，可以通过开源社区或者自行编译源码，去适配其他的中间件，从而让业务能够在不同的技术组合下运行起来。
2.4 总结
结合上面的观点，所有框架不会在各种方面都是完美的，CSE SDK在灵活性方面的折中做得非常的出色，CSE的SDK也通过ServiceComb项目进行了开源，并且代码是同源的。CSE通过提供业务代码的书写习惯支持大大减少了切换为CSE的工作量，同时后续如果将CSE迁移到其他框架，相对来讲也是非常容易的。可以通过ServiceComb的开放性设计，了解CSE SDK的设计思路。同时客户也应该认识到，应用系统进行良好的抽象设计，能够更好的适配不同的平台和开发框架，客户应该在平台能够提供的价值服务和绑定关系方面做出权衡取舍，以最优的方式选择适当的平台服务。单纯从技术上来讲，平台绑定的担忧很多时候是应用系统本身架构和代码质量的一个侧面反映。
作者：liubao68