据晶少了解，国庆假期后的首个工作日，AWS就在中国区域放出了一款“重量级”容器服务，名为 AWS Fargate，光环新网运营的 AWS 中国（北京）区域和西云数据运营的 AWS 中国（宁夏）区域均提供该项服务。

据悉这是一款可以适用于 Amazon ECS的计算引擎，主要帮助企业在生产过程中运行容器、却无需部署或者管理服务器，换句话说就是专注设计和构建应用程序，而不用挂心太多基础设施的“那些事儿”。

不得不说，针对容器服务的需求定位，AWS Fargate可谓一击即中，这一点从AWS现代化应用产品市场负责人Aaron Kao的介绍中我们就能深深感受到。

一段时间以来，以AWS为首的云服务提供商都会听到很多相似的用户反馈，其中构建属于自己的现代应用成为企业们不得不积极追逐并实现的。什么是现代应用？想必全球化、大规模，毫秒级延迟、PB级数据以及多模态等诸多特性是不可缺少的。

早在2000年，亚马逊网站构建的是单体性质的应用(monolithic application)，非常大型但敏捷性表现缺乏。具体来说如果想要在其中添加新产品，必须做到对源代码进行编辑与修改，很多团队需要集中在一个管道中进行单体应用的开发，效率之低可想而知。

“2001年，我们想改变这种构建应用的方式，所以就分解成多个微服务的架构，打造'双披萨团队'，这是一次组织上的变革，为的就是达成更加迅速的开发效率。”交谈中，晶少得知，所谓“双披萨团队”直观意义上是指团队成员的数量只需要两个披萨就可以满足食欲；引申来说则是这种配置的团队完全负责自身开发的服务，对应用有绝对的所有权，从发现应用、开发再到部署等环节，具备全面的问责机制，有人称这就是DevOps开发应用的模式。

从单一到微服务的过渡，我们发觉计算也在随着时间而变化，从虚机到各种实例的类型，然后是容器的崛起、无服务器计算Lambda的兴起。我们看到很多客户在容器方面做了许多有意思的事情，比如说麦当劳，推出了一个送货上门的服务，是在四个月之内使用Amazon ECS上运行的微服务而达成。

据悉这个云原生的微服务架构可以用不到100毫秒的延迟扩展到每秒两万个订单，而且能够轻松与全球交付合作伙伴进行集成。这是亚马逊对现代应用构建模式的探究，如今成千上万的用户早已经踏上了这条探索之旅。

回到AWS Fargate的新鲜出炉，归根到底还是在用户构建现代应用的过程中使用容器带来的启发。大家在此过程中经常会想到一个问题，如何对手上的容器进行整合？使用Fargate服务之后，用户就不需亲手处理服务器以及基础架构方面的工作，也能做到快速推出和扩充容器应用，这个过程只需要根据自身使用服务的情况完成付费即可。

提及安全的无服务器体验，不必花费过多精力管理基础设施的要求，我们至今记忆犹新，在2014 年 re:Invent 大会上发布的Lambda，如今Lambda 每月为数十万活跃客户处理数万亿次执行。作为事件驱动的无服务器计算的应用，Lambda 能够允许用户无需预配或者管理服务器即可运行代码，只需按被消耗的计算时间付费。

具体来说它能够自动扩展到工作负载，适用于流行的IDE工具包，也可以通过嵌套应用简化部署来提高工作效率；另外在不断增加功能集成方面，例如集成Lambda应用负载均衡、Lambda SQS等。

举个例子来说，作为使用AWS Lambda的用户，可口可乐公司高效使用Lambda和STEP函数来更新自动售货机通行证应用，并通过Lambda管理计算实例来促进开发人员进行创新，甚至可以做到让工程人员在几天内快速构建和部署新功能。截至目前的不完全统计，已经有数十万用户在使用AWS Lambda的过程中成功建立微服务以及现代化应用。

表述到这里，关于Fargate和Lambda的关系，可能会有很多人心存困惑，同样是专注应用与上层架构，区别呢？本质上来说，Fargate和Lambda是构建和包装客户应用的两种不同方式。如果用户想着手容器层面的运行，并将其包装成为容器类型的服务，即可以使用Fargate；如果用户只是要作为函数来打包代码的话 ，提及触发器就可以运用Lambda，简单来说用户想要涉及控制权的多少，以此来衡量抽象化的程度。

例如，美国金融业监管局FINRA，它主要针对美国证券交易市场上数以千计的证交所交易人员、几十亿美金的交易进行跟踪，发现可能的欺诈行为。“这样的工作内容决定有时候会遇到峰值情况，眼下的资源不够使用，所以就可以切换到Lambda来达成计算速度并满足峰值要求；美国著名的媒体公司Turner，因为不想花费太多精力掌管旗下的诸多实例，所以将其迁移到Fargate上，着手打造一个网站共享服务平台，不但降低成本还缩短了开发时间。”

如此一来，从产品和服务触发，我们观察到AWS容器服务的整体格局，广泛性是表现突出一个特点。“整体涵盖三个层面，最底层是弹性的映像注册表，即Amazon ECR (Amazon Elastic Container Registry)，可以存储容器映像文件且非常易用；中间层是计算引擎，容器要运行在某个计算平台上就可以使用Amazon EC2作为启动类型，也可以使用AWS Fargate来启动无服务器运行等；此外编排层，可以根据客户的需求选择，如果并没有自己明确的倾向，如果要求抽象水平低并专注于基础架构或者配置等，用户也可以自己搭建编排服务。” Aaron Kao表示。

谈整体后，聚焦如今大火的K8S，Aaron Kao进一步阐述随着时间的推移，用户又提及了关于Kubernetes的诸多需求，或许这就是推出Amazon Elastic Kubernetes Services的原因，那AWS的Kubernetes究竟优势何在？

众所周知，EKS是运行生产级工作负载的平台，安全和可靠是重中之重。“我们提供原生和上游（native and upstream)的Kubernetes体验，AWS的Kubernetes服务与开源层面的Kubernetes运行完全一样；此外我们还与社区共同合作，将代码贡献给上游。”

毋庸置疑，用户选择AWS之初很重要的一点就是服务的深度与广度，从存储服务、管理服务等出发的165种不同种类的云服务，可以高效帮助在EKS方面与AWS平台实现无缝的集成，能力的全面释放不容小觑。

具体来说，用户是如何使用Amazon EKS呢？整个过程主要包括通过微服务、平台即服务这样的运行架构，当然也有使用EKS来进行企业应用的迁移，此外还涉及到某些用户使用EKS进行机器学习等。“未来我们还要做的一些事情确保EKS针对任何想要用AWS的客户来说都是极其友善的，比如让EKS与AWS Identity and Access Management (IAM) 集成，每一个EKS的Pods都可以获得IAM的许可。相信EKS很快会在AWS中国（北京）区域、AWS中国（宁夏）区域、AWS南美洲（圣保罗）区域推出，值得提及的是目前51%的Kubernetes工作负载都在AWS上运行。”

除了让EKS使用起来更具友善之外，KAO表示更重要的创新举措还会集中在全堆栈的方向，例如硬件层面的Nitro系统，可以提高性能和硬件安全且让Hypervisor（虚拟机管理程序）更有效地运行；软件层面的Firecracker，作为一个开源的微虚机，让用户在运行容器时可以更安全。

据晶少获知的消息，这项用于运行多租户容器工作负载的新型虚拟化技术与开源项目，能够让服务拥有者将容器实现的速度、资源效率和性能与传统虚拟机的安全性与隔离性结合，从而运行基于容器的、安全的多租户服务。

Firecracker 在 Linux 基于内核的虚拟机 (KVM) 上运行虚拟机管理程序 (VMM)，并提供 RESTful API 来创建和管理具备任何 vCPU 和内存组合的微虚拟机，从而满足应用程序的需求。

作为Apache 2.0 下的开源项目，其设备模拟量低的特性可以缩短启动时间、减少每个微虚拟机的内存占用空间，并为每个容器提供可信赖的沙盒环境。目前Firecracker 支持 Intel 处理器，并会在 2019 年推出对 AMD 和 ARM 的支持。 

“我们与客户密切合作，其密切程度可以集中表现在90%的产品路线图都来源于用户，他们会准确地告诉我们，希望达成的技术未来将是如何？未来我们的重点还是专注于安全性、可用性、可靠性以及开发人员、工具方面的创新，但用户需求是关键，这一点绝对重要。”

推荐阅读：