标签 云计算 下的文章

PyTorch 和 Triton 正在打破英伟达 CUDA 的垄断

大部分机器学习软件开发框架严重依赖于英伟达 CUDA,并在英伟达 GPU 上表现最佳。但随着 PyTorch 2.0 和 OpenAI Triton 的到来,英伟达 CUDA 对机器学习的垄断地位正逐渐瓦解。即将到来的 PyTorch 2.0 在英伟达 A100 上的训练性能提升了 86%,在 CPU 上的推理性能提升了 26%。而且这种优势可以扩展到 AMD、英特尔、特斯拉、谷歌、亚马逊、微软等等各个公司生产的 GPU 和 AI 加速器上。而 Triton 能让高级语言达到与使用低级语言相当的性能,提高了可用性。

消息来源:Semi Analysis
老王点评:又一次证明了开源胜过闭源,无论闭源的护城河有多深。

Basecamp 因巨额账单退出云计算

Basecamp 的 CTO,也是 Ruby On Rails 的创建者 DHH 介绍了让该公司退出云计算的巨额账单。其 2022 年的费用为 320 万美元,绝大部分都花在了 AWS 上,其中 S3 花费 90 万美元,RDS 47 万美元,OpenSearch 52 万美元,Elasticache 12 万美元。即便如此,也是经过大量工作才减少到这一费用的,该团队不但运行了成本检查计划,还就作为私人协议就长期使用达成了协议。DHH 还用戴尔服务器的三年均摊成本做了对比。

消息来源:The Register
老王点评:云计算确实有很多好处,但也可能是个让你花钱上瘾的无底洞。

使用了 25 年的笔记本内存规范 SO-DIMM 将被替换

制定内存标准的组织 JEDEC 正在制定新规范,以取代已经使用了 25 年的 SO-DIMM 规范。新的 CAMM 标准将基于戴尔公司的设计,目标是在 2023 年下半年完成 1.0 规范,到明年推出基于 CAMM 的系统。现有的 SO-DIMM 在 DDR5/6400 时已经遇到了“困境”,CAMM 的主要吸引力在于它可以实现更高的内存密度,同时还可以扩展到更高的时钟速度。

消息来源:PC World
老王点评:这是不是代表以后笔记本会需要更多内存?

Ruby on Rails 作者称其新版本是“一个人的框架”

Ruby on Rails 上周三发布了 7.0 版本,作者称这是他“一直渴望的版本,……是多年来在五个不同方面取得进展的高潮。”不过,作者最兴奋的是,7.0 更接近“一个人的框架”的理想,“可以让一个人创建现代应用程序,并在此基础上建立一个有竞争力的业务”。Ruby on Rails 在官网宣传其可以让你边学边提高,“从入门到上市”。

老王点评:Ruby 和 Rails 相得益彰,虽然现在不是很流行了,但是 Ruby 的一些理念非常有趣,这个版本的理念也很有趣。

2021 年至少有六起超过 1 亿美元的加密货币盗窃案

据报道,在过去 12 个月中,至少有 20 次超过 1000 万美元从加密货币交易所或项目中被盗的案件,其中 6 起超过了 1 亿美元。这些窃案大多数没有抓住窃贼。有的交易所提前计划好了应急基金,如果被黑客攻击,它可以对客户进行赔偿,而有的干脆就倒闭跑路了。作为对比的是,根据美国联邦调查局的年度犯罪统计,去年银行抢劫案平均每次抢劫不到 5000 美元。

老王点评:以后的惊天大劫案就不再是抢银行了,而是在线抢劫了。

云计算使互联网更脆弱

在过去的三周里,亚马逊的云计算服务出现了两次重大故障,这导致了其他在线服务的广泛中断,比如视频流瘫痪、与互联网连接的吸尘器停止工作,甚至连宠物喂食器都关闭了。这些事情打破几十年来稳步提高的互联网速度和可靠性所强化的幻想。专家认为,“‘云’从来就不是可持续的,它只是一个由集中式实体控制的集中式网络资源的委婉说法。”在短时间内出现多次故障,这是一个值得警惕的事情。企业在“云服务是有弹性的”假设前提上投入了很多,而一些公司现在正在考虑使用多云解决方案。

老王点评:确实,现在的云,其实更多是一个集中计算中心,其弹性并没有得到足够的保证。

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽(Red Hat)精心制作的原创音频播客,讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客第一季(6):揭秘云计算音频脚本。

“没有什么云。这只是别人的电脑。”确切地说,还是服务器。大型云提供商提供了一种相对简单的方式来扩展工作负载。但真正的成本是什么?

在本期节目中,我们将讨论云中的战斗,说谁是赢家还很早。Major Hayden、微软的 Bridget Kromhout 等人会帮我们了解这场正在酝酿的风暴,以及它给开源开发者带来的影响。

Saron Yitbarek

Ingrid Burrington 想要走进云的世界。不是真实的“一朵云”哟,而是“云计算”的世界。

Ingrid Burrington

我不知道互联网真正的样子,我也不认为互联网是我想象中的那样,所以我想尝试找出它真实的模样。

00:00:30 - Saron Yitbarek

Ingrid 是一名记者。在她为《 大西洋 Atlantic 》撰写的系列报道中,她讲述了自己参观一个数据中心的经历,一个我们网络生活越来越依赖的地方。她在那里并不是走马观花逛一圈,而是浸入式的复杂体验。首先,她要拍照登记,申请访客身份卡。然后,要通过安检站,签署一份保密协议。最后,她才能去看机房。机房基本上就像个仓库,就像超市的那样,但比它大得多。

00:01:00

整个机房看起来有种别样的美,所有的东西都整齐陈列着。一堆光鲜靓丽的服务器上,连接着通往世界各地的光缆,光缆沿着天花板上的轨道整齐布线。正在通讯的光电信号闪烁着点点神秘的蓝光,仿佛粒子加速器一样。但本质上,它是一排排如猛兽般动力强劲的服务器。

00:01:30

数据中心每年消耗的能源比整个英国还要多。这就意味着它会释放惊人的巨大热量,这就是为什么当 Ingrid 环顾四周时……

Ingrid Burrington

对的,我发现这座建筑主要的设计理念,是建造最理想最完美的暖通系统(HAVC)。

00:02:00 - Saron Yitbarek

Ingrid 发现围绕数据中心的一切都强调经济实用,简单说就是一堆主机、一摞风扇、一大块租金便宜的地皮、用很多便宜的用来冷却的工业用水。完全没有“云”这个词本身散发的浪漫,但另一方面,我们的生活、我们的工作以及我们的话语,都在这个服务器的仓库里搏动着。

00:02:30 - Ingrid Burrington

是的,这有点超现实主义。并不是说我就知道那台机器里存有某人的电子邮件,这台机器又存有别的东西,而是我意识到周围有很多看不见的事情正在发生,我能听到服务器的呼呼声和大量运算产生的微小噪声。说来奇怪,我开始对工业充满敬畏……

00:03:00 - Saron Yitbarek

时刻要记住,在我们使用服务的时候,它们的基础,这些建筑都在某个隐蔽的角落嗡嗡运作着。以前,当我们谈论在云上存储东西,或创建应用程序时,我们有时会自欺欺人地认为它就像天上的云,是没有人能触碰的存在。但现实恰恰相反,一旦我们认识到云数据中心真实存在于某地,我们就会开始思考谁拥有着云了。那么是谁在控制这些服务器、线缆和风扇呢?

00:03:30 - Saron Yitbarek

它们是如何改变开发者构建未来的方式的呢?云让我们紧密地连接在一起。

我是 Saron Yitbarek,这里是《代码英雄》,一档由红帽公司推出的原创播客栏目,第六集,揭秘云计算。

Chris Watterston

没有所谓的“云”。那只是别人的电脑。

00:04:00 - Saron Yitbarek

Chris Watterston 是一名设计师,他对围绕云产生的误解很是恼火。这个词模糊了数据中心的形象,就像 Ingrid 参观过的那个一样。当 Chris 把这句口号做成贴纸时,他因此成为了网红。“没有所谓的‘云’,那只是别人的电脑。”这句话现在出现在 T 恤、帽衫、咖啡杯、海报、杯垫和许多主题演讲上。

00:04:30 - Chris Watterston

人们完全不理解云是什么,还用的很欢乐又心安。他们可能完全误解了云,不明白他们的数据实际上是穿过铜轴电缆、或者光纤,来到某一个实际上由他人管理和拥有的存储设备。显然,对于一些有需要隐藏的私人内容的人来说,这是相当可怕的隐患。

00:05:00

所以,下次你想把东西扔到云上的时候,想想 Chris 的贴纸吧。想想你到底要扔到哪里去。在 App 上工作也是同样道理,声称 App 跟服务器无关的说法都是骗人的,根本没有无服务器的 App。云就是别人的服务器、别人的电脑。不过云这件事情从某种意义上说,是一种成长。说到成长,在整一季节目里,我们会一直追溯开源的成长与变革。

00:05:30

从最初的自由软件运动到 Linux 的诞生,直至今天,开源工具和方法把我们带到了远离家园的云端。可以打个比方,一个人找房东租房,他需要签合同、搬进去、把房子整理成自己的居所。当开发者寻找云供应商时,他们也在做着同样的事情。这就是我们现在所处的情况,全世界的开发者都在转向各种云上线产品,然后开始明白租赁的真实含义。

00:06:00

严肃地发问一句,为什么我们一开始就急着跳上云端呢?

Brandon Butler

因为开发者不想维护 App 运行所需的设备。

Saron Yitbarek

这位是 Brandon Butler,《 网络世界 Network World 》的高级编辑,多年来致力于研究云计算。

00:06:30 - Brandon Butler

开发者想要开发 App,部署 App,并只在乎 App 能不能正常运行。我们已经看到云孕育的,越来越多的服务,例如无服务器计算、功能即服务、容器和容器管理平台,如 Kubernetes。

Saron Yitbarek

顺便打个广告,想了解容器和 Kubernetes,请看我们的上期节目

Brandon Butler

所有的这些成果都有助于抽象化 App 运行时所需要的底层基础设施。这将是一个可以在未来可预见的持续发展的趋势。

00:07:00 - Saron Yitbarek

云拥有巨大吸引力的部分原因,可以用“超大规模”这个词来解释。通过云为你提供的所有基础设施,你可以根据自己的需求,快速创建和定制自己的服务器。你不再需要购买自己的设备,你只需要租赁你想要的规模的云。Brandon 解释了“超大规模”对初创公司的具体帮助。

00:07:30 - Brandon Butler

使用公有云进行 App 开发的整套模型,对开发者来说是一个巨大的进步。它曾经成就了一系列全新的初创公司,这些初创公司也已经成长为大众都喜欢投资的公司。想想 Netflix 这样的公司,它的大部分后端都运行在亚马逊的以及其他的云上。

00:08:00 - Brandon Butler

这些公司现在如此壮大的原因,正是因为他们在使用云。因此,云对开发者的影响是不可轻视的。云已经成为过去十年,App 开发领域的主要转变。

Saron Yitbarek

Nick Bash 是 Meadowbrook 保险公司的一位系统管理员,他还记得在云计算诞生之前,调整基础设施是多么痛苦的事。

00:08:30 - Nick Bush

以前,有些人想出新项目的点子,我们会说,“这需要硬件支持,而我们没有。”他们会问,“那么我们该怎么办?”我们以前总是受到内存的限制,尤其是运行虚拟机软件,通常是最困难的部分。我们经常需要在任意时间启动虚拟机,但能随时启动的虚拟机数量总是不多。所以我们不得不花很多钱买新处理器、新内存、新硬件,或者花 5000 美元加新的东西。一旦我们从几个不同的供应商得到报价,就得报给管理层,他们要花时间审核。这样,仅仅是购买硬件都需要漫长的过程。

00:09:00

更不要说构建虚拟机,再反复考虑和测试等等。所以其实我的意思是,有了云,我们可以在几个小时内完成以往需要几个月完成的前期工作。让虚拟机运行起来,第二天就交付给其他人。所以这是一个很大的转变。

00:09:30 - Saron Yitbarek

在拓展性、速度和价格这些方面,云计算相当吸引人。还是拿租房作比喻,云就像可以让你免费得到一个管家和司机的服务,你很难对云计算说不。如今市场上有主要的四家壮志雄心的云供应商在开疆拓土。他们都想成为你在云上的“新房东”。但是且慢,每个租过房子的人都知道,租房和买房不一样。你不能自己拆掉一堵墙,或者安装一个新的按摩浴缸,你得通过房东来干这些事。

00:10:00

那么 Brandon Butler 先生,我们使用私有云,在某种程度上会受制于一家独资公司。这会不会对我们不利?

00:10:30 - Brandon Butler

当你使用云供应商的私有云时,你有不同的使用方法:你可以拥抱开源标准和开源平台,并且在云上运行开源软件,即便这是个私有云;你也可以使用不是开源的原生工具,这些工具可能在公有云上有更好的集成。因此,这是终端用户必须考虑的一个重大问题:我是想使用云供应商的原生工具,这些工具可能与这个云供应商提供的服务,以及其他服务更好的集成;还是拥抱开源标准,使用一个开源平台,享受更大的自由度,在自己和其他提供商的平台上也能运行?

00:11:00 - Saron Yitbarek

随着我们所依赖的云技术不断发展,四大云供应商相互竞争,我们作为开发者有了新选择。我们是放弃一些独立性,依靠单一的云供应商来保护我们的工作,还是选择另一条路,在保持独立性的同时最大化云的拓展性?

00:11:30

换句话说,我们能否在租房合同上写明,“房客有权任意处置该房 ,例如拆墙或其他装修”?

00:12:00

那么,放弃一点点独立性又有什么问题呢?如果你是一名开发者,可能没受到什么影响。因为大多数时候都有运维团队在背后监督开发者们小心行事,他们格外留心于具体细节。这位是 Major Hayden,他是 Rackspace 的首席架构师。

00:12:30 - Major Hayden

有些时候,开发者经常发现他们有各种不同的需要,比如某些专门化的存储,或者可能想要一定大小的虚拟机,或者想要一种云供应商未能提供的东西。还有一些东西可能开发者没有第一时间想要,但你认为他们需要的,对这些东西你还要进行成本效益分析。好吧,虽然使用公有云我们有很大的灵活性,但我们到底付出了什么代价?

Saron Yitbarek

Major 指出了另一个问题,这个问题超越了实用性,并且触及了像我这样的开发人员所信奉的核心,那就是开源实践。即使云供应商允许你使用自己的开源工具,但云本身并不是开源的

00:13:00 - Major Hayden

因此,开源对于云来说是一个需要处理的有趣议题,因为有大量的开源技术支持用户去高效地利用公有云,但并不是所有公有云都把它们的基础设施开源了。举个例子,如果你使用亚马逊,你无法知道他们使用的什么技术来构建虚拟机和其他服务。所以,你不可能对这些东西做点调整,或者很难了解幕后的机理和运作方法。

00:13:30 - Saron Yitbarek

如果你听过我们之前关于 DevOps 的节目,你会知道打破开发者和运维之间的壁垒会让我们获益良多。架构师 Major 刚给了我们一些真知灼见,接下来的这位是系统管理员 Nick Bush,他所在的团队正准备向云端迁移。开发者们已经厌倦了每五年一次硬件换代,每个人都喜欢尽可能快地扩展,而 Nick 想指出一些开发者可能没有考虑到的东西。

00:14:00 - Nick Bush

是的。我想说的是,云是存在延迟的。举个例子,就像远在蒙大拿的数据库服务器,对比我在街上用着 10-gig 的网络,本地数据库调用还是会花费更长的时间。要达到低延迟的云内数据库调用还有很长的路要走,还有其他的安全问题,因此我们暂时不需要担心物理上的前提。在本地,我们尚可以控制我们的硬件和其他类似的东西。一旦你进入了云端,你就得考虑连接问题。

00:14:30

我认为,你也得稍微担心一下安全问题,虽然这更多也是一个成本问题。你想要按月租一个云端虚拟机,要求网速快并且带有充足的存储空间。每千兆的传输和存储都是要花钱的,以前我们都是一次性买断一个机器,我们只要买好了一个云端虚拟机,就可以存储和使用。只要余额和储存空间都还足够,我们就不用付更多钱。

00:15:00 - Saron Yitbarek

声明一下,Nick 确实认为此事利大于弊。他只是不想让我们认为这是个完美的系统。如果你的云供应商宕机,而你想在其他云中重新部署应用程序,会发生什么情况?或者,如果在不同事务上使用不同的云能带来价格优势呢?运维人员提出的这些问题都可以被总结于一个词汇下,也就是 供应商依赖 vender lock-in 。你可能很熟悉这个词。

00:15:30

供应商锁定的意思是,在别人的服务器上构建业务会让你越来越依赖于他们的平台。你被绑定在这个平台了。可能突然之间,你被迫升级系统、付出更多成本、接受新限制,你变得身不由己。你懂的。

00:16:00

当我们都戴上 DevOps 的帽子时,我们开发者和运维就可以一起工作,面对供应商锁定,对症下药,但当我们沉浸在自己的代码中时,我们有时会忘记观览全局。为什么不找个折中方法,同时在公共和私有云上工作呢?终极解决方案可能是混合云,对于两方而言这都是最佳选择。我给 Bridget Kromhout 打了电话,询问她的看法。她是微软员工中的头号云开发提倡者,对这方面非常了解。

00:16:30

如果我们考虑一种混合的解决方案,既包含一些公有云,也包含一些私有云,这是两者之间的完美平衡吗?对于开发者,这是理想的解决方案吗?如果云是混合的,那么我就能想做什么就做什么,想用什么工具就用什么,同时仍然可以从大型公有云提供商那里获得一些好处。

00:17:00 - Bridget Kromhout

当然是的。举个例子,我有朋友在制造业中从事高性能计算研究工作,他们有各种各样的绝密资料,像 NDA 这样的东西,不适合放在公有云上。于是,他们可能会在自己的数据中心跟这些资料打交道,处理客户数据,或者研究数据,等等,也可能有其他的……

00:17:30

他们也有适合放在公有云上的其他工作资料,不过我想这个问题就……有时也会有这样的问题,公有云是否适合某些工作资料,比如,如果你计划使用 InfiniBand 同步你的不同笔记,你能在公有云中做到什么程度呢?

Saron Yitbarek

但这并不一定是完美的解决方案。Bridget 认为混合云也有自身的弊端。

00:18:00 - Bridget Kromhout

混合云的问题在于,有时,人们欺骗自己,认为他们可以接受一些实际上不工作的东西,所以如果他们之前等待两周来获得一个虚拟机,如果有人经历过一个完整的这样的情况,并且这个虚拟机还不能正常工作的话,就会有一堆的人由于失望而开始和他们的公有云提供商谈论信用卡问题了,然后他们会试着把这些东西粘合在一起,但是还是有数据来源和延迟的问题,我不是很确定,脱同步的数据集有很多出错的方式。我认为,如果你和云服务提供商合作,你可以有一些可用的直接沟通这样你就可以更好地同步数据,这样是很有帮助的。

00:18:30 - Saron Yitbarek

是的。当我们在开源的语境下谈到云的时候,我觉得,作为开发者,可能大多数人,都喜欢开源;如果你还在听我们的播客节目,就更是这样。对吧?你希望一切都是开放的,透明的,还向大众共享代码;但我觉得,当我们谈到云计算,因为它不会给人感觉是代码库,不会让人觉得云本身是个项目,它是环境,是可以用来帮助我们运行代码的东西,开发人员们还会坚持要让它像是传统的项目和代码库一样开源、透明吗?

Bridget Kromhout

我觉得这是一个非常合理的问题,我觉得这可能也会归结到你到底要注目于技术栈的哪一部分。想一想,你对芯片的了解有多少?你又能在何种程度上操控它们?

Saron Yitbarek

是的,这是真的。你说得不错。

Bridget Kromhout

他们坐在那里,他们有硅,他们也有秘密。他们不一定会将后者给你。

00:19:30 - Saron Yitbarek

是啊,硅和秘密。顺便说一句,这是个好播客的名字。

Bridget Kromhout

对吧?也许问题不在于是否一切都是开放的,而在于你需要开放的一切是否都是开放的,以及,当服务没有完全按照正确的方式运行时,你的服务提供者是否会对你保持信息透明,因为不该出的错误就是不该出。

00:20:00 - Saron Yitbarek

所以,我得到了 Bridget 作为一个公有云提供商的观点,她提出了一个有趣的观点。开发者在云上的控制需要多细?至于我,我的看法不一样。我不想为了一点公有云的优势而牺牲的是什么呢?比如说,一个应用在公有云上运行,然后,等一下,现在我已经扩大了规模,或者有新的合规要求,我的应用在私有云上更合适。

00:20:30

把应用从一个地方迁移到另一个地方之前,我需要知道它在迁移之后仍能工作。我需要知道它是以原先同样的方式打包,以同样的方式配置。换句话说,我需要知道从一个云跳到另一个云总是可能的。

除此之外,我们还有什么选择?仅仅锁定在一家云提供商?一个甚至可能完全垄断整个行业的供应商?不能选择迁移到另一个环境的话,这就像把一只手绑在背后写代码一样。

00:21:00

所以,我们不想欠下任何一朵云的人情,并且被它困住。我们希望在合适的时候能够在云间跳转。用摇滚传奇 皇后乐队 Queen 的名言来说,“我想要挣脱束缚”。我们希望能够获得公有云的绝佳拓展性,但又不放弃使用开源工具和方法所带来的自由。

00:21:30

有个好消息。混合云的建设正在顺利进行中。Mike Ferris,红帽公司的的业务架构副总裁,他给出了一个很好的解释,说明了混合云是如何帮助我们保持开源精神的。

00:22:00 - Mike Ferris

开源是世界上几乎每一个云服务的基础,现在即便不是大多数,也有许多世界上应用程序的基础设施和工具是从这里发展出来的,管理能力,以及人们用于构建、部署应用程序(无论是任务关键型,还是非任务关键型应用程序)的工具都是基于开源的。

00:22:30

混合云的概念和这一点非常兼容,这代表着,我们可以在混合云中处处使用开源工具,也可以最大程度地发挥出基础设施的优势。这是基于以下的一点事实:开源通过其在当今的强大影响力,能够在一定程度上定义下一代的开发模式。

Saron Yitbarek

我认为云计算本身具有开放的意愿。在本季节目中,我们花了很多时间讨论开源的起源。你甚至可以证明,某些版本的混合云是这些相同理想的延伸。

00:23:00 - Mike Ferris

在过去几十年里,开源开发活动的变化是越来越多的人参与进来了,包括像微软、IBM 这样的行业巨头。你知道,举个大公司的例子,他们要么使用开源软件来提供产品,要么构建开源软件并将其回馈给社区,或者两项都参与。

00:23:30

这些来自客户的重要需求通过那些大公司涌入,确实帮助了开源世界的发展,使之从最初设想中 Solaris 和 UNIX 的替代方案,发展为不仅是社区和业余爱好者使用,而且肯定也是部分任务关键型企业使用的基础。

00:24:00 - Saron Yitbarek

开源正在快速成长。现在,我们有机会确保我们记住我们从哪里来。当我们跃上云时,我们可以为自己声明开源的部分,以此来保持云的开放。幸运的是,由于有了 OpenStack® 平台这样的工具,在云之间构建开源桥梁变得更加容易了。Rackspace 的首席架构师 Major Hayden 描述了它的起源。

00:24:30 - Major Hayden

OpenStack® 来自于 Rackspace 和 NASA 的合作:“你看,这是一种构建基础设施的新方式,我们应该公开进行。我们应该得到更多的投入,应该和更多的人交流。我们应该得到更多的用例。” OpenStack® 是一组应用,它能很好地协同创建基础设施,并全面管理基础设施。无论你需要复杂的虚拟机、复杂的网络,还是有奇怪的存储要求,OpenStack® 通常可以满足大部分的要求。

Saron Yitbarek

Major 指的是,加入一些开源知道如何提供的东西:也就是适应性。

00:25:00 - Major Hayden

在我看来,OpenStack® 是一组相互连接的开放源码应用程序,它允许你构建你想要的基础设施。如果它不能建立你想要的,那么你可以进入社区,对它做出改变。我喜欢我去和顾客交谈时他们的反应,他们说,“我们想改变这个。我们想要改变这一切。”我们会说,“嗯,你可以。”

Saron Yitbarek

我们如何确保这样的的适应性被包含在明天的云中呢?就像我们在之前的节目中谈到的许多问题一样,这需要强大的社区。有请 Brandon Butler,《网络世界》的高级编辑。

00:25:30 - Brandon Butler

例如,我们已经看到了云原生计算基金会的成立,这个基金会制定标准,推广应用容器的使用,并创造了 Kubernetes。我们也看到了 OpenStack 基金会的成立,好将 OpenStack® 用户聚集在一起,讨论创建开源基础设施服务云时的最佳实践。

00:26:00

支撑这些开源社区的社群对于开发下一波开源工具,学习如何最好地使用这些开源平台的,以及鼓励公有云厂商接受这些开源标准都非常重要。

Saron Yitbarek

一旦我们开始构建混合云,并使其尽可能地开放,潜力似乎真的无穷无尽。Major,请说。

00:26:30 - Major Hayden

最让我兴奋的是看到更多的东西可以聚集在不同的云之上。例如,OpenStack® 提供了一个很好的基础设施基础层,但是你可以在它之上做很多事情。我想有时候不同的公司会采用 OpenStack®,然后说:“伙计,我现在该怎么办?我的自由程度太高了。我不知道该怎么办。”这就像你有一个装满食物的冰箱,你会想,“啊,我不知道该做什么菜。”

00:27:00 - Saron Yitbarek

我喜欢这个问题。Chris Watterson 告诉我们的可能是对的。

Chris Watterston

没有所谓的“云”,那只是别人的电脑。

00:27:30 - Saron Yitbarek

但故事并未在此结束。我们要与混合云一起跨入下一章。创建混合云应用的关键可能还没有被破解。跨多云管理任务,对于今天的代码英雄们来说将是一项艰巨的任务。会有很多尝试和错误,但这是值得的,因为我们知道的唯一的一件事是,保持开源意味着开发人员总是可以构建他们想要工作的世界。这种灵活性正是紧紧抓住开源最擅长的叛逆精神的诀窍。

00:28:00

下一集是我们本季的最后一集,我们将以一种让你惊讶的方式,从宏观角度来看开源作为一种全球现象是什么样的。我们也将展望开源的未来,我们的开发人员如何保持像 Linus Torvalds 这样的英雄的精神,即使当他们正在重塑他们的行业时。

00:28:30

《代码英雄》是一档红帽公司推出的原创播客。想了解更多关于本期和往期节目的信息,请访问 RedHat.com/CommandLineHeroes 。在那里你也可以注册我们的新闻通讯。想免费获得新一期节目推送,请务必订阅我们。只要在苹果播客、Spotify、Google Play、CastBox 和其他播客平台中搜索《代码英雄》,然后点击订阅,你就可以第一时间收听新一期。我是 Saron Yitbarek。感谢你的聆听,编程不止。

OpenStack® 和 OpenStack 标志是 OpenStack 基金会在美国和其他国家的注册商标/服务标志或商标/服务标志,并经 OpenStack 基金会许可使用。我们不是 OpenStack 基金会或 OpenStack 社区的附属机构,也没有得到 OpenStack 基金会或 OpenStack 社区的认可或赞助。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ,LCTT SIG 是针对特定领域、特定内容的翻译小组,翻译组成员将遵循 LCTT 流程和规范,参与翻译,并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽(Red Hat)发起的 SIG,当前专注任务是《代码英雄》系列播客的脚本汉化,已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献,并领取红帽(Red Hat)和我们联合颁发的专属贡献者证书。


via: https://www.redhat.com/en/command-line-heroes/season-1/crack-the-cloud-open

作者:Red Hat 选题:bestony 译者:LikChung 校对:acyanbird

本文由 LCRH 原创编译,Linux中国 荣誉推出

前段时间,笔者参加了 UCloud 在京举办的 TIC 2019 大会,适逢 UCloud 实验室负责人叶理灯的演讲结束,就容器计算方面和他进行了短暂沟通。叶理灯是国内在云计算方面有深入研究和实践的资深专家,我觉得他的一些观点和看法值得分享给大家了解。

叶理灯,UCloud实验室负责人

叶理灯,UCloud 实验室负责人。现负责 UCloud 创新产品研发,专注面向企业的云计算产品的研发及运营。叶理灯拥有 10 年以上丰富的互联网研发经验,先后任职于腾讯、盛大云等互联网公司,从事海量分布式后台系统研发及运营工作。

定制违背了 K8S 初衷,提供原生 K8S 产品

记者:在官方的 K8S 发行版之上,各方云厂商提供 K8S 服务时都有一些自己的定制和调整,今天大会上提及的 UCloud 的 K8S 发行版 UK8S 主要做了哪些定制,有什么特色呢?

叶理灯如果说定制 K8S 的话,其实是违背了 K8S 的初衷。我们并没有定制 K8S,我们是基于公有云给用户提供了原生的 K8S 产品。在公有云上提供原生的 K8S,其实要做很多的工作,例如与公有云的计算、网络和存储的整合,给用户提供一个开箱即用的原生K8S集群等等。

我为什么说不应该定制呢?因为大家知道 PaaS 发展到今天,一直存在的一个问题就是供应商绑定的问题。而 K8S 之所以那么有生命力,之所以迅速流行,是因为它提供了一个开源的标准,让用户使用 K8S PaaS 平台,可以避免厂商绑定。也就是说你的服务在某个服务商的 K8S 上运行,可以无缝的迁移到另外一个服务商。

作为云厂商其实最重要的工作是,基于我们自身云平台的体系,提供原生的 K8S 给用户使用,帮助他们减少在集群管理和资源整合方面的工作和投入。例如,我们网络能力、存储能力和计算能力的整合,就是让用户享受到原生K8S的好处,同时避免了很多运维的负担。

公有云的 K8S 处在底层 IaaS 和上层应用之间,一方面向下整合IaaS能力,一方面向上托管客户的应用。在整合 IaaS 方面,不改变 K8S原生特性,因为 K8S 本身架构足够开放,例如在我们实现的网络插件,是基于我们 IaaS 的 VPC 网络,让 pod 可以和我们托管区和物理云区域打通,这是我们 IaaS 能力在 K8S 产品上的体现,算是我们的特色之一,但这是在 K8S 体系支持下的插件方式实现的,不影响我们提供原生 K8S;在应用层面,厂商也可以基于 K8S 提供一些周边的功能以帮助用户提高效率,但它和提供一个一致的 K8S 环境不矛盾。

另外一方面,如果说定制的概念是指基于 K8S 本身开发体系所提供的插件机制去做二次开发,那每家厂商都要定制,因为 K8S 本身不是一个产品级就绪的环境,需要使用者去适配网络和存储还有计算,因为每个公有云厂商基于自己的 IaaS 去提供 K8S 产品,必然要去开发插件。

综上,向用户应该提供原生的、标准的 K8S 产品,但底层应该基于自身 IaaS 平台去定制,本质还是为了提高用户使用 K8S 的效率,让用户开箱即用。

K8S 落地挑战:改造成本和人才问题

记者:你觉得目前国内云厂商提供的 K8S 集群编排服务在推广方面目前欠缺的是什么?是什么阻碍了客户进一步去使用这些容器集群服务?

叶理灯:K8S 以容器技术为核心、以容器镜像为打包标准的特点,意味着如果要迁移到这个体系下,客户需要将软件做容器化打包和微服务改造,这个是有成本的。K8S 的特点决定它是运维和研发之间的桥梁,这样就要求公司的研发过程需要跟着改造。我们看到很多公司的运维人员有动力去推动,而研发人员则没有动力,因为它改变了研发的习惯和流程,增加了负担;当然也有的公司是研发希望用 K8S 管理应用,而需要运维跟着变。这样导致迁移到 K8S 的工作较重,但一旦这个阶段过去了,迁移后的效率和成本优势就体现出来了。

因此,这是个新技术落地的问题,涉及到用户教育和习惯的改变,这个需要社区和商业公司一起完成。而且每家公司的技术路线和文化不一样,上 K8S 的路径也不一样,所以没有一个放之四海皆准的最佳实践,但随着容器和微服务逐渐落地,K8S 作为事实标准,会逐步普及。

除了改造业务的成本,另外一方面是 K8S 人才比较缺乏,不同用户的情况不一样,有些用户的运维人员本来就很少,不可能专门抽出一两个人去做 K8S,以及用户又担心它出问题谁来帮我解决?其实,应该是云厂商再往前走一步,除了帮用户构建一个 K8S 平台,还要帮助解决很多技术上的问题。 UCloud 现在就是这么做的,一个用户进来,我们会拉一个群,他们所有技术问题我们帮他们解决。在落地方面,在人才和 K8S 本身对用户架构改造方面,我们可以多做点工作,帮助客户培养K8S的运维人员和为用户制定架构迁移的方案。但我相信随着技术的发展和普及,越来越多人懂 K8S。

最后,K8S 本身也在发展,K8S 刚推出的时候是为了让大家重新面向应用来运维,但是大部分用户用 K8S 同时管理集群里的节点和应用,就会同时有两个负担。我觉得目标应该是用户直接拿一个容器就可以跑起来,而不用知道它的节点在哪里,即 Serverless 形态。一旦这种技术更加成熟,对容器技术的落地也有很大的推动作用。另一方面,Serverless 形态也给用户节省了大量的成本,按需付费,免去用户的运维成本。我觉得 K8S 的落地已经是个趋势了,是不可避免的,但是 K8S 本身是要往前进步,它的革命还没有完成。

容器与 Serverless:覆盖场景不同,非替换关系

记者:你觉得现在目前 Serverless 的发展对于容器这种创新技术的迭代升级有什么影响?是不是可以让容器更加的轻量化?

叶理灯:不完全是这样,其实 Serverless 刚出现的时候是针对计算的。计算分很多层次,有物理机、虚拟机、容器和 Serverless。Serverless 刚出来的时候,它等同于 FaaS,有一个对标的产品叫 Lambda。

Serverless 出现的动力是,由于云计算的发展,带来了如对象存储等很多丰富的中间件,Serverless 概念的提出是希望应用开发者可以不用写后端逻辑,直接把逻辑写在客户端,组合云上的一些服务来完成业务逻辑,这样就没有管理后端资源的负担了。但是后来发现很多时候还是需要后端代码的,所以就演变成如果有后端代码,就拆成函数,托管在 FaaS 服务中,这样的话,你依然是不用管理服务器的,你用的还是一个个服务,没有服务器管理负担。

这个概念在不断进步,2017 年的时候 AWS 提出了一个新的概念,重新定义了什么叫 Serverless,只要一个服务具备了四方面特性:免运维、按需付费、高可用和自动扩容,这个服务就是个 Serverless 的服务。所以 Serverless 这个概念可以对应 FaaS,也可以代表一种架构,也可以代表一种服务的形态,例如 Aurora Serverless 就是把一个数据库的服务变成 Serverless 的。

容器和 Serverless 的区别在于,Serverless 是无容器的,除了不关注服务器,也看不到容器。两者是面向不同场景的,并不是互相替代的关系。FaaS 的特点,接收一个请求拉起一个函数执行,函数是无状态的,它的执行地点也不固定,这意味着延时相对于常驻进程要高,对一些延时敏感的地方它是不合适的,但是有些场景是非常合适的。我举个例子,在 IoT 场景中,有几十万的设备,为了节省电源,它们大部分时候处于睡眠状态,如果用传统的架构去为这几十万设备服务的话,肯定要考虑并发连接的时候,应该有多少计算资源去服务,这很浪费成本。所以最好的方式,来一个请求就拉一个函数服务一下,这就很节省成本。

这是按需的,但它不是完整的替换,相当于说 IT 领域里面不同的场景其实是使用不同的服务。我们推出这个服务的原因,背后的动力还是成本和效率,在某个场景上用某个解决方案它的成本更低、效率更高,而不是说新的东西会替换老的,因为不同场景需求是不一样的。K8S 接受的用户比 FaaS 的用户更多,因为 K8S 的面更广,它覆盖的场景更多,但是它不是替换的。

记者:目前,国内客户对 Serverless 和 PaaS 的接受和普及程度是怎么样的?

叶理灯:我觉得在国内还是处于起步和用户教育阶段。2014 年 Lambda 推出的时候,它的渗透率是 72%,什么原因呢?有 72% 的人用的 Lambda,我们有个 Serverless 产品叫 UGC,腾讯有 FaaS,阿里也有 PaaS,目前都不算是渗透率很高。

原因有几个。第一、国内用户对新技术接受程度是比较低的,可能是习惯问题,国内的IT的发展水平跟国外也有差距,有 5、6 年差距;其次,对国内用户来说,把一个架构改成 Serverless 架构,其实成本是很高,而且改造的收益和规模相关;最后, FaaS 本身不是一个独立能起作用的产品,你会看到 Lambda 推出时,不是个独立的产品,它是体系的副产品,例如其他产品要开放事件源,通过事件去触发 Lambda 函数执行。只有产品体系开放足够多的事件源,FaaS 才能渗透到整个平台里面去,才能覆盖更多场景。

我们国内的厂商还没有做到这一点。AWS 刚推出 FaaS 时,它主要是 S3 上的图片处理,不是每个用户都有这个场景,因此渗透率不高。随着 API 网关方式调用,和体系开放事件源越来越丰富,覆盖场景越来越多,我相信 FaaS 会逐步落地。

在现场的演讲中,提及了一个叫 USQL 的产品,就是 Serverless 方式的大数据分析工具,StepFlow 用 Serverless 的方式编排你的程序,这些都是 Serverless 的服务。

未来,虚拟化容器值得关注

记者:目前 UK8S 的主要发展方向有什么路线图吗?UK8S 是否已经开源?

叶理灯:有的,例如说我们让 K8S 管理更多的资源、异构的资源,还有物理机、GPU 资源,希望用户可以通过 K8S 对这些资源进行统一地管理。另外,再往业务层面走会提供一些微服务的基础设施,通过产品化,一方面减轻用户的资源负担,另一方面减轻应用层的架构负担,从而尽量减轻用户迁移到 K8S 的负担。

目前 UK8S 插件还属于正在整理开源的阶段,还没有正式的发布,但我们已经小范围的开放了代码,把我们的插件代码分发给到很多用户,但公开的开源,我们希望做的更加规范一点再进行,因为我们的插件还在不断的迭代中,有一天我们觉得达到一定程度的稳定了,我们就会进行公开开源。

记者:你认为未来 K8S 以及容器的技术方向上比较值得重点关注的技术点是什么?

叶理灯:虚拟化容器。未来的方向我们相信是 Serverless,这个也是云计算应该做的,持续地为了用户提高效率和降低成本。刚才我也说了,现在用户使用 K8S 还是有资源管理的负担的,不是完全的面向应用来运维,所以需要解决这个问题,让计算节点对用户透明。用户通过 Docker 镜像和配置文件就可以把一个应用跑起来,而不用去管资源问题。这需要我们去提供一个海量的集群去跑客户的应用,这就存在一个问题,多个客户的应用可能跑在一个节点上,考虑 Docker 本身的隔离问题,我们需要类似虚拟化容器的计算方式去做隔离,同时又希望拥有 Docker 本身轻量级快速启动的效率,现在看来,虚拟化容器是比较符合这个需求的。

尾声

通过和叶理灯的交谈,梳理了我对云计算、容器技术和 Serverless 等方面的一些认识,作为一个几年来亲自践行云计算发展,并有深入探讨和研究的专家,他的观点和认识或许值得从业云计算行业的技术人员参考。

看着我们在纽约的办公大楼,我们发现了一种观察不断变化的云原生领域的完美方式。

在 Packet,我们的工作价值( 基础设施 infrastructure 自动化)是非常基础的。因此,我们花费大量的时间来研究我们之上所有生态系统中的参与者和趋势 —— 以及之下的极少数!

当你在任何生态系统的汪洋大海中徜徉时,很容易困惑或迷失方向。我知道这是事实,因为当我去年进入 Packet 工作时,从 Bryn Mawr 获得的英语学位,并没有让我完全得到一个 Kubernetes 的认证。:)

由于它超快的演进和巨大的影响,云原生生态系统打破了先例。似乎每眨一次眼睛,之前全新的技术(更不用说所有相关的理念了)就变得有意义……或至少有趣了。和其他许多人一样,我依据无处不在的 CNCF 的 “云原生蓝图” 作为我去了解这个空间的参考标准。尽管如此,如果有一个定义这个生态系统的元素,那它一定是贡献和引领它们的人。

所以,在 12 月份一个很冷的下午,当我们走回办公室时,我们偶然发现了一个给投资人解释“云原生”的创新方式,当我们谈到从 Aporeto 中区分 Cilium 的细微差别时,以及为什么从 CoreDNSSpiffeDigital RebarFission 的所有这些都这么有趣时,他的眼里充满了兴趣。

在新世贸中心的影子里向我们位于 13 层的狭窄办公室望去,我们突然想到一个把我们带到那个神奇世界的好主意:为什么不把它画出来呢?(LCTT 译注:“rabbit hole” 有多种含义,此处采用“爱丽丝梦游仙境”中的“兔子洞”含义。)

于是,我们开始了把云原生栈逐层拼接起来的旅程。让我们一起探索它,给你一个“仅限今日有效”的福利。(LCTT 译注:意即云原生领域变化很快,可能本文/本图中所述很快过时。)

查看高清大图(25Mb)或给我们发邮件索取副本。

从最底层开始

当我们开始下笔的时候,我们希望首先亮出的是我们每天都在打交道的那一部分:硬件,但我们知道那对用户却是基本上不可见的。就像任何投资于下一个伟大的(通常是私有的)东西的秘密实验室一样,我们认为地下室是其最好的地点。

从大家公认的像 Intel、AMD 和华为(传言他们雇佣的工程师接近 80000 名)这样的巨头,到像 Mellanox 这样的细分市场参与者,硬件生态系统现在非常火。事实上,随着数十亿美元投入去攻克新的 offload(LCTT 译注:offload 泛指以前由软件及 CPU 来完成的工作,现在通过硬件来完成,以提升速度并降低 CPU 负载的做法)、GPU、定制协处理器,我们可能正在进入硬件的黄金时代。

著名的软件先驱艾伦·凯(Alan Kay)在 25 年前说过:“真正认真对待软件的人应该自己创造硬件”。说得不错,Alan!

云即资本

就像我们的 CEO Zac Smith 多次跟我说的:一切都是钱的事。不仅要制造它,还要消费它!在云中,数十亿美元的投入才能让数据中心出现计算机,这样才能让开发者消费它。换句话说(根本没云,它只是别人的电脑而已):

我们认为,对于“银行”(即能让云运转起来的借款人或投资人)来说最好的位置就是一楼。因此我们将大堂改造成银行家的咖啡馆,以便为所有的创业者提供幸运之轮。

连通和动力

如果金钱是润滑油,那么消耗大量燃料的引擎就是数据中心供应商和连接它们的网络。我们称他们为“连通”和“动力”。

从像 Equinix 这样处于核心地位的接入商的和像 Vapor.io 这样的接入新贵,到 VerizonCrown Castle 和其它接入商铺设在地下(或海底)的“管道”,这是我们所有的栈都依赖但很少有人能看到的一部分。

因为我们花费大量的时间去研究数据中心和连通性,需要注意的一件事情是,这一部分的变化非常快,尤其是在 5G 正式商用时,某些负载开始不再那么依赖中心化的基础设施了。

边缘计算即将到来!:-)

嗨,它就是基础设施!

居于“连通”和“动力”之上的这一层,我们爱称为“处理器层”。这是奇迹发生的地方 —— 我们将来自下层的创新和实物投资转变成一个 API 终端的某些东西。

由于这是纽约的一个大楼,我们让在这里的云供应商处于纽约的中心。这就是为什么你会看到(Digital Ocean 系的)鲨鱼 Sammy 和对 “meet me” 房间里面的 Google 标志的致意的原因了。

正如你所见,这个场景是非常写实的。它是由多层机架堆叠起来的。尽管我们爱 EWR1 的设备经理(Michael Pedrazzini),我们努力去尽可能减少这种体力劳动。毕竟布线专业的博士学位是很难拿到的。

供给

再上一层,在基础设施层之上是供给层。这是我们最喜欢的地方之一,它以前被我们称为 配置管理 config management 。但是现在到处都是一开始就是 不可变基础设施 immutable infrastructure 和自动化:TerraformAnsibleQuay.io 等等类似的东西。你可以看出软件是按它的方式来工作的,对吗?

Kelsey Hightower 最近写道“呆在无聊的基础设施中是一个让人兴奋的时刻”,我不认为这说的是物理部分(虽然我们认为它非常让人兴奋),但是由于软件持续侵入到栈的所有层,那必将是一个疯狂的旅程。

操作系统

供应就绪后,我们来到操作系统层。在这里你可以看到我们打趣一些我们最喜欢的同事:注意上面 Brian Redbeard 那超众的瑜珈姿势。:)

Packet 为客户提供了 11 种主要的操作系统可供选择,包括一些你在图中看到的:UbuntuCoreOSFreeBSDSuse、和各种 Red Hat 系的发行版。我们看到越来越多的人们在这一层上加入了他们自己的看法:从定制内核和用于不可变部署的 黄金镜像 golden images (LCCT 注:golden image 指定型的镜像或模板,一般是经过一些定制,并做快照和版本控制,由此可拷贝出大量与此镜像一致的开发、测试或部署环境,也有人称作 master image),到像 NixOSLinuxKit 这样的项目。

运行时

为了有趣些,我们将 运行时 runtime 放在了体育馆内,并为 CoreOS 赞助的 rktDocker 的容器化举行了一次比赛。而无论如何赢家都是 CNCF!

我们认为快速演进的存储生态系统应该是一些可上锁的储物柜。关于存储部分有趣的地方在于许多的新玩家尝试去解决持久性的挑战问题,以及性能和灵活性问题。就像他们说的:存储很简单。

编排

在过去的这一年里,编排层全是 Kubernetes 了,因此我们选取了其中一位著名的布道者(Kelsey Hightower),并在这个古怪的会议场景中给他一个特写。在我们的团队中有一些 Nomad(LCTT 译注:一个管理机器集群并在集群上运行应用程序的工具)的忠实粉丝,并且如果抛开 Docker 和它的工具集的影响,就无从谈起云原生。

虽然负载编排应用程序在我们栈中的地位非常高,我们看到的各种各样的证据表明,这些强大的工具开始去深入到栈中,以帮助用户利用 GPU 和其它特定硬件的优势。请继续关注 —— 我们正处于容器化革命的早期阶段!

平台

这是栈中我们喜欢的层之一,因为每个平台都有如此多的工具帮助用户去完成他们想要做的事情(顺便说一下,不是去运行容器,而是运行应用程序)。从 RancherKontena,到 TectonicRedshift 都是像 Cycle.ioFlynn.io 一样是完全不同的方法 —— 我们看到这些项目如何以不同的方式为用户提供服务,总是激动不已。

关键点:这些平台是帮助用户转化云原生生态系统中各种各样的快速变化的部分。很高兴能看到他们各自带来的东西!

安全

当说到安全时,今年真是很忙的一年!我们尝试去展示一些很著名的攻击,并说明随着工作负载变得更加分散和更加可迁移(当然,同时攻击者也变得更加智能),这些各式各样的工具是如何去帮助保护我们的。

我们看到一个用于不可信环境(如 Aporeto)和低级安全(Cilium)的强大动作,以及尝试在网络级别上的像 Tigera 这样的可信方法。不管你的方法如何,记住这一点:安全无止境。:0

应用程序

如何去表示海量的、无限的应用程序生态系统?在这个案例中,很容易:我们在纽约,选我们最喜欢的。;) 从 Postgres “房间里的大象” 和 Timescale 时钟,到鬼鬼祟祟的 ScyllaDB 垃圾桶和那个悠闲的 Travis 哥们 —— 我们把这个片子拼到一起很有趣。

让我们感到很惊奇的一件事情是:很少有人注意到那个复印屁股的家伙。我想现在复印机已经不常见了吧?

可观测性

由于我们的工作负载开始到处移动,规模也越来越大,这里没有一件事情能够像一个非常好用的 Grafana 仪表盘、或方便的 Datadog 代理让人更加欣慰了。由于复杂度的提升,SRE 时代开始越来越多地依赖监控告警和其它智能事件去帮我们感知发生的事件,出现越来越多的自我修复的基础设施和应用程序。

在未来的几个月或几年中,我们将看到什么样的面孔进入这一领域……或许是一些人工智能、区块链、机器学习支撑的仪表盘?:-)

流量管理

人们往往认为互联网“只是能工作而已”,但事实上,我们很惊讶于它居然能如此工作。我的意思是,就这些大规模的、不同的网络间的松散连接 —— 你不是在开玩笑吧?

能够把所有的这些独立的网络拼接到一起的一个原因是流量管理、DNS 和类似的东西。随着规模越来越大,这些让互联网变得更快、更安全、同时更具弹性。我们尤其高兴的是看到像 Fly.ioNS1 这样的新贵与优秀的老牌玩家进行竞争,最后的结果是整个生态系统都得以提升。让竞争来的更激烈吧!

用户

如果没有非常棒的用户,技术栈还有什么用呢?确实,他们享受了大量的创新,但在云原生的世界里,他们所做的远不止消费这么简单:他们也创造并贡献了很多。从像 Kubernetes 这样的大量的贡献者到越来越多的(但同样重要)更多方面,而我们都是其中的非常棒的一份子。

在我们屋顶上有许多悠闲的用户,比如 Ticketmaster《纽约时报》,而不仅仅是新贵:这些组织拥抱了部署和管理应用程序的方法的变革,并且他们的用户正在享受变革带来的回报。

同样重要的,成熟的监管!

在以前的生态系统中,基金会扮演了一个非常被动的“幕后”角色。而 CNCF 不是!他们的目标(构建一个健壮的云原生生态系统),勇立潮流之先 —— 他们不仅已迎头赶上还一路领先。

从坚实的治理和经过深思熟虑的项目组,到提出像 CNCF 这样的蓝图,CNCF 横跨云 CI、Kubernetes 认证、和讲师团 —— CNCF 已不再是 “仅仅” 受欢迎的 KubeCon + CloudNativeCon 了。


via: https://www.packet.net/blog/splicing-the-cloud-native-stack/

作者:Zoe Allen 选题:lujun9972 译者:qhwdw 校对:wxy, pityonline

本文由 LCTT 原创编译,Linux中国 荣誉推出

两个开发团队的一天

几个月以前,我与一些人讨论过关于公共云服务成本与传统专用基础设施价格比较的话题。为给你提供一些见解,我们来跟踪一下一个企业中的两个开发团队  —  并比较他们构建类似服务的方式。

第一个团队将使用传统的专用基础设施来部署他们的应用,而第二个团队将使用 AWS 提供的公共云服务。

这两个团队被要求为一家全球化企业开发一个新的服务,该企业目前为全球数百万消费者提供服务。要开发的这项新服务需要满足以下基本需求:

  1. 能够随时扩展以满足弹性需求
  2. 具备应对数据中心故障的弹性
  3. 确保数据安全以及数据受到保护
  4. 为排错提供深入的调试功能
  5. 项目必须能迅速分发
  6. 服务构建和维护的性价比要高

就新服务来说,这看起来是非常标准的需求 — 从本质上看传统专用基础设备上没有什么东西可以超越公共云了。

1 — 扩展以满足客户需求

当说到可扩展性时,这个新服务需要去满足客户变化无常的需求。我们构建的服务不可以拒绝任何请求,以防让公司遭受损失或者声誉受到影响。

传统团队

使用的是专用基础设施,架构体系的计算能力需要与峰值数据需求相匹配。对于负载变化无常的服务来说,大量昂贵的计算能力在低利用率时被浪费掉。

这是一种很浪费的方法  —  并且大量的资本支出会侵蚀掉你的利润。另外,这些未充分利用的庞大的服务器资源的维护也是一项很大的运营成本。这是一项你无法忽略的成本  —  我不得不再强调一下,为支持一个单一服务去维护一机柜的服务器是多么的浪费时间和金钱。

云团队

使用的是基于云的自动伸缩解决方案,应用会按需要进行自动扩展和收缩。也就是说你只需要支付你所消费的计算资源的费用。

一个架构良好的基于云的应用可以实现无缝地伸缩 —  并且还是自动进行的。开发团队只需要定义好自动伸缩的资源组即可,即当你的应用 CPU 利用率达到某个高位、或者每秒有多大请求数时启动多少实例,并且你可以根据你的意愿去定制这些规则。

2 — 应对故障的弹性

当说到弹性时,将托管服务的基础设施放在同一个房间里并不是一个好的选择。如果你的应用托管在一个单一的数据中心  —  (不是如果)发生某些失败时(LCTT 译注:指坍塌、地震、洪灾等),你的所有的东西都被埋了。

传统团队

满足这种基本需求的标准解决方案是,为实现局部弹性建立至少两个服务器  —  在地理上冗余的数据中心之间实施秒级复制。

开发团队需要一个负载均衡解决方案,以便于在发生饱和或者故障等事件时将流量转向到另一个节点  —  并且还要确保镜像节点之间,整个栈是持续完全同步的。

云团队

在 AWS 全球 50 个地区中,他们都提供多个可用区。每个区域由多个容错数据中心组成  —  通过自动故障切换功能,AWS 可以将服务无缝地转移到该地区的其它区中。

在一个 CloudFormation 模板中定义你的基础设施即代码,确保你的基础设施在自动伸缩事件中跨区保持一致 — 而对于流量的流向管理,AWS 负载均衡服务仅需要做很少的配置即可。

3 — 安全和数据保护

安全是一个组织中任何一个系统的基本要求。我想你肯定不想成为那些不幸遭遇安全问题的公司之一的。

传统团队

为保证运行他们服务的基础服务器安全,他们不得不持续投入成本。这意味着将需要投资一个团队,以监视和识别安全威胁,并用来自不同数据源的跨多个供应商解决方案打上补丁。

云团队

使用公共云并不能免除来自安全方面的责任。云团队仍然需要提高警惕,但是并不需要去担心为底层基础设施打补丁的问题。AWS 将积极地对付各种零日漏洞 — 最近的一次是 Spectre 和 Meltdown。

利用来自 AWS 的身份管理和加密安全服务,可以让云团队专注于他们的应用 —  而不是无差别的安全管理。使用 CloudTrail 对 API 到 AWS 服务的调用做全面审计,可以实现透明地监视。

4 — 监视和日志

任何基础设施和部署为服务的应用都需要严密监视实时数据。团队应该有一个可以访问的仪表板,当超过指标阈值时仪表板会显示警报,并能够在排错时提供与事件相关的日志。

传统团队

对于传统基础设施,将不得不在跨不同供应商和“雪花状”的解决方案上配置监视和报告解决方案。配置这些“见鬼的”解决方案将花费你大量的时间和精力 —  并且能够正确地实现你的目的是相当困难的。

对于大多数部署在专用基础设施上的应用来说,为了搞清楚你的应用为什么崩溃,你可以通过搜索保存在你的服务器文件系统上的日志文件来找到答案。为此你的团队需要通过 SSH 进入服务器,导航到日志文件所在的目录,然后浪费大量的时间,通过 grep 在成百上千的日志文件中寻找。如果你在一个横跨 60 台服务器上部署的应用中这么做  —  我能负责任地告诉你,这是一个极差的解决方案。

云团队

利用原生的 AWS 服务,如 CloudWatch 和 CloudTrail,来做云应用程序的监视是非常容易。不需要很多的配置,开发团队就可以监视部署的服务上的各种指标  —  问题的排除过程也不再是个恶梦了。

对于传统的基础设施,团队需要构建自己的解决方案,配置他们的 REST API 或者服务去推送日志到一个聚合器。而得到这个“开箱即用”的解决方案将对生产力有极大的提升。

5 — 加速开发进程

现在的商业环境中,快速上市的能力越来越重要。由于实施的延误所失去的机会成本,可能成为影响最终利润的一个主要因素。

传统团队

对于大多数组织,他们需要在新项目所需要的硬件采购、配置和部署上花费很长的时间 — 并且由于预测能力差,提前获得的额外的性能将造成大量的浪费。

而且还有可能的是,传统的开发团队在无数的“筒仓”中穿梭以及在移交创建的服务上花费数月的时间。项目的每一步都会在数据库、系统、安全、以及网络管理方面需要一个独立工作。

云团队

而云团队开发新特性时,拥有大量的随时可投入生产系统的服务套件供你使用。这是开发者的天堂。每个 AWS 服务一般都有非常好的文档并且可以通过你选择的语言以编程的方式去访问。

使用新的云架构,例如无服务器,开发团队可以在最小化冲突的前提下构建和部署一个可扩展的解决方案。比如,只需要几天时间就可以建立一个 Imgur 的无服务器克隆,它具有图像识别的特性,内置一个产品级的监视/日志解决方案,并且它的弹性极好。

如何建立一个 Imgur 的无服务器克隆

如果必须要我亲自去设计弹性和可伸缩性,我可以向你保证,我会陷在这个项目的开发里 — 而且最终的产品将远不如目前的这个好。

从我实践的情况来看,使用无服务器架构的交付时间远小于在大多数公司中提供硬件所花费的时间。我只是简单地将一系列 AWS 服务与 Lambda 功能 — 以及 ta-da 耦合到一起而已!我只专注于开发解决方案,而无差别的可伸缩性和弹性是由 AWS 为我处理的。

关于云计算成本的结论

就弹性而言,云计算团队的按需扩展是当之无愧的赢家 — 因为他们仅为需要的计算能力埋单。而不需要为维护和底层的物理基础设施打补丁付出相应的资源。

云计算也为开发团队提供一个可使用多个可用区的弹性架构、为每个服务构建的安全特性、持续的日志和监视工具、随用随付的服务、以及低成本的加速分发实践。

大多数情况下,云计算的成本要远低于为你的应用运行所需要的购买、支持、维护和设计的按需基础架构的成本 —  并且云计算的麻烦事更少。

通过利用云计算,我们可以更少的先期投入而使业务快速开展。整体而言,当你开发和部署业务服务时,云计算的经济性可以让你的工作更赞。

也有一些云计算比传统基础设施更昂贵的例子,一些情况是在周末忘记关闭运行的一些极其昂贵的测试机器。

Dropbox 在决定推出自己的基础设施并减少对 AWS 服务的依赖之后,在两年的时间内节省近 7500 万美元的费用,Dropbox…——www.geekwire.com

即便如此,这样的案例仍然是非常少见的。更不用说当初 Dropbox 也是从 AWS 上开始它的业务的  —  并且当它的业务达到一个临界点时,才决定离开这个平台。即便到现在,他们也已经进入到云计算的领域了,并且还在 AWS 和 GCP 上保留了 40% 的基础设施。

将云服务与基于单一“成本”指标(LCTT 译注:此处的“成本”仅指物理基础设施的购置成本)的传统基础设施比较的想法是极其幼稚的  —  公然无视云为开发团队和你的业务带来的一些主要的优势。

在极少数的情况下,云服务比传统基础设施产生更多的绝对成本  —  但它在开发团队的生产力、速度和创新方面仍然贡献着更好的价值。

客户才不在乎你的数据中心呢

我非常乐意倾听你在云中开发的真实成本相关的经验和反馈!请在下面的评论区、Twitter @Elliot\_F 上、或者直接在 LinkedIn 上联系我。


via: https://read.acloud.guru/the-true-cost-of-cloud-a-comparison-of-two-development-teams-edc77d3dc6dc

作者:Elliot Forbes 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出