This blog post discusses the strategies that Slack uses to manage the lifecycle (development, support, and eventual retirement) of infrastructure projects, through the lens of the migration through three successive internal “platform” offerings.
这篇博文讨论了Slack用来管理基础设施项目的生命周期（开发、支持和最终退役）的策略，通过三个连续的内部 "平台 "产品的迁移镜头。
Circa 2020, our Cloud Engineering team (now evolved into multiple teams responsible for narrower aspects) was responsible for managing our Infrastructure-as-a-Service providers, compute environments like Chef and Kubernetes, and a large variety of related systems.
This team had a broad remit, often with multiple systems and technologies serving overlapping purposes, and this broad remit caused several problems for us.
These overlaps meant we would spend valuable time recreating new features in multiple projects, instead of writing new functionality just once.
Retiring older technologies to focus on newer ones was challenging, because these older technologies still served important responsibilities, and we did not have a clear process for migration of those responsibilities to newer technologies.
We also could not easily and consistently communicate with our peers about what they could expect if they chose a specific technology: Would we support them? Address bugs they found? Surprise them with a “deprecation” warning a week after they went live?
我们也不能轻易地、持续地与我们的同行沟通，让他们知道如果他们选择了一种特定的技术，他们可以期待什么：我们会支持他们吗？解决他们发现的错误？在他们上线一周后发出 "弃用 "警告，让他们感到惊讶？
Not only did we not have clear answers to these questions, the un-clear answer a peer received would vary based on who on the team they talked to.
Our peers didn’t know which technologies they should — or could — use.