In Search of the Rare and Elusive DevOps Beastie

Steven Hill
Steven Hill

• Assuming that you can simply combine two important job functions into a single entity isn’t necessarily the best or smartest way of managing IT resources.
• Your environment may need a lot of work before you can effectively cross that line.
As IT professionals we’re constantly challenged to do more with less, and no one can argue that all of the wonderful flexibility offered by virtualization hasn’t fundamentally changed the nature of the data center in a remarkably short period of time. But simplifying the physical concerns of standing up servers and applications doesn’t necessarily mean that you can simply merge developer and operations functions into a single entity with a unified purpose. This is an evolutionary process, and — because bean counters are always looking for things like this to thin head counts — smart IT managers might want to head this off until they’ve taken an honest look at their environment.

Sure, it’s awesome to be able to give your development team high-level tools and APIs to that give access to resources that required more attention in the past, but this doesn’t really take into account the ongoing efforts that are still required of the operations team to cost, plan for and support critical applications for the long run. If you step back and look at it from an objective distance, there are a number of disciplines on either side of the DevOps relationship that don’t really cross over. And simply assuming that your development group should be concerned with — or has the time to deal with — the complexities faced by your operations team can be flawed reasoning. Call me old-fashioned, but I really don’t think this gives full credit to the challenges faced by the operations team and assumes that the development team should be saddled with that added responsibility.
Is this the way things may eventually work? I believe so, perhaps in the future. For now, it would certainly be in your best interests to consider the possible use cases for DevOps in your environment going forward, especially as you merge into more cloud-based solutions. That being said, unless you’ve already adopted such a complete level of data center abstraction that your systems automatically take into account the ongoing challenges of compliance, cost-control, SLA management, charge-back, troubleshooting, and every other little thing that comes into play after development launches an app, then you have more work to do before you can actually corral a herd of DevOps you can call your very own. Send me a picture when you do, I bet they’re cute as the dickens.


What do you think?

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.