Master (DevOps) Builders Need Collaboration, Too

If you’re a parent (and even if you aren’t, no judging here) you’ve probably been subjected to a viewing of the Lego Movie. More than once.

I’m of the opinion that it should probably be required watching for any enterprise that’s considering embracing DevOps.

Seriously.

That’s because one of the (many) lessons learned is that even Master Builders, experts in their particular domain, need to collaborate with others in order to save the world move an application to its desired, deployed state. That is, one that isn’t stuck in production with the frightening technological Kragle that is manual processes.

Individually, master builders are able to envision not only what they want to build but all the composite parts they need to build it. And they do so, often and admirably, in the movie, by whipping up completed creations that can smash, fly, race, and shoot-em-up to save the day. But when it came time to act on the “bigger” picture; to not only build up individual creations and then orchestrate (see what I did there?) a series of events to foil the Evil Bad Guy’s plot, they couldn’t do it. They needed the guy who liked to consult instructions and carry a checklist with the procedures required to get them all moving in the same direction.

In our case, that direction is production.

As continuous deployment becomes a real possibility and the ultimate goal of DevOps as it climbs over the wall between dev and the “rest of IT”, there is a very real need for coordination across all four operational domains (that’s security, storage, compute, and network) to ensure that the master builders of each individual set of services and systems aren’t working in a vacuum.

Even developers embracing microservices, with its “code local and independent of other services”, know that such a mindset and approach only works if there are clearly defined and documented interfaces (APIs) with which other services can communicate. Those interfaces aren’t (or shouldn’t be) developed in a vacuum, without an understanding of how other services are going to invoke them.

The same is true on the production side of the wall; where all four operational demesnes need to communicate at some point to enable the continuous deployment to actually happen. There is a master plan; a set of instructions that must be followed, even though the details of how each individual service or set of services might be built. They must, at some point, be orchestrated into an overarching process that drives deployment from one end of the production pipeline to the other.

The master builders within each domain cannot work wholly independently of one another. They need to coordinate, cooperate, and consider how their piece of the puzzle fits into the grand plan to save the (app) world on which the business is built today.

One of the ways to get started on that is to graphing out impact sets. I was reminded of this after reading a recent article on code coupling, The 80% Rule of Program Coupling, with an eye toward security. The article is very focused on code, and building what amounts to dependency graphs specific to development-minded folks, but if you bring it up a level (abstract it) and consider functions/procedures/methods as systems in production you can start to see how this might be useful. Understanding the level of dependency an application deployment has on specific services (or even at the domain level, to begin with) can provide some valuable insight into understanding just how much coordination is going to be required across groups to get ‘er done and to be able to lay out a plan for how to achieve that goal.

One of the best examples is that just about everything depends on core network services being deployed first. That’s true not only for the application and its dependent components, but for the security and higher-order (app) services that deliver the app. Load balancing, web application security, and even the firewall rely on network attributes to function. Understanding those dependencies (the coupling factor) between systems and services managed by different groups (silos) within IT can go a long way toward forwarding the need to communicate and collaborate to achieve even the resemblance of continuous deployment.

Even Master Builders have to understand how their creation fits in the bigger picture. Applying development techniques and tools to the increasingly automated and code-based world of operations across IT will help them better build the interfaces necessary to integrate their piece of the puzzle into the grand construction effort that is continuous deployment.