Serverless App Engine:Application migration

Why applications are migrated to SAE?

• SAE provides multiple features, which you can use to configure, query, and manage the release process of your applications, such as flexible startup parameter configuration, visualized deployment process, graceful release and shutdown, and phased release.

• After the commercial release, SAE provides the service discovery and configuration management features. You do not need to maintain middleware, such as Eureka, ZooKeeper, and Consul.

• You can govern services in the SAE console in a centralized manner. This allows you to query the details of released and consumed services.

• SAE provides the auto scaling feature, which you can use to dynamically scale in and scale out the instances in your applications based on traffic fluctuations.

• SAE provides the advanced monitoring feature, which you can use to query the basic information of instances, microservice traces, the system call topology, and slow SQL queries.

• SAE provides the throttling and degradation feature to ensure the high availability of your Spring Cloud applications.

• SAE provides the end-to-end canary release feature that allows you to perform canary releases to test a new version on a small number of Spring Cloud applications during application iterations.

What is smooth migration?

Migration process

1. Migrate an application

   In most cases, an application to be migrated is stateless and must be migrated first.

2. Optional: Migrate a Server Load Balancer (SLB) instance or modify the domain name settings

   After the application is migrated, you must migrate the SLB instance that is bound to the application or modify the domain name settings.

   • SLB instance

     • If an SLB instance is used before migration, you can reuse the SLB instance after migration. You can select a method to bind the SLB instance to your application based on your business requirements. For more information, see Bind a CLB instance to an application, and generate a public or private IP for it.

     • If no SLB instance is used before migration, we recommend that you create an SLB instance and bind it to the ingress application such as an API gateway after migration, as shown in the preceding figure.

     • When you migrate an application, we recommend that you enable dual-registration and dual-subscription to reduce the costs of using Elastic Compute Service (ECS). If an existing ECS instance cannot be used due to specific causes (for example, the original port configured for the ECS instance is occupied), you must use the traffic-splitting migration solution and add new ECS instances. After the application is migrated, reuse the existing SLB instance or create an SLB instance and bind it to the migrated application based on your business requirements.

   • Domain name

     • If an SLB instance can be reused after migration, you do not need to modify the domain name.

     • If you want to create an SLB instance and bind it to the migrated application, you must add a new SLB instance to the domain name settings. For more information, see Update DNS servers. You also must delete the SLB instance that is no longer required.

3. Optional: Migrate storage and message queues

   • If your application is deployed on Alibaba Cloud and uses Alibaba Cloud services, such as ApsaraDB RDS and Message Queue, you do not need to migrate storage or message queues.

   • If your application is not deployed on Alibaba Cloud, join the DingTalk group (ID: 32874633) to obtain technical support.

Migration solutions

You can use one of the following solutions to migrate applications: traffic-splitting, and dual-registration and dual-subscription. Both solutions ensure smooth application migration without business interruption. This section describes the dual-registration and dual-subscription migration solution.

• Traffic-splitting

  Use Dubbo to switch the original service registry to SAE Config Server, develop a new set of applications, and then deploy the applications on SAE. Then, use SLB and configure domain names to switch traffic.

  For information about the application development of the traffic-splitting migration solution, see Introduction to microservice scenarios.

• Dual-registration and dual-subscription

  The dual-registration and dual-subscription solution refers to access the original service registry and the SAE service registry during migration. This ensures that migrated applications and non-migrated applications call each other.

  The following figure shows the architecture of the dual-registration and dual-subscription migration solution.

  

  The dual-registration and dual-subscription migration solution provides the following benefits:

  • Migrated applications and non-migrated applications can discover and call each other. This ensures business continuity.

  • You need only to add dependencies and modify a small amount of code to implement dual-registration and dual-subscription.

  • You can view the details of consumer service calls and view the migration progress in real time.

  • You can dynamically modify the policies of service registration and subscription without the need to repeatedly restart applications. You need to restart applications only once in the migration process.

References

For more information about how to migrate microservices applications in different architectures, see the following topics:

• Smoothly migrate Spring Cloud applications to SAE

• Smoothly migrate Dubbo applications to SAE