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

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

[[227460]]

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

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

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

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

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

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

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

實踐devops同時啟用它

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

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

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

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

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

提出忠告

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

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

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