【专访AWS运算服务副总裁Deepak Singh】锁定企业本地端容器运算需求ECS Anywhere和EKS Anywhere有三大差异

原标题：【专访AWS运算服务副总裁Deepak Singh】锁定企业本地端容器运算需求ECS Anywhere和EKS Anywhere有三大差异

在2014年发表的容器服务，现在成了AWS运算服务中的关键核心。从2014年率领团队一手打造出容器服务产品线的产品和工程负责人，就是AWS运算服务副总裁Deepak Singh，在AWS发表最新的容器落地产品ECS Anywhere和EKS Anywhere之后，iThome也专访到这位AWS容器团队负责人，来剖析AWS最新容器产品的特色和布局。

Deepak Singh指出，AWS推出了ECS Anywhere和EKS Anywhere，让企业能够在自己的资料中心里，执行Amazon ECS和Amazon EKS，目的就是为了锁定企业本地端执行容器的需求，也能提供一套与AWS在云端相同管理和部署机制。

两项容器新产品都聚焦企业本地端容器运算需求，不过，两者还是有几项关键差异。Deepak Singh进一步说明了这些差异，并点出背后不同的产品定位和布局。

首先，两产品具不同的部署形式。EKS Anywhere将以软体形式推出，让企业在自己的资料中心使用EKS执行K8s，且在任何基础架构上皆可执行，包含裸机、VMware vSphere和VM。

不同于EKS Anywhere，ECS Anywhere将不会以纯软体形式推出。Deepak Singh表示，ECS Anywhere的运作方式与EKS Anywhere相当不一样，用户需在自家资料中心安装一个代理程式，以在本地端环境部署原生Amazon ECS任务（ECS容器映像档），他进一步指出，该ECS产品较偏似于以服务模式来提供，这是两者的关键差异之一。

其次，两者因具有不同的部署形式，背后的管理机制也不同。ECS Anywhere是由AWS管理。企业于本地端资料中心机器上安装ECS Anywhere代理程式后，将代理程式与距离最近的AWS区域连结，接着，执行于AWS区域中的控制层，会负责管理企业本地端资料中心内的所有容器，包含调度、排程等。Deepak Singh补充，因不清楚机器的规格和架构，AWS不会负责管理机器。

而管理、执行EKS Anywhere软体的职责，则属于企业。企业于本地端基础架构上，直接安装EKS软体，以执行Amazon EKS，管理丛集。Deepak Singh表示，AWS不会远端管理EKS控制层，不过，他也强调，这与企业于云端执行AWS EKS的方式，完全相同。企业可以借助AWS控制台中的整合式仪表板，来连结、查看在各处执行的所有K8s丛集和应用，并可以更新、管理丛集，还有进行故障排除。

也因为EKS Anywhere将以软体形式打包，提供企业安装，企业将可以自行客製和修改套件，这是另一个EKS Anywhere与ECS Anywhere的相异之处。Deepak Singh表示，企业可以添加任何他们想要的东西，于AWS提供之套件上，像是控制器，但，他也提到，AWS仅会支援他们所提供的东西。AWS不排除会提供一个建议清单，列出他们经测试后，已验证的自行添加项目。

EKS Anywhere软体套件不仅可让企业自行客製和修改，软体厂商也可以将自家软体整合进套件。Deepak Singh表示，刚推出由Amazon EKS部署相同开源K8s和相依项目的发行版EKS Distro，已获得许多软体供应商支援，期望当EKS Anywhere正式推出后，也有众多合作伙伴提供各项工具，像是提供管理面向的功能。

新容器落地产品无法提供AWS区域所有服务

AWS去年正式开卖的伺服器硬体AWS Outposts，其实，也可让企业在其上建立并执行EKS节点，以及建立ECS丛集。究竟透过Outposts于本地端执行ECS和EKS，与未来可通过ECS Anywhere和EKS Anywhere，在本地资料中心执行ECS和EKS，会有什么差别，Deepak Singh也做出了说明。

Deepak Singh表示，Outposts是全託管服务，执行于AWS硬体上，通过AWS网路与AWS区域连接，而可以提供众多AWS区域的功能，因此，在Outposts上执行ECS和EKS，与在AWS区域中使用两服务，两种使用情境的体验是非常相似。

然而，企业通过ECS Anywhere和EKS Anywhere，于自家资料中心执行服务，情况会有所不同。Deepak Singh表示，服务将不再执行于AWS网路，不再执行于AWS硬体，因此，一些可在Outposts和AWS区域获得的功能，将无法通过ECS Anywhere和EKS Anywhere取得。

像是Arm架构处理器Graviton、高效能区块储存服务EBS、採用Nitro系统的EC2执行实例等，缺少了这些功能也将使企业无法做某些事情，比如无法使用EC2进阶执行实例，则无法存取Nitro架构。

儘管，本地端容器新产品无法涵盖所有AWS区域能提供的云端服务，Deepak Singh强调，新产品聚焦解决的是，企业现于本地资料中心和AWS执行容器时，面临使用不同维运模式的问题，通过新容器落地产品，企业将可用相同的维运模式和工具，横跨自家资料中心和AWS，来执行容器。

AWS自己则早已积极拥抱容器技术多时，就连母公司亚马逊也是。Deepak Singh表示，如今，内部有约99%团队思考以容器为基础，来打造新服务，或是用以更新既有应用。目前正积极扩充的机器学习产品，就是一个内部团队大力採用容器技术的例子。Deepak Singh表示，几乎所有机器学习服务都是建立在ECS上，且他认为，採用容器的趋势只会加速。

但，为何AWS现今未选择全面以容器技术打造所有新服务，Deepak Singh对此也做出回应。他指出，有一些情况像是建置高效能资料库，需要一些EC2实例具有的特殊功能，来调校网路、伺服器，以获得最佳效能，这时候容器可能就不是最好的选择。不过，他强调，需使用EC2的特殊Runtime、数据处理等情况，将会越来越少，并将在未来几年内消失。

 相关报导  AWS后疫新战略