分析师视角 | Rancher如何成为全球客户众星捧月的企业K8S平台明星

本文作者为美国著名分析师James Governor。James Governor是RedMonk的首席分析师和创始人。他负责领导企业应用程序领域的相关分析报道,为客户提供应用程序开发、集成中间件和系统管理等问题的分析和建议。James Governor有十多年的从业经验,他的分析与观点常被美国和欧洲的媒体引用,他还曾任BBC等媒体机构的特邀行业专家。



Rancher Labs 于6月28日在旧金山举办了分析者大会。Rancher Labs在美国已拥有200多家付费企业客户,考虑Rancher产品的下载使用量,以及Rancher Labs只是一个成立短短4年的初创公司,这个付费客户数已经非常可观。此次分析者大会上,有13位客户代表进行了发言分享。整场分享没有在市场宣传上做大动作,而是密切关注于技术层面的干货输出。每一位发言人都提供了很有意思的技术见解。


K8S平台的强大功能VS简易性


Rancher  Labs CEO及联合创始人梁胜博士首先针对“平台的强大功能性VS.简易性”之间的取舍及对比展开了完整有力的讨论 。虽说AWS在推出伊始也很简单,但不可否认,AWS如今已变成了一个完整、功能强大的平台,拥有一系列先进功能来与传统企业供应商(如VMware)相抗衡。


正因如此,那些想使用开源产品(如原生Kubernetes平台)来避免技术锁定的用户,正面临“开源开放VS.方便强大”这个进退两难、难以抉择的困境。通常情况下,用户会选择“便捷”这一属性,这也是AWS如今能垄断市场的原因之一。


“做一个管理平台,仅仅是‘能在多云环境下均可使用’,这一特性是远远不够的,用户需要的是一个比让他们自己直接使用多云更优的解决方案。”梁胜博士表示,“为了推动用户对多种云的使用,市场期待比AWS更优的产品。”


这正是对Rancher以及业里其他玩家的挑战。只提供可移植性是不足够的——跨平台体验需要更好的表现方式。


当下市场广泛接受的一个观点是,我们需要云基础设施以及微服务更多地为用户服务,而不是要用户小心翼翼地去维护基础设施——粗暴点说,即虚拟机和容器需要是短暂且可抛弃的。在持续部署和应用镜像扩容的年代,服务是很难持续的。不断修修补补打补丁的方式,终将会被不可变基础架构取代。


最初当Docker腾飞时,Rancher Labs结合其自身一贯的简易、灵活的理念,创建了自己的容器编排和管理平台,称之为Cattle。Cattle能在开发人员的笔记本电脑上构建及管理Docker镜像,这一特性帮助Rancher 1.6赢得了业界的“易于部署和管理”的赞誉。


但在2017年,Kubernetes逐步赢得了容器编排工具之战,成为了标准的容器服务编排环境。Rancher Labs极具前瞻性地对Rancher产品做了重大升级转向,新推出的Rancher 2.0延续了Cattle一贯的简洁易用的特性,但成为了完全基于Kubernetes的平台。Rancher的这一决策也充分证明了我们前文所说的“灵活性”的理念。虽说不少客户认为 Cattle比Docker Swarm、Apache Mesos或Kubernetes更简单、更易于使用、甚至可能更适合他们的需求,但在2.0产品上他们不得不放弃对Cattle的使用。Rancher并不是唯一作出这样决策的公司 ——例如,Docker公司原本拥有自己的编排工具Swarm,但也在不久后宣布拥抱Kubernetes;Mesosphere现在也支持DC / OS上的Kubernetes。

Kubernetes不是哪家公司的竞争对手,当下情况是,业界各公司正处于Kubernetes这一环境中在进行竞争。


Rancher的此次大会可能是最具说服力、最具参考价值的,因为客户的紧张感暴露无遗。客户在一定程度产生了认识失调。一方面他们想继续使用Rancher的Cattle编排调度工具,另一方面他们意识到Kubernetes的势头不可抵挡。同时对于Rancher来说,从研发团队的角度看,标准化Kubernetes总是比支持多个第三方协调引擎更容易。


因此,对于Rancher 2.0而言,它的工作主要是通过CLI、UI、Compose等,来为运行在Kubernetes pod上的容器提供Rancher UX和API。原生支持Kubernetes,意味着对于那些想要使用Kubectl、Helm chart的公司而言,所有常见的Kubernetes工具都可以用了。


Rancher还计划通过Prometheus(用于监控和指标)以及RBAC(基于角色的访问控制)等工具提供更好的集成。 Rancher拥有自己的身份验证模型,并支持SAML、LDAP和Microsoft Azure Active Directory。用户可以设置警报和阈值——例如,如果etcd内存消耗超过70%,它会通过Slack通知团队。


Rancher首席架构师Darren Shepherd对功能性与简易性的理解略有不同,他在大会上表示Rancher正在开发的一个名为Rio的新项目——基于Kubernetes,拥有用户熟悉的、简单的Docker 1.11.x 风格的UX,拥有端到端的服务,包括构建、运行时、日志、监控与无服务器架构。


我在大会上询问了Rancher Labs团队如何达到产品、服务和技术支持间的平衡。 Rancher联合创始人兼销售副总裁Shannon Williams说:“客户使用Kubernetes之后,我们需要为客户提供的服务大部分都是培训。 然而AWS、VMware它们都不需要这样做。 如果产品易于使用,技术浪潮中并不需要这么多培训”。


1.jpg


客户对于K8S与Rancher的想法


客户对此说了什么?这里有一系列的观点。


Sling TV目前正在VMware上运行容器,并希望通过采用原生的Kubernetes避免未来技术锁定的风险。 它计划将容器从VMware迁移到AWS,因此可移植性是他们非常看重的特性。 正因如此,他们选择了可以纳管兼容不同基础架构容器服务的Rancher。


Toyota Connected是一个很有趣的案例,一部分原因是因为与其他客户不同,丰田直接选用Rancher 2.0,而不是1.6或更早的版本。 也就是说,它因为选择Kubernetes而选择了Rancher,而不是因为摒弃Kubernetes而选择了Rancher。


Toyota Connected高级开发与运维工程师Ross Edmond说:“Kubernetes并不完美,但我们坚信它有着非凡的持久力、未来发展会越来越好,一是因为它的功能非常强大,二是因为它可以让用户进行很多拓展,从而进行长期的、可持续性的探索。”


丰田公司所有出售的凯美瑞车型的“主机(head unit)”(也就是仪表板中带有无线功能、蓝牙、网络等的部分)都将运行在Kubernetes上。 丰田公司希望通过Kubernetes的灵活性加快公司的软件开发速度,并使用各种堆栈(例如,丰田用Java和Elixir编写软件,而这需要Erlang虚拟机)。


2.jpg


丰田凯美瑞的远程信息中包含超过100个微服务。在启动时,该服务需要能够支持1500万辆汽车。HA配置中的集群目前为20到30个节点。Kubernetes这一最初是用于管理Google服务器群的开源软件,如今已经开始服务于汽车仪表盘,这真的让人感到难以置信。


Edmond继续说:“Rancher Kubernetes Engine(RKE)不再需要用户‘自带容器’。它与底层基础设施并无绑定。使用RKE大大降低了我们使用其他云的启动成本。”


国家能源研究科学计算中心(NERSC)是美国能源部的一部分,也是另一个精彩的案例——实现了在Cray超级计算机上运行Docker。它使用容器进行计算工作——一个NERSC开源项目Shifter将Docker镜像随时转换为Cray超级计算环境中的非特权用户——那有9000个节点。 NERSC还以更传统的方式为应用程序开发工作流程提供容器。它选择Rancher进行身份验证、CLI、管理工具和策略实施。


总而言之,与容器生态系统中的其他参与者一样,Rancher现在专注于优化改善Kubernetes的易用性 。Kubernetes将成为未来几年的基础设施的重要角色。这次活动让我深刻地认同 Rancher在这方面有很好的基础,而这势必会在将来帮其赢得更多的新客户。


英文原文:

https://redmonk.com/jgovernor/2018/06/28/rancher-labs-treating-cattle-like-cattle/

相关文章
相关标签/搜索