基础设施与操作系统
Auto-scaling、Spot 实例 fleet、容器化迁移，以及适合之处的 Serverless。将 legacy Windows 和 Linux 操作系统升级到现代受支持版本。
- EKS
- ECS
- Lambda
- Auto-scaling
云计算 · 现代化改造
超越直接迁移，超越上线。
应用、数据与数据库：为云而重构，而非简单搬移。
大多数系统都是以直接迁移的方式上云的：这是最快的入场方式，也是正确的第一步。现代化改造则是把这种落地转化为真正的云优势。
Phoenix 对四个层面进行现代化改造：基础设施与操作系统、应用、数据平台和数据库。我们识别哪些保持原样仍有价值、哪些应该重塑，并按业务在每一步都能感受到收益的节奏排序，而不是只在最后才见效。
服务范围。
应用现代化
重构为云原生架构：微服务、事件驱动模式、托管集成。不是为了重构而重构，而是为了业务要求的具体成果。
- Microservices
- EventBridge
- Step Functions
数据现代化
AWS 上的数据湖与 Lakehouse：Redshift、S3、Lake Formation、Glue。在系统需要的地方集成 SAP 数据源。
- Redshift
- S3
- Glue
- Lake Formation
数据库现代化
Oracle 到 Aurora PostgreSQL、SQL Server 到 Aurora MySQL、自管到托管。许可模式要求时，迁移与重构结合进行。
- Aurora
- PostgreSQL
- DMS
- SCT
交付方法。
-
01
基线
实际运行的是什么、成本多少：使用模式、依赖关系、许可、支持义务。
-
02
排优
按业务价值、工作量和爆炸半径为现代化清单打分，与客户共同排序。
-
03
交付
迭代式交付：先交付最小的安全价值单元，反馈闭环紧凑，成果如实报告。
明确的交付物。
每个项目都交付具体的成果物，而非一堆幻灯片。
- 现代化基线与排好优先级的清单
- 目标模式的参考架构
- 按基线衡量的优先事项交付
- 现代化后系统的运行手册与培训
常见问题
应该在迁移期间还是迁移之后做现代化改造？
两种模式都可行。“先迁移后现代化”降低迁移风险，并在稳定的基础上释放云原生投资；“边迁移边现代化”适用于目标架构明确、工作负载非常适合容器或 Serverless 的情况。决策按工作负载逐个做出。
容器还是 Serverless，如何抉择？
事件驱动、波动大或真正无状态的工作负载用 Serverless（Lambda、Step Functions、API Gateway）。需要长时间运行的进程、对运行时精细控制或跨环境可移植性时用容器（ECS 或 EKS）。真实工作负载常常在同一个落地区内混合两者。
数据库层怎么办？
数据库现代化是一等公民的工作流：将经典关系型数据库迁移到托管服务（Amazon RDS、Aurora），向专用引擎重构（键值用 DynamoDB、时间序列用 Amazon Timestream、搜索用 OpenSearch），并将冷数据归档到 Amazon S3 分层存储。
你们会重平台化 SAP 工作负载吗？
SAP 自身的现代化路径是 S/4HANA 转换（棕地）或绿地重建，Phoenix 两者都交付。SAP 周边工作负载（定制 Java、.NET、批处理、集成）的云原生现代化属于本业务实践范围。
现代化改造期间如何管理业务风险？
尽可能采用 strangler-fig 式迁移：新组件与 legacy 并行运行并分流流量，直到信心确立。在既定检查点进行 Well-Architected 评审，每个部署窗口都备有 rollback 方案。
