隨著微服務的興起和擺脫單體架構，IT和DevOps團隊專注於將基礎設施中的一切整合到越來越小的一套平臺和技術中。大膽的設想是，每個人都會在同一個 “上帝平臺 “上，有一個管理平面、一個資料平面和一個簡單的參考點。Kubernetes、雲原生和微服務將成為這一願景的載體。每個人都將站在同一起跑線上，使用同樣的衡量指標，說同樣的語言。網路和開發團隊將突然心心相印，快樂隨之而來。
問題是，現實和關鍵績效指標KPI阻礙了它。NetOps、SecOps和DevOps團隊需要非常不同的能力和衡量指標，以至於把所有團隊都塞到一個平臺上，強迫他們共用一切，給各方都帶來了真正的痛苦。
對大多數大型企業來說，今天的現實是，他們必須生活在兩個世界裡：雲原生和舊有的，但仍然存在的單體應用世界。
現況。不同團隊的需要不同的
例如，NetOps和DevOps對流量管理有不一樣的期望。NetOps希望保持安全和正常運行，以網路的穩定性和一致性為主要目標。NetOps團隊必須保持整個公司的正常運行，包括跨越財務、人力資源、行銷等方面的應用。所以，一些熱心的開發人員想嘗試一個新的基於Clojure的微服務，這周不能做藍綠色的推廣，不行。你得先去提出變更申請，然後再去排隊等候。這種保守的觀點使得NetOps不願意，坦率地說是不能對防火牆、負載平衡器和其他關鍵網路平臺進行快速修改。NetOps的謹慎態度顛覆了快速反覆變更、持續測試和快速部署的整個前提，而這些都是敏捷DevOps的主要目標。
另一方面，DevOps，特別是在構建雲原生和基於微服務的應用程式時，需要能夠快速地對安全規則和應用路由進行修改，以便以現代CI/CD管道的速度進行測試和反覆修改。服務和雲原生應用程式在設計上是鬆散耦合的，只有當開發人員對部署有更大程度的自我決定和控制時才能成功。同時，現代應用被分解成許多不同的服務，缺乏細微性的控制，將會大大降低DevOps適當調整和提供適當應用性能的能力。對於DevOps團隊來說，其他人控制他們的部署的想法感覺像是回到了20世紀90年代，那時他們不得不為一台伺服器等待漫長的一個月時間。
對於SecOps來說，微服務和Kubernetes帶來的安全挑戰不能僅通過傳統的方法來解決，例如圍欄安全。雖然SecOps有能力在Kubernetes集群之外執行政策，但他們的工具並不適合輕量級的容器化應用程式。由於安全性不足，Kubernetes團隊的配置錯誤將會導致資料洩露和暴露。當SecOps通過延遲或停止生產中的容器化應用部署來保護組織免受風險時，他們就成了壞人。DevOps認為他們是快速交付應用程式的主要限制因素，影子IT成為常態，安全經常以發布速度的名義被妥協。
雲原生迫使整合的問題出現
隨著各種規模的組織推動雲原生和採用微服務，不同的世界觀發生了碰撞。結果不是很好。要麼是DevOps不耐煩地等待NetOps兩周的變更週期，要麼是NetOps急得團團轉，試圖以DevOps的瘋狂速度工作，並時刻擔心一個團隊要求的防火牆或負載平衡規則的變更會導致整個應用基礎設施的癱瘓，使數百個應用一下子就無法使用。對SecOps來說，他們經常被夾在兩個世界之間：試圖弄清楚全球WAF如何處理邊界後面的 Kubernetes 集群的規則，同時還強制執行微服務級別的安全性。
整合的連帶效應也迫使DevOps、SecOps和NetOps必須在不同的觀察和管理的工具集、不同的安全原則和對應用行為的不同期望之間做出選擇。例如，對於NetOps來說，平均丟包量是一個關鍵的KPI，而對於DevOps來說，它與理解用戶體驗幾乎無關。
解決方案：複製，而不是整合
解決方案既違反直覺又顯而易見。停止鬥爭並朝向整合。相反，擁抱基礎設施和工具的重複與不同。允許 NetOps 使用基本的安全檢查和相當靜態的規則和管理來控制前門入口。允許每個DevOps團隊對自己的應用程式進行負載平衡和配置，作為在前門入口的大容量設備後面由NetOps管理的負載平衡的第二層網路負載平衡。
要明確說的是，我們不提倡讓每個 DevOps 團隊都可以選擇自己的負載等化器和工具，而讓 NetOps 來收拾爛攤子。相反的，我們討論的是基於各團隊的有權限控制的整合方案，這些團隊保持使用重複不同的工具——就像在兩個軌道中一樣——這樣每一方都有一些可行的方法。這是生產力和幸福感的黃金配方。
我們一次又一次地看到，一旦公司接受這一新現實，他們實際上能夠在不降低安全性或穩定性的情況下加快代碼速度和應用程式反覆運算。每個團隊都可以愉快地專注於自己的 KPI。同樣重要的是，雙重基礎架構使 NetOps、SecOps 和 DevOps 能夠協同工作，而不是為選擇和控制單一解決方案而苦苦掙紮。您的開發人員不需要學習 Nagios，這是他們不關心的東西，您的 NetOps 團隊不需要學習如何配置和調整 Prometheus，這只是兩個例子而已。
下面是我們看到聰明的組織如何處理這種使用重複不同的工具的做法，如何使它變得更容易，以及他們在特定領域獲得最大影響力的地方。
流量管理。大處著眼，小處著手
前門的流量與安全還在那裡，而且可能會保持相當長一段時間。而且，坦率地說，它是必要的。對於那些既想獲得性能和控制，又想保護自己免受DDoS和其他威脅的公司來說，一個由NetOps團隊控制的經過測試的、穩定的、全企業範圍的負載平衡是非常有意義的。NetOps可以像前門的保安一樣發揮作用，確保每個人都有進入的權限。通過嚴密的策略，NetOps可以給予DevOps團隊他們需要的功能，使他們能夠在外圍負載平衡器後面部署自己的羽量級網路基礎設施，如Kubernetes。
DevOps使用專門的負載平衡器，即入口控制器ingress controller，然後在他們自己的沙箱中運行，而不用提出請求給NetOps處理。DevOps可以進行反覆修改。NetOps可以依自己步調工作。SecOps可以維護防火牆的全球安全基礎設施，同時與DevOps–或者更有可能是DevSecOps–合作創建一個零信任框架，在服務層面上將安全分佈在整個應用中，並使DevOps團隊能夠根據其特定的應用或服務需求來滿足安全。
監測和績效。兩套優先順序和指標
因為對兩個團隊來說，重要的指標是如此不同，所以NetOps和DevOps需要各自選擇自己的分析工具。當每個團隊決定工具時，這種方式效果最好，但通過標準化的工具，，限制了各團隊工具過多蔓延的情況。NetOps可以用Nagios、Zabbix、ThousandEyes或任何其他常用於網路分析的工具來監控資料包丟失、一般輸送量和流量。DevOps可以選擇像Prometheus這樣的工具進行服務監控，也可以選擇像NewRelic或AppDynamics這樣的工具進行有足夠細微性的具體應用性能監控。
近年來，運行平行分析工具實際上變得更容易了，因為像Grafana和Kibana這樣的集成儀錶盤可以接受來自NetOps和DevOps監控工具的分析，同時為不同團隊保持不同的角色。
SecOps 主要監控異常行為，這與 NetOps 或 DevOps 並非完全不兼容。通過在統一儀表板上顯示這兩種類型的監控，該儀表板提供警報以及與 SIEM 等安全平台的集成，安全性實際上可以更好地被了解。對於 CTO、CIO 和 CISO 來說，有一個統一入口可以查看正在發生的事情是一個重大的優勢。
安全基礎設施：保持圍欄和左移
雙層安全結構對於成功的流量管理同樣重要。當 NetOps 和 SecOps 可以繼續依賴穩定的外圍安全性（如 Web 級應用程式防火牆、資料丟失防護和強制要求的所有端點保護要求）時，它們將輕鬆應付。
將 Kubernetes 與入口控制器、Kubernetes 原生 WAF 和服務網格結合使用的 DevOps 團隊可以管理應用程式和特定於服務的安全規則，這些規則考慮到在快速應用程式迭代過程中產生的獨特風險——只有開發人員才能理解的風險。更快地修訂安全規則使 DevOps 能夠保持代碼速度和快速啟動功能引入，而不會使企業面臨風險。風險劃分還意味著企業的重要應用——ERP、財務——可以享受更嚴格的安全標準，而不會中斷快速的開發週期。
部署工具：使用不同的流程設置進行整合
雖然基礎設施即代碼聽起來很棒，但實際上基礎設施會根據您關心的內容以不同的速度變動。這就是為什麼一些雲原生應用程式公司可以每天多次發布新版本，而擁有廣泛應用程式組合的大型企業在新部署中移動速度要慢得多的原因之一。與監控和負載均衡一樣，如果需要，成熟的部署工具可以輕鬆支持重複的 CI/CD 平台。在這種情況下，您可能希望設置雙管道：一個用於全局網路系統和防火牆上的配置更改、修補和規則更改，以及一個用於各個代碼團隊的單獨管道。您可以將相同的 CI/CD 原則和檢查點或過程應用於兩者，或者根據需要進行自定義。例如，您可以將靜態代碼分析或單元測試添加到DevOps 管道，同時跳過 NetOps 管道中的這些步驟。SecOps 團隊可以在 CI/CD 環境中建立自己的要求，包括代碼審查、測試和暫存或沙盒新應用程式，以便在實時部署之前在運行時測試行為。
結論：必要的妥協
這兩個世界說不同的語言，以不同的速度工作，喜歡不同類型的工具。你不能命令一個世界的居民突然改變他們所知道和喜歡的一切，而不會對組織生產力造成大規模破壞，或者在 NetOps 的情況下，冒著整個應用程式組合的全球穩定性的風險。對於 SecOps，您希望保持前門安全堅如磐石，同時允許 DevOps 團隊在不犧牲敏捷性的情況下正確保護自己的應用程式。DevOps 團隊只需要更快地行動，而他們使用的許多平台並不能很好地融入 NetOps 工作模式。
從這個角度來看，重複既是不可避免的又是可取的，這是工具和整合戰爭的積極結果，這些戰爭已經消耗了無數小時和大量精力來爭取不存在的中庸之道。
作者：Jenn Gile
Jenn是F5旗下NGINX的產品行銷經理，擅長使用Kubernetes和微服務等雲原生技術進行現代應用開發和安全。她來自俄勒岡州，現在住在西雅圖。