Application migration

If your applications are deployed in a production environment and run as expected, you can migrate them to Serverless App Engine (SAE) to ensure business continuity and prevent data loss.

Why migrate to SAE?

SAE reduces infrastructure overhead so your team can focus on application development. After migration, you get:

Flexible deployment controls: startup parameter configuration, a visualized deployment process, graceful release and shutdown, and phased release.
After the commercial release, built-in service discovery and configuration management, replacing self-managed middleware such as Eureka, ZooKeeper, and Consul.
Centralized service governance: query details of released and consumed services from the SAE console.
Auto scaling: dynamically scale instances in or out based on traffic fluctuations.
Advanced monitoring: view instance metrics, microservice traces, system call topology, and slow SQL queries.
Throttling and degradation: maintain high availability for Spring Cloud applications under load.
End-to-end canary release: roll out new versions to a subset of Spring Cloud applications before a full release.

What is smooth migration?

Smooth migration lets you move a live Spring Cloud cluster to SAE without taking the system offline. If you want to migrate the cluster to SAE to access all SAE features, you can use the smooth migration method to ensure business continuity.

Note

If your Spring Cloud cluster is not in a production environment, or if downtime during migration is acceptable, you can build and deploy applications directly on SAE instead. See:

Spring Cloud applications: Use Spring Cloud to develop microservice applications and deploy them on SAE
Dubbo applications: Host Dubbo applications to SAE

Migration process

Migrate applications

Start with the applications themselves — most are stateless and must be migrated first.
Optional: Migrate the Server Load Balancer (SLB) instance or update domain name settings

After the applications are migrated, update the SLB instance binding or domain name settings to route traffic to the new environment.
- SLB instance
  - If an SLB instance was in use before migration, you can reuse it after migration. Choose a binding method based on your requirements. For more information, see Bind a CLB instance for public or private access.
  - If no SLB instance was in use before migration, create one and bind it to the ingress application (such as an API gateway) after migration.
  - When migrating, enable dual-registration and dual-subscription to reduce Elastic Compute Service (ECS) costs. If an existing ECS instance cannot be reused (for example, because its original port is occupied), use the traffic-splitting migration solution and add new ECS instances. After migration, reuse the existing SLB instance or create a new one and bind it to the migrated application.
- Domain name
  - If the SLB instance is reused, no domain name changes are needed.
  - If a new SLB instance is created, add it to the domain name settings and remove the old one. For more information, see Modify DNS servers.
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, no storage or message queue migration is required.
- If your application is not on Alibaba Cloud, join the DingTalk group (ID: 32874633) for technical support.

Migration solutions

SAE supports two migration solutions: traffic splitting and dual-registration and dual-subscription. Both keep applications running throughout the migration.

Traffic splitting

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

For application development steps for the traffic splitting solution, see Introduction to microservice scenarios.
Dual-registration and dual-subscription

With dual-registration and dual-subscription, applications register with and subscribe to both the original service registry and the SAE service registry simultaneously. This lets migrated and non-migrated applications discover and call each other throughout the migration window.

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

Key benefits of dual-registration and dual-subscription:
- Migrated and non-migrated applications can discover and call each other, maintaining business continuity.
- Only a small dependency addition and minimal code changes are required.
- View consumer service call details and track migration progress in real time.
- Adjust service registration and subscription policies dynamically without repeated application restarts. A single restart is all that is needed during the entire migration.

References

For migration guides specific to different microservice architectures, see: