在过去的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 中。有了这一切，我们将以更低的成本提供更好的平台，为我们的用户提供更高的灵活性和更低的摩擦。
参考链接：
https://thenewstack.io/adobes-internal-developer-platform-journey-and-lessons/