I really like and support this ADR, and want this to work. The SSM Parameter Store seems like a solid solution that integrates well with our tech stack.
On a procedural note, I'm worried that we are making these decisions without considering the migration cost. In the software indstry, I've very frequently experienced this pattern:
| Time index | Organizational mood |
|---|---|
| 1 | B is better and easier to maintain than A, so we will move to B |
| 2-50 | Implement B |
| 51-60 | Migrate a few easy systems, as a test bed |
| 61-99 | Migrate a big, heavily used system |
| 100 | We are now at (Pareto's) 80% of systems migrated to use B. Hurrah! Big win! |
| 101 | Organizational analysis of remaining systems indicates it isn't worth migrating - some of the systems are "going away", and any way Product is putting pressure on us to deliver customer-facing value and it is very hard to explain the value of what is affectionately known as "the second 80% of the project" |
| 101+ | Organization maintains A and B indefinitely, increasing costs, the fragility of the system, and defeating the original purpose of the project. |
At 2U, I think we are particularly prone to ignoring aspects of how we get to the end state. In fact, these are the incomplete migrations that I'm aware of:
- SumoLogic to Datadog
- EC2 to Kubernetes
- SimpleDB to Vault
- OARS to Viking
- OARS to AMT
- Single tenant to UMT
- Adobe Connect to Zoom
- SIS to ???
- SIS to UDX
- CircleCI to BuildKite
In fact, I can't think of any instance where we replaced a technology and successfully killed the previous technology. Granted, I don't have visibility into a lot of things on the organizational scale, but I can see we have a very high miss percentage.
I think it is important in making this decision that we have a migration plan. I think it is ten times more imporatant to know the migration plan, than say the cost of the service, because the migration plan will absolutely dominate the cost and effort.