What CloudOps Tools Builders Can Learn from Software Designers

I have done both software development and operations in my career. I’ve worked for large companies where dev and ops were run by different Vice Presidents, and startups where we all did everything. I’ve been working with cloud computing (or as we naively called it then, utility computing) and ops automation since the early 2000’s.

These days I’m a consumer of cloud and devops tools, and an observer of trends in both areas. They strongly overlap in my work, so for this post at least I will conveniently conflate them into CloudOps. I would like to offer some thoughts about the state of CloudOps. I confess to being a software engineer first and an ops engineer second. My opinions reflect that bias.

I’ll start by making some crass generalizations about the difference between development and ops. In my experience developers spend a lot of time thinking about design elegance. Whether it’s a programming language like Lisp or Ruby, or a framework like Rails, or a methodology like Agile, developers strive for simplicity, uniformity, clarity, coherence. At least when it comes to tools for ourselves, we have a good sense of usability. I remember people slamming C++ because it was powerful but complicated and ugly.

Operations, on the other hand, tends to be pragmatic and concrete. Ops engineers pride themselves on their ability to master complexity, not hide it. Developers talk about moving up the abstraction stack. Ops engineers often have a hard time moving up the stack. The thought of not being to “fondle the router” makes them nervous.

Moving from crass generalizations about people to crass generalizations about the things they build, I’m going to claim that the current generation of CloudOps management tools reflects the ops engineer mentality. They make it possible to “do a bunch of things”, but lack design integrity. I think Chef is the coolest thing since sliced bread. I love what I can do with it. I try to design it into systems management solutions wherever I can. But the process of learning Chef was not a pleasant one. The catalog of “what you can do with Chef” was overwhelming. I had to repeatedly dig through the documentation and scratch my head to figure out the heart of its semantic model.

Cloud management tools often fail to reflect critical user needs. Development used to be really bad about that, too. Agile has helped us get better at listening to users and focusing on relevant business value. The key customer insight I see missing from cloud tools is the understanding that, just as maintenance is 90% of software development, so too change management is 90% of configuration management. CloudFormation is a prime offender. Once you change a template, or an environment you’ve built from a template, there is no way to sync the change across the objects that supposedly reflect each other. IMHO CloudFormation is almost counterproductive because it creates a false sense of security.

Vagrant, on the other hand, is a shining example of how to get it right. It has a very clean conceptual model. I found myself able to understand what it was and what it did nearly instantaneously (all credit to Vagrant, none to me). Even better, Vagrant is all about managing change. At the risk of sounding corny, I would say that Vagrant is beautifully designed.

There are as many definitions of DevOps as there are practitioners. One that I’ve thrown around is “operations acting more like development”. I was referring to operations adopting software development tools and processes like scripting, version control, automated verification, and scrums. I think, though, that I need to expand my definition. Operations needs to act more like development when it comes to designing tools, in at least two ways:

  • By striving for design integrity and beauty
  • By adopting user-centered agile requirements techniques

I’ve viewed the world from the ops side of the fence. I have nothing but respect for everyone involved in creating the CloudOps tools ecosystem. If we’re going to start building things for others to operate, though, we need to be willing to learn from the folks on the other side of the fence. If we do, then together we can build things better, and build better things. IMHO that truly is DevOps.

Post Comment