Chapter 9. Migrations and Sunsetting of Platforms
A platform is meant to be the stable thing that provides an enduring surface to build on, like a foundation. Platform engineering requires building those stable foundations and not externalizing work onto the things that people build on top of it.
C. Scott Andreas
The relentless pace of change creates an existential challenge for platform engineering teams. Your underlying systems are evolving all the time: there are regular patches and upgrades to keep up with security issues, vendor changes, hardware updates, and new features. End-of-life timelines for fundamental infrastructure systems, once spanning a decade, have compressed to one to two years for cloud products like EKS, increasing the frequency of upgrade disruption on application teams. Without a plan to manage the impact of these changes on application developers, platforms become a source of migration pain that outweighs their value.
We’ve mentioned migrations several times already in this book, and for good reason. In the face of this challenge, great platform teams realize that migrations are in fact an opportunity to prove their value. They see their job as easing the pain of mandatory migrations, limiting and even removing work so their customers can focus on delivering top-line features.
Note
For the purposes of this chapter, a migration is any mandatory change to your platforms that requires some work by the users in order to adopt. This is a spectrum from the ...
Get Platform Engineering now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.