容器平台加速并简化云应用开发
容器平台风行一时，但是开发人员的期望也需要管理。Red Hat的OpenShift产品策略师提供了来自内部的看法。
如果开发人员不是在谈论微服务，那一定是因为他们正在谈论容器。随着移动应用与云应用开发技术的日益成熟，容器技术的使用也变得越来越普遍。那么为什么不呢?它们提供了简便的平台可移植性，可确保应用程序在从测试环境迁往生产环境时保持一致的运行性能。增加过程隔离可提高安全性，其技术也变得简单不可抗拒。
近期在波士顿召开的Red Hat峰会有5000多名开发人员参加，在会议期间，Red Hat OpenShift容器管理平台产品策略总监Brian Gracely接受了笔者的独家采访。
为了实现数字转型，据说我们需要了解一个可组合的容器平台的概念。您能告诉我们这是什么吗?
Brian Gracely：平台不仅能够帮助开发人员更快地部署他们的应用，还可以帮助运营让应用更顺畅地运行。众多平台本身还具有一定的差异——这是关于用户应当如何做，它将让用户走得更快。早期的平台限制太多，支持的语言不多，标准化程度不高。
我们认为Red Hat OpenShift是更加标准化的。它是基于容器的标准和诸如Kubernetes之类的编排标准。但是，如果用户不喜欢我们提供的开箱即用的监控功能，我们还提供了更高程度的模块化功能，用户可以有多种选项来进行定制且不会丢失任何功能。我们最终的意图是想要为用户提供一个易于操作的超棒开发体验，此外我们还希望为用户在其他方面提供一个更好的灵活性，如存储、网络以及监控等。
如果存在技术限制或供应商方面的原因，用户是否无法选择在平台中采用某一工具?
Gracely：供应商希望用户使用他们的技术，但是很多技术在成规模应用并出现标准之前还不够成熟。有些技术确实得到了发展;Docker来自于一家平台供应商，其技术发展成为了标准。一项技术是否能够得到发展，主要取决于其成熟度以及用户是否喜欢。
使用诸如OpenShift容器平台的IT部门是如何跨云平台实现应用安全部署以及减少开发、测试和运行新开发与现有应用程序的时间?
Gracely：我们在OpenShift上做了大量的工作。安全性始终一直是我们的第一要求。从Red Hat Linux企业版开始就是如此。从Red Hat公司角度来看，安全性是我们一切工作的基础，OpenShift平台亦是如此。所以当用户部署应用程序时，容器将是安全的，平台通信、应用程序之间的内部通信都进行了加密处理。我们还对用户的安全密钥进行了加密。我们确保围绕权限和身份验证的所有内容都内置在平台中。当用户使用这个安全的平台时，用户完全可以在自有数据中心内运行，在Azure、AWS或谷歌平台上运行。
容器平台、容器管理以及平台即服务是如何帮助开发人员和运营团队更好地了解业务流程，并最终帮助提高盈利能力?
Gracely：容器的一大优点就是他是与开发人员相关的首要技术之一。它为用户提供了一个大包应用的标准方法。它还与运营团队有着较高相关性，因为它将实现基础环境自动化。它将帮助用户扩展这些环境。用户现在所拥有的是这种语言的共同性，大家都知道那是在过去我们无法一直拥有的。谈谈开发团队和运营团队。
当底层基础设施和开发人员使用一种通用语言时，我可以从一个商业理念开始。我可以在实验中开发出一个最小可行的产品。我可以实现快速的部署、完全的自动化，而企业也能在几周甚至几天内看到结果。在我们的主题演讲中，有一位客户说他的观念就是从想法到执行直至走向客户只需几天的时间。拥有这种快速的技术将有助于我们的新想法和新产品快速可见和成为可能。
这对于老观念的人来说是一个严重的问题。
Gracely：在未来，对于规划的传统思维方式将成为一大阻碍。人们将不得不与时俱进。
云与移动应用程序的发布周期从几年变为几天。即所谓的“先快出货，后打补丁”。对于缺乏OpenShift或其他容器平台的情况下，这种无法进行全面测试的真正影响是什么?
Gracely：最终用户现在已经习惯了这种持续更新的理念。从本质上来说，我们围绕OpenShift解决这一问题的方法是采用一个Docker或Kubernetes项目，我们确保在某一个特定时间内及时抓住它。我们集成了这些组件，完成了大量的测试，而其结果就是用户最终能够获得经过测试、运行基本稳定的软件。
接下来的一部分就是，“如何在不停止服务的情况下完成应用更新?”这就是我们针对自动化工具(如在Ansible和云形式中)所开展大量工作的意义所在，这些自动化工具能够帮助用户完成持续不断的升级。有时候，人们称其为Blue-Green升级，即可以升级一定数量的用户，从而确保应用程序正常运行，然后再完成剩余用户的升级。业内存在着这样一个认知，如果我只是用之前的方法为用户提供相同的软件，我不会让这个方法更简便，那样做也不会发挥作用。我们一直在这两个方向上同时投入。