首页 > 其他分享 >Adobe 构建 IDP 之路的经验与教训

Adobe 构建 IDP 之路的经验与教训

时间:2023-06-07 09:33:51浏览次数:45  
标签:Adobe Kubernetes 开发人员 解决方案 平台 IDP 构建 团队 我们

在过去的25年多时间里,我创建了软件组件和分布式框架,建立并领导了相关团队。近几年我致力于推动 Adobe 服务开发、部署和管理系统的开发人员生产力。
 

抽象陷阱

在云时代早期,Adobe 的每个团队都有自己的云账户、部署系统,其对应的成熟度也截然不同。很快我们就意识到需要对此进行标准化,这样成本控制、合规性、安全性和可靠性等关键问题就能够一次解决,且一劳永逸。
 

在2016年,Kubernetes 还处于早期阶段,尚未有能力大规模支持 Adobe 的云产品。当下最好的选择是 Mesos,当然我们清楚地了解我们正处在一个不断变化的环境中。因此我们没有将用户暴露给原始平台,而是创建了一个抽象——服务规范。这个服务规范描述了所有关于如何提供和部署服务的信息。然后,定制的内部软件在在部署时将服务规范转为必要的原语,平台就此起飞,迅速成长并为1000多个服务和开发人员提供支持。
 

但随着规模和需求的增长,我们在 Mesos 之上的本土解决方案开始陷入困境。这时 Kubernetes 已经成熟,是时候改变了。我们构建了一些自定义迁移工具,并且能够保证在不停机的情况下将所有正在运行的服务从 Mesos 集群迁移到 Kubernetes 集群,也就是我们的新后端是将服务规范转换为 Kubernetes 配置,尽管出现了一些小问题,但总体一切正常。就此 Mesos 集群被关闭,成本也得以节约。
 

之后的几年,情况变得不太乐观。我们的服务规范以一种非常简单的“黄金路径”,支持近4000个适用于服务 REST API 或 Workers 的基本应用程序。但随着越来越多的 Adobe 团队开始寻求平台成本节约以及安全性、合规性和可靠性的保障,要求也越来越多样化,渐渐超出抽象支持的模式。因此公司内部规模较大且技术较成熟的团队开始绕开抽象,在我们的托管集群上构建自定义方案,充分利用 Kubernetes 的自由和强大功能。当然,他们也必须对部署系统承担所有责任与风险,因此在安全性和可靠性方面增加了更多负担。
 

随着越来越多的团队要求更高的自主权和更大的灵活性,我们开始意识到原来我们被困在抽象陷阱里了。我们的抽象不支持团队部分使用,因此在定制解决方案时需要绕过抽象,也就是说我们提供了一个不可扩展的“全有或全无”解决方案
 

定制解决方案逐渐成为负担

随着时间的推移,我们的定制解决方案变得越来越复杂,为了添加新功能并跟上 Kubernetes 的发展消耗了团队越来越多的时间,我们几乎没有什么空间进行创新了,也开始落后于新技术了。更糟糕的是我们没有为可扩展性而构建。即使有好的想法,但如果我们无法确定优先级,让用户贡献他们需要的更改也变得不切实际。

平台的大规模采用与资源消耗

从 Mesos 到 Kubernetes,再到接下来我们要做的平台,在每个阶段我们都不得不与制度惰性和对变化的恐惧与抵触作斗争。如何让用户参与进来,让一个有效但果实的解决方案变为更好更先进的解决方案,同时又能够解决他们对生产服务发生变化的风险产生的担忧呢?
 

这便是需要了解企业内部,确定一些在当前系统中苦苦挣扎的关键参与者的时候了。也许这些参与者正在使用已有的系统和解决方案,但由于缺乏自由度,他们无法成长。明确受影响最多的团队,以及主要负责公司关键业务需求的团队是哪些,并与他们一起协作,以便更好地梳理痛点与需求。同时让负责构建新解决方案的工程师加入这些团队,综合专业知识为团队进行培训,同时将收集的反馈和教训回滚到产品中。当这些成功的经验在整个公司内传播开来,对采用新技术的担忧和抵触将能够有效减弱。
 

这是一个好的开始,但这个模式不可持续,因为只能小范围实施无法达到庞大的规模。由于企业内部的工程师数量有限,他们需要构建平台,而与业务团队协作并给予支持会消耗他们大量的时间和精力。因此自助服务成为平台的关键。例如包含故障排除链接的智能错误消息,可以搜索可用文档以回答问题的智能代理,为团队解决问题的认可和奖励机制,各个级别的自动化,等等。
 

培养“T型”开发人员

无论我们构建什么解决方案,都需要主题专家(Subject Matter Expert, SME)来进行创建和维护,由此带来的问题则是过度专业化。开发人员成为他们所负责组建的专家,无需担心其他任何事情。这样开发人员可以更专注于开发业务,但在平台环境中也带来了很多问题。这类开发人员通常在自己关注的领域表现出非常高的生产力,但他们同样有可能面临与不太了解熟悉的系统集成的问题。如果这些开发人员离开岗位,他们所专注的业务就可能成为企业的单点故障。
 

我们通过三种方式解决了这个问题。首先通过培训和日常使用我们自己的交付来确保团队的每个成员都是平台的专家用户,然后为每个成员分配一个支持轮换。最后我们鼓励团队内的流动,我们定期根据开发人员的个人意愿和企业的需要在组件之间轮转岗位。
 

当然开发人员需要集中精力完成工作,所以这些轮换不会进行得太频繁,组件的转移也不会时常发生。这样我们就能够培养“T型”人才,即开发人员在整个平台上具有广泛的知识,且在数个组件上的了解具备深度
 

完美≠进步

多年来我们一直在试图兼顾短期胜利和长期规划。尤其在开始一些新的、有风向的项目,随着时间的推移,企业的处理态度往往会转向谨慎,开始按流程展开项目,例如成立规划小组,确保规范详尽无遗,不断进行审查......
 

事实上没有什么完美又神奇的解决方案。但我们发现,如果我们能发现什么时候遇到问题停滞不前,并及时改变模式,就能取得很好的结果,不用过分追求规范上的详尽和完美。带几个开发人员组织一个小团队集中创新研发几周,消除干扰,然后与选定的关键核心用户密切合作来评估概念。如果顺利的话,将信息反馈给团队及其他成员,利用这些反馈和简洁的“规范单页”,确保研发的目标和愿景是清晰的,接下来进行迭代并交付平台用户所依赖的价值。
 

平台团队也可能成为瓶颈

平台团队的一个自然趋势就是随着时间的推移逐渐忽视用户。当我们对用户开始说“不”的时候,他们就会开始寻找其他的解决方案。而平台工程的关键特征,那些为公司带来的优势——成本节约、合规性、安全性和可靠性,也都没有意义了,平台团队将成为瓶颈,这也将是平台消亡的方式。
 

因此我们通过与高层领导和主要用户保持联系来避免这种情况,尤其是面对公司内新项目和关键业务时。我们确保平台是不断发展的,以满足关键用户的需求,保证平台足够通用,使开发人员的工作变得轻松和灵活,支持所有必需的用例。当然实现这点并不容易,我们需要不断地创新和改进。
 

下一步是什么

从一个好的想法开始,到大规模和持续的适应,这就是 Adobe 构建 IDP 的旅程。我们正处在一个转折点,由于抽象的限制性,而用户想要得更多,维护自定义解决方案正在消耗平台团队的大量精力和时间。总结构建 IDP 之旅中的经验与教训,我们认识到抽象是好的,但不灵活的抽象可能是一个陷阱。在内部构建解决方案允许完全自由,但这种自由是以持续维护来兜底的。我们依旧在寻找一个区别于固定的“黄金路径”解决方案和原始 Kubernetes 的新解决方案。
 

我们正在使用 Helm 图表的轻度抽象来替换服务规范的重度抽象,并将我们的定制组件套件换为 Argo,我们在努力解决可扩展性问题。我们让关键用户参与到开发过程中,结合开源和企业内部资源,再次构建自定义转换工具,将旧服务规范转换为 Helm 图表和 Argo 模板,让用户可以随意定义这些模板。
 

我们的下一个挑战是通过与云提供商、监控解决方案、可观察性、分布式跟踪等更紧密的集成,将开发人员的生产力提升到另一个水平。我们开始将 Adobe 所有不同的内部产品集成到 IDP 中。有了这一切,我们将以更低的成本提供更好的平台,为我们的用户提供更高的灵活性和更低的摩擦。
 

参考链接:
https://thenewstack.io/adobes-internal-developer-platform-journey-and-lessons/

标签:Adobe,Kubernetes,开发人员,解决方案,平台,IDP,构建,团队,我们
From: https://www.cnblogs.com/sealio/p/17462444.html

相关文章

  • 如何在Flutter中构建自定义Widget
    Flutter最近越来越流行。您可以使用它来构建可在MacOS、Windows和Linux上顺畅运行的复杂应用程序。但是构建这些应用程序并不总是一个简单的过程。您经常需要重构代码以保持应用程序的性能。一种这样的重构技术是提取重复的代码和组件并在多个地方重用它们。在本教程中,您......
  • 构建之法读书笔记之二
    继续我的阅读之旅,上次说到我们编程时要规范化代码,这样方便他人也方便自己,其次就是要交流,来使我们的合作更加顺利。第五章又是团队,果然在软件工程这一领域扩展到信息技术乃至整个人类社会,最不能忽视的就是团队,这也是老生常谈了。本章讲了团队模式。团队模式有很多种如作者给我们......
  • 构建之法读书笔记之一
    和人月神话一样,构建之法也是老师所推荐的书目,当然这也是一本早有耳闻却现今才刚刚上手的一本。此书开始便告诉我们什么是软件工程,以及它与现代计算机技术之间的关系。什么是软件工程呢?软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。它包括下......
  • 构建之法读书笔记之三
    首先还是回顾一下之前的阅读,团队的合作模式、敏捷流程。对于合作,我们需要足够的交流,足够的耐心,同时也要积极发展个人能力,争做软件工程界面的优等生。这次我们要讲的是用户,每一个程序、项目,最终的审核者都是我们的目标受众——用户。因此我们最终的目的就是让用户满意。那怎么才能......
  • 构建之法阅读笔记01
    阅读代码大全有感: 在我的软件开发经验中,我经常会写出冗长且难以理解的代码。我认为将所有功能都放在一个函数或者一个类中是最简单的方法,同时也不需要处理代码的复杂性。但是,在读完《代码大全》后,我意识到这种做法会导致代码的可维护性降低,而且使代码的重复性也增加。 根据书......
  • 构建之法阅读笔记02
    人月神话读书有感:在我的软件开发经验中,我曾经认为增加人力就能够加快软件开发速度。但是,我在读完《人月神话》后,意识到这种做法是错误的。根据书中的描述,增加开发人员的数量并不一定能加速软件开发的进度,反而可能会延迟项目的完成时间。这是因为在一个时间节点上,有很多的......
  • 构建之法阅读笔记03
    阅读《人件》有感:在我的学习中,我曾经认为技术才是软件开发中最重要的方面。因此,我在项目学习中更注重了技术层面,而忽视了人性层面。然而,通过阅读《人件》这本书,我意识到这种做法是错误的。根据书中的描述,技术是软件开发中非常重要的一部分,但是人性因素同样重要。充分考虑......
  • Jenkins构建时间变量
    在jenkins的内置环境变量中,没有job的构建时间变量,要获取job的构建时间,可以安装BuildTimestampPlugin并使用 ${BUILD_TIMESTAMP} 变量,具体步骤如下:步骤1:在jenkins插件管理中安装"BuildTimestampPlugin"插件。步骤2:在jenkins系统配置(ConfigureSystem)中勾选'BuildTimes......
  • 使用Eclipse构建Maven的SpringMVC项目
    使用Eclipse构建Maven的SpringMVC项目      首先Eclipse需要安装Maven的插件,地址:http://m2eclipse.sonatype.org/sites/m2e。     用MyEclipse安装Maven插件,建出的Maven项目有些问题。一是,发布tomcat的时候resources总是不会被发布到tomcat下;二是,把WEB-INF下的cla......
  • 28) 跳过去 (只装父pom |不测试|构建特定模块)
    只装父pom跳过子命令行mvn-Ninstall-N,--non-recursive          Donotrecurseintosub-projectsusage:mvn[options][<goal(s)>][<phase(s)>]eclipse 跳过测试mvninstall-DskipTests http://maven.apache.org/surefire/maven-su......