《獨角獸創業勝經》:YouTube原本是約會網站?這些創辦人「打掉重練」造就的關鍵轉折

《獨角獸創業勝經》:YouTube原本是約會網站?這些創辦人「打掉重練」造就的關鍵轉折
Photo Credit: iStock

我們想讓你知道的是

本書以大數據探究全球最成功的新創公司,破解創業長久以來讓人卻步的繆論,如創辦人年齡、學歷、職涯背景等迷思,以實際案例解碼產品策略、市場規模、行業競爭、資金來源,整理出成功創業的真實面向,並融合知名獨角獸草創真實故事,對創業提出嶄新的見解!

文:阿里.塔馬瑟(Ali Tamaseb)

6 關鍵轉折
這幾位創辦人在關鍵時刻「打掉重練,從頭開始」

「做決定時不受情緒干擾的人才能看清什麼事該先做。」

——安迪.葛洛夫(Andy Grove),半導體晶片龍頭英特爾(Intel)前執行長

2008年,史都華.巴特菲(Stewart Butterfield)離開雅虎,轉去創辦多人線上遊戲Glitch。這個遊戲優雅、美麗,有一小批死忠鐵粉。那問題是出在哪裡?不成氣候。最終,巴特菲只能叫停。「我沒有感覺到我們在打鐵趁熱,」2012年,巴特菲一封給投資金主的電郵中寫道,「反而比較像是隔水加熱,不太可能搞得如火如荼。」

巴特菲試圖為他的全體35名員工找到新工作,而且留住核心團隊。他們在打造遊戲期間也開發出一種溝通工具,取代內部電郵往返,「我們『在Glitch』沒搞出什麼名堂,但是我們效率超高,」巴特菲後來又說,「當我們明白,一旦少了這套系統就會動彈不得,我們認為它可以是一項產品。」他動用手邊的現金,與這支小團隊一同將這項工具開發成產品,並在2014年正式以Slack之名發表,定位成企業內部的即時通訊平台。Slack馬上大獲成功,從投資金主手中募集幾億美元。

2019年1月公開上市,初登板當日市值上衝近200億美元。

「確實,我的職涯第一堂課就是『超級幸運』,」巴特菲說,「但要是說有哪一層實際面向不是取決於運氣,肯定是當我們還有選擇餘地時就主動放手。我們在還有充足時間與資金的情況下,做出『收掉Glitch』的決定,180度轉向新業務。」

Slack不是巴特菲的第一個關鍵轉折,早在2002年他就創辦另一家名為Neverending的遊戲公司,但也未成功。不過巴特菲覺得,當初為這款遊戲開發的其中一項功能是共享圖片,似乎頗有自成產品的潛力。巴特菲與他的團隊決定重新設計這項共享圖片的功能,最後取名為Flickr,當成獨立運作的網站。

在當時,共享圖片算是很新穎的概念,就連Facebook都還要再過幾個月才會問世;其他網站運作只是為了存放或列印照片,沒有人為攝影達人開闢分享作品的空間。Flickr取得小幅成功,2005年雅虎出價3,500萬美元收購,一舉讓巴特菲成為超級創業家,然後他就和其他地位相當的前輩一樣,繼續創辦下一間幾十億美元的企業。

關鍵轉折十分常見,新創公司社群通常張臂歡迎它們。

許多最終締造十億美元市值的新創公司都始於一個截然不同的構想。這些創辦人一路走來做出激進改變,這一點印證一項事實,亦即他們並非特定構想的傳教士,更像是天生就有一股打造新事物的狂熱。他們尋找機會,但不執迷於某一道特定構想,而且主動傾聽市場聲音。

考慮到許多新創公司故事只提及行得通這最後構想,因而經常改寫歷史,要蒐集總共有多少家獨角獸企業曾在關鍵時刻轉折的數據,或是拿這些關鍵轉折和隨機組新創公司兩相比較,實為不可能的任務。但是顯而易見的是,有些獨角獸企業成功,單單是因為創辦人有能力看清楚什麼事行不通,因此及時調整公司方向。成功的創辦人不需要立即擁有完美構想,但他們確實有必要看清楚何處必須改變。

許多名聲響亮的企業初創型態與我們當今所見截然不同。就以YouTube為例,許多人知道它是一座海量影音分享平台,各式各樣的內容包山包海:喵星人影片、音樂影片、手作影片。

但是2005年YouTube初登場時,創辦人心裡想的可不是這麼一回事,它原本應該是約會網站。

「我們一直覺得,網站上要可以播放影片,但實際應用究竟是什麼?」YouTube共同創辦人陳士駿說,「我們就想,約會將是顯而易見的選擇。」線上約會算是新興領域,YouTube打算成為一處用戶可以上傳影片的網站,除了自我介紹也聊聊夢寐以求的對象,當時的口號是:「進來就上鉤(Tune In, Hook Up)。」

這道想法真是大敗筆,沒有半個人上傳影片到網站。陳士駿和他共同創辦人實在太渴望吸引用戶了,於是到分類廣告網站Craigslist張貼公告,提供每一名註冊的女性用戶20美元答謝金。有幾名用戶開始上傳影片,但都不是想要找對象,反之,他們上傳度假畫面或自家寵物的搞笑影片。

創辦人留意到這一點,同意讓用戶自行決定YouTube的用途,他們沒有狂熱地非要打造約會產品不可;反之,他們從中看到蠢蠢欲動的商機,亦即不斷成長的網路寬頻與分享影片趨勢合為一體。很快地,鄉民紛紛上傳各式各樣的影片:烹飪教程、業餘音樂影片以及沒完沒了的喵星人影片。2006年Google出價16億5,000萬美元收購YouTube,至今仍是Google史上最大手筆收購案,但也是一筆絕佳的交易。

像YouTube這類企業唯有拓寬看待自家產品的眼光後,才發現自己的立足之地。總部設於加拿大的電商平台Shopify協助企業打造線上門市,市值已達數百億美元,但一開始也是命運多舛。三位創辦人托皮亞斯.路克(Tobias Lütke)、丹尼爾. 溫南(Daniel Weinand) 與史考特. 雷克(Scott Lake)原想成立一家滑雪裝備的電商公司,這座名為雪魔(Snowdevil)的平台運作良好,直到它們終於大轉向改名為Shopify,在線上銷售各種貨品。

諸如Instagram(即IG)等其他公司則是反其道而行,先大幅限縮構想,直到摸索出正確的產品與市場道同契合之路。

IG成為社群網路人氣王之前是共享社群計畫的供應據點,當時名為Burbn,提供類似到四方的服務:用戶可以在餐廳與咖啡店「打卡」,公告四周知己的朋友他們現在正往哪裡去。

它具備一大堆功能:打卡、發送照片與文字、甚至還有造訪某些據點的積分系統。IG的共同創辦人凱文.希斯卓(Kevin Systrom) 在一場派對中認識幾位來自創投公司Baseline Ventures與安霍創投(Andreessen Horowitz)的投資金主,在對方興致勃勃的情況下,募集50萬美元開始落實這道構想。

智慧型手機的相機越來越強,行動照片看起來像是這家新創關注的正確標靶。「我們花了一個星期做出單單聚焦照片的原型版本,」事後希斯卓這樣寫,「其實成果滿糟的,所以我們回去打造全包辦的原生版本,我們真的做出全包辦的完整版本App,可以內建在iPhone使用,但是整體而言雜亂無序,功能多到超載。下定決心打掉重練真的很艱難,但是我們豁出去了,基本上是砍掉整個App,只留下照片、評論和按讚的功能,剩下的就是IG了。」

這起故事令人耳熟能詳的部分是:IG締造空前大成功,2012年Facebook出價10億美元收購時已經囊括幾千萬名活躍用戶的IG。當時,斥資10億美元收購一家零收入的企業看似荒唐之舉,但事實證明,幾年後它成為馬克.祖克伯做過的所有決定中最出色的代表。

並非每一道關鍵轉折都會結出10億美元的果實。PayPal早期員工凱斯.拉布伊斯後來成為成功的投資金主,他告訴我:「門外漢成功的例子顯然不虞匱乏,但一塌糊塗的也所在多有。」當領導者改變企業初衷,有可能傷害當初員工加入這家企業以示力挺的理由。「試想一下,你正在駕駛一輛黃色校車。你每天載送學童上下學,然後突然來幾個瘋狂大轉彎。這些學童因為沒有繫上安全帶,所以被你左甩右晃、前傾後搖。對你的同事來說,簡直是一整個七葷八素,」拉布伊斯說,「所以我十分審慎看待關鍵轉折。」

拉布伊斯曾親自參與幾場半類似關鍵轉折的行動。在PayPal他目睹產品轉向,交易型態從內嵌在掌上型個人數位助理轉至以電郵為主。「那次還不算是激進的關鍵轉折,因為電郵已經被整合置入原始產品中,這就是它行得通的原因,」他說,「目標市場eBay雖然貨真價實是所有交易量與速度採用的重鎮,但完全是無心插柳,反而是由下往上推動的結果。」

當我請教拉布伊斯成功的關鍵轉折之祕,他指出一些要素。當企業規模還很袖珍,有時候關鍵轉折比較容易,以便減少整支團隊被打臉的痛感;要是新點子與舊想法之間有一個公分母存在通常也有幫助。

不過有時候微小改變還是不夠,你必須百分之百做到更好,」拉布伊斯說,「如果你只是在這裡和那裡加分10%,加起來也不會成就一家偉大的企業。而且如果你耗費時間與精力搞那10%的點子,就等於是耗盡所需的心智、時間與注意力,最終一無所成。所以我會覺得,你這名創業家花了大把時間卻沒有任何搞頭,而且要是你拿不出十倍的創造力,反倒耗光各種出色的新穎構想,那麼激進變革或許是更好的解方。」

一般來說,「多數關鍵轉折都行不通,」根據天使投資人依萊德.吉爾的說法,「它們行不通的原因是創辦人往往在同一個市場中原地轉身,而不是跨市轉向,但事實上原始市場根本就是爛市場。問題是,當人們大轉向時,多數時間他們會感受到龐大的沉沒成本,出於某種未知原因必須採用他們開發而成的既有產品。」吉爾告訴我,關鍵轉折往往是創辦人「打掉重練,從頭開始」比較管用。並非所有關鍵轉折都發生在構思階段初期。

英特爾最初其實是生產電腦記憶體的公司,後來才大轉向生產處理器,這是截然不同的產品類別,距離創辦之日整整隔了十六年。它原本穩掌記憶體晶片主要市占率,當日本競爭對手發動攻勢時獲利能力驟降,迫使這家企業重新思考策略。倘若英特爾死抱著記憶體業務不放,多年前的競爭可能就已經扼殺這家企業。

其他成功的關鍵轉折也陸續發生在這家企業整體生命週期的後期,涉及更激進的核心產品變革。Slack在第四年就從Glitch大轉向,當時它已募集1,700萬美元,銀行帳戶中還有500萬美元,外加一支35人團隊。製作播客內容的公司Odeo(譯注:和台灣的公關公司Odeo不是同一家)成立兩年後就募集600萬美元、14名全職員工,大轉向成為即時訊息發布平台推特。

關鍵轉折很艱苦,簡直苦到不行,可說是新創家在創業道路上做過的最艱難決定之一。他們冒著團隊與投資金主信心蕩然全失的風險,在許多情況下必須放棄某些受歡迎的觀點與大量的工作成果。請謹記,成功的關鍵轉折實屬例外。畢竟,關鍵轉折涉及原始手法或市場失敗就得嘗試全新手段或市場。不過若給源自研究顧客反應、觀察市場的全新想法一次機會,可能會比完全放棄更好。

我所見過最常見的關鍵轉折類型就是從主攻消費者(即企業對消費者,B2C)策略大轉向專門鎖定企業(即企業對企業,B2B)策略,反之亦然。就企業對消費者的公司來說,往往是發生創辦人明瞭對產品來說,贏取顧客芳心的成本高如天價,因此想要試圖將產品改成企業合用的工具。同理,就企業對企業的公司來說,則是發生在消費者銷售週期拉得太長,創辦人相信他們直接鎖定消費者反而可以做得更輕鬆。

雖說這種型態的關鍵轉折有時確實奏效,但多數時候是功虧一簣。企業試圖為顧客解決的原始問題,姑且不管對象是消費者或企業,通常迫切程度都遠低於創辦人自己腦補,因此關鍵轉折並未解決實質問題:市場需求。萬一你正在經歷這種類型的關鍵轉折,請驗證顧客需求真實存在,這一點遠比銷售週期或贏取客戶的成本更重要,後兩者可能意味著市場需求不存在。

關鍵轉折最重要部分在於,在你的銀行帳戶還有資金時,有能力執行關鍵轉折然後坐等看它發酵。這是新創家面對關鍵轉折時尚能掌握控制權的少數領域,這一步強調精簡花費的忠告,直到你看見產品與市場道同契合的曙光。除非市場明顯向你手中的產品招手,否則請勿招聘業務與行銷團隊。如果你不是很確定自己是否看見產品與市場道同契合的曙光,很可能你根本就是沒看到。

「企業最常犯的錯誤之一就是,產品都還無法留住現有客戶,就試圖以非自然的方式開發贏取顧客的管道。那等於是將燃料倒入漏油的引擎裡,」格雷洛夥伴合夥人莎拉.郭(Sarah Guo)說,「承認一項產品還看不到產品與市場道同契合的曙光,確實很困難也很讓人害怕。關注所有次要議題容易得多,不過除非你看到了(當然,連同交付產品的初始團隊),否則沒有什麼其他的事更重要。現實情況是,多數新創公司都看不到產品與市場道同契合的曙光,這是它們致命的肇因。」

請勿愛上你的點子,請勿盲目相信。只要你是一家高速成長新創公司的核心階層或屢獲殊榮的學者,市場就會自動張臂擁抱你的產品,請打開心胸,傾聽顧客的心聲。確保你有效、徹底地向員工及投資金主傳達你的思維過程,這樣一來關鍵轉折就不會覺得像是拉布伊斯所描述的校車瘋狂大轉向,請保持小規模團隊有助你做到這一點。

你若不是為同一批顧客改變產品,就是為同一批產品另尋顧客。要是兩套策略都不管用,請檢視一下你的團隊有何獨特能耐,然後發想出新點子。在後者情況下,你可能想要打造一家新公司,清除股權結構表(股東的相關紀錄)與債務,並將銀行帳戶中的資金還給投資金主,並提供之前的投資金主一次機會入股新公司。

最後,務必請確認自己與共同創辦人的狀況,以便確定你們實際上是否仍對進入新市場創辦企業或面對新顧客懷抱熱情。如果你看不到自己未來十年間依舊循著願景前進,或許就此關門大吉吧,要是資金還有剩的話,還給投資金主反而是更好的主意。

書籍介紹

本文摘錄自《獨角獸創業勝經:大數據分析200+家新創帝國,從創造、轉折、募資到衝破市場,揭開成功的真正關鍵》,商周出版

作者:阿里.塔馬瑟(Ali Tamaseb)
譯者:吳慕書、游懿萱

  • momo網路書店
  • Pubu電子書城結帳時輸入TNL83,可享全站83折優惠(部分商品除外,如實體、成人及指定優惠商品,不得與其他優惠併用)
  • 透過以上連結購書,《關鍵評論網》將由此獲得分潤收益。

Zoom , Spotify , SpaceX , Coinbase , Airbnb , LinkedIn……
15位創業家/投資人現身說法
本書分析重量級獨角獸,
以全新概念翻轉大眾對成功者的迷思,
你將會看到獨角獸們如何從嗅出市場需求到創造高收益!

  • 什麼是獨角獸?

成立不到10年,市值10億美元以上,且未上市的新創公司,被喻為「獨角獸」。

破解迷思:要成為獨角獸,年齡、學歷、職涯背景至關重要?

獨角獸創辦人都很年輕?
→不是,有半數的獨角獸創辦人年紀都超過34歲。

他們都從大學輟學?
→不是,大學輟學生的比例,比擁有博士學位的還低。

單一創辦人很吃虧?
→單一創辦人占20%,比想像的多!

他們都是該領域的專家?
→不是,超過50%的獨角獸創辦人沒有在該產業工作過。

  • 如何創辦獨角獸?

獨角獸如何選擇產品定位?止痛型產品更有機會成功?維他命型產品較易被取代?
創辦人是選擇切入有確定需求的大市場,還是勇於開創市場?
獨角獸易傾向B2B還是向B2C發展?他們如何度過關鍵轉折?如何打造護城河?如何向投資人募資?

獨角獸如何在鉅變的市場浪潮中脫穎而出,他們憑什麼能衝破市場,走向頂尖,改變世界?

  • 揭露獨角獸的草創故事

IG前身為Burbn,且具備超多功能,包含:打卡、發送照片和文字、造訪據點的積分系統。「我們做出什麼都包的App,但是功能多到超載,整體雜亂無序。要下打掉重練的決心真的很艱難,但是我們豁出去了,砍掉App大部分的功能,只留下照片、評論和按讚,剩下的這些,就是IG了。」IG創辦人凱文.希斯卓(Kevin Systrom)說。

Flickr原本只是一款遊戲的小功能?史都華.巴特菲(Stewart Butterfield)在2002年創立遊戲公司Neverending,雖然未成功,不過當初為這款遊戲開發的其中一項功能是共享圖片,巴特菲與他的團隊決定重新設計這項功能,作為獨立運作的網站,最後取名為Flickr。在當時,共享圖片算是很新穎的概念,其他網站運作只為了存放或列印照片,沒有人為攝影達人開闢分享作品的空間。Flickr取得小幅成功,2005年雅虎出價3,500萬美元收購,一舉讓巴特菲成為超級創業家。

大家知道YouTube是一座海量影音分享平台,但它原本應該是約會網站。「我們一直覺得,網站上要可以播放影片,但實際應用究竟是什麼?」YouTube共同創辦人陳士駿說,「我們就想,約會將是顯而易見的選擇。」不過,他們沒有狂熱地非要打造約會產品不可;反之從中看到蠢蠢欲動的商機,亦即不斷成長的網路寬頻與分享影片趨勢合為一體。很快地,鄉民紛紛上傳各式各樣的影片:烹飪教程、業餘音樂影片以及喵星人影片。2006年Google出價16億5,000萬美元收購YouTube,至今仍是Google史上最大手筆收購案。

  • 你能從超級獨角獸們身上得到

iPod之父、iPhone共同發明者湯尼.法戴爾告訴你:打造高度差異化產品有多麼重要。
Zoom創辦人袁征述說:在市場如此競爭之際,如何讓產品無可匹敵。
Coinbase創辦人布萊恩.阿姆斯壯和佛瑞德.艾爾森如何勇闖需求甚小但成長飛快的市場,實現消費者安全存放並買賣虛擬貨幣的平台
紅杉資本林君叡和彼得.提爾教你:應如何正確向創投投資人募資。

你將可借助書中獨角獸們的經驗,增加成功機會!

本書以大數據探究全球最成功的新創公司,破解創業長久以來讓人卻步的繆論,如創辦人年齡、學歷、職涯背景等迷思,以實際案例解碼產品策略、市場規模、行業競爭、資金來源,整理出成功創業的真實面向,並融合知名獨角獸草創真實故事,對創業提出嶄新的見解!

獨角獸創業聖經_立體書封(加書腰_300dpi)
Photo Credit: 商周出版

責任編輯:翁世航
核稿編輯:丁肇九


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 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 部可以獲得以下三大好處。

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。

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

了解 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。

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


猜你喜歡