?7Signals從公有云撤退后還應(yīng)該繼續(xù)類似公有云商的技術(shù)堆棧，繼續(xù)使用K8S，但是他們連K8S都放棄了，改為私有云虛擬機+DOCKER，就值得我們更仔細的去研究一番了。為了更好地了解這個事件，我一大早又看了一遍rework對David和37Signals COO Eron Nicholson的訪談的文字稿。實際上從訪談中我們可以獲得更多的值得思考的線索，不過很多內(nèi)容不在今天要討論的范圍內(nèi)，以后找機會再聊吧。

從這個訪談中，我看到了很多對于這個問題思考的細節(jié)，David他們當(dāng)初上云的目的是解決IT的復(fù)雜性問題，他們可能會面臨系統(tǒng)上線兩周后的幾十萬訪問的尖峰，公有云很好地幫他們熬過了這個時期。隨著業(yè)務(wù)的不斷成熟與擴大，系統(tǒng)負載變得很平穩(wěn)，沒有黑色星期五的銷售量暴增，也沒有圣誕假期的低谷。于是業(yè)務(wù)的發(fā)展，IT系統(tǒng)的負載變得十分容易預(yù)測了，因此需要公有云解決的復(fù)雜性問題不存在了。此時帶來了一些新的復(fù)雜性，公有云對于37Signals來說是一個黑匣子，它是否真的安全、可靠，只有出了問題才知道，在此之前，它就像一場夢一樣不可捉摸。

37Signals付出了高額的成本，但是他們還是買不起更高級別的服務(wù)，亞馬遜并不能及時接聽他們的電話，遇到的所有問題也必須由他們自己的運營團隊來解決。因此上云數(shù)年后公有云并沒有真正幫他們解決掉復(fù)雜性的問題，只是讓他們的運營成本變得更高了。

對于他們回歸自營虛擬機+DOCKTER，則是對復(fù)雜性的另一個思考，他們認為K8S太復(fù)雜了，其陡峭的學(xué)習(xí)曲線讓他們感到力不從心。當(dāng)一切都正常時，大家都覺得K8S很不錯，用起來很省心，但是一旦出問題的時候，他們是無力解決這些問題的。對于一個擁有數(shù)十萬注冊用戶，但是只有80多人的中型SAAS服務(wù)商來說，很好地掌握K8S的復(fù)雜運維并不是一件容易的事情，因此他們最后決定將K8S上的應(yīng)用退回到虛擬機+DOCKER的環(huán)境中，復(fù)雜度的降低讓他們對整個系統(tǒng)的把控能力提升了許多，他們的十幾個人的運營團隊可以十分輕松的把控整個平臺和系統(tǒng)了。而之前他們的系統(tǒng)一直為不太必要的系統(tǒng)復(fù)雜性的可能性買單，從而面臨諸多的運維挑戰(zhàn)。

大型互聯(lián)網(wǎng)企業(yè)的業(yè)務(wù)面臨巨大的不確定的負載挑戰(zhàn)，因此他們的系統(tǒng)可以面向各種各樣的復(fù)雜性。因此他們從頭到尾構(gòu)建了一套IT體系，從研發(fā)到運營，這套體系是完全適應(yīng)這個IT基礎(chǔ)平臺和技術(shù)堆棧的。近些年來，大型互聯(lián)網(wǎng)企業(yè)也在做技術(shù)輸出，很多傳統(tǒng)企業(yè)也接受了這種技術(shù)輸出。但是這些傳統(tǒng)企業(yè)往往只能學(xué)其表，而無法做到表里一體。因此他們引入大型互聯(lián)網(wǎng)企業(yè)的技術(shù)的同時也引入了IT的復(fù)雜性，但是并沒辦法掌握解決復(fù)雜性問題的方法。同時，這些企業(yè)的業(yè)務(wù)與互聯(lián)網(wǎng)企業(yè)完全不同，他們也并沒有那么多的復(fù)雜性要去解決。他們實際上并不需要掌握解決這些復(fù)雜性的鑰匙，因此他們拿到鑰匙之后并不知道門在哪里。

實際上很多企業(yè)或者團隊低估了復(fù)雜性所帶來的成本，因此過于強調(diào)了敏捷和可擴展性帶來的好處。這幾年我一直跟蹤一個項目，這是一個面向近百萬用戶使用的管理類系統(tǒng)，其在線用戶數(shù)最終會突破10萬。最初設(shè)計是從以前的Oracle數(shù)據(jù)庫遷移到RDS Mysql作為數(shù)據(jù)庫。他們最初選擇了32C/128GB的標準RDS實例，每個數(shù)據(jù)庫不超過500GB容量。在研發(fā)過程中，他們解決了很多分庫分表的難題，通過一年多的時間，終于完成了應(yīng)用的改造。上線試運行階段他們解決了大量的性能問題，對數(shù)據(jù)庫做了進一步的拆分。不過隨后他們發(fā)現(xiàn)，如果完成整個系統(tǒng)上線，數(shù)據(jù)庫系統(tǒng)將需要被拆分為120+個RDS實例，而如果為了進一步提升處理能力，為今后系統(tǒng)長期運行做準備，必須使用讀寫分離的方式，如果這樣，他們可能需要將整個系統(tǒng)拆分為360+實例。在一個系統(tǒng)中創(chuàng)建與運維如此大數(shù)量的RDS實例，讓他們感到恐懼。

為了解決數(shù)據(jù)庫的復(fù)雜性問題，他們又開始對數(shù)據(jù)庫實例進行合并，將120+的數(shù)據(jù)庫實例都改為大規(guī)格的90C/720GB的MYSQL實例。這樣就把數(shù)據(jù)庫實例的數(shù)量減少為40+，不過每個數(shù)據(jù)庫的容量也變成了1.5TB。看到這個新的數(shù)據(jù)庫設(shè)計，很多人覺得放心多了，不過我也提出了一個新的問題，運維一個23C/128GB，小于500GB的MYSQL數(shù)據(jù)庫實例與運維一個90C/720GB，1.5TB的MYSQL實例的難度相同嗎？我想很多了解MYSQL，深度使用過MYSQL的朋友心里已經(jīng)有答案了。

對于需要長期運行的系統(tǒng)來說，復(fù)雜性必然帶來額外的成本，增加的成本的高低取決于系統(tǒng)本身的屬性。因此解決IT系統(tǒng)的復(fù)雜性是我從事IT工作這三十多年來很多企業(yè)一直在考慮的問題。IOE架構(gòu)也是因為它解決了企業(yè)IT建設(shè)與運營的復(fù)雜性而獲得了巨大的成功。云平臺實際上也是解決了IT的復(fù)雜性而得到了極大的發(fā)展，它讓用戶不需要考慮底層IT基礎(chǔ)設(shè)施與平臺的復(fù)雜性，而可以更多地關(guān)注企業(yè)的業(yè)務(wù)。

實際上前面所舉的例子并不需如此復(fù)雜，實際上近百萬用戶是按省為單位使用這個系統(tǒng)的，這套系統(tǒng)完全可以按照省為單位拆分為多套系統(tǒng)。每套系統(tǒng)的應(yīng)用、數(shù)據(jù)庫都可以獨立部署，因為除了總部的統(tǒng)計分析業(yè)務(wù)外，用戶不會跨省辦理業(yè)務(wù)，而統(tǒng)計分析完全可以在數(shù)據(jù)中臺或者數(shù)據(jù)倉庫里完成。

近些年一些企業(yè)的IT似乎陷入了一個思維怪圈，放棄了原有的簡單設(shè)計，從而選擇了一個更為復(fù)雜，似乎也更為先進的技術(shù)堆棧。不過在這些設(shè)計中引入的復(fù)雜性，早晚還是會以運營成本的方式給予回報的。復(fù)雜性也是IT成本這個問題，早晚會引起人們的廣泛思考的。?