Ready? Set? DevOps!
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Not so fast! Jumping headlong into a DevOps strategy without understanding the common pitfalls and mistakes is like climbing a mountain without any gear.
Jumping headlong into a DevOps strategy without understanding the common pitfalls and mistakes is like climbing a mountain without any gear.
Like most truly transformational ideas, DevOps success starts with a comprehensive vision of the future, a plan, and an ambition that requires revolutionary thinking and new perspectives. If you treat DevOps as a another small step forward and fail to treat it as an end-to-end reengineering of your processes that requires real investment, you are likely to experience significant issues or downright failure along the way.
There are seven deadly sins associated with DevOps: the failures that plague a DevOps strategy and transformational initiatives in enterprise environments.
1. Failing to plan. Attempting to adopt a DevOps transformation without a clear plan for success will almost guarantee failure. A very common mistake that occurs is that a bunch of smart people start to experiment with pieces of the DevOps universe and quickly get way out in front of their organization. Unfortunately, these pioneers are at risk for career pain without the commitment and support of the organization and senior leadership.
2. Failing to fund. A client once quipped, "Strategy without a budget is just a dream." These words are particularly true of a transformational program like DevOps. The other side of the DevOps initiative is flush with benefits, including lower costs, higher agility and better quality. However, you don't get to the other side without a serious level of investment in people, process and technology.
3. Failing to join the revolution. If you take your existing delivery model -- slow, manual, process-laden and expensive -- and try to change it piece by piece, you will fail. DevOps is deeply entwined with continuous delivery and cloud, going all the way through the process from coding to production. Trying to operationalize DevOps with your existing tools is virtually impossible -- or at least ridiculously hard and expensive.
If you want to succeed with DevOps, build a new, continuous process model centered on goals and objectives, not existing processes and tooling. Then move your application teams -- who should be leading the design and implementation of the process -- out of the old and into the new.
4. Failing to let developers lead. Too often DevOps is seen as an initiative driven by IT operations as a service to the application development teams who are, at best, consulted along the way. Clouds written by and for developers are typically far more successful than those built by operations teams. DevOps is no different. Remember that DevOps brings applications and infrastructure together and requires integration at a code level. The most successful DevOps transformations are actually led by developers in deep partnership with operations.
5. Failing to drive for scale. DevOps driven with continuous delivery is supposed to enable rapid cycle times and weekly or even daily releases of code. Operations management is the science of measuring and removing process bottlenecks to get more output for a given level of input -- all while continuously improving quality. DevOps is the practice of operations management in IT, and it requires deeply critical analysis at each step in the process of delivering applications.
Even if you are in a regulated business, most of your applications can be delivered far more frequently than the one or two major cycles you typically have per year. Getting to monthly, weekly or even daily releases is really the same challenge any operations process presents; it requires a scale perspective that is not familiar to many in IT.
6. Failing to test. A DevOps continuous delivery process is a complex system and needs to be tested deeply and continuously. The more automated a process is, the more likely a single small failure can halt the whole works. Unit tests; system tests; chaos and outage tests; and performance, resiliency and quality tests – they all need to be performed. Statistical process control, Six Sigma and other processes typically associated with manufacturing or process industries can be hugely valuable in this environment, but are often overlooked.
7. Failing to treat dev and prod consistently. Too often enterprises use different processes, tools and staff to stand up an application across each stage -- development, test, and preproduction and production environments. Monitoring, license management, security and other components of the management stack will vary at each stage. The process for deployment will vary too -- with very manual, approval-driven processes typically at the production stage.
This model, however, does not work in a DevOps continuous process environment. If you don't build, deploy and manage the application consistently at each stage, there will be chaos when you try to reduce cycle times to weeks or days from the many months that you typically see now.
About the author:
John Treadway is a senior vice president at Cloud Technology Partners and is based in Boston. You can reach him at firstname.lastname@example.org or on Twitter @johntreadway.