DevOps: DIY vs. Commercial
DevOps: DIY vs. Commercial
DevOps is a popular trend in software development, but is it efficient to implement it DIY-style, and is it effective in the long-term?
Join the DZone community and get the full member experience.Join For Free
Planning to extract out a few microservices from your monolith? Read this free guide to learn the best practice before you get started.
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:
- 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.
- 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.
- 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.
Published at DZone with permission of Bernard Golden , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.