为什么我＆＃m构建Stelvio

我之前撰写了一篇关于云端软件开发未来趋势的文章。今天，我想分享我创建Stelvio的原因以及它旨在解决的问题。

我拥有超过20年的编程经验，过去十年主要专注于Python和云计算。过去几年，我一直在AWS工作，每天都在构建和部署云系统。

长期以来，我观察到哪些方法有效，哪些方法无效，以及开发人员在哪些方面浪费了大量时间。

核心问题始终如一：创建功能、设置API网关（资源、方法、集成）、添加IAM权限、设置环境变量等等。我已经重复做过数百次——通过控制台、CLI或使用IAC（基础设施即代码）。去年某个时候，我意识到一个问题：云计算过于复杂。

为什么我一次又一次地重复这些步骤？为什么我需要不断编写类似的配置？为什么我必须成为AWS专家才能正确执行这些操作——确保日志能够到达正确的位置，权限足够严格但又能正常工作，端口关闭等等。

AWS功能强大，但它庞大而复杂，因此难以维护，确保一切正常运行非常繁琐。这并非因为它是火箭科学，而是因为需要花费大量时间来学习和正确配置所有内容。

最糟糕的是，这些工作大多分散了开发人员的主要精力（实现业务逻辑）。最终，您对基础设施的了解越多越好。您应该努力学习和理解它，但这并不意味着您需要在开始之前成为专家。

这不应该如此繁琐。

很难同时精通所有方面——编写复杂的系统和管理基础设施。两者相互干扰。许多团队需要独立的运维人员或DevOps工程师。虽然对于大型项目（通常速度较慢）来说这是可行的，但这对于需要快速迭代的中小型团队来说效率低下。他们不想等待运维人员完成工作，才能让开发人员继续他们的工作。> > 除非您从事非常大型的项目，否则您不需要团队中拥有基础设施专家。>

开发人员应该能够独立处理所有内容。Stelvio旨在为他们提供工具，使这个过程更轻松、更高效、更安全。

缺失的部分：当前的解决方案还不够完善

有一些现有的解决方案可以帮助您创建基础设施。

首先是AWS CloudFormation——仅适用于AWS。然后是云无关的Terraform。这些都是优秀的工具，它们是革命性的，因为它们允许您将基础设施定义为IAC（基础设施即代码）。（如果您认为YAML或JSON/HCL是代码的话:)）。但是，这些工具存在两个问题：

它们并非真正的代码——更像是配置。

它们专注于基础设施。

为什么这些是问题？这取决于谁在使用它。对于基础设施工程师来说，这可能不是问题，他们认为自己是这方面的专家，YAML/JSON/HCL对他们来说根本不是问题。

但是，从开发人员的角度来看，这远非理想。使用YAML/JSON/HCL与使用Python不同。它很容易学习，但从Python切换到它很痛苦。这就像用挖掘机构建应用程序，然后用铲子构建基础设施。

哦，还有更多！使用CloudFormation，您的模板很快就会达到数千行。使用Terraform，情况有所改善，但仍然远非理想。

我一直在寻找一种更快速、更简单的工具。

有一些工具允许您使用实际的编程语言来定义基础设施：AWS CDK和Pulumi。

它们很棒，您可以使用Python（或TypeScript、Go、C#、Java）来定义您的基础设施。

我每天都在使用它们，但它们仍然存在问题：> > 它们专注于基础设施，而不是开发人员。他们的目标是在云中实现所有可能的功能，这使得它们变得复杂。

您可以使用您喜欢的语言，但您仍然需要编写大量代码。

您仍然需要编写大量重复的样板和配置（例如IAM）。它不那么乏味，但仍然很繁琐。> 另一端是简单的部署平台和点击式解决方案。它们非常简单且易于使用——这很好——但是它们功能有限（非常狭窄的关注点）且昂贵（甚至比AWS价格高出5倍）。

对于中小型项目，您可能愿意为更高的效率付出更多代价。但是，根据我的经验，在没有扩展选项的情况下，它们过于有限。我在这些解决方案中看到的另一个问题是，它们专注于UI而不是代码（IAC）。这意味着您将失去许多好处——您无法跟踪更改，无法轻松地重现构建，无法正确地自动化等等。其中一些平台正在朝着定义基础设施框架（FDI）的方向发展，这是一个有趣的想法，但现实是混乱的。您经常使用不同的框架来构建解决方案——因此被困在一个框架中是行不通的。> 开发人员需要更好的工具，专注于开发人员体验（DX）和生产力。

使用正确的工具，大多数项目不需要专门的基础设施专家。

我想要一些简单易用的工具。一个允许我使用Python编写代码并部署到AWS的工具，而无需过多考虑AWS内部机制。> > 一个可以自动处理无聊和重复工作的工具。

解决方案：以开发人员为中心的基础设施

这就是Stelvio诞生的原因。

Python优先方法

Python开发人员应该只使用Python来定义他们的基础设施。考虑一下——在Python、YAML/JSON/HCL和AWS控制台之间切换不仅烦人，还会破坏您的工作流程。

当我开始构建Stelvio时，很明显它必须只使用Python。

无限画

千库网旗下AI绘画创作平台

下载

在Stelvio中，您始终使用Python。这并非因为您无法学习其他工具，而是因为它更快、更高效。

为什么选择IAC？

当所有内容都是代码时，我们获得许多好处：> > 版本控制和历史记录——我们可以跟踪、查看（在拉取请求中）并回滚每个基础设施更改

可重复性——开发、登台和生产环境保持一致，因为它们是由相同的代码构建的

测试和验证——我们可以在部署前测试基础设施。我们可以通过自动扫描来捕获错误的配置和安全问题

自动化和重用——我们可以将通用模式封装到可重用的组件中。CI/CD将处理部署。不再需要手动点击控制台

文档即代码：我们的基础设施是自文档化的。开发人员可以阅读和理解事物的工作原理，而无需依赖外部（过时的）文档>

我们的基础设施与我们的应用程序代码一样重要。

正确的抽象级别——自上而下

一旦我们在Python中定义了基础设施，下一个技巧是在正确的抽象和控制级别上。 > 基于基础设施的工具专注于云的基本组件——核心基础设施的基本构建块。您必须配置所有内容。基于UI的平台专注于高级抽象。它有效——直到您需要配置一些细节或以自己的方式操作。

最好的方法是拥有一个具有智能默认值的高级抽象，只需几行代码即可轻松使用。但是，每个细节都应该可以配置——但只有在需要时。

复杂性应该可见，但只有在必要时才可见。 Stelvio >

愿景：不仅仅是另一个工具

我的愿景是拥有一个可以自动化无聊的重复性任务并提供高级但可定制的构造的工具。> 但不止于此。

我想改变我们与基础设施交互的方式。> 整个世界都缺少的东西。我们需要更好的开发人员体验。不仅在定义基础设施时，而且在使用过程中，无论是在开发还是生产环境中。以下是我列表中的一些内容：- >

• 创建、管理和克隆整个环境的简便方法

• 更好的自动部署

• 更好、更轻松、更快的日志查看

• 监控

• 成本理解、分析和预测

• 安全检查

• 架构概述

• 备份管理

• 在云中运行测试的简便方法> 等等。

时机成熟

为什么是现在？首先，因为我对此感到沮丧。

但是，时机也很成熟，因为Python已经成为世界上使用最广泛的编程语言之一，并且还在不断增长。即使我们忽略它在AI/ML中的使用，它仍然是云计算中最常用的语言之一。>

现在，云平台已经非常成熟，不再需要新的工具来启动。Pydantic和FastAPI表明，需要更好的开发人员工具来提高他们的生产力并帮助他们创建> 更好的软件。

Stelvio旨在为Python云开发人员提供此类工具。

加入旅程

我很快将发布Stelvio的第一个开发者预览版，作为一个开源项目> 在GitHub上。- 如果你对Stelvio感兴趣：

关注我- GitHub上的星标-

• 让我们一起为Python开发人员提供更好的云开发体验。

• 我迫不及待了——这将是一段精彩的旅程！