AWS云端架构策略副总裁:飙速开发又有新方向,Serverless是容器和微服务的下一步
2018-07-14 10:25:35 | 来源:ithome | 投稿:小柯 | 编辑:dations

原标题:AWS云端架构策略副总裁:飙速开发又有新方向,Serverless是容器和微服务的下一步

图片来源:

资料来源:Adrian△Cockcroft,iThome整理,2018年7月

早在2015年冬天AWS年度大会一场演讲中,AWS云端架构策略副总裁Adrian△Cockcroft就预言,Serverless将是下一阶段的云端架构方向。当时,Docker崛起才2年,正是红遍半边天的IT明日技术。但Adrian△Cockcroft从IT飙速的角度来看,他当时就指出,可以提供毫秒级部署能力,也只需存活数秒钟的AWS△Lambda(这是AWS率先推出的Serverless服务),将比容器化部署更有速度力。当时他还没进入AWS,而是在技术创投担任技术评估者和推广者。

Serverless的发展也如Adrian△Cockcroft所预言的,越来越兴盛,甚至不只AWS,其他云端巨头也相继推出Serverless服务,近年更结合了边缘运算架构和AI认知服务,扩大了Serverless服务的运用型态。

Adrian△Cockcroft后来更进一步从商业逻辑的发展变化,将近10年来企业IT架构演进分为三个阶段,分别是Monolith分裂(大部头架构分裂)、Microservice(微服务架构)和Functions(功能架构)。

Monolith架构是早期大型主机时代的架构,将所有功能和服务都集中到一个庞大、复杂的系统中,但在十年前,因为单一系统过于复杂、缓慢,这个主流架构开始分裂。不过,他解释,当时CPU速度和网络效能还不够快,只能依赖XML和SOAP协议来传输讯息,因此只能将大部头系统切割成规模较小的服务,一个服务仍旧包含了大量不同类型功能,依旧是大部头式的复合式服务。

5年前,微服务架构开始崛起,开始分门别类地更进一步来切割服务的用途,而不同类型服务之间也更容易进行双向沟通,也容易通过服务架构来存取各类储存服务或快取机制,应用系统和储存硬件间容易通过服务串接。

2014、2015年,企业开始拥抱云端,愿意把自家应用搬上云端,这更促成微服务架构的普及,因为Restful△API开始成为微服务架构的讯息传递方式后,不只可以串接内部各种微服务,也很容易串接到云端上的专用型服务。而“容器技术的出现,让微服务架构变得更容易也更快导入。”他解释,因为容器技术带来新的应用程序部署模式。

Adrian△Cockcroft用笔电软件升级过程来比喻。过去,得不断更新笔电中的软件,才能享受到新功能。但是,若笔电价格非常便宜时,甚至是只要几百美元就可以拥有一部低价Chromebook,一旦发生问题,直接换一台新的笔电更省事。容器技术降低了应用程序部署和封装的时间成本,也带来了新的部署作法,就是“直接换新免升级”,这就是Docker所能提供的Immutable打包更新作法。一旦将微服务容器化之后,一来更容易跨平台、跨云、跨不同环境来部署相同的微服务,要更新时,也不用关闭正在执行的微服务,修改完再重上线,而是直接部署新版微服务,再关闭旧版微服务,就像是直接换一台新笔电,就可以获得新功能,而旧笔电就直接作废,不用来进行软件更新。

不过,经过这几年,许多常用服务都已经标准化,也成为云端服务平台提供的基础服务元件,彼此再通过API来沟通,这也是许多企业开始用云端平台提供的服务来组合出自己的微服务架构,而不会全部自建。而实现应用程序商业逻辑的程式,其实会反映在串接这些常用服务之间的程式上,而且这些串接常用服务的机制,往往不用永久存在,只有需要的时候才执行,执行完成了,就可以下线。因此而出现了像AWS△Lambda这类的Serverless服务。

而Serverless服务就是一种Functions架构的服务,是将微服务打破成更小的单位,也就是按照功能来打包成最基本的程式单位或程式积木。“Functions很简单,一次只做一件事,但微服务还是要提供一个介面。Functions等于是更小型也更专注的微服务。”Adrian△Cockcroft指出,你可以将一个Functions转变成一项服务,这就是一个只提供单一功能的微服务,但有些微服务更加复杂。

AWS云端架构策略副总裁Adrian△Cockcroft喜欢用太空梭玩具生产方式来比喻新旧开发模式的差别。传统(瀑布式)开发,从黏土模型、鑄模、大量生产零件到组装完成一个精致的玩具,需要好几个月,但飙速开发(Rapid)则通过标准化、可组合的乐高积木(如自制容器化服务或Serverless服务),只需要几个小时就可以先打造出一个可用又容易修改的太空梭玩具。

?

微服务和Serverless可组合运用

微服务和Serverless其实不冲突,而是可以组合运用的架构。举例来说,容器化的微服务,可以负责那些低延迟而需长久存在的功能,例如即时控制、硬件驱动等,但通过API介面,不同应用程序的商业逻辑则可通过Serverless的功能来实现,再通过API串接两者。“这正是打造现代应用程序该有的方式。”Adrian△Cockcroft表示。

他建议,现在若要开发新应用,最好优先采用Serverless架构,快速完成需要的App,再持续根据顾客需求来优化。例如服务网络流量很大,可以改租用PaaS来分摊部分Serverless上的服务。或先需要有能快速回应的Ap,再来专注于优化网络延迟。“使用Serverless服务,设计出你的应用系统的第一个版本,只需要几天。”

通过Serverless标准功能服务,更容易实现飙速开发

不过,想要利用标准化的微服务或功能性的Serverless来打造应用程序,“得先适应Serverless服务可提供的功能。”他说,但可以更容易实现新的飙速开发模式(Rapid△Development)。

Adrian△Cockcroft以打造玩具太空梭来比喻新旧开发模式的差异。传统作法是,你得先设计太空梭玩具的原型,再用黏土来复制每一个零件模型,接着用黏土模型来鑄造出每个零件的模具,就可以大批鑄造生产零件,再来组出一个个太空梭玩具,这就是传统的瀑布式开发流程,得花上几个月才能开发一套系统,在部署到不同环境或各地据点中。

而新的飙速开发模式截然不同,是改用乐高积木来组合太空梭,几个小时就能组装出一个太空梭玩具。这台乐高太空梭仍旧可以玩,颜色搭配也可以长得像是当初设计的原型,但精细程度比不上鑄造组装的版本。这类积木可以自己开发,或用容器技术来打包出容易再利用的常用程式积木,也可以使用Serverless提供的功能。“使用Serverless好处是,最后组装出来的太空梭玩具,可用(依旧可玩)、可靠(坚固)、容易局部调整,但最重要的是能够快速完成。”他说。

不少企业担心,系统架构改用微服务架构和容器技术后,长期维护工作将会越来越困难?不过,Adrian△Cockcroft认为,服务种类和数量变多了,就像乐高积木越出越多款,组合工作不会变得太难,“只有一开始找对积木得费一番功夫”他更进一步指出,拆碎后的微服务,每一个都独立运作,可以掌握且限制其权限和用途,因此“微服务架构反而Monolithic架构更简单,因为微服务的复杂度可以被看见。”他说。

?相关报道? 企业IT飙速关键大公开

tags:

上一篇  下一篇

相关:

微软延长支援Windows Server、SQL Server 2008/2008 R2,条件是搬上云端

图片来源: 微软 微软拥有广大用户的SQL△Server及Windows△Server△2008即将在明年和后年结束延伸支援。微软周四提供了新的选项:搬移到Azure云上。根据微软的支援方案,SQL△Server△2008/2008 R2的延伸支援将在201

加强云端DevOps功能,甲骨文公有云服务推出Ansible模组

除资料库、ERP产品,公有云是甲骨文近年加强经营力道的事业,在今年陆续加强对Kubernetes、GPU的支援,也与Cloudera合作,让企业用户可以在该公有云平台使用Cloudera的资料仓储、串流分析等服务。而除扩张平台的大数

微软AKS推开发人员空间功能,简化容器开发环境建置工作

非常早就积极拥抱容器服务的微软,在今年6月Azure代管Kubernetes服务(Azure△Kubernetes△Service,AKS)推出正式版后,周边的Visual△Studio、.NET生态系都陆续与Kubernetes整合。而现在微软又再加强AKS的开发者功

云端大量部署优先! Canonical推迷你作业系统Minimal Ubuntu,映像档只有29MB

在云端运算蔚为普及的时代,因应应用程序快速部署、开启及执行的需求,厂商也会推出相对轻薄的作业系统,适应云端原生环境。在2015年时,正逢Docker如日中天,许多厂商推出专属容器作业系统支援Docker,像是红帽Atom

Google开源释出Java容器化工具Jib,Java应用可以打包成容器映像档

根据全球知名热门开发语言排行榜TIOBE的资料显示,问世超过20年的Java程式语言,仍然是高居热门搜索的程式语言,广为开发者使用。而在Docker容器问世之后,让该技术技术跨平台、快速搬迁等性质,受到开发者欢迎,多家

站长推荐: