Convincing Product teams to Adopt Gitops in a Large Org

Is it practical to govern different teams in an organisation to adhere to the same infrastructure automation model or is it over-engineering? Does your product team love managing infrastructure as well or do you feel overwhelmed? Thinking about it from an organisation perspective, how complex is it to bring the change and convince teams to adopt a well-established concept like Gitops?

In my current team, we had bigger concerns resolving this problem as the way different Product teams manage their infrastructure was unclear to us and sometimes even manual that furthermore lead to - no audit trail - less transparency - lack of infrastructure visibility - no predictable state in case of disaster recovery - no best practices followed Moreover, a launchpad-like cloud solution called Digital Platform was offered by us more or less at the same time the organisation adopted “lift and shift” to a cloud provider - Google Cloud Platform, with the idea of spinning micro-services quickly for product teams with less effort and minimal cloud knowledge. This eventually became a bottleneck as it restricted teams from upskilling themselves for infrastructure automation and furthermore added dependency on us in terms of upgrades and support.

In my previous team, where I was focused on product development, I often questioned myself about the future of Digital Platform. For example, it wasn’t easy to even upgrade NodeJS versions while on the other end my current team already planned to decommission it in favor of Gitops. During this dramatic shift from software engineer to system engineer, I gathered an overarching experience from “asking support” to “giving support” to product teams in adopting Gitops. Some takeaways - How successfully was it implemented? - How was the infrastructure knowledge gap filled? - Infrastructure as Code and predictable systems - Deadline after deadline after deadline