|
这段时间除了德州停电把 Sabre 总部搞得够呛以外，在美国航旅 IT 领域最大的新闻莫过于 IBM 在航空领域又攻下一城：继老客户美国航空公司（American Airlines）之后，IBM 又签下了达美航空公司（Delta Air Lines）的实施合约，将会承揽达美的全面 PaaS 化转型。 值得留意的是，这一次签约的团队不是和美国航空签约的 IBM Cloud 团队，而是和 IBM 在 2020 年收购而来的 Red Hat OpenShift 团队，严格来说是 Red Hat 的生意。 这也是首次有大型航空公司全面使用 PaaS 类解决方案。整个签约过程历时三年有余：自 2017 年四季度开始，达美和 Red Hat 密切合作，为既有系统设计了完整的 PaaS 化方案。 笔者有国内从业朋友问到 OpenShift 在航空业是如何应用的。笔者公司大规模使用 OpenShift 作为架构，因此（以请老朋友一顿饭的代价）和 Red Hat 航空业务首席架构师（也是全美唯一一个同时为四大航写过软件的团队）就这个问题进行了深入的交流，并总结了一篇文章供国内同行参考。 这篇文章将分为几个部分：我们先从 Red Hat 的哲学讲起。 Red Hat 的有趣之处在笔者看来，Red Hat 是 IT 江湖内一家非常特别的公司，其主营业务是技术支持服务——这当然是一句玩笑话。但是，Red Hat 作为成功将 GNU/Linux 生态引入大型企业运营的功臣，通过解决一系列问题，获得了今天的行业地位。 熟悉企业 IT 的同行可能知道，五十年前的大型企业的 IT 架构往往以大型计算机（MainFrame） + 终端（Console）为绝对主力。这种架构一直延续至今，以 IBM/z 架构继续活跃在世间。在这种大型计算机上，运行着包括初代 Sabre 在内的航司 IT 架构。事实上，著名的 Sabre 系统是 IBM 大型机的最初几个应用，而美国航空也是第一批采用 IBM 大型机的公司（这里面的故事非常有趣——这一单生意是在美国航空的航班上成交的）。 但是大型机架构有一个问题，投资太大了。 在大型机刚刚面世的年代，像美国航空、达美航空这样业务稳定的航空公司在进行「数字化转型」时使用大型机可谓得心应手——它们本身具有巨大的业务量，通过大型机辅助处理可以大大提高生产力，降低单位顾客销售成本。 但对于开发新业务的时候，这个事情就不太好了——新业务、新应用一开始就投入大量资金买计算机的话，门槛很高，不利于快速试探市场。因此，企业在开发新业务的时候，需要「更小的计算机」——从 60 年代基于 IBM System 3x0 的大型机到 80 年代基于 UNIX 的小型机，再到 90 年代的微型机。 每一代转变往往都会带来一些新的从业者——Microsoft 和 Red Hat 就是在微型机时代成长起来的。Microsoft 最早的的微型机操作系统解决方案 Windows NT 3.1 Advanced Server（00 年成为 Windows Server）在 1993 年发布，而 Red Hat 则在 1995 年成立，并发布自己的发行版 Red Hat Linux（02 年成为 Red Hat Enterprise Linux）。 对大型企业而言，Red Hat Linux 相比 Windows Server 有两个优点： 第一是 RHL 基于的 Linux 内核原生兼容大部分按照 POSIX 标准实现的 UNIX 工具。相对底层 API 和 UNIX 完全不同，需要以子系统实现 POSIX 的 Windows 而言，原生兼容 POSIX 的 Linux 是移植原小型机应用软件的更好的选择。大部分小型机应用软件，可以平滑迁移到 Linux 这一点，为 Red Hat 的成功奠定了基础。 同时，Red Hat 通过招募开源人才和收费技术支持解决了开源代码的可靠性问题，这是第二个优点。开源软件长期存在着「谁为代码的 bug 负责」的问题——大部分开源代码的许可证文档里都明确说明「代码贡献者不负责」，因此总得找个人来负责才行。Red Hat 通过「订阅制」解决了这个问题——对技术支持按年收费。 这种「软件本体免费，增值服务收费」模式打开了 Linux 在企业界应用的局面，也奠定了 Linux 在企业界的信任。 00 年代的互联网世界——私有集群90 年代 Windows 和 Linux 的服务器软件生态，以服务内部网为主——终端机拉专线到中央服务器进行处理。这个时候的终端机数量始终有限——以航空公司的销售系统为例，全世界的旅行社满打满算也没多少家，很容易就能通过 SABRE 完成接入。 但是 00 年开始进入了互联网时代，企业接入的终端数量大幅度增长——随之而来的是企业购置了越来越多的服务器组成集群处理业务。 这种集群架构带来了一个新问题——服务器就像交响乐团一样，需要一个指挥——中间件（Middleware）应运而生，开始协调底层服务器组合共同进行服务。一个通俗的解释是使用银行支行做例子：
随着中间件的发展，使用集群处理业务变得可能。在妥善处理 ACID 的情况下，业务需求可以分散在多数据库、多后台处理。例如，马云和马化腾可以同时在自己的银行账户内进行存取款（需要将新的余额写入数据库）而不会干扰到对方钱包余额；北京-上海航班的订座和北京-广州航班的订座（也需要写入数据库）也同样互不冲突。 Red Hat 在中间件领域的造诣主要是处理 Web 请求的 JBoss 系统。这套系统相信国内同行用起来也是轻车熟路，在此不赘述。 容器化带来的 aaS 抽象对于航空公司（以及其它很多企业来说），对公网服务的服务器具有两个特征：
因此，将服务器抽象化为计算资源对这些企业而言是最好的选择。从 2006 年的 AWS 开始，云服务迅速席卷企业 IT 行业。 云服务由于通过将传统的「购买产品」变成「订阅服务」，产生了一系列的 xaaS (x as a service，x 即服务) 生态。常见的 xaaS 生态有 Infrastructure、Platform、Software (例如存储和数据库，以及人工智能等应用软件) 以及 Function。各种云都会同时提供这四种 SaaS，在此不再赘述。 aaS 抽象带来的隐忧——不信任公有云提供商aaS 模式和私有服务器集群最大的不同，在于客户失去了对服务器的物理控制权（物理控制权在「房东」身上）。这会对其上存储的关键信息——带来三个可能的问题： 首先是「我的信息会不会存着存着就被房东有意无意知道了」。这个问题在业界称为保密性（Confidentiality）——信息不被非授权人士获得的能力。保密性问题一般最好解决——先对保存在云端的数据进行加密，并通过身份认证和访问控制机制管理加密密钥，就可以达到限制访问保密信息的目的。 其次的问题是「我的信息会不会存着存着就被「房东」有意无意丢了一部分」。这个问题叫做完整性（Integrity）——信息在传输、存储过程中不丢失。完整性问题一般也好解决——大部分云服务提供商都有「n 个 9」的服务水平保证——这种服务保证一般通过备份和冗余处理。 再次是可用性（Availability）：如果我下一年不和「房东」续约，「房东」会不会不让我拿走数据？或者，会不会「房东」允许，但是「房东的房东」（监管部门）不允许？这个问题就相当棘手了——如果盲目依赖单一供应商，可能就会进入这样的窘境。 这三个问题往往最为棘手，因此很多大型企业或者对数据可控性有要求的企业，会选择同时和多家公有云企业签约。而这个时候，一个问题就会浮出水面——不同的公有云企业的设计逻辑、硬件选型等可能完全不同。 换言之——业务上云的最大障碍在于避免和单一云供应商的绑定：这对业务企业而言可能是致命的。 因此，一种名为「混合云」的模式出现了：既保留一部分自有服务器集群，又采购公有云的云服务（公私混合云），或者同时采购多家公有云的云服务（公公混合云）。不少公有云厂商都意识到了这一需求，推出了包括 AWS Direct Connect、Azure ExpressRoute 的服务，改善私有云连接到自家公有云的网络速度。但是，这并不能打消企业的疑虑。 Red Hat 的超脱地位那么，在哪里找一家能够避免和单一供应商绑定（在各供应商的系统上都能很好的运行），同时对你的数据又没有兴趣的供应商呢？可以知道的是，这个供应商需要满足这样的条件：
Red Hat 完美满足这两个条件——RHEL 的立足点是中立而超然的技术提供商，在大型企业客户中很有口碑。对几乎所有云提供商而言，RHEL 都是大型企业客户指名道姓需要的操作系统。包括 AWS、Azure、阿里云、谷歌云都保证自身基础设施和 RHEL 架构的兼容性。 因此，Red Hat 在 2011 年搞出了 OpenShift 这个 PaaS 平台。OpenShift 既是 Red Hat 的公有 PaaS 平台，也可以部署在任意一台运行 RHEL 的计算机上，承载以容器为基本单位的负载。这种架构使得 OpenShift 原生具备混合云能力。 换言之，使用 OpenShift 相当于使用公有云提供商的 IaaS 服务（虚拟机），并在上面搭建企业具有控制权的 OpenShift，让 OpenShift 为企业客户处理刚刚的三大难题：
另一方面，Red Hat 本身在 Linux 上的造诣，使得 OpenShift 本身也是个体验非常优秀的 PaaS 平台。因此，OpenShift 迅速在市场扩展，成为了混合云业务的领先者（市占率超过四成）。即使是 AWS 这样的大厂，也需要为客户提供 OpenShift 作为选项，而非一味推荐自家的 Elastic Beanstalk。 （真是有什么样的需求，就有什么样的产品） 中国的云服务商没有为大型企业的挑战做好准备笔者最后实在有几句话要讲。 航空公司作为最早使用 IT 服务的大型企业客户，对 IT 服务提供商的技术能力和产品能力都提出了极高的要求。从「双 Smith」时代开始，IBM、NEC、AWS 以及今天的主角 Red Hat 等 IT 企业就谦逊地面对航空公司等大型客户，切实地面向业务痛点勤勤恳恳地进行改进。 笔者刚刚从业这一行的时候，在东京和 NEC、AWS、Red Hat 的工程师一起为客户写软件。虽然笔者当时有着尚可的理论功底，但「事非做过不知难」，在实际应用中还是承蒙了这些老工程师的关照。而客户的产品经理中，也有对业务极为了解，一针见血地指出问题的高手。 然而，与国外 IT 服务商从大型企业开始不同，中国的云服务商都是从中小企业开始。最明显的特征是，国外 IT 服务商在 yum 系提供的选择是 RHEL，而国内云服务商在 yum 系提供的是 CentOS（RHEL 的社区复刻免费版本）。 这种面向中小企业开局的特点使得中国的云服务商往往居高临下地以传教士般的话语向客户灌输自身的「观点」。这种洗脑式销售当然对中小企业很适合——云对中小企业就是信息化「从 0 到 1」，有就比没有好；但是航空公司不少有强健的自有系统，「买家比卖家还懂」，那这一套洗脑式销售——忽悠谁呢？ 同时，洗脑式销售带来的恶果还包括无视客户的业务需求，「为了卖系统而卖系统」、「销售和交付分离」、「层层转包，坑完客户坑转包商」等现象，导致云服务商在航空公司为代表的超大客户处纷纷翻车——华北华东华南西南、哪家机场哪家航司敢说自己没在云业务上经历过「仆街」？著名「负面教材」包括
一朝被蛇咬，十年怕井绳，这种「仆街」经历令得中国各航空公司早已对「云」心生芥蒂——谁敢用这种「管杀不管埋」的系统？还是自己负责服务器管理为好（无奈）。 好了，吐槽结束了。在下一篇中，我们将介绍 Red Hat 是如何用四年时间陪伴 Delta 完成混合云转型的。 |
|
|
