Grounded in the Cloud
cancel
Showing results for 
Search instead for 
Did you mean: 

DevOps: DIY vs. Commercial

Stephen_Spector

Guest Post: Bernard Golden, VP of Strategy, ActiveState

 

I’ve had the opportunity to attend a number of DevOps Days events. These are informal, community-based conferences devoted to a critical topic: how to get applications into production more quickly. DevOps Days speakers are always inspirational as they outline the immense challenges they faced and what they’ve done to improve things -- and the improvements are often dramatic. A common refrain in these presentations is how they moved to standardized resources like commonly configured virtual machines to allow automation -- often described as “moving away from snowflakes.” In other words, a necessary step in achieving automation is removing variance to allow common configuration automation.

 

I have to say, though, that a typical feature of most presentations is a recitation of the various open source products and components and how they integrated them to implement their solution. In a word, how they created their home-grown solution. Given that many of these speakers hail from startups with small teams and and a focus on conserving cash, this approach makes sense. Moreover, given that these are typically small teams working at companies following the Lean Startup approach, using open source that allows rapid change as circumstances dictate makes sense as well. And, in any case, startups need to solve problems today because who knows what the future will bring?

 

On the other hand, I often feel that there are downstream implications unaddressed in these presentations -- implications likely to be major roadblocks later on, if the startup blossoms and grows. And for enterprises, which must plan for the future (after all, they’ve been around quite a while and need to measure their future in years, if not decades), an approach that doesn’t have a long-term time horizon is problematic, to say the least.

Here are the issues I see with the DIY approach:

  1. It presumes intense interaction between development and operations. Presentation after presentation on IT issues pronounces one of the major issues in IT is “silos” -- groups separated into their own self-centered organizations focused only on solving their own problems. So why would interaction between developers and operations be a bad thing? It’s not. But in an enterprise, the kind of “he sits two seats away from me, so I can just turn to him and ask a question” is unachievable. The highly productive intense interactions common to startups doesn’t scale, so solutions based on proximity and immediate response to problems is not scalable. A solution that can scale to many development and operations groups managing many different applications is critical. Homegrown solutions invariably are written for a limited use case that reflects the situation at the moment and are difficult to modify when new requirements appear associated with a new use case.
  2. It uplevels the snowflake issue. DevOps seeks to standardize resources to enable automated installation and configuration. This is perfectly appropriate. However, the DIY approach “uplevels” the issue by moving the one-off approach from individual resources to the DevOps system. It’s fantastic that the application resources themselves are standardized, but a bespoke system invariably falls further and further behind commercial systems, particularly those that take responsibility for selecting, integrating, and supporting one or more open source components. The commercial systems benefit from a large community of developers in the open source community, which allows for a greater rate of innovation compared to the homegrown solution. However, the heavy lifting needed to make sure all the components are properly integrated is the responsibility of the vendor and benefits all customers, rather than each user needing to take on that burden itself.
  3. It overlooks the need for continuity. It’s fantastic that you have a member of your staff who is talented and creative and puts together your DevOps system. However, someday he or she will be gone, and someone else will have to maintain the system. At that point, your DIY solutions becomes the legacy system you’re always complaining about. You’ll mostly likely be using this DevOps platform for a decade; will your company fund maintenance and investment for that period of time?

A far better approach to DevOps is to use an externally-developed system. This will free up the resources that would have been devoted to writing your own system to work on applications that you can use to differentiate your company from its competition. At the end of the day, that’s the purpose of IT: provide applications that deliver value via differentiation. Everything else is just overhead that should be outsourced as much as possible.

 

Senior Manager, Cloud Online Marketing
  • HP Cloud
0 Kudos
About the Author

Stephen_Spector

I manage the HPE Helion social media and website teams promoting the enterprise cloud solutions at HPE for hybrid, public, and private clouds. I was previously at Dell promoting their Cloud solutions and was the open source community manager for OpenStack and Xen.org at Rackspace and Citrix Systems. While at Citrix Systems, I founded the Citrix Developer Network, developed global alliance and licensing programs, and even once added audio to the DOS ICA client with assembler. Follow me at @SpectorID

Events
28-30 November
Madrid, Spain
Discover 2017 Madrid
Join us for Hewlett Packard Enterprise Discover 2017 Madrid, taking place 28-30 November at the Feria de Madrid Convention Center
Read more
See posts for dates
Online
HPE Webinars - 2017
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all