2012 could easily be referred to as the year of the software glitch. While the Royal Bank Of Scotland (RBS) and Knight Capital Group are top of mind, they were certainly not the only victims of notable glitches. In fact, they were kept in good company throughout the year with major failures at United Airlines, Lloyds TSB, RIM, Amazon web services, Google Mail and many more.
So what’s the common factor in all these outages? Software. Software has become so prevalent in our world that estimates show up to 95% of all businesses have an IT component in them. And when IT fails, it is almost always in software. But it is not the software itself that is failing, at least not according to research from Gartner [PDF], which states over 80% of failures are caused by people and process failure. That’s IT people and process.
The Tangle Between the Business and the Customer
Development and Operations stand between the business and the customer. The business makes an offer or a commitment to customers and, from a business perspective; IT (development and operations) is then trusted to deliver on business requirements as efficiently as possible at high quality. The reason IT has two separate constituencies is they each represent an equally critical function for the business. Innovations and competitiveness on the one hand, stability and compliance, on the other. Development (Dev) is the first and Operations (Ops) is the second. Of course, there is an inherent conflict between the two where development is driven by change and operations is driven by control (to ensure stability).
This conflict represents a wall between the two constituencies. For decades now, development and operations have been separated by this virtual wall. “Production” was the world belonging solely to operations. Developers had no access and no privileges. The isolation of the production environment from all other environments that developers use, such as Test or QA, is considered a key to keeping things in production (relatively) stable. In production, change is viewed as the enemy. Change and configuration control systems in production guard against undocumented changes and strict change processes and time windows managed by Ops aim to assuring change is confined and “managed.” Developers were expected to plan deployments months in advance and cycles generally pointed at production releases only happening every three, six or nine months depending on the application at hand.
Complexity Changes Everything
Applications and services are made up of many times more components and integrations today as they were only a few years ago. And, coupled with a much more competitive business world, this complexity has drastically changed things for development and operations, separately. For example: Development, pressed to deliver more functionality faster, focuses on small and incremental changes using agile methodologies and tools (such as continuous integration servers) to help them achieve changes faster. The Ops environment is, likewise, much larger these days with many more servers and services then ever before. The production environment, which used to be all physical, is almost entirely virtualized today so Ops can spin up servers in an instance. OPS are also managing more resources today then ever before.
Complex Deployments at a Continuous Pace
Still, here’s the biggest problem yet: As development becomes completely focused on delivering quickly by chopping up services and developing more in parallel, making the application work as a whole requires many more configuration steps and, with that, more interdependencies are created. Also, with agile, developers are spending a lot less time on “internal” projects that could have simplified some aspects of complexity. Ops people hate fixing developer problems, as developers don’t usually appreciate spending time on configurations and deployment (it isn’t coding) and over time this has become a major point of contention between Dev and Ops. “Its not my code, it’s your machines” vs. “It’s not my machines, it’s your code.” The DevOps movement’s motto (unofficially) states “Developers that think like Ops and Ops that think like Dev.” This is indeed necessary, and involving Ops early in the development cycle is one proven method to improve collaboration and processes. Using advanced configuration management solutions such as Puppet and Chef by Ops also helps greatly, but we won’t be “home free” until we tackle the last mile, that 80%.
Fix Deployment and You’ve Fixed (most of) DevOps
The only way to reconcile speed and control is automation. And as application changes have brought about the biggest challenge in IT, so will automating the application delivery process, end-to-end fix the biggest challenge in DevOps. Application Release Automation (ARA) technology is the sure way forward in the transformation of the way Dev and Ops hand over applications between them and collaborate. ARA provides mechanisms for packaging software artifacts and tracking them between Dev and Ops, Visual automation workflows that Dev creates and Ops controls and a model that lets them collaborate effectively to deliver applications to production in a continuous way. ARA is the key to DevOps (i.e. the last and most critical hurdle), as it fixes the biggest pain-points in Dev and Ops collaboration.
About the Author
Wesley Pullen is Vice President of Global ARA Technologies for UC4 Software. To learn more, please visit www.uc4.com.
Latest posts by Guest Author (see all)
- Search stole the customer experience; AI is your chance to get it back - May 4, 2015
- Understand Hadoop’s limitations in order to realize its full value - March 5, 2015
- Why graph databases are perfect for the Internet of Things - February 24, 2015