开发人员质疑平台即服务 (PaaS) 的未来——这是有充分理由的。他们中的许多人已经在 PaaS 上构建了成功的产品，但是当他们的应用程序达到一定规模时，他们发现自己需要更多。由于缺乏透明度和自以为是的黑盒功能，他们无法轻松调试性能问题。他们无法像 Web 应用程序防火墙那样实施完全可配置的安全性和合规性控制。他们被平台提供的任何有限的附加组件所困，如果它们被提供的话。持久存储、可配置负载平衡和自动缩放等功能对于在 PaaS 上的实际使用来说要么不存在，要么过于有限。 那么开发人员做什么呢？他们将应用程序移植到基础架构即服务 (IaaS)。 并不是说IaaS更好，而是它没有实施限制。开发人员可以通过 IaaS 提供商构建他们想要的任何东西。权衡是时间、专业知识和额外人员配置之一。但这对于拥有成功的 PaaS 应用程序的大多数开发人员来说是可以的，因为他们已经度过了构建某些东西并找到适合市场的产品的困难部分。他们并不担心迁移到 IaaS 的学习曲线，因为到那时，他们已经有了用户群、收入和跑道。 如果 是大规模可行的选择，开发人员可能不会将他们的应用程序移植到 IaaS。但这是否意味着 PaaS 应该被认为不如 IaaS？几乎不。 PaaS 的未来是光明的——比许多开发人员所认识的要光明得多。事实上，我相信 PaaS 将主导软件开发的未来。市场渴望出现一个“伟大的起点，伟大的规模”平台，以超越当今的开发者体验和价值。 PaaS 绝对支持全球可扩展的应用程序交付，但它必须首先克服一些挑战。  PaaS  IaaS 是伟大的，直到它不是 IaaS 的美妙之处在于它提供了近乎无限的配置和可扩展性选项。 IaaS 提供商已经将他们的产品广泛化，足以支持几乎任何规模的任何用例。它非常强大且具有成本效益。此外，IaaS 提供商很乐意提供使用积分和折扣价，以推动采用并吸引团队。 然而，如果不搬起石头砸自己的脚，构建可扩展的配置可能会非常困难。不正确的配置更改可能会导致灾难性的后果，如果没有深厚的基础设施专业知识，几乎不可能进行故障排除和补救。实际上没有可用的平台支持（除了昂贵的企业参与之外），而且 IaaS 文档非常不一致且难以阅读。甚至不要让我开始了解 IaaS 控制台的实际用户体验。 全力投入 IaaS 意味着建立昂贵的基础架构团队来使用和管理 IaaS。基础设施专家不仅是业内最抢手的一些人，而且要找到知道如何满足独特增长需求的合适人选也极其困难。筹款环境更加紧张、团队被告知“事半功倍”以及 IaaS 解决方案的复杂性迅速增加等现实加剧了这些复杂性。团队的工作是随着基础设施的发展建立和维护基础设施——这项工作永远不会“完成”。 公司使用 IaaS 的典型旅程如下所示： 聘请 1-2 名后端专家或基础架构工程师来确定和实施架构。 扩大团队，经历一些人员流动，架构发生有机变化。 现在维护基础架构的团队不再是最初构建它的团队。 当某些东西坏了，修复起来简直就是一场噩梦。没有人记得为什么做出决定，部落知识消失了，几个月前有效的现在是“遗产”，因为没有人理解它。 在资金问题和缺乏可用的基础设施人才之间，很难建议深化对基础设施和平台工作的投资。 IaaS 的特性和功能变得越来越复杂，进一步证明需要更高级别的抽象，就像 PaaS 提供的那样。  IaaS 希望他们可以做 PaaS  IaaS 供应商知道这一点，这就是他们投资于类似 PaaS 的抽象的原因。谷歌通过他们的云平台和移动开发平台 在这方面做得很好。 Amazon 一直在尝试构建抽象，但他们的开发人员体验……并不好。尽管如此，很明显他们明白开发人员想要（并且应该得到）更好的体验，例如 和 。 Azure 现在提供  ，它允许在自动缩放基础设施上简化部署。 Firebase S3 对象的自动加密 RDS 与 AWS Secrets Manager 的集成 App Service 主要的云提供商在类似 PaaS 的产品方面做得越来越好，但他们也专注于传统的直接迁移策略或科幻小说中的“无服务器 Kubernetes”幻想。他们的大部分现金来自企业，这使得他们的功能开发偏向于服务更多的企业。初创公司和中型公司只能祈祷他们的反馈能带来更易于使用和更易于构建的类似 PaaS 的环境，这些环境不需要高级基础设施专业知识即可充分利用。  Raman Sharma ，“至少有两个主要的超大规模云提供商（Azure 和 GCP）开始了他们使用 PaaS 产品的云之旅，只是很快意识到真正的钱（以及大量的肌肉和机构记忆）仍在基础设施中.因此，他们转向以 IaaS 为中心（就像当时的 AWS）。” 敏锐地观察到 换句话说，如果 IaaS 不是那么有利可图，IaaS 就会在做 PaaS。他们不是在为初创公司服务，而是在为企业服务。  IaaS 不是竞争优势，而是干扰 在 IaaS 中构建确实提供了大量的自由和机会，但您愿意花 15 万美元聘请 AWS 认证的管理员，还是花 15 万美元聘请可以构建创收功能的开发人员？ 如果您不必担心基础架构，那么聘请开发人员是不二之选。不幸的是，公司经常遇到两全其美的情况：他们雇用价值 15 万美元的开发人员并强迫他们也做所有 DevOps 工作。这更不划算。 对于从 PaaS 转移到 IaaS 的产品团队，以及那些从 IaaS 开始并扩大规模的团队来说，确实没有竞争优势。在某些时候，这将不可避免地需要聘请一位昂贵且经验丰富的云基础设施架构师。当然，我并不反对熟练的云基础架构工程师，但是当我面临越来越大的“事半功倍”的财务压力时，我对增加管理费用并不是很兴奋。 此外，即使我拥有世界上最棒的云基础设施团队，即使它没有我想象中担心的那么昂贵，拥有该团队的竞争优势是什么？这真正为任何企业提供什么优势？老实说，我宁愿拥有一支由价值创造开发人员组成的精干团队，也不愿拥有价值保护管理员。是的，我可以在 IaaS 上花费时间和精力来获得持久性磁盘、数据库的时间点恢复、可配置的负载平衡、蓝/绿部署逻辑和自动缩放，但我保证大多数开发人员宁愿拥有所有在设计精美的 UI 中通过复选框提供。 我有更多时间专注于保持正常运转，我花在为想要花钱购买我的产品的客户提供出色功能上的时间就越少。更多的基础设施，更少的价值。   PaaS解决了IaaS的问题 PaaS 存在的主要原因首先是因为 IaaS 太复杂了。开发人员想要编写和部署代码。他们想要构建新的应用程序和功能，了解市场的反应，并进行迭代。他们希望以尽可能少的障碍来做到这一点。 例如，如果我需要符合 HIPAA 标准的基础架构来构建以医疗保健为中心的 SaaS，我可以从 开始，该架构不完整且复杂，然后花费数周时间来启动和运行它。或者，我可以在几分钟内在 Aptible 上启动一个应用程序，并且知道它符合 HIPAA 标准。 Amazon 的参考架构  PCI 合规性也是如此。 Stack Overflow 和 Reddit 上充满了在任何大型 IaaS 云中建立和维护符合 PCI 标准的基础设施的艰苦战斗的例子和警告。或者，您可以找到符合 PCI 标准的 PaaS，并在防火墙配置上花费零时间。 事情是这样的：没有人选择从复杂的基础设施架构和实施开始。他们只是没有太多选择，或者他们不知道现有的选择。如果 PaaS 具有成本效益并且能够满足长期扩展需求，那么任何开发人员或产品领导者都会选择它。 PaaS 不存在成本效益问题，但会因支持成长型企业的长期能力而陷入困境。如果不是这样，PaaS 将成为启动和扩展应用程序的明智之选。 这就提出了一个问题：谁不会支付一些可持续的额外资金来让一切“正常工作”、出色的文档和内置支持？  PaaS需要解决自己的问题 IaaS 在提供适用于任何用例的通用解决方案方面做得很好。 PaaS 尚未实现。有太多较小的缺失功能和混淆导致团队离开 PaaS。没有单一的 PaaS 可以支持公司需要运行的每个应用程序，这是一个非常重要的问题。 此外，自 2010 年 PaaS 开始蓬勃发展以来，应用程序开发模式也发生了变化。Heroku 及其同类产品并没有跟上。以下是一些对业务至关重要但未被 PaaS 涵盖的常见工程团队“待完成的工作”： 对象存储 事件驱动计算（“无服务器”） 数据入库 NoSQL 和图形数据库 事件数据库 搜索数据库 需求显然是多种多样的。 PaaS 世界在专业平台方面做得很好，这些平台明确地将自己定位为在单个任务中同类最佳的平台，但世界需要一个可以支持一系列业务支持功能的 PaaS。  PaaS需要支持更多样化的应用架构 PaaS 应用程序往往是单一的，以便利用底层基础设施平台的各种功能。然而，不断增长的产品最终可能需要拆分成一组相互依赖的微服务。 现在，开发人员必须经历种种困难才能使微服务架构在 PaaS 上正常运行。他们需要像服务发现和直接容器连接这样的结构来高效运行。在 PaaS 世界中很难找到这些原生功能。 当应用程序变得比 PaaS 可以理解的复杂时，就会出现有问题的动态。这是开发人员转向 IaaS 的一个重要原因。如果 PaaS 不能支持数据仓库，那么就没有理由将其他任何东西部署在 PaaS 上。  IaaS 用户渴望类似 PaaS 的抽象 一旦一家公司从 PaaS 转向 IaaS，矛盾的是他们会渴望使 PaaS 变得更好的东西：降低的复杂性、出色的开发人员体验、出色的文档和可预测的成本。今天阅读任何“DevOps 现状”报告，您都会了解到“平台工程”运动及其哲学基础。 但公司不应该需要重新发明平台。这是生产力的主要成本。创建和发展一流的开发人员体验足以成为一个业务线本身。对于财富 50 强之外的公司而言，通过 IaaS 构建抽象可能几乎没有投资回报率（对他们的客户和股东来说更不用说了）。这是一个荒谬的商业提议。   PaaS 有很大的增长空间——我们看好 PaaS 解决了很多 IaaS 的问题： 基础设施是一种干扰，而不是竞争优势 公司和产品团队乐于花钱解决他们的大问题（或外包给平台） 性能、增长和规模不应成为构建、运行和维护的必要压力 我们看到了通用 SaaS 的机会，它不会让开发人员陷入困境，我们感到很兴奋。我们正在利用我们已经构建的东西——最好的和唯一的非 Heroku PaaS，可以扩展以满足企业需求——并使开始构建应用程序变得更容易和更容易访问。 以下是我们对市场的预期反应（以及我们自己的应对方式）： 自动缩放和简单定价：在 Heroku 之外，很难围绕 PaaS 缩放和成本设置约束。这是 PaaS 提供商要解决的第一个也是最重要的领域。 开发人员体验和首次用户体验：PaaS 提供商将专注于帮助开发人员快速构建和发展他们的应用程序。这是迄今为止大多数创新的地方——努力重新获得 Heroku 提供的魔法感觉。 支持现代、更高级别的开发人员抽象：支持第 3 方无服务器基础架构解决方案、运营分析、人工智能、供应链安全和去中心化软件。 交付现代用例：允许公司完成与工程相关的任务，如静态网站、对象存储等。 随着 AWS 和其他 IaaS 提供商向他们的控制台添加越来越多的服务，我们不得不期待更多的复杂性。越来越多的 IaaS 客户最终将依赖即将成为遗留云架构和开发范例的东西。这些公司将不可避免地寻求 PaaS 来摆脱束缚，或者甚至只是为了避免处理实用 IaaS 的复杂性和挫折感。 最后，我将特别关注大公司中规模较小、相对独立的团队中的开发人员。 “你构建它，你运行它”运动可能会成为增加 PaaS 采用率的驱动力。事实上，它已经变成了“你构建它，你运行它，你保护它”。随着开发团队对他们的基础架构更加负责，他们将对自己的 DevOps 负责。他们只能管理这么多，因此 PaaS 将更具吸引力。 PaaS 将成为必需品。 今天人们可能看跌 PaaS，但这些团队需要一个真正的企业级 Heroku 竞争对手的日子即将到来。一个平台将开辟这条道路，它将比 Heroku 更快地流行起来。  2023 年，Aptible 将展示它就是那个平台。

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Focus on product, not infrastructure!

該音頻是用故事的原始語言製作的！

IaaS 是伟大的，直到它不是：PaaS 的回归

About Author

註釋

標籤

这篇文章刊登在

Related Stories

比特币 UTXO 模型，为独特的生态系统提供动力

使用这 18 种开发工具来提高你的工作效率 🚀🔥

扬帆起航：利用数据湖开发生产级 RAG 应用程序

Telegram：加密岛通往大陆的桥梁

比特币 UTXO 模型，为独特的生态系统提供动力

使用这 18 种开发工具来提高你的工作效率 🚀🔥

扬帆起航：利用数据湖开发生产级 RAG 应用程序

Telegram：加密岛通往大陆的桥梁

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps