Infrastructure As Code - Tiki-Taka of TechOps

Techops traditionally has been pursuing a dual mandate. On one hand, a part of resources is dedicated to new projects and expansion initiatives. On the other hand, there’s always been a significant effort to make sure existing systems are up and running. In each focus area, the industry has developed a significant knowledge base and accumulated a lot of experience.

This dual mandate has been in place for such a long time that not a lot of people are even questioning it now. So let’s pause and think - could there be a better way? I propose approaching this question with the help of a soccer analogy.

Just as techops, a soccer team on the field is also pursuing a dual mandate - attack and defense. Over the years there have been numerous strategies and metholodologies how each phase of the game needs to be built. These strategies included recommendations and best practices on how to defend, how to attack and how to transition between the two.

But then they adopted tiki-taka in Spain (see also a thread on quora). While I am not going to go into significant detail here, for our purposes it’s important to note that tiki-taka deprioritizes the dual mandate - instead of focusing on attack and defense as completely separate situational configurations, tiki-taka focuses on maintaining ball possession as one of the primary means through which games are won.

In tiki-taka, possession is a primary goal, and particular decisions on offense and defense are a consequence. In other words, tiki-taka in large part replaces an offense/defense dual mandate with a single focus on possession.

Going back to techops, I see infrastructure as code playing the same role in techops as tiki-taka plays in soccer. Intsead of trying to tailor one’s strategy to cover both new projects while continuing to keep the lights on (it’s worth noting that these two areas often times present different or even conflicting goals), by treating your infrastructure as a software engineering project, you can eliminate ambiguity and potential conflict.

Categories: devops |