Netflix 构建了一个 PaaS……为什么我不能?

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前, 星球 内第2个项目《仿小红书(微服务架构)》正在更新中。第1个项目:全栈前后端分离博客项目已经完结,演示地址:http://116.62.199.48/。采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 255 小节,累计 39w+ 字,讲解图:1716 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 1300+ 小伙伴加入,欢迎点击围观

云的主要好处是能够使用某种类型的资源“即服务”。资源可以是基础架构 (IaaS)、平台 (PaaS) 或软件 (SaaS)。 IaaS 和 SaaS 空间在过去五年中或多或少保持稳定,这主要是因为人们对这些产品的外观达成了广泛的共识。问 10 个人 IaaS 解决方案是什么样的,您可能只会得到一两个不同的答案。问 10 个人什么是 PaaS 解决方案,您可能会得到 15 个答案。

PaaS 的目标是为您的应用程序提供 基础 。 PaaS 解决方案应该为您的代码或部署工件提供大部分(如果不是全部)运行时平台(包括基础设施)。如果做得好,PaaS 会很棒——您担心您的代码,而其他人则担心其他一切。您的 PaaS 供应商使用的操作系统存在安全漏洞?这是您的 PaaS 供应商要处理的问题。飓风淹没了您的 PaaS 供应商的数据中心?再一次,不是你的问题。从根本上说,PaaS 的使用减少了您必须关心的范围。您只关心您的供应商能否达成一致的服务水平协议。 DevOps 和微服务的兴起越来越多地使传呼职责成为现代开发角色的一个方面。减少你必须关心的范围通常是通宵解决生产中的问题和睡一整夜之间的区别。

PaaS 的挑战在于没有人能就解决方案的范围达成一致。一方面,通常由 IaaS 供应商支持的 PaaS 解决方案基本上是不同层的操作级“布线”,任何层之间都没有垂直集成。这种方法提供了极大的灵活性,但它是以垂直集成为代价的,垂直集成是自动化生命周期活动(如备份、恢复、补丁等)的关键。IaaS 供应商无法垂直集成,因为他们不拥有任何上层堆栈软件——他们是基础架构供应商,而不是 SaaS 供应商或 ISV。另一方面,PaaS 解决方案通常受到 SaaS 供应商和 ISV 的拥护,它是硬件和软件的紧密集成的垂直堆栈,您只需将代码带入其中。 SaaS 供应商和 ISV 拥有上层堆栈代码,因此他们可以为您提供特定堆栈的垂直集成体验。虽然这种方法提供的灵活性相对较低,但它确实为您提供了更好的体验,因为常见的生命周期活动通常完全由供应商处理,或者您只需按一下按钮即可使用。这是一个权衡——您想要灵活性还是更好的生命周期体验?

PaaS 并没有像许多人预期的那样起飞,因为评估 PaaS 解决方案迫使组织对其开发理念、技术选择以及运营与开发人员的角色做出艰难的决定。这通常会导致僵局并继续维持现状,这通常只是普通的 IaaS。任何 PaaS 都比普通的 IaaS 好。例如,如果您仅使用 IaaS,您将不得不手动完成以下活动,这些活动由基于 IaaS 的良好 PaaS 完成:

  • 确定要安装的软件,包括操作系统级别的软件包依赖项
  • 为安装软件准备操作系统 - 环境变量、内核更改等
  • 下载软件,验证完整性
  • 安装软件
  • 按比例放大/缩小/缩小/缩小

仅将这几个步骤自动化即可提供出色的成本节约,同时不会过多地限制选择。这是伟大的第一步。

SaaS 供应商或 ISV 提供的良好的垂直集成 PaaS 走得更远,可以为您做一些事情:

  • 在防火墙中打开端口
  • 安装监控和日志记录基础设施
  • 根据需要对每一层进行聚类
  • 向负载均衡器注册
  • 确定要安装的补丁
  • 下载补丁,验证完整性
  • 在同一时间点备份每一层
  • 安全地将备份写入存储
  • 安装补丁
  • 从存储中重新水合备份

执行这些活动需要广泛的垂直集成,只有 SaaS 供应商和 ISV 才能做到。只要您的软件堆栈与 PaaS 供应商的堆栈相匹配,您就万事大吉了。垂直整合是降低运营复杂性的关键。难道你不想创新而不是打补丁吗?

开发人员不喜欢在他们的头脑之上做出他们必须永远忍受的技术决策。这是可以理解的,因为他们经常不得不忍受他人(通常是错误的)决定的后果。现在,云购买决策通常由开发人员做出,他们在选择 PaaS 解决方案方面拥有选择权或发言权。对企业来说重要的是开发人员正在使用某种 PaaS。开发人员不必使用相同的 PaaS,但他们至少应该使用一个。

从技术上讲,您可以使用 IaaS + DevOps 工具构建自己的 PaaS。要构建您自己的 PaaS,您必须定义脚本来供应基础设施,在您供应的每个计算单元(VM、容器等)中安装软件,然后集成每一层以协同工作。然后你必须编写额外的脚本来处理生命周期活动,如备份、恢复、补丁等。虽然它很可能会起作用,而且你可能会对所有的 PaaS 供应商嗤之以鼻,但你必须预先权衡构建、测试和维护脚本所需的时间可以节省成本:供应基础设施、安装/配置软件、集成所有不同层以协同工作、向上/向下扩展、备份/恢复、打补丁等.维护所有这些脚本最终可能比维护您的应用程序更费力。

对于少数以技术为业务的组织而言,构建自定义 PaaS 是完全可行的。 Facebook、谷歌、Netflix 等公司在技术上大手笔投资,因为技术是他们的业务——这不仅仅是一种开支。这些公司只有少数面向客户的大型应用程序,因此为每个应用程序构建一个 PaaS 堆栈是可行的。世界上绝大多数其他企业都不属于技术行业。他们从事保险、医疗保健、制造或构成“实体”经济的数百个其他学科的业务。他们将总收入的百分之几用于技术,而成本主要归类为费用——成本中心。普通公司拥有数十个(如果不是数百个甚至数千个)小“点”应用程序来保持其业务平稳运行。这些应用程序对于保持业务平稳运行至关重要,但不是任何公司都会用来使自己脱颖而出的应用程序。你不会发现一家运输公司在会议上吹嘘他们的工资系统。这就是为什么大多数这些应用程序都是从 ISV 购买的。当您查看所有涉及的成本时,为这些较小的单点应用程序构建 PaaS 系统几乎没有任何意义。熟练的劳动力并不便宜。

PaaS 解决方案存在于垂直集成级别的连续统一体中。可以购买或构建 PaaS 解决方案。除非您是 Netflix 或其他少数以技术为业务的公司之一,否则请考虑购买您的 PaaS 解决方案,最好是具有紧密的垂直集成。让 PaaS 供应商处理保持应用程序正常运行所需的繁琐工作。

关于作者

Kelly Goetsch 是 Oracle 的产品管理总监,负责 Oracle 的多个 PaaS 解决方案。他是 eCommerce in the Cloud(O'Reilly,2014 年)的作者,撰写了大量有关大规模分布式 Web 架构的文章。 Oracle 云是一个全面的集成服务套件,使开发人员、IT 专业人员、业务用户和分析师可以更轻松地构建、扩展和集成云应用程序。