The word “DevOps” has a lot of different meanings. Some people mean automating traditional operations tasks like server configuration. Some people mean writing some bash scripts. Some people are just talking about the culture of DevOps, which usually encompasses developers and operations people working together.

When I heard the term, I thought it meant that, due to the expansion of cloud services like AWS, GCE, and others, a development team could do away with operations. In this case, the “glue” between the cloud and the development team would be DevOps. Places like Netflix revolutionized the space with heavy automation and scaling, relying on AWS for hardware and “DevOps teams” to develop the automation software.

I started doing the same thing, developing a deployment and maintenance platform on Rackspace for Under Armour, and developing a custom infrastructure on top of Linode for Rafflecopter. Neither team used operations people; we just had developers.

This is my romantic notion of the “original dream” of DevOps: No distinction between dev and ops, just one team working toward one goal.

But, now, DevOps means much more and much less than that. DevOps is not a revolution for developers; instead DevOps is a revolution for operations engineers. No longer can one linux guru sit in an office and manage all the servers, deployments, and miscellanea. The expansion of the cloud and data size is forcing operations engineers to learn better techniques, hence DevOps.

So now that operations engineers are being displaced, and they naturally land as DevOps engineers. This floods the space of DevOps people with an imbalance in backgrounds. Most people in the space are on the operations side, be it linux admins or release engineers.

This has made DevOps lose some of its original sheen, because instead of bridging the gap between Dev and Ops, its simply been renamed operations to DevOps. Now it doesn’t mean what I thought it did, instead it now stands for 15 different things that are far less revolutionary.