Skip to content

Instantly share code, notes, and snippets.

@lethain
Last active January 25, 2020 17:59
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save lethain/851a7ac92643681d254684448fc3905c to your computer and use it in GitHub Desktop.
CFP for "Migrations: the only scalable approach to technical debt"

Description

Migrations are both essential and frustratingly frequent as your codebase ages and your business grows: most tools and processes only support about one order of magnitude of growth before becoming ineffective, so rapid growth makes them a way of life.

Two of Stripe’s most important migrations have been typing our Ruby codebase and migrating our metrics and dashboard stack. This talk will explore why migrations are the only mechanism to effectively manage technical debt as your company and code grows, what makes running them so hard, and a repeatable approach to running them effectively:

  • derisking the migration by testing the approach,
  • enabling the migration with documentation, tools and self-service to make it go as quickly as possible, and
  • finishing the thing.

If you're already languishing in technical debt and are afraid to even consider how you'll dig out, this talk is for you.

Audience Takeaways

The core idea that I hope for the audience to take away from the talk are:

  1. Tech debt: the core constraint on your velocity (at scale).
  2. Migration: fully replacing a tool, system or library.
  3. Approach: treat every migration like a product.

They'll have a framework for explaining to their teams and companies why thoughtful migrations are essential to long-term success, as well as tools for designing their own thoughtful migrations.

They'll have specific successful migrations they can reference that demonstrate how/why the approach works. They'll also have examples of specific failed migrations that demonstrate impact of failed migrations.

Outline

  1. Self-intro
  2. Thesis:
    1. Tech debt: core constraint on your velocity
    2. Migration: fully replacing a tool, system or library.
    3. Approach: treat every migration like a product
  3. "What is a migration?" - add examples of migrations, e.g. netflix colo to cloud, etc
  4. "Why do migrations matter?" 4. Productivity goes down as code bases age. 5. Teams do whatever they can to increase productivity in their own scope, but working across teams' scope gets harder as a company grows larger 6. MIgrations are when large groups of teams need to work together at roughly the same time to increase productivity (e.g. reduce tech debt) 7. There is limited capacity to run migrations concurrently since they require "acquiring the lock" on many teams at same time. 8. Too many migrations can also disproportionately impact product engineering teams, which use many other teams' systems (as opposed to infrastructure teams which usually have fewer dependencies) 9. And migrations fail! (Which requires a rollback, even more time.) 10. Fail too many and you reach "zero productivity" and have to do a full migration.
  5. "How do you do migrations well?" 11. Treat it like a product. 12. Derisk - make sure it's truly worth doing and that your approach is viable. 13. Enable - build tools to make it fast 14. Finish - get to 100%, have to fully replace the previous tool
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment