Adrian Cockcroft有雲端第一架構師的美稱,也曾入選雲端運算年度十大關鍵人物。 (攝影/洪政偉)

他是打造Netflix全球服務架構的關鍵人物。早在2009年,當時擔任Netflix網站工程總監的Adrian Cockcroft,就開始率領團隊藉助AWS雲端基礎架構,來改造Netflix的IT架構。這個關鍵基礎建設,更助Netflix奠定了全球影片串流服務的龍頭地位。Netflix還大方公開了這套轉型上雲端的經驗,甚至打包自己開發的工具和架構設計範本,開源釋出了NetflixOSS平臺,這也成了設計雲端原生架構的最佳實務參考之一。

當時,Adrian Cockcroft被譽為比AWS更懂得善用AWS的架構師,更有雲端第一架構師的美稱,科技圈也將他選入雲端運算年度十大關鍵人物之一。

Adrian Cockcroft不只熟諳雲端技術和軟體技術,他更是高效能電腦技術的專家,曾在昇陽電腦任職長達16年,最後成為昇陽高效能工業計算(HPTC)部門的首席架構師。2004年離開昇陽,轉而進入eBay,成為eBay Research Lab創始團隊一員。早在iPhone和Android手機問世之前,Adrian Cockcroft就開始研發自製手機和先進行動應用。

他在2007年進入Netflix,負責Netflix首頁和個人化選片服務,也參與了SOA架構的導入。2010年成為Netflix雲端架構長,率領12人團隊重新設計資訊架構,打造出Netflix雲端新架構,後來成為微服務架構的經典。

2014年,Adrian Cockcroft轉而進入Battery Ventures創投擔任技術院士,從更宏觀的角度,來觀察科技產業、網路新創、創新技術的發展。2年前進入AWS擔任雲端架構策略副總裁,不只帶領AWS的開源推動工作,也開始到各國分享自己一路參與雲端架構發展的經驗。趁Adrian Cockcroft近日來臺之際,iThome特別專訪他對雲端架構趨勢與企業數位轉型關鍵的觀察。

Q:為何當年Netflix敢決定把關鍵網站搬上雲端?

A:大膽是Netflix根本的文化。一部份來自公司領導高層,特別是創辦人Reed Hastings,他是很願意投入創新嘗試的人。Netflix喜歡做「不易複製」(Hard copy)的事,就是別人看到會想複製,但又很難複製的事,Netflix也很享受這樣的作風。

Q:當時你如何說服管理階層,接受全上雲端的策略呢?

A:不是我說服他們,反而是管理團隊來說服工程團隊,要採取「全上雲端」的策略。Netflix當時有兩項主要業務,一是DVD出租服務,其次是影片串流服務。串流服務的發展非常快速,對於運算有很大的需求。管理團隊當時最大的煩惱是,運算能力的擴充速度,能不能支持業務的成長需求。

從DVD租片到串流服務,是一種數位轉型帶來的需求改變。就好比,一家零售業者,過去透過零售店面來銷售產品,就算店面擴張到上百家,IT的運算力,只需要擴充到足以滿足這一百家店面就夠了。但是,經營型態數位化後,IT不只要支援生產或銷售所需的系統,還需要直接滿足第一線的終端顧客。

過去租片業務,IT只需考慮幾百家店的連線存取需求,但串流服務不一樣,得直接服務顧客,這是數百萬名顧客以及數百萬個播放裝置的挑戰規模。從支援數百個用戶端,到有能力支持百萬等級規模的連線需求,而且是隨時上線的需求。IT得面臨,不只是幾倍成長的挑戰,而是上千倍成長的衝擊。這是所有面臨數位轉型企業共通的挑戰。

Q:但為何是管理階層發動轉型,而不是IT?

A:Netflix管理階層也頗有技術能力,這是部分原因。但關鍵原因是,這是Netflix當時最大的風險,IT若無法支持擴充需求,公司就會失敗。

Q:臺灣不少企業也想擁抱數位轉型,管理階層要有技術能力,才能順利啟動嗎?

A:不一定必要。如何解決商業上的問題,是企業永遠的課題。不能只看到有新科技,就想用,雖然這可能很有趣,但企業不應該如此。企業要去解決商業的問題。企業可分成三種,多數企業儘管追求效率,但只是一種不想落後對手的態度,這是安全牌的企業。但有些企業則是有種什麼都要搶第一,這是領導型企業,Netflix就是這類企業,想要搶占市場大宗,各種類型的顧客都要滿足,雖然只是少數,但AWS會找出這群顧客,花時間了解他們的需求,因為安全牌顧客後來都會想要具備領導型企業的能力。

Netflix就是那種率先衝進叢林打頭陣開路的領導型企業,多數人則是想走在這條開拓出來的道路,安全地前進。第三種則是落後型企業,忽然才發現,大家都往前進了,自己才開始擔心如何跟上隊伍。

Q:除了業務面的轉型,IT架構如何改變,來滿足轉型所需?

A:Netflix在自家資料中心部署的內部系統(on-premise),都是大部頭式(monolithic)的大型系統,我們把它打破成一塊塊小型服務,再部署到雲端成為各種微服務。Netflix上雲端就是從大部頭系統到微服務的轉型之路。

Q:上雲端轉移,花了多久時間?

A:至少花了2年,光是前端系統上雲端,就花了1年,包括從學習如何拆解,後來腳步比較快,但也花了一年才將後端系統和資料庫搬上雲。前端系統和後端系統分成兩階段來進行。在資料中心的運作,其實很慢,資源調度和分配得花很長的時間,技術改變的腳步也很慢,打造各種內部流程,希望穩妥完成工作,但你就是在打造一套緩慢的大系統。大部頭系統就是這樣的系統,所有的改變都相互綁定在一起,因為你不得不如此。

當你希望緩慢穩定前進時,大部頭系統是對的架構。但是,在雲端,幾分鐘就可以增加一臺機器,你應該藉由做「小事」來提高效率,所以,要打破成微服務型態,因為每一小塊服務,都可以獨立且快速地改變。對速度的需求,系統自然發展成最理想的架構。(編按:Neflix仍有少數資料在本地端,直到2016年)

Q:你自己設計出整套新架構嗎?

A:不,我率領了一個12人團隊,我們一起打造出所有的新架構。

Q:第一步從哪裡開始?你當時幾乎沒有前例可參考?

A:改變要從最簡單的地方開始。因為你必須藉此學習新技術、新平臺和新模式,來了解如何上雲端部署任何事情。第一步要從最簡單的工作開始,然後才逐漸嘗試更複雜的工作,逐漸就會學會新技術,也會熟悉新平臺。Netflix服務是網站,我們從最簡單的那一個網頁開始,一次一頁。最後才是最複雜的那一頁。同時有兩套系統並行,一開始用戶瀏覽Netflix網站時,有些網頁在資料中心內執行,另一些則是在雲端。幾乎花了一年才全部搬上雲,但透過轉址切換,顧客其實不會發現。

Q:這個作法現在還適用嗎?如果臺灣企業想把自家系統搬上雲端?

A:是的,我認為還適用。就算你的網站再複雜,還是一次搬一頁最好。但現在可能比較容易,因為企業的行動應用,多半會不只用到資料中心提供的後端API,也會用到不少雲端服務的API,這會讓轉移工作變得更容易一些。但基本原則是要採取漸進式作法,一次轉移一個功能。

Q:你從Netflix學到什麼經驗?至今仍適用嗎?

A:我從Netflix上雲學到的第一個經驗就是,Netflix先為了追求速度而展開優化轉型,也因此而贏得市場,因為可以比市場上任何人都跑得更快。速度致勝,至今不論那個產業都還是如此,跑得快的人可以贏得市場。Uber、Lyft、Airbnb、Expedia都是因為雲而速度很快的公司。世界現在變得更快,技術也是,更要善用這些技術來加速自己。

很多公司是自己綁住自己,自己設置了很多內部門檻,其實可以簡單一點,不要花了6個月才做出決定,但只用1個禮拜就完成工作。利用科技只需1周時間的工作,卻耗上數個月,這就是問題。所以,第二項經驗是,產品開發過程要盡可能減少摩擦。快速決策是數位轉型的其中一項關鍵,要讓各種決策的發生,更加自主和自動化,

Amazon有個披薩團隊的比喻,團隊要小又獨立,10個人左右剛剛好,產品經理、維運、開發人員都組隊在一起,共同讓產品更好。保持獨立運作,但要和產品相關的團隊保持聯繫。這也是我在Netflix看到的工作模式,去除磨擦,就可以加速決策,這正是讓企業組織變快的方法。

第三項經驗是「最高信任,最少流程,避免工作在團隊間輪流接棒。」寫完一段程式碼,何時才能上線執行?傳統企業得花上好幾個月,但在現代化企業,可能只要幾分鐘,不用開會,只需一張工作單發動任務,透過持續整合、持續派送自動化完成。

要衡量一個組織的績效,要用創造價值的時間(Time to Value)來評估,對開發團隊而言,就是看一段程式碼從提交(Commit)到上線執行,花了多久時間。這是最好的績效指標,任何影響,最後都會反應到這個指標上。

例如越少開會,這個時間就能越短。有些企業得花上幾個月,甚至程式碼寫完永遠無法抵達顧客,因為專案最終還沒上線就取消了。今天寫完,明天上線,這是對開發者最好的獎勵,也能讓你的產品持續改善,每一天都變得更好,這是一個新世界。

Q:非科技公司,尤其是傳統企業也能適用這樣的快速開發模式嗎?

A:所有企業,現在都是科技公司。Netflix其實是內容產業,不只用前所未有的方式來拍攝電視劇,還用更有效率的方法來製作,也比任何人更能瞄準受眾。過去只能用猜測,但Netflix現在可以清楚知道每一部電影,有多少人看,誰在看,都能知道。Netflix再用這些資料來優化業務所打造的內容,科技只是負責派送和記錄,看電視才是Netflix真正的生意,科技只是工具。

任何非科技公司,都能複製這樣的模式。就算是食品業,儘管仍舊需要在實體世界生產、製作和運送食物,但你對顧客的了解越多,甚至透過直接銷售的方式,來掌握顧客的特性,你就越能優化你的生產過程,甚至改變商業模式。數位轉型就是回到基礎,思考企業商業模式的改變。

尤其現在許多產品連上網路,不只可以與顧客有更多聯繫,也可以讓產品來告訴你要如何改善,許多智慧家電就是如此。這是一個商業模式的大改變,也需要開發應用程式來輔助這件事。

Q:開發新應用最好直接採用微服務架構嗎?

A:不,現在開發新應用,最好優先採用Serverless架構。可以快速完成你的App,再持續根據顧客需求來優化。例如服務網路流量很大,可以改租用PaaS來分攤部分Serverless上的服務。或你需要快速回應的App,就專注於優化網路延遲。但使用Serverless服務,設計出你的應用系統的第一個版本,只需要幾天。Serverless架構就是要排除中間的障礙,讓你盡快嘗試技術。

Q:採用Serverless架構的代價是什麼?

A:應用程式的設計得有一定的妥協,來適應Serverless服務可以提供的功能。

就像要打造一款玩具太空梭,傳統作法是你得先設計太空梭玩具的原型,再用黏土來複製每一個零件模型,接著用黏土模型來鑄造出每個零件的模具,就可以大批鑄造生產零件,再來組出一臺臺太空梭玩具,這就是傳統的瀑布式開發流程,得花上幾個月才能開發一套系統,再部署到不同環境或各地據點中。

但新的快速開發模式(Rapid Development)截然不同,而是改用樂高積木來組合太空梭,幾個小時就能組裝出一個太空梭玩具。這臺樂高太空梭仍舊可以玩,顏色搭配也可以長得像是當初設計的原型,但精細程度比不上鑄造組裝的版本。你得和樂高積木提供的那幾種積木型態妥協。這就是用Serverless的代價,得適應Serverless提供的功能選擇,但帶來的好處是,可用(依舊可玩)、可靠(堅固)、容易局部調整,而且快速完成。這是我最喜歡的比喻。

你要了解各種功能型服務的能耐和限制,如AWS提供的SQS、Kinesis、S3、DynamoDB,以及AWS Lambda等,這些都是AWS上實現Serverless架構的積木,研究如何組合這些服務,來解決你的需求。

 相關報導  企業IT飆速關鍵大公開

熱門新聞

Advertisement