【深度專訪AWS雲端架構策略副總裁】衝刺數位轉型，企業需要什麼IT新架構？

他是打造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飆速關鍵大公開