Categories
程式開發

基礎設施即代碼的誤區和規避方法


基礎設施即代碼的誤區和規避方法 1

有兩個行業趨勢指向許多人選擇DevOps工具的一項空白。運維團隊需要的不僅是基礎設施即代碼的方法,而是一個完整的模型驅動的運維思想。

在ThoughtWorks洞見黃博文的一篇文章中,作者指出:

現代軟件開發對基礎設施的管理提出了更苛刻的要求:產品要適應瞬息萬變的市場,要求基礎設施有更快的響應速度。持續交付和DevOps的推行要求產品團隊對部署和運維要有更高的自主性。技術的快速進步和演化,也使得基礎設施的配置不得不頻繁變化。在這種快速變化的過程中,要求基礎設施既要靈活,也要安全、可靠。

而傳統的基礎設施運維管理具有以下幾個問題:

  • 被動響應。產品團隊獲取服務器資源採用的是申請制,中間存在若干審批過程,以及需要等待運維團隊實施,響應不及時。
  • 自動化缺乏串聯。雖然有一定的自動化,但不能做到無人值守,需要執行一些臨時命令介入。由於環境釋放和重建的成本高,因而傾向於不釋放,導致資源利用率低。
  • 和產品團隊脫節。很難根據需求隨時動態增加環境。需要額外的文檔來描述環境,可能更新不及時。

Canonical通過開發開源DevOps工具Juju解決這些問題,從而創建多個世界領先的產品。

2020年的兩個DevOps趨勢

讓我們考慮以下兩個趨勢以及它們對DevOps的影響。

1.微服務將復雜性從應用程序端推到運維端

轉換到微服務需要將復雜的大型應用程序分解成許多較小的服務單元。在“分而治之”的架構風格中,每個單元都更容易部署、擴展、更新以及獨立移除。

然而,微服務體系結構可能會將復雜性推到運維端,而不是消除複雜性。

採用基礎設施即代碼工具可以減輕部分負擔,但不是全部。突然間,你需要考慮網絡延遲、消息格式和連接。每個新服務都需要連接到其他服務。

如果沒有適當的工具,升級和遷移就會變得非常耗時,並且容易出錯。

基礎設施即代碼的誤區和規避方法 2

2.基於容器的部署可能導致性能損失

對許多應用程序來說,基於容器的部署平台(如Kubernetes)令人愉快。

但是,容器並非適合所有用例。數據庫和其他中間件經常受到I/O條件的約束。當這些應用程序作為容器運行時,會導致性能損失。

大多數基礎設施即代碼工具都適合在單一平台上託管應用程序。但現實更為複雜。它們很少允許你跨平台部署應用程序。當容器和虛擬機搭配使用時,情況就更加複雜了。

系統工程師和運營團隊希望提供最佳的性能,但他們也希望為編寫應用程序的產品工程團隊提供敏捷性。

最終,複雜性會影響業務。對工具進行整合的管理決策可能意味著將數據庫轉移到了Kubernetes集群中。

自動化軟件出現

Canonical開發Juju來解決這些問題。它的方法與其他DevOps工具的不同之處在於:

  • 通過允許DevOps團隊在更高的抽象級別上工作降低複雜性
  • 通過允許應用程序動態響應它們的部署提高穩定性
  • 通過將配置管理與應用程序的特定託管環境解耦增加靈活性

Juju是一種簡單、安全的DevOps工具,用於管理當今復雜的應用程序,而不管你在何處運行軟件。計算、存儲、網絡、服務發現和健康監測都是免費的,適用於Kubernetes、雲計算和筆記本電腦。

Juju允許你的軟件基礎設施始終保持最佳配置。當部署發生變化時,每個應用程序的配置操作都由charms動態調整。 Charms是與你的應用程序一起運行的軟件包。它們對業務規則進行編碼,以適應環境變化。

使用模型驅動的思想意味著提高抽象級別。 Juju的用戶很快就會習慣這樣一種靈活的、聲明式的語法。這種語法與底層無關。

Juju與基礎設施提供者交互,但是操作代碼總是保持不變。我們專注於為你的產品基礎設施創建一個軟件模型,這可以提高生產率並降低複雜性

通過在較低的抽象級別上自動化基礎設施,DevOps讓這個行業獲得喘息空間。但這種喘息空間正在耗盡。

用一個可同時應對多種後端的工具有幾個好處:生產率不僅提高,而復雜性保持不變

基礎設施即代碼的誤區和規避方法 3

有兩個例子,大家可以進一步閱讀:

  • Open Source MANO (OSM) 是由Telefonica、BT和Telenor等全球電信服務提供商支持的ETSI NFV MANO棧的一個開源實現。通過提供一個實現服務編排功能的原生框架,Juju charms被OSM社區選為開源MANO項目背後的引擎。
  • Canonical為OpenStackKubernetes提供的託管服務為私有云和容器編排平台提供最快且最經濟的路徑。成本降低是通過工具(即Juju)的增強實現的。

英文原文:

Infrastructure-as-Code mistakes and how to avoid them