Vanity Fair:微軟「失落的十年」(下)

根據 Vanity Fair 於7月的文章,內容指稱微軟的管理不當、官僚作風盛行,使得微軟在財務以及技術上歷經了「失落的十年」。
評論
評論

(photo by  orcmid)

【編輯按】根據 Vanity Fair 於 7 月的文章,內容指稱微軟的管理不當、官僚作風盛行,使得微軟在財務以及技術上歷經了「失落的十年」,雖然微軟 CEO 史蒂夫·鮑爾默 (Steve Ballmer) 在日前接受富士比採訪的時候反駁此一說法,並認為全球目前有超過 13 億人使用 PC,中間又有推出 XBOX 等新產品,怎麼會是失落的十年。

不過, 我們仍找到騰訊新聞 的簡體翻譯,全數正體中文並修正字彙後刊出,以饗讀者,曾兩次獲得喬治波爾卡新聞獎(George Polk Award)的美國知名記者、最近剛剛擔任《Vanity Fair》特約編輯的 Kurt Eichenwald 於文中,對鮑爾默極盡嘲諷,將微軟「失落的十年」歸咎於鮑爾默。

 

<接續上篇 >

官僚主義的形成

正是在這種情況下,官僚主義開始在微軟逐漸形成。一些微軟高官試著改變去迎合鮑爾默的口味。但事實上,微軟當年向員工發放股票期權確實對公司的快速發展起到了推波助瀾的作用。更多的微軟員工尋求獲得管理崗位,而更多的管理者意味著要召開更多的會議,更多的會議導致了更多的備忘錄,所有的這一切也導致微軟創新能力的大幅降低。

一位微軟前技術人員表示,“在這樣的組織系統中,軟體設計工作似乎都是由委員會來完成的。所有的事情都進展的非常緩慢,員工需要開的會太多了。”

就像是電子書一樣,主要產品的開發機遇就這樣悄悄流失了。微軟曾開發了一款與 Windows 有著明顯差別的作業系統 Windows CE,原本被用於掌上電腦(PDA)等口袋設備,這款作業系統最終成為了支援微軟第一代智慧型手機的移動作業系統的基礎。儘管事實上微軟要先於競爭對手發佈 Windows CE 作業系統,但該公司依然在智慧型手機流行後的作業系統大戰中敗下陣來。

麥卡希爾說,“你眼睜睜地看著 Windows Phone 計劃表現不佳卻幫不上什麼忙,而心裡怎麼也想不通:微軟為何就輕易失去了曾以 Windows CE 設備領先的優勢?該作業系統曾大幅領先競爭對手,且領先對手多年。然而他們卻把事情搞砸了,原因就是官僚主義作祟。”

微軟產品經理馬克·特科爾(Marc Turkel)在接受採訪時表示,2000 年左右他曾負責一項涉及數個部門的計劃開發工作。在計劃開始之初,特科爾辦公室窗外的建築工地上,建築工人開始動工建造一幢 12 層高的大樓。為了能夠讓計劃順利完成,特科爾開始與不同的產品經理舉行談判,然後是與他們的上級,以及上級的上級。特科爾說,“如果不是在這個問題上浪費太多的時間,我們應當最多需要 6 個星期便能夠完成產品開發工作。”

直到有一天,當特科爾組織另外一場內部小型會議時,向窗外遠眺的他突然發現,那棟建設中的大樓已經完工了,而自己的計劃還沒有完成。他當時就指著那棟大樓說,“當我們開始這個計劃時,那棟大樓還不存在。這太令人難以置信。”

不過有些時候,微軟的官僚問題來自於一個簡單的事實:上世紀 80 年代的“大牛們”在他們 20 或 30 出頭的時候加入了微軟,如今已成為了 40 歲甚至 50 歲的中年經理人。一些年輕的工程師表示,許多的微軟高官並不了解電腦使用者這一迅速增長的階層,因為在微軟開始運營時,這些使用者仍還是孩童,或是甚至還未出生。當年輕的微軟員工想要抓住市場的潛在趨勢時,管理層有時卻只是讓他們靠邊站。一位軟體開發者表示,“絕大多數的微軟高官都不了解家庭使用者使用電腦的方式,特別是對年輕一代,他們更不了解。”

舉例來說,1997 年 AOL 推出了名為 AIM 的即時通信軟體。兩年之後,微軟也推出了名為 MSN Messenger 的即時通信軟體。2003 年,一位從事微軟 MSN Messenger 即時通信軟體開發的年輕開發者曾注意到,一些大學生已在 AOL 的 AIM 即時通信服務上面發佈狀態更新訊息,而微軟 MSN Messenger 卻缺乏相應功能。這位開發者說:“這其實就是向著 Facebook 發展的趨勢所在。網友需要一個發佈自己想法的場所,並能連續發佈相關訊息。AIM 的主要目的並不是聊天,而是讓使用者隨時登入該服務,以查看自己好友的最新活動狀態。”

當這位年輕開發者向其上司提出 MSN Messenger 缺乏簡訊功能的意見後,其上司並沒有當回事,並表示自己不理解為何年輕人沒事時老喜歡在即時通訊服務中打上幾個字。這位開發者說:“我的上司根本就不明白其中的道理。正是因為他不理解或說不相信年輕人使用即時通訊的具體方式,因此我們在這項業務上毫無作為。”

 

員工大排名

到了 2002 年,官僚主義的滋生物-- 殘忍的企業政治開始在微軟逐漸抬頭。接受採訪的微軟現任和前任高官紛紛表示,因為員工需要擊敗同事才能夠得到提拔、獎金或是生存下來,微軟的企業文化已經開始完全的走樣。

微軟高官層曾制定了名為“員工大排名”(stack ranking)的績效管理制度。該規定的大致操作模式是:每個業務部門都必須按照一定比率將員工工作表現劃分不同等級:優、良、中、差。也正是這種“殘酷”的績效管理制度,讓微軟的技術創新能力大為降低。

在接觸到的微軟在任和前員工中,他們都表示,員工大排名已成為導致人心渙散的最主要因素。大量員工因此選擇了從微軟離職。”一位微軟前軟體開發人員也表示:“如果你是 10 人團隊中的一員,你上班第一天就知道,即使該團隊的每個成員都表現良好,總會有 2 人得優評,7 人得中評,1 人得差評。這就導致員工之間明爭暗鬥,而不是微軟與其他公司爭搶市場。”

假設微軟把科技產業的一些巨頭們編入同一個小組,其中包括了蘋果已故聯合創始人史蒂夫·賈伯斯(Steve Jobs)、Facebook 首席執行官馬克·扎克伯格(Mark Zuckerberg)、Google 首席執行官拉里·佩奇(Larry Page)、甲骨文首席執行官拉里·埃里森(Larry Ellison)和亞馬遜的傑夫·貝索斯(Jeff Bezos)等人。按照微軟的“員工大排名”,他們中間只有 1 人會得到優評,還有 1 人會得到差評。

微軟高官表示,正是這個原因,許多微軟的超級明星都竭盡所能與其它頂級開發者在一起共事,因為擔心排名會受到影響。這個排名帶來的直接影響就是:得到優評的員工得到了獎金和提拔;排名墊底的員工不僅不能獲得獎金,而且還被掃地出門。

更為糟糕的是,微軟的“員工大排名”每 6 個月進行一次。微軟普通員工和他們的上級都需要參加排名,這也讓他們更加的關注短期表現,而不是通過長期的努力來進行創新。一位微軟軟體設計人員表示,“每 6 個月進行一次排名,迫使微軟做出了許多大量的糟糕決定。微軟員工依據排名時間來安排工作,而不是按照產品開發進程。這對企業而言,百害而無一利。”

微軟的“員工大排名”同樣存在著弄虛作假的可能。因為計劃團隊歸屬於更大的微軟集團,因此計劃團隊負責人依據程式每 6 個月召開一次會議,商討“員工大排名”的最終結果,因此每年有兩次時間,計劃團隊的負責人們都會聚集在一起,經過精明算計完成交易。

一位微軟高官表示,員工需要牢牢記得,現實是想要保證獲得更高排名的最佳途徑,不僅是要給自己的老闆留下深刻印象,而且還要給其他團隊的負責人也留下深刻的印象。這也就意味著,微軟員工需要盡可能的與各個不同的計劃團隊負責人搬弄是非,浪費時間。

微軟前軟體工程師布賴恩·科迪(Brian Cody)在接受採訪時表示,“在每一次的排名中,我都被告知在我的職涯發展中,政治遊戲一直非常重要。”當問到微軟對科迪的工作評價,是否基於其工作業績表現時?科迪回答道:“一直以來的情況是,我如何成為一名更好工程師並不那麼重要。重要的是,我必須考慮如何在一群計劃經理中間變得更為引人注目。”

最終,微軟的“員工大排名” 系統削弱了微軟的創新能力。微軟前高官比爾·希爾(Bill Hill)說,“我曾經希望帶領一個能夠攜手共事的團隊,他們只專注於開發偉大的軟體產品。但是在微軟,你無法實現這個夢想。”

微軟時任 Windows 業務主管吉姆·阿爾琴(Jim Allchin)就曾經想要弄明白蘋果的技術為什麼要比微軟好出許多。2004 年 1 月 7 日,阿爾琴曾經向蓋茨和鮑爾默發送電子郵件稱,“如果不是在微軟工作,我就會購買一台 Mac。蘋果並沒有迷失方向。”

情況確實如此,對微軟的高官階層來說,公司內部出現的這些問題並不是什麼大麻煩。微軟在科技產業依然擁有一些最優秀的人才。該公司擁有數百億美元的資金,在高官選定計劃之後,有能力向該計劃投入大筆的資金。蘋果怎麼能夠避開微軟的陷阱?

答案並不難尋找。現任和前任微軟管理者均表示,每年他們都嘗試著向公司高官解釋微軟為何在與蘋果、Google 和其它競爭對手的競爭中,在創新品質上苦苦支撐。透過每半年對員工的調查,訊息被傳遞給了公司高官。但是一次又一次微軟高官都得到了同樣的答案:因為“員工大排名”這一績效管理制度的併發症,微軟旗下的各個部門沒有協調共事。不過微軟對此沒有任何的反應。特科爾表示,“微軟保持著對員工進行調查的習慣,傾聽公司的問題,每一次都試圖用同樣的方式來修補問題,但是它從來也沒有奏效。”

音樂播放器

也正是因為這樣,微軟一直在市場競爭中不斷遭受打擊。蘋果早在 2001 年便發佈了 iPod 音樂播放器,而直到兩年之後,微軟的高官一直在試圖想出如何與蘋果對抗的方法。

蓋茨在 2003 年 11 月 2 日向部分微軟高官發送電子郵件稱,“因為我們推出音樂服務的時間過晚,我們可能將在該市場永遠落後於其它競爭對手。使用者不希望放棄自己的硬件。 ”蓋茨在郵件中表示,結果就是微軟不會說服消費者使用微軟的產品。他寫道,“我看不到有什麼能夠確保我們成為市場龍頭的證據。我認識的人(我承認他們都是富人),都擁有下載了數千首歌曲的 iPod。”蓋茨說,投資銀行 Allen & Co. 的管理者赫伯·艾倫(Herb Allen)曾一次為好友購買了數十個 iPod。他寫道,“巴菲特也非常喜歡 iPod。”

在此郵件發出不到兩週之後,阿爾琴試用一款由獨立的硬體廠商為微軟開發的音樂設備。當年 11 月 13 日,阿爾琴在發送給一些微軟高官的郵件中寫道,“我必須要告訴你們,我們的軟體和這款設備的體驗非常糟糕。蘋果就是遠遠領先於我們。”

隨著時間的推移,直到 2006 年 11 月 14 日,微軟才推出了自有音樂播放器 Zune。在該設備推出僅僅 45 天之後,賈伯斯便發佈了把手機、音樂播放器、上網、照相機和其它 Zune 所不具備的功能融為一體的 iPhone 手機。但是對於不想購買手機的使用者,iPod 依然是他們不二的選擇。事實上,蘋果早已推出了公司第五代 iPod,售價並不昂貴的 iPod Mini。在距此不到一年之前,蘋果還推出了公司售價最低的音樂播放器 iPod Nano。

Zune 很快便在市場中取得了慘敗的戰績。到 2009 年,iPod 依然佔據著音樂播放器市場 71% 的份額。除了北韓大選之外,這樣的數據在市場中幾乎就看不到。與此同時,Zune 的市場份額卻不足 4%。去年 10 月,微軟終止了 Zune 業務,寄望於消費者能夠購買一部像 iPhone 一樣融入音樂播放器功能的 Windows Phone 手機。

長角作業系統

在微軟失落的十年間,蘋果甚至還在作業系統市場猛打猛衝,而該市場正是微軟的謀生之道。2001 年 5 月,微軟執行了名為“長角”(Longhorn)的計劃,預計將會在 2003 年年底發佈名為 Windows Vista 的產品。微軟的高官為長角製定了許多的目標,其中包括與免費作業系統 Linux 進行抗衡;推出文件存儲系統 Windows File System(WinFS),讓不同類型的文件能夠儲存到一個單一的資料庫之中;開發代號為“Avalon”的演示系統,讓軟體擁有著與網站一樣的外觀。

隨著長角計劃開發的展開,微軟的技術人員向長角植入了一系列的功能。數量眾多的開發團隊被指派從事長角作業系統的開發,但是即便是如此,該款作業系統的推出時間依然被一拖再拖。微軟當時遇到的問題包括,開機需要 10 分鐘時間;系統不穩定,經常出現當機問題。

到了 2004 年 6 月,賈伯斯宣布蘋果將推出名為“Tiger”的作業系統。這款作業系統在微軟內部引起了軒然大波,因為“Tiger”中的許多功能都是微軟計劃在長角中推出的功能。當時,微軟員工不斷發送著電子郵件,表達著對“Tiger”的驚愕之情。讓微軟高官難以置信的是,“Tiger”竟然還包括了等同於 WinFS 和 Avalon 的功能。

長角團隊成員雷諾·普賴爾(Leno Pryor)在郵件中寫道,“Tiger 太 XX 神奇。它就像是我在今天剛獲得了免費登錄長角的密碼一樣。”曾參與長角計劃開發的高官維克·岡多特拉(Vic Gundotra)試用了 Tiger 作業系統後寫道,“他們的 Avalon 競爭對手很惹火。剛才我用 Mac 操作賈伯斯展示的所有功能。5 個小時的時間它竟然沒有當機。”岡多特拉還寫道,“視訊會議功能?太神奇了!影片製作軟體?非常酷!”

岡多特拉的電子郵件被發送給了所有的微軟總部高官,其中就包括了阿爾琴。阿爾琴又把這封電子郵件轉發給了蓋茨和鮑爾默,只是在郵件下方添加了自己的名字和一個詞--“Sigh(唉)!”

長角的命運早已被注定。幾個月之後,阿爾琴把所有的長角開發團隊聚集在一起並宣佈:微軟將無法在預訂的時間期限內完成 Windows Vista 作業系統的開發工作。事實上,微軟當時也無法預計這款作業系統能在何時上市。也正是因為這樣,微軟高層在一次會議後達成了以下意見:在歷經三年的工作之後,一切從頭再來,放棄或調整原先的許多目標。放棄 WinFS;對 Avalon 進行修訂。

蘋果早已向市場推出了附有這些功能的作業系統,而微軟卻仍在冥思苦想如何能夠讓這些功能在作業系統中運行。此後又過了兩年多的時間,Windows Vista 作業系統終於在商店的貨架中現身。科技雜誌“PC World”當時就撰文指出,微軟推出 Windows Vista 是 2007 年最令人失望的科技事件。蘋果在微軟擅長的作業系統市場已然取得了一場大勝。

搜尋引擎 Bing

到了 2004 年秋季,微軟面臨著來自 Google 的激烈挑戰,因為這家規模更小的公司網羅了數量眾多的擁有天賦的青年軟體設計人員。Google 在當年 8 月進行了首次公開招股(IPO)。因為向員工派發股票期權,Google 的上市同樣也造就了眾多的百萬富翁。也正是因為這樣,越來越多的微軟高官宣布計劃跳槽到 Google。

有關微軟人才跳槽 Google 的故事,最著名的當然是馬克·盧科夫斯基(Mark Lucovsky)事件。盧科夫斯基曾先後在 DEC 和微軟工作了 16 年,並獲得“傑出工程師”的稱號。他曾是微軟 Windows NT 的首席架構師,而 Windows NT 最終發展成 Windows XP。盧科夫斯基曾經表示:“我編寫了大部分核心執行程式、kernel32 以及 Windows API。”

作為 Windows NT 的首席架構師,盧科夫斯基對微軟的影響力不言而喻,所以當他 2004 年 11 月 11 日告訴鮑爾默自己要跳槽時,鮑爾默的反應可想而知。法庭文件顯示,鮑爾默曾這樣說:“拜託你告訴我,你不是要去 Google。”當被告知盧科夫斯基的新東家正是 Google 時,鮑爾默氣得抓起一把椅子扔到了房間的另一邊。鮑爾默隨後所說的話可能被載入網路史冊:“埃里克·施密特(Eric Schmidt)這個混蛋。我要讓他死無葬身之地,我以前幹過一次,我還要再幹一次。我要弄死 Google。”

網路搜尋那時已經是微軟最新的頂級優先發展計劃。當時,微軟早已擁有了一款平凡的搜尋引擎 MSN 搜尋,但是這款搜尋引擎無法阻擋 Google 的前進步伐。因此微軟又開發出了 Windows Live Search,但這款產品同樣也被證明是劣等產品。在不斷對 Windows Live Search 進行修整併終止了一些功能之後,微軟又推出了自己的新平台 Live Search。最終,鮑爾默在 2009 年 5 月推出了搜尋引擎 Bing。但是到了這時,微軟的網路搜尋團隊早已受到公司官僚作風潛移默化的影響。一位參與 Bing 開發的前微軟員工表示,“Bing 的開發人數是實際所需人數的數倍。”

許多微軟網路部門的員工表示,在該部門工作擁有著非常痛苦的體驗。絕大多數的自主創新都被槍斃;相反,該部門的高官整天都在研究 Google,告訴員工開發出的 Bing 必須具備與 Google 一樣的功能。從事 Bing 計劃開發的微軟前產品經理約翰·加西亞(Johann Garcia)表示,“高官們一直要求必須追趕上 Google。到了後來,我們發現 Bing 沒有了任何創新性的東西。Google 一直遠遠的領先著我們,而我們卻陷入暗鬥。最後,許多人都變得非常不開心,也失去了所有的動能。”

截至目前,Bing 已累計為微軟帶來了大約 60 億美元的虧損。如果把早期的搜尋產品和所花費的資金加在一起,微軟單是為搜尋引擎業務就已經投入了近 100 億美元之巨。微軟確實為 Bing 完成了一些成功的交易,特別是與雅虎達成的交易。2009 年,微軟與雅虎簽署了為期 10 年的搜尋廣告合作協議。根據這一協議,微軟將向雅虎網站提供 Bing 搜尋引擎服務,兩家公司將分享廣告收入。

自與雅虎簽署協議至今,Bing 的市場份額已經獲得了大幅的增長。根據網路流量監測機構 ComScore 的統計數據顯示,今年 3 月份,微軟在美國網路搜尋市場的份額已經達到了 15.3%,高於 2010 年 3 月份的 11.7%。不過值得注意的是,在同一時期 Google 的市場份額也獲得了增長。這也就是說,Bing 所獲得的市場份額,大部分均來自於雅虎。

Bing 市場份額的提升以雅虎份額的下滑為代價,對微軟而言,這無疑是自食其果。

蘋果的創新

當蘋果推出 iPhone 手機時,鮑爾默在 2007 年曾嘲笑著說,“iPhone 沒有機會在市場中獲得很多市場份額。”他在同一年還表示,“iPod 的確是熱門品牌,但蘋果不是。”在蘋果 2010 年推出 iPad 平板電腦時,鮑爾默更是對這款產品嗤之以鼻。但是自那時至今,iPad 的累計銷量已經超過了 5500 萬部。鮑爾默對 Google 的預測同樣也不靠譜。法庭文件顯示,鮑爾默在 2005 年曾經公開表示,“Google 算不上是一家真正的公司,它就是一個爛攤子。”

許多人都曾做出過後來被證明是愚蠢的預測,但是鮑爾默的預測卻讓他在微軟內部的形象受到了嚴重的影響。直到賈伯斯臨終前,他依然不僅能夠預測出市場的發展方向,而且能夠帶領著蘋果朝著該方向前行。Google 繼續不斷的透過推出新服務,來與微軟的傳統優勢業務 Office 和 Windows 進行抗衡。

因為競爭對手均展示出了某種程度的成功,鮑爾默不斷犯下的錯誤,也讓微軟的技術專家們開始抱怨他們的這位幾乎沒有任何技術背景的首席執行官。一位在去年跳槽到 Google 的微軟前程式開發者說,“鮑爾默擁有著把腳塞進嘴裡,讓人看上去非常愚蠢的技能,這會一點一點的折磨在微軟的每一位員工。在他做出了那麼多錯誤的預測之後,你就明白這些絕對無法原諒,因為這意味著他聽不進去身邊技術人員的諫言。”

鮑爾默為微軟設計的商業哲學早已過於成就,似乎已嚴重的離題。作為微軟的首席執行官,鮑爾默聲稱他首先考慮的不是讓微軟“耍酷”,而是利潤。換句話說,微軟首先考慮的是通過銷售自有的新技術賺錢。但是這基於一個事實:微軟靠著錢獲得了市場領先優勢,因為這家公司總是比任何一家競爭對手擁有更多的資金。

不過微軟的這種優勢已經不復存在。鮑爾默長期以來一直依靠的優勢如今已經徹底消失了。Google 當前帳面上已經持有 500 億美元的資金,與微軟的 580 億美元相差無幾。另一方面,蘋果從今年開始已經持有了超過 1000 億美元的資金。使用財務力量讓公司在市場中保持領先優勢對微軟或鮑爾默來說已經無法再次奏效。

但是奇怪的是,鮑爾默可能對微軟的未來是無價之寶。因為未來的微軟可能將面臨著一系列的麻煩,像其它眾多的公司一樣,業務擴展太多導致公司擁有了太多的產品線。對於擅長交易的鮑爾默而言,他應當能夠勝任於這種大規模的企業重組。

鮑爾默此前表示,他計劃擔任微軟首席執行官至 2018 年。但是無論他本人或其他微軟管理層希望與否,華爾街對微軟的不滿態度可能會導致微軟管理層出現調整。市場中也早有消息稱,目前已是鮑爾默主動讓賢的最佳時機。

賈伯斯曾經在沃爾特·艾薩克森(Walter Isaacson)為他撰寫的自傳中公開談論過鮑爾默在微軟的問題上所扮演的角色。賈伯斯說,“做銷售的人經營公司,做產品的人就不再那麼重要,其中很多人就失去了創造的激情。斯卡利加入後,蘋果就發生了這樣的事情,那是我的失誤;鮑爾默接管微軟後也是這樣。蘋果很幸運,能夠東山再起,但我認為只要鮑爾默還在掌舵,微軟就不會有什麼起色。”

不過最有趣的是,賈伯斯在這一點上最終譴責的是蓋茨。賈伯斯說,“他們從來沒有顯示過原本應當顯示出的產品智慧野心。蓋茨習慣把自己標榜為產品人,但他確實不是。他就是一名商人。贏得業務永遠比製造出偉大的產品重要的多。微軟的基因中沒有人性與人文科學。


開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

打造第一個在 AWS 上的應用程式

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!