編譯丨千山

51CTO讀者成長計劃社群招募，咨詢小助手（微信號：CTOjishuzhan）

長年從事IT咨詢工作，Jan Kammerath看到了很多公司的IT基礎設施和系統架構。在過去十年里，他觀察到這樣一個現象：Kubernetes和Apache Kafka變得非常普遍和流行，但對一些企業來說，部署效果卻并不那么盡如人意。

魔鬼藏在細節里，別人都在用不代表你也適合。

1、一切是怎么開始的

有一天，某家中型軟件公司的CEO打電話找我咨詢。

這家公司的SaaS產品運行良好，商業化也很成功。在過去幾十年的發展中，已經從面向Windows的桌面軟件產品成功過渡為一個具有微服務架構的成熟SaaS產品。

這位CEO本人在20世紀90年代中期編寫了最初的產品。隨著產品的升級迭代，他不再參與具體的開發工作。

一般來說，管理層可能不太了解開發團隊的具體事宜，但當事情的發展似乎要出現偏差時，他們通常會有某種直覺。在多數情況下，他們只是想讓我檢查一下，并希望得到一些來自外部的肯定，來確保他們的IT基礎設施和開發流程都很好。接到這位CEO的電話時，我也是這么想的。不過事情顯然沒有那么簡單。

公司業務的利潤率很好，運營成本也在可接受范圍內，真正令CEO頭疼的是，“我們的可用性只有87%，我們的SLA是95%，我已經為下一個財年的運營增加了50萬歐元的預算。”

盡管到目前為止他們還沒收到任何客戶投訴，但是這位老板依舊對于他們的服務質量和不斷上升的運營成本深表擔憂。對此，我非常理解：50萬歐的額外投入對于這種體量的公司來說并非小事。

即使在2019年，87%的可用性也非常糟糕。而且95%的SLA依舊意味著總共兩周的中斷。通常來說，SaaS的SLA在一年中大多在97-99%左右。97%仍然相當于11天的總停機時間。

2、為什么選擇Kubernetes和Kafka

擔任顧問的角色時，下結論之前必須收集足夠的信息。

我了解到：他們使用了一個托管的git存儲庫和一個大型存儲庫主機，并使用Jenkins作為CI/CD管道，將每個微服務部署到Kubernetes集群中。服務總線，微服務之間的通信，是通過Kafka完成的。

在現代化進程中，曾經有一個顧問來為他們的IT基礎設施起草整體的現代化和遷移方案，包括在Kubernetes上運行重構應用程序，并通過Kafka傳遞消息。如今這個顧問早就離職了，現在的運營和工程團隊對于這種設置并不感冒，還有人直接問我有沒有更簡潔的替代方案。

在我查看了所有的項目文檔之后，發現最初使用Kubernetes和Kafka的主要理由是“與云無關”。

與云無關是指一種云設計策略，其中應用程序、工具和服務旨在以混合模式在多個云平臺之間或本地和云之間無縫遷移，而不會中斷服務。這種策略的一些原則是支持獨立于底層操作系統的無縫可移植性，確保遷移中工作負載的有限中斷，并限制應用程序停機的風險，同時提高成本效率。

公司可以輕松地以簡化和直接的方式構建與云無關的應用程序。這是因為 Kubernetes 創建了一種跨不同公共云和私有云環境管理和運行應用程序的標準方法。

在那段時間里，有人認為最好“獨立于任何云提供商”。而且我認為風險是CEO腦海中縈繞的一個念頭。

3、如何解決“與云無關”策略的弊端

雖然與云無關的方法為組織提供了一些好處，讓相關的公司組織在與云無關時可以避免被鎖定在單個供應商中，但這也可能是其工程團隊的劣勢。

比如，一個云提供商提供了對貴司的應用程序很重要的關鍵功能，那么如果其他云提供商沒有此功能，則可能無法在與云無關的方法中使用它。無法使用云提供商的創新服務可能會減慢團隊的速度并使競爭對手處于優勢地位。

另外一個潛在缺點就是處理意外的數據傳輸成本。眾所周知，這些成本很難預測和理解。對于許多組織來說，構建多個云提供商可能不經濟。可替代方案是什么呢？在這個案例中，我給出的建議是：無服務器。

考慮到他們擁有的吞吐量和資源利用率，他們幾乎不會達到AWS任何無服務器產品的服務限制。在AWS SNS上每秒不會超過200條消息，更不用說達到AWS SQS隊列限制了。他們用Kafka所能做的一切沒有什么是SNS或SQS所不能做到的。

由于他們已經在AWS上運行了Kubernetes和Kafka，他們可以很容易地遷移到無服務器產品(Lambda、API Gateway、SQS、SNS)，而且他們的基礎設施賬單也有很好的成本降低潛力。很明顯，他們的主要問題是Kubernetes集群的運行占用了大量的時間，而且沒有云基礎設施本身的成本。

針對這些情況，我做了一個演示，解釋了團隊將如何遷移到無服務器產品。最重要的是，我提出了一個風險緩解路線圖，我的藍圖甚至提供了一個完整的“災難撤退到本地部署”。退回到本地部署的選擇聽起來很荒謬，但在大多數情況下可以緩解擔憂。

畢竟，我能夠說服團隊和管理層逐步轉向無服務器。我還說服他們用CI/CD管道產品取代他們的Jenkins，他們已經為他們的存儲庫主機支付了費用。我同意他們的意見，之后我會繼續觀察事情進展如何。

4、99.99%的可用性，成本降低約40%

大約在我拜訪的7個月后，他們問我是否可以對他們迄今為止所構建以及遷移的東西做一個架構回顧。

我又去了他們的辦公室，基本全天都在看架構圖。老實說，并沒有什么神奇之處：帶有API gateway和Lambda的微服務，帶有SNS的中央服務總線，以及帶有SQS的幾個扇形架構。許多DynamoDB表和S3桶。

從技術的角度來看，他們的產品沒有很高的復雜性。他們的產品優勢在于，他們與他們所在的特定行業的現有客戶生態系統緊密集成。他們還將客戶高度專業化的業務流程完全自動化，并開發了許多令人印象深刻的功能。他們擁有的最“復雜”的系統是關系數據庫和搜索引擎。

由于大部分基礎設施運營已經外包給了亞馬遜，因此可用性的顯著提高也就不足為奇了。與此同時，他們已經通過云賬單削減了成本，因為他們從Kubernets遷移的服務將不再永久運行，而是只在需要時運行。

5、這不是Kubernetes和Kafka的錯，但是……

Kubernetes和Kafka在技術上沒有任何問題，但是Kubernetes和Kafka有可能成為一個經濟問題。

雖然從技術上講，這是一個非常好的解決方案，但很多企業既沒有人力也沒有財力來運營Kubernetes和Kafka。當企業，更具體地說是內部人員，最初決定使用k8s和Kafka時，他們沒有將TCO(總擁有成本)與其他替代方案(如AWS、谷歌Cloud或Azure上的無服務器)進行基準測試。

運行Kubernetes集群需要人力、時間和預算。在我參與的大多數業務案例中，Kubernetes在經濟性方面總是落后于無服務器，甚至是負載均衡器與多az部署的虛擬機。

無論你的技能有多好，如果Kubernetes集群的TCO是第二備選的2 - 4倍，你就會陷入麻煩。隨著越來越多的公司轉向FaaS(功能即服務)，所需要做的只是盡職調查或技術審計，你將需要解釋為什么要運行Kubernetes集群。

當你的管理層看到其他公司的標桿時，“每個人都這么做”是一個相當站不住腳的理由。

結果是你的老板可能會因為Kubernetes集群或昂貴的Kafka環境而責怪你。我的建議是：積極地對Kubernetes和/或Kafka集群的總擁有成本進行基準測試（AWS、谷歌Cloud、Azure或IBM/Red Hat的無服務器產品都有該測試）。評估你是否需要Kubernetes和/或Kafka，以及為什么沒有合理的替代方案。

當你有Kafka和Kubernetes的經驗時，它肯定會在你的簡歷上看起來很好，當你把它們扔到一邊，節省了50萬歐元的成本時，它會看起來更好。你的雇主花在超重基礎設施和系統上的每一分錢，都不能花在你的下一次加薪上。比起運行Kubernetes集群的輝煌，你更有可能因為削減成本、提高服務質量和縮短上市時間而獲得回報。

原文鏈接：https://medium.com/@jankammerath/how-kubernetes-and-kafka-will-get-you-fired-a6dccbd36c77