【深度专访AWS云端架构策略副总裁】冲刺数位转型企业需要什么IT新架构

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飙速关键大公开