随时了解云服务更新

在快节奏的云服务领域，与服务更新保持同步通常具有挑战性。最近宣布的StackFeed旨在解决这个问题，特别是对于管理多云架构的软件架构师。架构师选择他们感兴趣的云服务，StackFeed 使用 RSS 阅读器、Slack 或 Microsoft Teams 生成定制的服务更新提要。

软件工程师协作图表工具IcePanel的联合创始人Jacob Shadbolt和Victor Leach以及IcePanel 的高级软件工程师Chris Saganic创建了 StackFeed。该团队亲身经历了 StackFeed 解决的挑战:

三大云提供商都在不断推送更新，但找到相关更新非常具有挑战性——就像从消防水带里喝水一样。掌握这些更新非常重要，无论是改进和优化您提供给客户的服务，还是更激进的是，您所依赖的服务正在被弃用。每家公司和团队的服务/技术堆栈都是独一无二的，要随时获取所有更新实在是太难消化了。

为了创建 StackFeed 后端，创建者在 Google 工作表中手动编目了 600 个云服务，并将该工作表导入到 Firestore 数据库中。一个自动脚本每小时运行一次，从三大云提供商那里抓取RSS更新提要，以获取过去 72 小时内发布的新文章。StackFeed 然后抓取每个更新的 URL 以获取文章的长格式正文，将其转换为 Markdown，并将其插入数据库。StackFeed 还每小时运行一次使用数据库文章的前端构建。

StackFeed 的前端架构采用混合渲染，将每个服务（最初来自 Google 表格的 JSON 数据）转换为用户友好的格式。StackFeed对提要和文章内容使用服务器端呈现(SSR)，用户可以通过查询字符串传递服务以创建自定义提要。Netlify 函数上的Nitro处理部署，允许在边缘进行 SSR。

InfoQ 就 StackFeed 及其实现采访了 Shadbolt。

InfoQ:构建 StackFeed 的主要挑战是什么?你是如何克服它们的?

Jacob Shadbolt: 构建 StackFeed 的主要挑战是手动对来自三大云提供商的约 600 项服务进行分类。每个服务的管理、记录和更新方式的不一致确实令人惊讶，所以不幸的是，对我们来说，自动化是行不通的。解决方案是手动坐下来将数据输入电子表格，我们用它来管理 StackFeed。

InfoQ:在您看来，当今软件架构师面临的主要挑战是什么?

Shadbolt: “架构师”这个头衔有着自上而下的“象牙塔”决策者的历史，一些公司因其公司和类似独裁的过去而取消了员工的头衔。然而，实际上，该角色已经并且仍在转变为协作促进者，使业务、产品和工程团队在设计决策上保持一致。

了解企业软件系统的工作方式具有挑战性，甚至在为该公司制定未来战略举措以保持竞争优势之前也是如此。如果你加上系统的变化率、服务依赖性、新趋势和分布式/更自主的团队——你有一大堆问题需要战略性地处理。我看到架构师监督技术决策并将其与业务和产品目标相关联的角色和责任的复兴。

InfoQ:您还是 IcePanel 的联合创始人。IcePanel 如何应对这些挑战?

Shadbolt:整个技术和非技术团队都应该有一个地方来了解他们的软件系统如何从上下文到代码工作。图表工具不适合这项工作，因为系统非常复杂，而用于可视化这种复杂性的静态、未链接的图表几乎不可能准确记录（或保持最新）。

大多数人认为您应该自动生成设计文档，但我们认为这是错误的。在解决系统问题时，设计应该是首要考虑因素;需要人为因素才能使这些决定为他人所理解。去除人为因素意味着您最终会得到一个信息网络，这些信息可能是准确的，但需要更加抽象以供人类使用。我们正在努力成为一种工具，让团队能够完全了解他们的技术设计，无论是现在还是未来的解决方案，并根据现实的变化进行链接和通知。