Ophan adoption feedback

[nicl]

Why haven't Ophan adopted CDK yet? After talking with the team, some of the reasons are:

• 'too much to do' and 'not enough devs'!
• non-standard Cloudformation (nested stacks - especially 'tracker' which is the key high-risk app, kinesis streams, and other less common resources)
• unclear benefits
• risk of loss of availability during migration (which is especially relevant here as lost Ophan data is gone forever and the stakeholders are understandably wary)

In general, they are open to CDK but want to see more evidence of the benefits to offset the challenges above. Resource constraints are relevant here; it's not that they don't think CDK is beneficial, but need to way it against other work.

[markjamesbutler]

@nicl Was there any update on this discussions at your meeting with @idrise last week?

[nicl]

@markjamesbutler @akash1810 attended the catchup with them so can provide further detail. But I believe they are going to draft some epics for planning and then we'll work with them to refine things.

[markjamesbutler]

'too much to do' and 'not enough devs'!

What work is blocking them? How is the prioritisation being made?

non-standard Cloudformation (nested stacks - especially 'tracker' which is the key high-risk app, kinesis streams, and other less common resources)

Are these non-standard for a good reason?

risk of loss of availability during migration (which is especially relevant here as lost Ophan data is gone forever and the stakeholders are understandably wary)

Great point, I wonder if Ophan should be investing more in this area as it's not simply infra changes that can cause data loss.

[nicl]

Thanks @markjamesbutler .

What work is blocking them? How is the prioritisation being made?

I'm not sure - this was beyond the scope of the discussion to be honest. The question of prioritisation is a good one though - how should teams balance the competing health requirements (Java/Play/Scala upgrades, CDK, ...)? I don't think a central answer to this makes sense. Rather we should be clear on what is required (e.g. quickly addressing critical security vulnerabilities) and what is strongly encouraged - CDK for example. And also we should be improving our tracking/dashboards to help teams better understand which bits teams are falling behind on and where.

Are these non-standard for a good reason?

Pre-CDK nested stacks were an idiomatic way to re-use Cloudformation code. They have some operational disadvantages though - coupling deploys for example - and CDK now provides a better solution for code re-use.

Great point, I wonder if Ophan should be investing more in this area as it's not simply infra changes that can cause data loss.

Almost certainly, though I'm not familiar with their stack. Infra changes are especially risky though, depending on how done, but I'm confident there is a migration path that contains risk here.