Development Plays Chess, Operations Plays Poker
Categories
DevOps & SRE
In our company we have a program that temporarily moves engineers around. I was lucky to be picked in this round to step away from my usual day-to-day development role and spend three months as an embedded developer with our great Operations team.
Related blog post: Use Microservices to Modernize IT Operations
On the surface, it’s the same job in a different team— we work on the same product, we write code, we test it and we make sure our customers are happy. But working with Operations made me realize how different it is. If work was an intellectual game (and at times it certainly is), development would be a game of chess, while operations is a poker match.
In both games, proper assessment of the current state is key. But in chess both players have all the information right in front of them, and the only surprises come from a good opponent.
Not so in poker, where something is always hidden.
A game of probability
Certainty is replaced by probability. You have to use reason to determine what are the chances to have three aces in the flop (or of three data centers going down). No one could know if the three cards on the table are just such a rare event.
And operations engineers need to think of the rare situations that could happen, no matter how unlikely, and make sure our customers are getting their notifications delivered no matter what.
Putting code to the test
How do we ensure our solution works in any situation? We have tests. On the development side, testing is often a straightforward activity — a little more than an exercise of translating customer requirements into the formal language of computer code. On the Operations side every test is an integration test. It is always a question of two or more systems acting in accord with each other. Our tests make sure applications can talk to each other, share the information and— crucially— alert the right person if anything goes wrong.
My three months with the Operations team are over, and I am back with the development team. This experience enriched me and provided me with many insights into areas in which we can further improve our service. It has also brought the two software engineering teams even closer, ensuring the xMatters spirit of the Same Team is not lost as we grow in size.
As you may know, embedding developers in Operations (and Operations workers in development) is a classic DevOps strategy. We take it very seriously, and it allows us to provide excellent service to our DevOps customers.
How is your DevOps strategy going? Leave some comments below and tell us.
Learn More About DevOps Tool Chains
We’re not the only ones promoting the idea of creating a tool chain that you can use as you move processes forward. In a new research note, Gartner discusses the merits of a DevOps tool chain as well.
For more on how xMatters can help with DevOps processes and operations, check out our new DevOps datasheet.