云原生环境的IDP不仅需要抽象云提供商基础架构，还需要即时反馈的可观测性解决方案
译自 Why Platform Engineering Is Different for Cloud Native Apps，作者 Eric Newcomer 是 Intellyx 的首席技术官。他曾担任领先的集成供应商 WSO2 和 IONA Technologies 的首席技术官，以及 Citi 和瑞士信贷等大型企业的首席架构师。
正如系列文章前文所述，由于云原生计算本身就不同且复杂，要为其打造内部开发者平台(IDP)具有挑战性，想要做好并不容易。
然而，做好这一点对于让企业获得云原生的益处至关重要，它可以让开发者更快、更可靠、成本更低地构建和部署应用程序。
要想做好这一点，理解开发者平台为什么在云原生计算中有所不同是一个必要的第一步。
云原生应用程序与传统应用程序主要有很大不同，因为它们是为云原生的“横向扩展”基础架构而设计和开发的，并且通常使用多个云提供商的服务。
公共云提供商提供了数百种系统软件服务，其中任何一种与当前任务相关(或不相关)。筛选出这些服务中需要集成到你的 IDP 中的那些将非常耗时。
此外，开发云原生应用程序通常需要将功能分解为微服务，将微服务代码打包到含必要组件的容器镜像中，并将容器部署到 Kubernetes 集群。
走上这条路有助于实现云原生的好处，但在支持微服务、容器和 Kubernetes 方面，并非所有软件工具都与众不同。
传统工具通常不支持云原生开发者，因为它们不是为以微服务、容器和 Kubernetes 为特征的云原生计算环境而设计的。
微服务是一个独立的工作单元，通常是一个应用程序的特性或功能。微服务会暴露 API 来封装其功能，并通过网络与其他微服务进行交互。
云原生开发者需要快速大规模地开发和部署微服务，以跟上当今变化的步伐，他们需要快速响应客户反馈和事件。
成功采用微服务的组织通过中央内部开发平台来支持小型自治团队，该平台实施组织标准和一致的工具。
与仅为修复错误而重新部署整个单体应用相比，修补和更新单个微服务要容易得多。
这种模式的成功需要正确的组织结构和治理、谨慎协调影响多个微服务的重大更改以及 IDP 中正确的云原生技术和工具组合。
平台工程的目标是创建一个像产品一样为开发者服务的 IDP，抽象掉基础架构问题和工具考量。
由于云原生环境与传统IT环境的不同，这些抽象必须适用于微服务、容器、Kubernetes和云提供商服务。
云原生最佳实践对开发者提出了额外的要求。在传统的IT环境中，开发者会请求运维团队来配置他们的数据库、事件存储和密钥保险库等。云原生环境没有手工配置所需软件的运维团队。
取而代之的是，开发者使用一个IDP，它通过声明式API、配置文件和脚本来让开发者可以自助服务。
考虑一下配置数据库的请求。站点可靠性工程师或运维团队会在IDP中设置满足安全性、可用性、可靠性和开箱即用监控的可用数据库。
例如，开发者声明需要一个关系型数据库，而不必指定哪一个。这种抽象级别允许在不影响应用程序的情况下用另一个数据库交换数据库。
假设你在一个云原生环境中工作，使用容器和Kubernetes开发微服务。
还假设你遵循最佳实践，将开发者组织成小型自治团队，这些团队负责至少一个微服务的整个开发生命周期，包括生产支持。
所有这些都是为了提供出色的客户体验、快速开发和部署、提高开发者生产力，以及更快更高质量和弹性地将应用代码发布到生产环境。
这些选择的成功很大程度上取决于在IDP中包含合适的可观测性工具。
传统的可观测性工具只监控部署后的代码 —— 即，它们监控暂存和生产环境中的代码。当然，这也很重要，但同样重要的是减少事故和宕机的次数，这些会占用改进客户体验和业务竞争力所需开发和部署代码的时间。
仅捕获数据的可观测性解决方案效率低下，并阻碍生产力。微服务、容器和 Kubernetes 的云原生世界需要一种针对开发、部署和支持微服务的小型自治团队过滤和定制数据的解决方案。
面向云原生应用程序的工程是从云原生计算中获取最大价值和最大收益的方法。
为云原生环境构建IDP不仅需要抽象云提供商服务基础架构，还需要整合一个可观测性解决方案，尽可能早地并且尽可能频繁地在开发过程中提供即时反馈。
设计用于云原生应用程序的IDP中的可观测性尽快为开发者提供有用的数据，以保持他们的生产力和愉快的心情。
Google Cloud 和 Chronosphere 提供了这样一个准备上线的可观测性解决方案，可以集成到你的 IDP 中，以帮助充分实现云原生环境的优势。