NotionNext BLOG https://blog.devops.gold/ 这是一个由NotionNext生成的站点 Fri, 23 Feb 2024 10:25:46 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2024, kevin_zz <![CDATA[康威定律、DevOps 和您的源代码]]> https://blog.devops.gold/article/conways-law-devops-and-your-source-code https://blog.devops.gold/article/conways-law-devops-and-your-source-code Wed, 24 Jan 2024 00:00:00 GMT
康威定律，作者：ChatGPT
康威定律，作者：ChatGPT
源代码库的布局会影响公司的组织结构图，如果第一个布局出错，软件交付能力就会受到影响。
康威定律（Conway's Law）指出，软件架构会自然而然地与公司的组织结构图相匹配。我扩展了这一定律，认为你的源代码库结构会自然而然地影响你的组织结构，如果你正在实践 "DevOps"，错误的结构将导致混乱。
定义服务基础架构的代码（通常称为 "基础架构即代码"）与服务的其他部分属于同一源代码库。

康威定律

让我们快速回顾一下康威定律的内容。梅尔文-康威在他的开创性论文中将该定律总结为
任何组织在设计一个系统（广义上的系统）时，都会产生一个其结构是该组织通信结构的复制品的设计。
马丁-福勒（Martin Fowler）对法律进行了更详细的阐述：
康威定律的本质是观察到软件系统的架构与构建该系统的开发团队的组织结构极为相似。我最初是这样描述它的：如果一个团队编写一个编译器，那么它将是一个单通道编译器，但如果团队分为两个，那么它将是一个双通道编译器。
证明康威定律远远超出了本文的讨论范围，维基百科上的文章列出了一系列支持康威定律的证据，供希望进一步研究的人参考。为了今天的目的，我们假设康威定律是真的。
 
 
马丁-福勒（Martin Fowler）解释了康威定律的三种反应，这与我在实践中看到的情况相吻合。
notion image
notion image

DevOps

notion image
实践 DevOps "你构建，你运行 "的软件开发团队负责服务生命周期的几个不同方面：
  1. 编写构成服务的应用代码
  1. 创建自动测试，包括单元测试和系统/集成测试
  1. 开发构成生产服务的 IaC
  1. 创建观察服务的仪表板和警报。
在许多组织中，前两个存储在一个存储库中，第三个存储在一个单独的存储库中，通常由不同的团队管理，而第四个存储库则是人工事后想到的。
顺便提一下，我所说的 IaC 是指将服务部署到开发、测试环境和生产环境所需的一切。这包括 Docker 文件、Helm 图表、Cloudformation 或 CDK、Terraform、shell 脚本、CI/CD 定义、SQL 脚本等。
让我们深入探讨一下为什么应用程序代码、自动测试代码和 IaC 属于同一个资源库的几个更明确的原因。
  • IaC 是代码。它不属于其他地方的任何特殊、奇怪或怪异的东西。根据我的经验，有些开发人员似乎可以维护复杂的应用程序代码和奇怪的测试结构（你见过 TDD 框架吗？)
  • 没有部署定义的服务是不完整的。我甚至可以说，如果没有 IaC，应用程序代码大多是无用的，它无法真正发挥预期的功能。如果您的服务托管在 AWS 上的 Kubernetes 中，并且有一个 DynamoDB 表，那么如果没有用于打包的 Docker 文件、用于部署的 Helm 图表、用于定义 DynamoDB 表的 CloudFormation 或 Terraform 以及授予权限所需的 IAM 工件，应用程序代码本身就毫无用处。
  • 当所有代码都位于同一个版本库中时，开发人员就更容易对服务进行推理。当 IaC 位于同一个版本库中时，对复杂服务进行更改会更简单，尤其是当这些更改跨越应用和基础架构代码时，例如更改 DynamoDB 定义或添加需要更改 IAM 策略的新 API 调用时。
  • 如果所有工件都在一个版本库中，特别是在从主分支持续部署时，版本控制就会简单得多。
  • 应用 "或 "服务 "代码与 IaC 之间的界限越来越模糊。十年前的传统服务可能是手工部署在虚拟机甚至物理硬件上的单一二进制文件。现代服务可能是一种无服务器应用程序，无法在云执行环境之外运行，IAM 角色允许访问 AWS 的 DynamoDB 或 Google 的 BigTable，其结构在 IaC 中定义。DynamoDB 或 BigTable 的定义实际上与 SQL 数据库的定义没有什么不同，后者通常存在于应用程序代码旁边。或者，服务可以由步骤函数(step functions)组成，其中一些应用工作流现在是在 IaC 中定义的。这些界限的模糊使得将所有代码保存在一个存储库中势在必行。
一战中的演习--伊梅尔曼转弯示意图。来源：维基百科维基百科
一战中的演习--伊梅尔曼转弯示意图。来源：维基百科维基百科
 
将所有代码保存在一个版本库中的最佳理由是，如果不这样做会发生什么。根据 "康威逆向操作法"，如果将应用程序代码与部署所需的 IaC 分离开来，最终就会出现拥有 IaC 的独立团队，从而回到拥有独立开发团队和运营团队的旧时代，并带来与之相关的所有功能障碍。康威定律表明，最终出现两个团队是不可避免的。
关于我对 "源代码库 "的定义，我有一个简短的切入点--我实际上是用这个词来代表代码的逻辑分组，并在其周围设置了一系列权限。通常情况下，源代码库是以单个 GitHub 或 GitLab 源代码库的形式实现的，但运气不好的话，也可能是 Perforce 等软件中的一个子目录。
共享服务和类似平台工程小组的情况如何？肯定需要 IaC 来定义共享网络、共享 Kubernetes 集群、安全护栏等服务，这通常由专业团队负责。随着公司的发展，分拆出平台工程和安全团队是一种自然的演变，将共享服务的 IaC 保存在不同的存储库中通常是正确的做法。只要这些团队不成为 DevOps 团队，而且这些专业团队仍能以 DevOps 的方式处理自己的源代码。

结论

在制定架构决策、规划源代码库布局和进行组织变革时，将康威定律放在首位是组织取得成功的关键。忽视或违背康威定律将导致组织和架构功能失调。
]]> <![CDATA[2024年最佳Devops工具,平台,服务]]> https://blog.devops.gold/article/2024-best-devops-tool-platformengineering https://blog.devops.gold/article/2024-best-devops-tool-platformengineering Tue, 30 Jan 2024 00:00:00 GMT

背景

Video preview
 

观点

著名Devops频道DevOps Toolkit评选了他认为的2024年可能的最佳
 
notion image

具体分类列表

Service Catalogs:

Backstage: https://backstage.io
Port: • How To Build A UI For An Internal Developer Platform (IDP) With Port?

App Management (Kubernetes Manifests):

Helm: • Helm vs Kustomize - The Fight Between Templating and Patching in Kubernetes
Kustomize: • Kustomize - How to Simplify Kubernetes Configuration Management
Carvel ytt: • Carvel ytt Instead Of Helm? A Better Way To Manage Kubernetes Resources?
Jsonnet Tanka: • Helm And Kustomize Replacement? Jsonnet With Grafana Tanka
cdk8s: • cdk8s - Kubernetes Manifests With GoLang, TypeScript, Python And Java
CUE: • Is CUE The Perfect Language For Kubernetes Manifests (Helm Templates Replacement)?
Timoni: • Is Timoni With CUE a Helm Replacement?

Pipelines (CI/CD):

Jenkins: • Running Jenkins In Kubernetes - Tutorial And Review
GitHub Actions: • Github Actions Review And Tutorial
GitLab CI: https://about.gitlab.com/solutions/continuous-integration/
Tekton: https://tekton.dev
Argo Workflows: • Argo Workflows and Pipelines - CI/CD, Machine Learning, and Other Kubernetes Workflows
Dagger: • Dagger: The Missing Ingredient for Your Disastrous CI/CD Pipeline

Observability:

Lok：https://grafana.com/oss/loki
Prometheus: https://prometheus.io
Victoria Metrics: https://victoriametrics.com
Jaeger: • Distributed Tracing With Jaeger And OpenTelemetry In Kubernetes
Grafana: https://grafana.com/oss/grafana
Robusta: • Kubernetes Notifications, Troubleshooting, And Automation With Robusta
Komodor: • How To Troubleshoot Kubernetes Applications With Komodor
Pixie: • Kubernetes-Native Observability Through eBPF And Scripting With Pixie
GroundCover: • Kubernetes Observability And Troubleshooting With groundcover and eBPF

Databases:

Aiven: • All Databases In Cloud Managed With a Single Service - Aiven
Kube Blocks: • KubeBlocks: Cloud-Native Data Infrastructure for Kubernetes
Cloud-Native PG (CNPG): • Should We Run Databases In Kubernetes? CloudNativePG (CNPG) PostgreSQL
Atlas Operator: • Kubernetes? Database Schema? Schema Management with Atlas Operator

Infrastructure and Service Management

Ansible: https://ansible.com
Terraform: https://terraform.io
Pulumi: https://pulumi.com
Crossplane: • Crossplane - GitOps-based Infrastructure as Code through Kubernetes API
Cluster API (CAPI): • How To Create, Provision, And Operate Kubernetes With Cluster API (CAPI)

Security

Falco: • Detecting Kubernetes Security Threats with Falco
KubeArmor: https://kubearmor.io
Kyverno: • Kubernetes-Native Policy Management With Kyverno
External Secrets Operator (ESO): • Manage Kubernetes Secrets With External Secrets Operator (ESO)
Kubescape: • How to Secure Kubernetes Clusters with Kubescape and Armo
Sigstore Cosign: • Signing and Verifying Container Images With Sigstore Cosign and Kyverno
Notary: • Notary Project: Ensuring Trustworthy Container (Docker) Images
cert-manager: • What Is HTTPS? How Does It Work? Automate With cert-manager And Let's Encrypt
Teller: • Secrets Made My Life Miserable - Consume Secrets Easily With Teller

Networking:

Istio: https://istio.io
LinkerD: https://linkerd.io
Kuma: https://kuma.io
Cilium: • Kubernetes Networking, Security, And Observability With eBPF And Cilium
Gateway API: • Gateway API - Ingress And Service Mesh Spec Replacement?

Miscellaneous:

Charm: https://charm.sh make the command line glamorous. ssh git.charm.sh
  • From Evaluate to Adopt:
eBPF: • Is eBPF The End Of Kubernetes Sidecar Containers?

🤗 总结归纳

这是一个围绕Kubernetes建设的生态，不按云原生的架构方法来大概率是用不上这些工具的，勉强用上火力也大打折扣。
 
]]> <![CDATA[VCluster在Kubernetes上实现成本效益高的多租户]]> https://blog.devops.gold/article/vcluster-cost-effective-multi-tenancy-on-kubernetes https://blog.devops.gold/article/vcluster-cost-effective-multi-tenancy-on-kubernetes Wed, 31 Jan 2024 00:00:00 GMT
2023-06-19
配置Kubernetes集群是昂贵的，如果你的组织或客户要求租户隔离，这将变得有问题。在这份报告中，我决定介绍vcluster和Loft Labs。
notion image
太长不看版：配置Kubernetes集群是昂贵的，如果你的组织或客户要求租户隔离，这将变得有问题。在这份报告中，我决定介绍vcluster。这个工具在CNCF领域越来越受欢迎，因为它提供了一个替代方案，可以在面临租户隔离和每月底只为运行Kubernetes本身的机器付费的昂贵账单时使用。vcluster背后的公司，Loft Labs，使团队能够使用成本效益高的集群和你需要给开发者他们需要工作的管理工具。
公司名称：Loft Labs
  • 融资：种子轮 - 25人
  • 投资：430万美元 竞争对手：- Hypershift / Kamaji **
  • 社区参与：CNCF金牌赞助商 - KubeCon EU 2023，核心维护者
  • 产品：Loft V3 - 具有GitOps集成的大规模自助虚拟集群
项目：vcluster
  • 成熟度：CNCF孵化，巩固其用户基础并完善用例
  • 领域：多租户，开发环境，隔离
  • * 这些项目不是vcluster的直接竞争对手，但它们处于同一领域，即多租户Kubernetes。Hypershift主要由Red Hat维护，Kamaji由Clastix维护。
评级：
  • 热度因素 6 / 10
  • 社区 5 / 10
  • 项目准备情况 6 / 10
  • 易用性 8 / 10
  • 产品市场适应度 5/10
  • 公司成功 3/10

问题空间

迟早，你会需要不止一个Kubernetes集群，这并不便宜。无论你是需要一个新的集群让内部团队运行他们的应用程序，还是你想给每一个客户他们自己的隔离集群来运行你的服务。一旦这个对话开始，两个主要因素会阻碍团队的前进：金钱和时间。支付新的集群并不是大多数团队可以做出的决定，他们将需要整个组织的支持。在任何云提供商中创建集群都不是即时的。通常需要5到10分钟（取决于云提供商）来设置硬件和软件。虽然这与你在本地设置一个集群所需要的时间相比几乎微不足道，但你不能让你的客户等待10分钟才开始使用你的软件。

开源项目

vcluster提供了一种简单的方法，在现有的Kubernetes集群（主机）内创建新的虚拟Kubernetes集群。这些虚拟集群可以使用vcluster CLI或Helm（一个Kubernetes的包管理器）来创建。一旦创建了一个虚拟集群，你可以分享详细信息（凭证和API服务器URL）给团队/客户与之交互。从消费者的角度看，他们与一个真实的集群进行交互。从提供者的角度看，你仍然有一个运行着工作负载的Kubernetes集群。因为每个vcluster都会启动一个新的API服务器，每个租户在API服务器上的负载都是隔离的，不会通过主机。

产品空间

Loft Labs成立于2019年，专注于使团队能够以快速和成本效益的方式采用Kubernetes。像vcluster、DevSpace和现在（2023年5月）的DevPod这样的工具，旨在帮助平台团队使用专注于采用基于Kubernetes的解决方案的工具。Loft V3是一个托管服务套件，为你提供一个中心位置，让你为你的团队创建vclusters。他们的定价模型是基于用户的。Loft V3允许你在多个区域创建和管理vclusters，包括VPC支持和单点登录功能。Loft V3提供的功能可以为公司节省时间，因为你最有可能在内部实现所有这些功能。

评级详情

  • 热度因素（6/10）：vcluster从一个具有巨大潜力的优秀社区项目，发展成为一个得到了对该领域感兴趣的不同公司大力支持的坚实项目。在像KubeCon NA和KubeCon EU这样的会议上，有很多公司在CNCF工作组和主要议程中提到vcluster，这表明该项目已经准备好进行大规模的采用。
  • 社区（5/10）：vcluster Contrib GitHub组织包含75个由社区驱动的扩展。显示了与Linode、Civo和DigitalOcean等云提供商的集成。
  • 项目准备情况（6/10）：虽然vcluster已经完成了其基本功能，但一些更复杂的功能正在开发中。这表明该项目正在进入一个阶段，需要为实际使用案例的复杂和大规模设置做好准备。
  • 易用性（8/10）：要安装和使用vcluster，你必须是一个经验丰富的Kubernetes用户。vcluster扩展了Kubernetes的非常高级的功能。这需要用户理解它将连接和与云提供商交互以创建外部资源。扩展vcluster是可能的，但需要经验丰富的Kubernetes工程师。
  • 产品市场适应度（5/10）：如果你是一个Kubernetes用户，并在云提供商的顶部工作，vcluster非常有意义。但在生产环境中运行和维护vcluster是一个完全不同的故事，因为SREs将需要学习如何在出现问题时管理和解决它。
  • 公司成功（3/10）：Loft Labs的公开客户列表没有显示任何大名鼎鼎的公司，但说服大公司支持初创公司总是很难的。我期待他们的公开客户参考和合作伙伴的扩展。

社区热点

  • 你需要一个成本效益高的替代方案来配置集群吗？vcluster可能是答案
  • 如果创建vcluster的开销可以针对不同的场景轻松参数化，平台团队可以调整vcluster以适应他们的用例。
  • 查看ArgoCD和vcluster的集成，以及Codefresh如何使用vcluster进行他们的托管服务
  • 查看最新的vcluster朋友DevPod，就像GitHub codespaces/GitPod，但是开源的
  • vcluster 0.15.0包括一个通用的同步机制，让你不仅可以在集群上节省，还可以在安装在它们上的工具上节省。我迫不及待地想在KubeCon NA 2023上看到DevPod和启用vcluster的平台

采用成本

vcluster易于使用和被现有的Kubernetes用户采用，因为它不需要在你现有的集群上安装任何东西。vcluster用户也不需要任何培训，因为他们将获得对一个完全成熟的Kubernetes API服务器的访问。一旦被采用，一个平台团队将需要构建一个管理层，以使开发团队能够请求新的vcluster并访问它们。根据你的组织的成熟度，你可能想避免设计和构建这个自助服务的管理层。

速度

如果你正在讨论如何处理与你的Kubernetes集群相关的多租户场景，或者因为你的团队创建了太多的集群而在每个月的最后一天收到大量的账单，vcluster可以为你节省时间和金钱。
如果很明显，你的团队将从一个成本效益高且自助的方法来访问他们的Kubernetes集群中受益，我建议你与Loft Labs进行交谈。归根结底，这是关于成本和减少团队需要为他们的应用程序获取集群的时间的决定。

风险

市场上存在其他的多租户方法，如Hypershift和Kamaji。vcluster和这些其他工具的主要区别是复杂性，但这都归结为你今天的需求。你是否正在受到开发者请求你无法支付的集群的困扰？或者你正在管理一个大规模的Kubernetes集群，你希望在各个区域隔离和管理它们？我在这里强烈推荐，当你决定如何分割一个单一的Kubernetes集群以供租户共享时，应该考虑vcluster作为一个选项。

收获

为什么你应该关注vcluster和Loft Labs：
  • vcluster为多租户场景提供了一个可行的替代方案
  • vcluster使团队能够访问Kubernetes，而无需为云提供商上的隔离集群支付高昂的价格
  • Loft Labs正在构建工具，以自助服务和大规模管理vclusters，以解决更具针对性的用例，如开发环境。
  • Loft Labs正在扩展其开源产品组合和产品，以应对公司和团队在将团队引入Kubernetes时面临的更多挑战
]]> <![CDATA[Crossplane控制平面的地位稳固]]> https://blog.devops.gold/article/crossplane-provisioning-cloud-resources https://blog.devops.gold/article/crossplane-provisioning-cloud-resources Wed, 31 Jan 2024 00:00:00 GMT
2023-5-19
 
Crossplane（项目）发展迅速，已经准备好迎接其黄金时代。这个开源项目现在是一个安全的选择。项目背后的公司（Upbound）已经创造了令人印象深刻的动力，带来了来自云原生领域的大公司的合作。
notion image
太长不看版：Crossplane（项目）发展迅速，已经准备好迎接其黄金时代。这个开源项目现在是一个安全的选择。项目背后的公司（Upbound）已经创造了令人印象深刻的动能，带来了来自云原生领域的大公司的合作。Crossplane（项目）的未来看起来很光明，但公司呢？通过开源项目实现盈利是困难的，但Upbound正在押注在开源项目周围的托管服务，并与其他软件和服务提供商建立合作关系。
公司名称：Upbound
  • 投资：6900万美元
  • 竞争对手：HashiCorp / Pulumi
  • 社区参与：CNCF金牌赞助商 - KubeCon EU 2023，核心维护者
开源项目：Crossplane
  • 成熟度：CNCF孵化中，成熟，生产已就绪
  • 领域：基础设施即代码，内部开发平台
评级：
  • 热度因素 10 / 10
  • 社区 9 / 10
  • 项目准备情况 8 / 10
  • 易用性 4 / 10
  • 产品市场适应度 7/10
  • 公司成功 4/10
KubeCon Europe是看到云原生领域如何充满活力的好机会。在这个月的报告中，我想突出一个我非常关心的公司和项目：Crossplane和Upbound，他们在今年的会议上非常活跃。
我一直在尽我所能为Crossplane项目做贡献，并与Upbound的工程师、Crossplane的维护者以及与项目相关的一些公司进行交流。我对项目了解很深，我已经关注Upbound一段时间了，所以我想利用我的个人经验，我在KubeCon期间收集的数据，以及一些外部反馈来整理这些报告。

问题领域

创建云原生应用需要团队配置云资源，如数据库、集群、网络、虚拟机、代理、存储桶等。创建和配置这些云资源是具有挑战性的，并且是特定于云提供商的。团队已经学会使用像HashiCorp的Terraform这样的工具来描述和配置跨云提供商的复杂基础设施。Terraform使用其语言（HCL）来描述需要配置的内容，然后操作员可以运行terraform命令将这些配置应用到您选择的云提供商。这种方法（基础设施即代码）在行业中被广泛使用。

开源项目

Crossplane的创建是为了使定义和配置基础设施成为Kubernetes原生的。这意味着什么？或者为什么这很重要？首先，Crossplane允许用户将所需的基础设施定义为Kubernetes资源。它没有引入新的语言。如果你是一个Kubernetes用户，使用Crossplane会感觉很自然。这也允许你重用所有的Kubernetes工具来管理和使用Crossplane。不需要新的工具。对于大量投资于Kubernetes的团队，Crossplane非常有意义。

产品空间

在Crossplane进入Kubernetes领域（于2020年6月25日捐赠给CNCF）的近三年后，我可以说这个工具是坚固的，生产就绪的，并且有非常健康的社区支持。最近VMware在他们的Kubernertes产品，Tanzu中添加了对Crossplane的支持，这是第三方产品提供商对Crossplane的信任的一个好的迹象。项目背后的公司Upbound，提供了一个Crossplane托管服务，也就是说，你将运行Crossplane本身的责任转交给Upbound。在KubeCon之后，他们发布了公司的一页纸，你可以在这里查看。

评级详情

  • 热度因素（10/10）：Crossplane从一个具有巨大潜力的优秀社区项目，发展成为一个得到了对该领域感兴趣的不同公司大力支持的坚实项目。在像KubeCon NA和KubeCon EU这样的会议上，有很多公司在CNCF工作组和主要议程中提到Crossplane，这表明该项目已经准备好进行大规模的采用。
  • 社区（9/10）：Crossplane Contrib GitHub组织包含75个由社区驱动的扩展。显示了与Linode、Civo和DigitalOcean等云提供商的集成。 项目准备情况（8/10）：虽然Crossplane已经完成了其基本功能，但一些更复杂的功能正在开发中。这表明该项目正在进入一个阶段，需要为实际使用案例的复杂和大规模设置做好准备。
  • 易用性（4/10）：要安装和使用Crossplane，你必须是一个经验丰富的Kubernetes用户。Crossplane扩展了Kubernetes的非常高级的功能。这需要用户理解它将连接和与云提供商交互以创建外部资源。扩展Crossplane是可能的，但需要经验丰富的Kubernetes工程师。
  • 产品市场适应度（7/10）：如果你是一个Kubernetes用户，并在云提供商的顶部工作，Crossplane非常有意义。但在生产环境中运行和维护Crossplane是一个完全不同的故事，因为SREs将需要学习如何在出现问题时管理和解决它。
  • 公司成功（4/10）：Upbound的公开客户列表没有显示任何大名鼎鼎的公司，但说服大公司支持初创公司总是很难的。我期待他们的公开客户参考和合作伙伴的扩展。我相信在11月的KubeCon NA会有更多的公告。

社区热点

  • Daniel Magnum，Crossplane的创始工程师之一，最近离开了公司，追随他对硬件和物联网的热情。他在商业方面尝试了托管控制平面，我对他的离职感到有些惊讶。
  • 一个名为KCP的由Red Hat创立/赞助的类似项目现在已经死亡并且停止资助。查看这条推文。
  • 配置基础设施对开发者活动有直接影响。使开发者能够使用所有创建的云资源也是解决问题的重要一环。查看这篇博客文章。
  • Upbound的Nic发表了一本名为《什么是Crossplane》的电子书，与O’Reily合作。
FINAL_OReilly-Report.pdf
952.6KB
  • 我已经听到不止一次：“我喜欢Crossplane，但我已经在使用Terraform了”

收获

为什么你应该关注Crossplane和Upbound：
  • 他们正在推动如何在Kubernetes(API机制)之上运行和产品化托管服务的边界
  • 他们正在解决你在Kubernetes旅程中迟早需要解决的挑战
  • 他们正在与像VMware这样的组织合作，这些组织汇集了多个开源项目，以向大型组织提供服务和产品。这是成熟的一个很好的标志。
  • 随着更大的公司对项目的投注，采用率将会增长。
  • Upbound最大的挑战是与Pulumi和Terraform用户争夺市场份额。展示更多的生产用例和案例研究，将极大地影响社区和新的潜在大用户的认知。
]]> <![CDATA[平台工程不是关于如何建设华丽UI的]]> https://blog.devops.gold/article/platform-engineering-is-not-about-building-fancy-uis https://blog.devops.gold/article/platform-engineering-is-not-about-building-fancy-uis Wed, 31 Jan 2024 00:00:00 GMT
编者：本文原作者是一家平台编排器(一种自动组织编排infra资源的infra)公司的CEO，他们帮助一些公司实施平台工程时发现的规律：刚开始客户会对搭建可见的门户(Portal)非常感兴趣，慢慢会回到解决环境配置、云资源依赖的编排等“更实际”的问题上来。在一些访谈里他建议500人及以上研发团队，才有必要投资Backstage为代表服务目录Portal。IDPs是关于建设面向内部的API，门户Portal是IDPs之上偏薄的一层。
 
notion image
 
对开发者门户、服务目录和内部开发平台的混淆带来了真正的问题。
如果我必须说出一些人对平台工程最大的误解，那就是成功的平台工程战略结果是一个有很多按钮可以点击和仪表板可以查看的闪亮用户界面。
许多人将开发者门户和服务目录与内部开发平台(IDPs)混为一谈，但它们并不相同。这种混淆带来了真正的问题。充其量，那个闪亮的 UI 只允许组织获得它们可以从平台工程中获得的投资回报(ROI)的一小部分。
在 2022 年，我与大约 300 个平台工程团队进行了交流。这些团队中的许多人开始他们的平台工程之旅是从构建开发者门户开始的。然而，对于它们中的 95%，其他平台化举措本可以对开发者的生产力和投资回报产生更大的影响。不到 20% 的团队看到开发者实际采用和使用开发者门户。

开发者门户(Developer Portals) vs. 服务目录(Service Catalogs) vs. IDP(Internal Developer Platforms)

在 2022 年，Gartner 阐明了开发者门户和内部开发平台之间的关系： “内部开发者门户充当开发者发现和访问内部开发平台能力的界面。”
例如，Netflix 在其现有的平台工具之上构建了一个开发者门户。 内部开发平台是平台工程团队为开发者构建的所有技术、工具和流程的总和，它们结合在一起形成了一条黄金路径。这条黄金路径通过设计减少了认知负荷并推动了标准化。一个内部开发平台甚至不需要有用户界面。内部开发平台远不止于聚合信息和展示信息——它们包括从配置和基础设施管理到环境和部署管理等方面。设计内部开发平台是关于倾听开发者在日常工作中实际需要什么，并构建满足这些需求的解决方案。开发者门户可以可视化底层平台，但它不是内部开发平台的必要组成部分。
开发者门户或服务目录是一个用户界面，它从多个 API 中提取数据，并将它们与不同的视图进行对比。服务目录向您展示了可用服务的列表，包括它们具有哪些 API 和服务的拥有者。它从 GitHub，工单系统和持续集成（CI）中拉取并聚合元数据。服务目录通常具有一个“模板图库”，这是一个或多或少的精美 GitHub 模板和仪表板集合。

为什么组织专注于开发者门户和服务目录？

如果开发者门户和服务目录并非必需，为什么许多组织还是首先专注于构建它们呢？以下是我见过的一些最常见的原因：
  • 它看起来显而易见：当组织开始他们的平台之旅时，他们倾向于按时间顺序缓解痛点。首先想到的是你最先完成的任务。对于应用程序的生命周期来说，那可能是创建服务。对于开发者来说，通常是新入职。许多组织选择首先从这里开始自动化。
  • 易于展示：仪表板是您可以向您的管理者展示的东西，特别是如果他们没有技术背景。可视化要比重新构造配置管理更容易解释和销售。但这并不意味着它更有意义。
  • 每个人都对界面有看法：尽管在平台工程领域，真正理解如何就底层技术和实际痛点（如配置管理）架构内部开发平台的人相对较少，但更多的人对界面有看法。结果是，关于界面的讨论比关于开发者体验中的真正深层问题更多。

为什么开发者门户和服务目录的努力常常失败？

在投入时间和资源开发开发者门户和服务目录之后，许多组织对结果感到失望。原因如下：
  • 开发者讨厌“又一个界面”。他们希望留在代码中，在他们的 git-push 通道中，快速且不受干扰地操作。您可以构建最美观的用户界面，但这并不意味着有人会定期查看它。我查看了一个非常大的电子商务公司的门户的使用指标，发现平均来说，开发者每年确切地使用一次（搜索）功能，以检查他们正在构建的内容是否之前已经被构建过了。
  • 可观的收益很低。我听到的最常见的用例是“我们想要标准化新服务的创建。”假设你每年创建了疯狂的 1000 个新微服务。你今天是如何做到的？可能只是通过克隆 GitHub 模板。因为门户本身基本上只是 UI 框架，它们所做的只是调用其他 API。所以如果你实现了“通过点击按钮创建新服务”的功能，这个按钮将调用 GitHub 模板 API 并克隆链接的示例仓库。使用最常用的开源框架构建一个门户，实际上需要至少两个全职员工 (FTEs) 至少六个月的时间。但你的影响在哪里？每次创建服务节省了 10 秒？即使是一分钟？我们假设由于某种奇迹般的原因是 1 分钟，我们拿 1000 个服务和我们每年支付 10 万美元的两个 FTE 来计算。那么你的投资回报率仍然在疯狂的 -80%，而且请记住这假设我们每年创建 1000 个服务！恭喜你，你只是浪费了时间。
  • 门户和服务目录在实现和保持更新方面也是出了名的复杂。开发者会不断地绕过，一个数据错误的仪表板可能比没有仪表板更糟糕。你将花费大量的资源和时间尝试保持东西的最新。

将平台作为产品（Platform as a Product）来看待是一种方法

与其专注于构建开发者门户或服务目录，不如优先考虑对开发者最有益的功能。您可以通过采取产品方法来确定您的组织需要哪些功能。采用产品方法，您不会从构建"某些管理层"告诉您的东西或任何看起来显而易见的东西开始。相反，您要从用户研究开始。去问您的开发者他们需要什么或想要做什么。
然后，您有责任对这些问题进行排序。这样做的一种方法是记录开发者每 100 次部署中有多少次执行某个任务以及需要多长时间。您最终会得到一个看起来类似于下面的表格。
简单的计算：
过程
部署中的分布频率
开发的时间 (包含等待与错误）
运维的时间 (包含等待与错误)
增加或更新应用配置(例如环境变量
5%*
1h*
1h*
增加服务与依赖
1%*
16h*
8h*
增加或更新资源
0.38%*
8h*
24h*
重构与文档
0.28%*
40h*
8h*
等待被阻塞的环境
0.5%*
15h*
0h*
搭建环境
0.33%*
24h*
24h*
开发者入职、再培训和团队轮换
1%*
80h*
16h*
回滚失败的部署
1.75%
10*
20*
调试与错误定位
4.40%
10*
10*
等待其他团队
6.30%
16*
16*
您可以使用这个表格来计算内部开发平台的投资回报率。 在大多数情况下，我发现两个变化产生了最大的结果：确保您真的建立了基本的 CI/CD 流程，可以减少辛苦工作并提高效率。将您的配置管理从“静态”重构为动态配置管理，可以通过设计实现标准化，关注点分离，并持续自助服务，同时降低认知负担。

什么时候您仍应该构建门户/服务目录？

这并不是说没有充分的理由来构建一个开发者门户。如果您的开发者正在创建大量的服务和资源，并且需要对它们进行分类以支持内部源代码共享的努力，那么门户会非常有益。然而，并不是很多组织拥有达到积极投资回报率所需的数千个服务和开发者。
有时候，你必须构建一个开发者门户，因为管理层这么要求。你别无选择。但如果这些情况都不适用于你，就不要浪费时间把开发者门户作为起点。相反，应该从构建你的内部开发平台(IDP)开始。你的开发者会感激你的！
]]>