第9章 没错，大型机也可以迁移至云端

最初发布于2017年1月9日：http://amzn.to/migrate-mainframe-to-cloud

对于不少规模可观且运营良好的企业而言，大型机通常被视为一大阻碍或者拖慢云迁移的制约性因素。很多企业感到自己没有具备大型机迁移技术与经验的人才，而原有大型机技术人员则显然对云迁移工作缺乏动力（但我认为您已经拥有了自己需要的人才，详见第15章）。诚然，并不存在能够轻松将大型机应用程序直接迁移至云端并现代化的百试百灵的解决方案，但我们仍然可以通过多种合理方法运用各类迁移策略（详见第6章）。为了解决这个问题，下面是AWS公司的Erik Farr——他去年曾与Infosys公司合作开展AWS大型机现代化实践工作。

在Stephen最近发布的大规模迁移系列博文中（第4～9章），他经常会谈到应该将云迁移工作根据实际复杂度水平划分成一段频谱。在这一频谱内，他将采用虚拟化、面向服务型架构的工作负载视为低复杂性一端，而将整体式大型机视为高复杂性一端。这样做当然是有理由的：大型机几十年以来一直与组织密切契合，且通常运行有具有特定性能与安全要求的任务关键型工作负载，甚至直接决定着企业业务能否顺利运作。在与客户讨论整体IT环境与云迁移策略时，他们通常倾向于跳过大型机工作负载将其划入“以后再说”类别。然而，对于那些有重要原因放弃大型机或者开始处理遗留问题的企业而言，已经是时候认真考虑大型机的迁移工作了。

我曾有幸与AWS的优秀合作伙伴Infosys合作，以AWS代表的身份帮助其进行大型机迁移。这段经历让我对这类任务拥有更深刻的理解。该公司几十年来在大型机现代化领域一直扮演着领导者角色，而如今开始将这些经验扩展至大型机工作负载迁移领域，希望借此建立起新的核心竞争力。利用其知识管理平台（Ki），他们得以分析客户的大型机代码以了解其中确切运行有哪些工作负载。

整个过程的结果一般在6周之内即可显现，我们此后会借此帮助客户建立商业案例，并最终制定出完整的大型机迁移路线图。

在实践过程中，我们发现客户主要采用3种大型机迁移方法——工作负载重新托管、批量迁移与完全重新设计。每一种方法都有着自己的优势与短板，客户则根据自身风险承受能力、商业案例以及整体云战略做出选择。以下是对这些迁移方法的简要分析：

重新托管

重新托管解决方案利用大型机模拟器（包括Micro Focus Enterprise Server、TMaxSoft OpenFrame以及Oracle Tuxedo ART）在基于x86-64架构的Amazon EC2实例上运行大型机应用程序。从最终用户的角度来看，这种迁移拥有无缝化特性，且不需要对3270 Screens Web Cobol、JCL以及DB2等标准大型机技术做出更改。这种方法中通常涉及一定的平台更新元素，例如将版本陈旧或者难以维护的数据库迁移至更新的RDMBS引擎或者托管在Amazon RDS之上。

批量作业迁移

批量作业在大型机应用程序组合中占据着相当可观的比例。虽然其中一部分属于关键性业务，但大多数批量作业的商业价值很低且消耗大量MIPS。无论基于文件还是属于近实时进程，将这些高强度工作负载迁移至AWS云都能帮助客户从现有数据中获取大量洞见，同时降低现有大型机的MIPS消耗水平。

重新设计

当现有大型机应用程序无法继续满足未来业务需求或者敏捷架构目标时，建议您采用重新设计方法。这种方法能够构建起具备相似性能，但功能相同或者有所增强的新型应用程序。一般来说，需要利用云原生技术进行重新设计，同时充分利用微服务（Amazon API Gateway、AWS Lambda）、容器与解耦（Amazon EC2 Container Service、Docker容器、Amazon Simple Queueing Service）以及数据分析、人工智能与机器学习（Amazon EMR、Infosys Mana for AI或者Amazon Machine Learning）等技术成果。

无论具体采用哪种方法，企业都应该在云迁移策略中充分考虑大型机工作负载的存在与迁移可能性。这不仅能够显著节约成本，同时亦可提高敏捷性并带来面向未来需求的可靠架构。关于大型机迁移以及AWS与Infosys相关服务的更多细节信息，请参阅我的同事Sanjeet Sahay、Tom Laszewski以及我本人与Infosys合作撰写的《大型机AWS迁移白皮书》。