如果企業(yè)正在考慮實施一種持續(xù)交付方式，或者將云計算服務引入其軟件開發(fā)實踐中，請不要擔心理論，并關注實踐。

在IBM公司，IBM云容器服務平均每天更新40次。這些更新的數量可能看起來有些驚人，但有一個很好的理由。人們建立在微服務之上，并在IBM云上進行全球部署，IBM公司希望為用戶提供持續(xù)不斷的新特性和功能、高性能以及針對新興網絡威脅的***安全解決方案。 

[[227460]]

每天更新容器服務40次需要做什么?這意味著迭代和部署額外的功能，在新的地點推出服務，根據更新***的操作系統(tǒng)補丁提高安全性，改進Kubernetes和容器引擎是提供服務的核心，并修復任何性能或可用性問題。這也意味著不斷增加維護功能，并擴展服務以滿足市場和技術需求。

雖然每日更新的數量可能令人望而生畏，但它是通過對任何云原生、容器或微服務策略：devops的嘗試和真實的補充來實現(xiàn)的。

將devops納入人們的文化和開發(fā)實踐，已幫助人們克服了當今***的障礙：安全。隨著遷移到原生云端，能夠以極快的速度構建和更新應用程序，因此，無論應用程序的功能或組件可能發(fā)生多少變化，都必須以相同的速率進行安全性更新并不斷更新，這一點至關重要。

確保應用程序的持續(xù)安全性和性能現(xiàn)在是每個開發(fā)人員需要考慮的事情，尤其是在不斷部署更新和功能時。這可能看起來像一個不可能的壯舉，直到考慮devops。加上云工具的強大功能以及云工具提供的將安全性和穩(wěn)定性融入應用核心的新功能，devops可以幫助團隊加速建設，而這正在成為規(guī)范。

使用devops和云計算增加容器安全性

有些人可能會認為，持續(xù)交付和開發(fā)實踐所帶來的持續(xù)不斷的流量狀態(tài)，與管理許多不同容器和/或微服務的復雜性，可能會帶來各種安全風險。更多的活動部件往往意味著更大的風險，但是，如果正確實施，則情況正好相反。

使用devops持續(xù)更新基于容器的軟件可以創(chuàng)建更高的安全性。這是因為托管的容器平臺等云環(huán)境不斷保持***狀態(tài)，并轉移到***的補丁級別，這些補丁通過云計算在全球推出。這有助于人們應對***的威脅，并立即解決它們。反過來，這使得整個環(huán)境更加安全，因為應用程序內的不安全的主要來源是過時的軟件。

實踐devops同時啟用它

容器的興起對devops來說是一個巨大的推動因素，因為用戶需要持續(xù)交付容器體系結構以保證安全和有效。要持續(xù)交付工作，需要可重復的軟件部署，還需要部署到可容忍更改的環(huán)境(包括滾動更新和回滾)。

云容器服務需要全球數以萬計的集群必須保持***狀態(tài)，如果沒有成熟的devops工具可以以可靠的方式實現(xiàn)自動化，實際上是不可能做到的。

如今的許多團隊并沒有運行數以萬計的集群。他們正在運行一些集群。但是，當用戶運行具有大量容器集群的復雜大型應用程序來管理并保持安全時(特別是在不同地區(qū))時，需要采用不同的devops方法來處這種規(guī)模。

在案例中，翻轉了模型，以便環(huán)境本身不會將更改推入環(huán)境，而是改變環(huán)境。每個集群不斷檢查是否有需要應用的新更新。然后，可以使用A/B測試工具LaunchDarkly來控制每個單獨群集的更新。

這使得可以在粒度級別上控制誰在運行什么以及哪些更新在世界各地流動，只需通過更改LaunchDarkly中的配置即可。系統(tǒng)對此作出響應，而不需要復雜的協(xié)調邏輯來確定何處推送更新。

提出忠告

如果企業(yè)正在考慮實施持續(xù)交付方法，或者甚至將容器、微服務和開發(fā)人員等云計算服務納入自己的軟件開發(fā)實踐中，那么這似乎是一項艱巨的任務。雖然立即可以看到改進和回報，但構建成熟的流程需要時間，以幫助組織真正實現(xiàn)這些技術和流程的價值。

如果企業(yè)開始了旅程，給出很簡單的建議：不要再擔心理論，而應該專注于實踐。使用容器的Devops是一條成熟的路徑，不要將它們分開。大多數團隊都希望為容器和實施devops提供單獨的策略。他們應該成為一攬子交易。

所以，企業(yè)選擇一個項目并一起完成。許多技術專家做的很好在，而這種方法可以讓企業(yè)快速失敗并更快地創(chuàng)新。