We wanted to standardize the technology status and the expectations that we communicated to our peers, regardless of who they were talking to, but also across the technologies in our inventory. We set out to develop a model to help us track and talk about the technologies we supported, with a few goals in mind: Standardization Our peers didn’t know which technologies they should - or could - use. 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.

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? 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. These overlaps meant we would spend valuable time recreating new features in multiple projects, instead of writing new functionality just once. This team had a broad remit, often with multiple systems and technologies serving overlapping purposes, and this broad remit caused several problems for us. Our challengesĬirca 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 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 technologies products