关于adobe:Adobe-构建-IDP-之路的经验与教训

6次阅读

共计 3209 个字符，预计需要花费 9 分钟才能阅读完成。

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

在云时代晚期，Adobe 的每个团队都有本人的云账户、部署零碎，其对应的成熟度也截然不同。很快咱们就意识到须要对此进行标准化，这样老本管制、合规性、安全性和可靠性等关键问题就可能一次解决，且一劳永逸。

在 2016 年，Kubernetes 还处于晚期阶段，尚未有能力大规模反对 Adobe 的云产品。当下最好的抉择是 Mesos，当然咱们分明地理解咱们正处在一个一直变动的环境中。因而咱们没有将用户裸露给原始平台，而是创立了一个形象——服务标准。这个服务标准形容了所有对于如何提供和部署服务的信息。而后，定制的外部软件在在部署时将服务标准转为必要的原语，平台就此腾飞，迅速成长并为 1000 多个服务和开发人员提供反对。

但随着规模和需要的增长，咱们在 Mesos 之上的外乡解决方案开始陷入困境。这时 Kubernetes 曾经成熟，是时候扭转了。咱们构建了一些自定义迁徙工具，并且可能保障在不停机的状况下将所有正在运行的服务从 Mesos 集群迁徙到 Kubernetes 集群，也就是咱们的新后端是将服务标准转换为 Kubernetes 配置，只管呈现了一些小问题，但总体一切正常。就此 Mesos 集群被敞开，老本也得以节约。

之后的几年，状况变得不太乐观。咱们的服务标准以一种非常简单的“黄金门路”，反对近 4000 个实用于服务 REST API 或 Workers 的根本应用程序。但随着越来越多的 Adobe 团队开始寻求平台老本节约以及安全性、合规性和可靠性的保障，要求也越来越多样化，慢慢超出形象反对的模式。因而公司外部规模较大且技术较成熟的团队 开始绕开形象，在咱们的托管集群上构建自定义计划 ，充分利用 Kubernetes 的自在和弱小性能。当然， 他们也必须对部署零碎承当所有责任与危险，因而在安全性和可靠性方面减少了更多累赘。

随着越来越多的团队要求更高的自主权和更大的灵活性，咱们开始意识到原来咱们被困在形象陷阱里了。咱们的形象不反对团队局部应用，因而在定制解决方案时须要绕过形象，也就是说 咱们提供了一个不可扩大的“全有或全无”解决方案。

随着工夫的推移，咱们的定制解决方案变得越来越简单，为了增加新性能并跟上 Kubernetes 的倒退耗费了团队越来越多的工夫，咱们简直没有什么空间进行翻新了，也开始落后于新技术了。更蹩脚的是咱们没有为可扩展性而构建。即便有好的想法，但如果咱们无奈确定优先级，让用户奉献他们须要的更改也变得不切实际。

从 Mesos 到 Kubernetes，再到接下来咱们要做的平台，在每个阶段咱们都不得不与制度惰性和对变动的恐怖与冲突作奋斗。如何让用户参加进来，让一个无效但果实的解决方案变为更好更先进的解决方案，同时又可能解决他们对生产服务发生变化的危险产生的担心呢？

这便是须要理解企业外部，确定一些在以后零碎中苦苦挣扎的要害参与者的时候了。兴许这些参与者正在应用已有的零碎和解决方案，但因为不足自由度，他们无奈成长。明确受影响最多的团队，以及次要负责公司要害业务需要的团队是哪些，并与他们一起合作，以便更好地梳理痛点与需要。同时让负责构建新解决方案的工程师退出这些团队，综合专业知识为团队进行培训，同时将收集的反馈和教训回滚到产品中。当这些胜利的教训在整个公司内流传开来，对采纳新技术的担心和冲突将可能无效削弱。

这是一个好的开始，但这个模式不可继续，因为只能小范畴施行无奈达到宏大的规模。因为企业外部的工程师数量无限，他们须要构建平台，而与业务团队合作并给予反对会耗费他们大量的工夫和精力。因而自助服务成为平台的要害。例如蕴含故障排除链接的智能谬误音讯，能够搜寻可用文档以答复问题的智能代理，为团队解决问题的认可和处分机制，各个级别的自动化，等等。

无论咱们构建什么解决方案，都须要主题专家（Subject Matter Expert, SME）来进行创立和保护，由此带来的问题则是 适度专业化。开发人员成为他们所负责组建的专家，无需放心其余任何事件。这样开发人员能够更专一于开发业务，但在平台环境中也带来了很多问题。这类开发人员通常在本人关注的畛域体现出十分高的生产力，但他们同样有可能面临与不太理解相熟的系统集成的问题。如果这些开发人员来到岗位，他们所专一的业务就可能成为企业的单点故障。

咱们通过三种形式解决了这个问题。首先 通过培训和日常应用咱们本人的交付 来确保团队的每个成员都是平台的专家用户，而后 为每个成员调配一个反对轮换 。最初咱们 激励团队内的流动，咱们定期依据开发人员的集体志愿和企业的须要在组件之间轮转岗位。

当然开发人员须要集中精力实现工作，所以这些轮换不会进行得太频繁，组件的转移也不会时常产生。这样咱们就可能 造就“T 型”人才，即开发人员在整个平台上具备宽泛的常识，且在数个组件上的理解具备深度。

多年来咱们始终在试图兼顾短期胜利和长期布局。尤其在开始一些新的、有风向的我的项目，随着工夫的推移，企业的解决态度往往会转向审慎，开始按流程开展我的项目，例如成立布局小组，确保标准详尽无遗，一直进行审查 ……

事实上没有什么完满又神奇的解决方案。但咱们发现，如果咱们能发现什么时候遇到问题停滞不前，并及时扭转模式，就能获得很好的后果，不必过分谋求标准上的详尽和完满。带几个开发人员组织一个小团队集中翻新研发几周，打消烦扰，而后与选定的要害外围用户密切合作来评估概念。如果顺利的话，将信息反馈给团队及其他成员，利用这些反馈和简洁的“标准单页”，确保研发的指标和愿景是清晰的，接下来进行迭代并交付平台用户所依赖的价值。

平台团队的一个天然趋势就是随着工夫的推移逐步漠视用户。当咱们对用户开始说“不”的时候，他们就会开始寻找其余的解决方案。而平台工程的要害特色，那些为公司带来的劣势——老本节约、合规性、安全性和可靠性，也都没有意义了，平台团队将成为瓶颈，这也将是平台沦亡的形式。

因而咱们通过与高层领导和次要用户保持联系来防止这种状况，尤其是面对公司内新我的项目和要害业务时。咱们确保平台是一直倒退的，以满足要害用户的需要，保障平台足够通用，使开发人员的工作变得轻松和灵便，反对所有必须的用例。当然实现这点并不容易，咱们须要一直地翻新和改良。

从一个好的想法开始，到大规模和继续的适应，这就是 Adobe 构建 IDP 的旅程。咱们正处在一个转折点，因为形象的限制性，而用户想要得更多，保护自定义解决方案正在耗费平台团队的大量精力和工夫。总结构建 IDP 之旅中的教训与教训，咱们意识到 形象是好的，但不灵便的形象可能是一个陷阱 。在 外部构建解决方案容许齐全自在，但这种自在是以继续保护来兜底的。咱们仍旧在寻找一个区别于固定的“黄金门路”解决方案和原始 Kubernetes 的新解决方案。

咱们正在应用 Helm 图表的轻度形象来替换服务标准的重度形象，并将咱们的定制组件套件换为 Argo，咱们在致力解决可扩展性问题。咱们让要害用户参加到开发过程中，联合开源和企业外部资源，再次构建自定义转换工具，将旧服务标准转换为 Helm 图表和 Argo 模板，让用户能够随便定义这些模板。

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