如果企业正在考虑实施一种持续交付方式，或者将云计算服务引入其软件开发实践中，请不要担心理论，并关注实践。
在IBM公司，IBM云容器服务平均每天更新40次。这些更新的数量可能看起来有些惊人，但有一个很好的理由。人们建立在微服务之上，并在IBM云上进行全球部署，IBM公司希望为用户提供持续不断的新特性和功能、高性能以及针对新兴网络威胁的***安全解决方案。
每天更新容器服务40次需要做什么?这意味着迭代和部署额外的功能，在新的地点推出服务，根据更新***的操作系统补丁提高安全性，改进Kubernetes和容器引擎是提供服务的核心，并修复任何性能或可用性问题。这也意味着不断增加维护功能，并扩展服务以满足市场和技术需求。
虽然每日更新的数量可能令人望而生畏，但它是通过对任何云原生、容器或微服务策略：devops的尝试和真实的补充来实现的。
将devops纳入人们的文化和开发实践，已帮助人们克服了当今***的障碍：安全。随着迁移到原生云端，能够以极快的速度构建和更新应用程序，因此，无论应用程序的功能或组件可能发生多少变化，都必须以相同的速率进行安全性更新并不断更新，这一点至关重要。
确保应用程序的持续安全性和性能现在是每个开发人员需要考虑的事情，尤其是在不断部署更新和功能时。这可能看起来像一个不可能的壮举，直到考虑devops。加上云工具的强大功能以及云工具提供的将安全性和稳定性融入应用核心的新功能，devops可以帮助团队加速建设，而这正在成为规范。
使用devops和云计算增加容器安全性
有些人可能会认为，持续交付和开发实践所带来的持续不断的流量状态，与管理许多不同容器和/或微服务的复杂性，可能会带来各种安全风险。更多的活动部件往往意味着更大的风险，但是，如果正确实施，则情况正好相反。
使用devops持续更新基于容器的软件可以创建更高的安全性。这是因为托管的容器平台等云环境不断保持***状态，并转移到***的补丁级别，这些补丁通过云计算在全球推出。这有助于人们应对***的威胁，并立即解决它们。反过来，这使得整个环境更加安全，因为应用程序内的不安全的主要来源是过时的软件。
实践devops同时启用它
容器的兴起对devops来说是一个巨大的推动因素，因为用户需要持续交付容器体系结构以保证安全和有效。要持续交付工作，需要可重复的软件部署，还需要部署到可容忍更改的环境(包括滚动更新和回滚)。
云容器服务需要全球数以万计的集群必须保持***状态，如果没有成熟的devops工具可以以可靠的方式实现自动化，实际上是不可能做到的。
如今的许多团队并没有运行数以万计的集群。他们正在运行一些集群。但是，当用户运行具有大量容器集群的复杂大型应用程序来管理并保持安全时(特别是在不同地区)时，需要采用不同的devops方法来处这种规模。
在案例中，翻转了模型，以便环境本身不会将更改推入环境，而是改变环境。每个集群不断检查是否有需要应用的新更新。然后，可以使用A/B测试工具LaunchDarkly来控制每个单独群集的更新。
这使得可以在粒度级别上控制谁在运行什么以及哪些更新在世界各地流动，只需通过更改LaunchDarkly中的配置即可。系统对此作出响应，而不需要复杂的协调逻辑来确定何处推送更新。
提出忠告
如果企业正在考虑实施持续交付方法，或者甚至将容器、微服务和开发人员等云计算服务纳入自己的软件开发实践中，那么这似乎是一项艰巨的任务。虽然立即可以看到改进和回报，但构建成熟的流程需要时间，以帮助组织真正实现这些技术和流程的价值。
如果企业开始了旅程，给出很简单的建议：不要再担心理论，而应该专注于实践。使用容器的Devops是一条成熟的路径，不要将它们分开。大多数团队都希望为容器和实施devops提供单独的策略。他们应该成为一揽子交易。
所以，企业选择一个项目并一起完成。许多技术专家做的很好在，而这种方法可以让企业快速失败并更快地创新。
