云原生环境的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 的云原生世界需求一种针对开发、布置和支撑微服务的小型自治团队过滤和定制数据的解决方案。
Intellyx的看法
面向云原生应用程序的工程是从云原生核算中获取最大价值和最大收益的办法。
为云原生环境构建IDP不只需求笼统云供给商服务根底架构，还需求整合一个可观测性解决方案，尽可能早地而且尽可能频频地在开发过程中供给即时反应。
规划用于云原生应用程序的IDP中的可观测性尽快为开发者供给有用的数据，以保持他们的出产力和愉快的心境。
Google Cloud 和 Chronosphere 供给了这样一个预备上线的可观测性解决方案，可以集成到你的 IDP 中，以协助充沛实现云原生环境的优势。
本文在云云众生（yylives.cc/）首发，欢迎我们拜访。
