容器炒作期已过，打磨企业级产品要耐得住寂寞

过去两年，Docker 引燃了容器技术：很多 IT 公司已将容器技术带入生产环境，甚至一些公司已将核心业务全部容器化，创业公司应运而生基于此提供容器服务，传统行业中的公司开始思量如何应用容器技术提高 IT 效率，而广大 IT 工程师们也开始关注、学习和应用容器技术。

容器技术炒作期已经过去，业界开始理性认知

容器技术对于基础设施构建以及应用生命周期所起的作用相信很少有人会怀疑了。

但是，和其他新技术一样，容器也会经历一个“炒作周期”， 容器当初作为新技术的光芒会逐渐淡去，这是我们从去年第四季度起开始有明显的感受。容器慢慢会变成开发、测试、运维习以为常的工具，会贯穿企业 IT 的各个方面。在热度褪去之后，沉淀下来的才是真正市场的接受度。这是目前我们正在见证的变化。

“炒作周期”指的是 Gartner 提出的 Hype Cycle。这条曲线不见得适用于所有的技术，但对于一些重大的、具有革命性的新技术的成熟周期有比较准确的描述。云计算是一个例子，容器技术也是。值得一提的是这条曲线的纵坐标标示的是人们对于新技术的价值的“预期”，并不代表该技术的实际价值。

通常来说，我们在短期内会高估一项重大新技术的价值，而长远来说低估同一技术的实际价值。

容器的技术并发症有哪些？

很多时候，当一项技术逐渐淡出大家关注焦点的时候，才是产业化的真正开始。在中国市场，从 2015 年下半年到 2016 年上半年，可能是对于容器技术价值期望的高峰。在当时，大家关注的是容器作为新技术所带来的巨大优势，以及取代已有技术的可能性。这些优势和潜力的确存在，而且很容易让市场兴奋。可是容易被忽略的是：这类影响力巨大的新技术要真正被应用起来，一定会改变我们已有的工作方式和行为，其中有些变化是深层次的；而伴随这些改变的会是一系列新的挑战，我们通常称之为”新技术并发症“。

要让容器技术真正落地，就需要去深入理解这些挑战，提供相应的解决方案。这其实也是容器的生态圈很重要的一个责任。关于这点，我们自己也是在接触了大量企业客户之后才有了比较深刻的体会。管理容器的“技术并发症”及其所带来的行为上的变化是让容器落地的关键之一，这些变化分为三类：

• 必须规避的：比如企业很难完全放弃已有的 IT 基础设施，一步迁移到一个全新的平台上，容器服务需要有能力去对接现有基础设施，一定程度上保留基础架构的透明度和可控性。
• 必须解决的：有些变化需要容器服务提供相应的解决方案，比如在基础设施和应用交付容器化之后，如何做配置管理，如何监控告警，如何通过日志排查线上故障，如何做服务发现，以及网络和存储在平台层面相对应的支持，这些问题如果不解决，容器化的过程会举步艰难。
• 可以优化的：另外有些变化是提供更大价值的机会，比如将容器与持续集成、持续交付的流程相结合，或是在容器化基础设施上提供自服务的 IT 治理。这当中一定有一些最佳实践，很多时候，我们所做的就是把这些场景中的最佳实践提炼出来，自动化之后作为一种有价值的服务进行输出。

容器技术如何落地

有人说，在未来，绝大多数成功的企业都会是“技术公司”。我觉得这是有道理的。这里的“技术公司”指的是以软件为中心的特性，软件会更多的更直接的去执行公司的战略。传统的企业也会做这种转变，可能就是所谓的数字化。在这个场景下，持续创新的能力会成为每个企业的核心竞争力。我们的使命就是帮助企业获取这种持续创新的能力。这会体现在方方面面：现代化的基础设施，敏捷化的交付流程，服务化的 IT 治理等等。目前来说，容器技术能够很有效的帮助企业获取这些能力，甚至将这些方面贯穿起来，配合 DevOps 的文化来推动持续创新。长远来讲，我们会不断的将最合适的技术与企业的应用场景结合起来，助力企业在以软件为中心的大环境下释放持续创新的能力。

可以结合我们自己的实践分享一下几点体会：

1. 首先，显而易见的，是要去深入了解客户的业务，从客户需求反推产品。在过去一年当中，我们与超过 1000 家企业进行了深度的交流，从最前沿的互联网公司到各个垂直行业的传统企业都有。我们会花很多时间去了解每个客户的现状，包括业务上和技术上的。因为容器是新技术，在早期很多客户对于应用场景并不了解，无法直接告诉我们他们所期望的产品是什么样子。我们需要去深度挖掘需求背后的场景，然后进行提炼最终抽象成通用性的产品。有时候有一些全新的想法，我们会用最快的速度做出一个原型，然后在客户中寻找“设计伙伴”；当场景上能契合时，我们就紧贴着客户的需求去继续产品化这些想法。
2. 在创业最早期，我们是基于一项全新的技术在创造没有人尝试过的产品。不可否认，那个阶段是最令人兴奋的。在当时，作为一个全新领域里的创新者，我们可以尽兴的用最前沿的技术去解决自己最感兴趣的问题。到了容器技术开始成熟，开始落地的时候，更加重要的是去解决企业客户实际的痛点和需求。这时最需要解决的问题会很现实、很琐碎，会远不如早期纯粹的创新阶段来的激动人心。企业级产品的打磨需要耐得住这种“寂寞”。当一项技术开始显得“无聊”的时候，才是产业化的开始。
3. 我们严格遵循的一条原则使用自己的产品，做自己的客户。我们所有的环境都部署在灵雀云平台之上。我们所有的组件都容器化、微服务化，上线用的就是自己产品里提供的持续集成、持续交付流水线，每天都会上线好几次。运维团队正在使用产品中运维平台打造监控中心，对基础设施、容器、应用、业务各个层面进行监控，通过日志服务来排查线上故障，就连内部的黑客松项目很多都会用上灵雀云。我们每个员工都是用户，“吃自己的狗粮”，也会持续的提反馈和需求。我觉得这点很关键，确保我们在打磨产品的过程当中对我们自己绝对诚实。

灵雀云和客户合作实践经验分享

举一个灵雀云客户的案例（这个场景在大一些的行业客户中还是比较典型的）。客户的基础设施比较复杂，有几个机房，另外在开始尝试使用一些公有云；开发、测试、运维人员加起来有将近 1000 人，分布在不同的项目中，包括一些外包团队。有一个中心化的 IT 部门负责管理所有的基础设施资源。项目组需要从 IT 部门申请资源，是个很繁琐的流程。每个项目会搭建和维护自己的环境。资源分配是相对静态的，资源利用率很低。客户希望使用容器技术来升级自己的基础设施，构造一个现代化的应用管理平台，同时梳理开发、测试、运维流程，从而获取企业层面的敏捷性。

我们看到，这个客户需要的远远不止是“在一堆机器上运行一堆容器”（这似乎是不少人对于容器平台的狭义理解）。我们把客户的机房和公有云环境都接入到我们的云服务中来，将异构的混合云环境统一的管理起来。根据客户需求，我们将底层基础设施划分成不同的环境，包括开发环境、集成环境、预发布环境、生产环境。客户希望不同的项目能够高效共享这些环境，但同时确保项目之间的隔离性。

除此之外，IT 部门需要能对项目成员进行灵活的权限分配，例如 CRM 项目的测试人员只能在集成环境中对属于 CRM 项目的服务进行操作。灵雀云的平台能够很完整的支持这类复杂的“企业内部多租户”的场景。管理员可以按照项目以及成员的角色进行细粒度的权限管理，并且给每个项目设定资源配额。项目的成员不再需要申请资源或搭建环境，可以自助式的在平台上部署和管理容器化的服务。不少项目开始基于灵雀云的CI/CD流水线改造交付流程。流水线会把开发、测试和运维以及相对应的环境贯穿起来，将代码从提交到上线的流程自动化。最终，我们帮助客户落地的不仅仅是容器技术，更重要的是涵盖自动运维、敏捷交付、以及自服务 IT 的一系列最佳实践和能力。

彩蛋 QA

Q：听说灵雀云最近与 ZeroDown 合作，推出 One-Click Business Continuity 方案。能不能介绍下，传统的数据传输、迁移的方案和痛点是怎样的，与 ZeroDown 合作的方案是如何解决这类问题的？

A：严格的说，市场上具备通用性、产品化的“跨云热迁移”方案很少见。更多的是咨询性质的服务，解决方案也多是为特定上下文中的应用量身定制的。即便这样，迁移的实施难度也不小（所以才会有咨询服务的必要）。从技术角度看，应用迁移的重心当然是数据，这是我们通常提到的“数据引力”：就是说，数据会像有引力一样把计算吸附在它附近，这也是迁移实施要解决的重点。根据具体使用的数据服务以及数据的性质，迁移方案五花八门（所以一般方案没有通用性）。

但总的来说，静态的数据迁移起来都还好，真正的难点在于迁移动态的数据。这也是“热迁移”要解决的核心问题。如果说真的要做到业务不中断，通常数据会在持续的动态的变化中，这种情况下怎样完成迁移？怎么样进一步提供全自动的，通用性的解决方案？

当初 Docker 非常受欢迎的原因之一是它实现了容器级别的程序可移植性，也就是以 Docker 镜像为载体的“一次构建、处处运行”。作为一个跨数据中心、跨云的容器服务，需要能够提供更上一层的、应用级别的可移植性。灵雀云在一定程度上做到了这一点，比如，任何基础设施（无论是物理环境、虚拟化环境、私有云、公有云、或是混合云）都可以被接入到云服务中，将现有的基础设施升级成容器云平台。这意味着在异构的基础设施之上提供统一的应用管理体验：一个应用，无论多复杂，可以用一摸一样的方式通过云服务部署到任意的基础设施上。

对于某些企业场景而言，单纯的可移植性还只是第一步，具体的业务如何进行迁移，并且不对业务造成任何影响也是需要解决的问题，而 ZeroDown 具有知识产权的基于 Business-Continuity-as-a-Service(BCaaS) 的方案刚好可以解决这个痛点，所以我们在原有的技术方案上集成了 ZeroDown，以实现应用级别的不中断业务的一键跨云迁移。

Q: 在创办灵雀云之前，您已经有过十一年的微软研发积累经验；您怎样回顾这些年的职业发展。您怎样看待大公司的学习积累耕耘与小公司打拼的权衡与选择？

A: 最早的时候我从事的是 Windows 操作系统内核的开发。Windows 内核团队系统工程方面极为严谨，毕竟写每行代码都觉得责任重大。同时也初步体会到成为一个极为成功的平台级产品究竟意味着什么。当时可能是 Windows 的鼎盛时期，但除了技术上有挑战之外其他并没有很大的成就感，毕竟产品已经极为成熟了，每个人在这之上能够创造的边际价值非常有限。这倒是让我对接下来要做的事有了明确的想法：就是要找到有朝一日会变成另一个 Windows 的平台，然后去和这个平台一同成长。就是这样加入了当时还在最早期的 Azure 团队。那个时候的 Azure 就像是一个初创公司，早期和计算相关的很多功能我都做过，后来开始组建自己的团队，负责研发 Azure 最核心的中控系统 Fabric Controller，直到出来创业做灵雀云。回想起来我觉得有几点体会可能会对别人有帮助：

1. 对于个人成长最有利的是投入到一个本身在飞速发展的环境中。这点其实不太好单纯的用公司的大小来衡量。
2. 无论在什么环境中，都要尽量做最重要的事情。所能创造的价值很大程度上决定了这段经历对于职业发展的价值。
3. 技术人，尤其在职业发展的早期，要舍得投入时间和有耐心做技术深度的积累。