Welcome!

XML Authors: Michael Bushong, Elizabeth White, Jason Bloomberg, Jayaram Krishnaswamy, David Weinberger

Related Topics: Virtualization, Java, XML, SOA & WOA, Cloud Expo, Apache

Virtualization: Blog Feed Post

How to Stop Running the Project Gauntlet of Doom with DevOps

RedHat puppetizes its infrastructure to reduce inefficiency and streamline deployment

I could cite various studies, pundits, and research to prove that automation improves the overall success rates of continuous deployment efforts, mitigates outages caused by human error and misconfiguration, and generally makes the data center smell minty fresh, but we already know all of that. It's generally understood that there is a general need for devops, for continuous deployment and lifecycle management systems enabled by frameworks like Puppet.

What we don't often consider is that the process of "puppetizing" production (and pre-production) environments affords organizations the opportunity to re-evaluate existing network and application architecture and eliminate inefficiencies that exist there, as well. Many an architecture has been built upon legacy application network infrastructure, for example, that cannot be – easily or otherwise – puppetized and thus serves as an impediment to realizing the full benefits of operational automation.

Sure, you could automate everything but those components that can't be integrated, but that leaves open the possibility for misconfiguration, for fat-finger errors, for fragmentation of ownership that is often the source of delays in moving releases through various environments and into production. RedHat, for example, maintains 4-7 pre-production environments through which it used to take 2-6 weeks to cycle a new release. Part of that time was caused by what RedHat veteran Bret McMillan called the "Project Gauntlet of Doom", which required collaboration across an increasingly fragmented set of groups responsible for managing the manual configuration of various infrastructure components – both hardware and software.

What the fine folks at RedHat discovered when they decided to puppetize their environments to eliminate the fragmentation was a great deal of inefficiency in the existing architecture. Multiple tiers of proxies performing fairly standard application networking functions: SSL termination, header manipulation, compression, URL rewrites and redirects and, of course, load balancing. Approximately 10% of the virtual machines in the infrastructure were performing what RedHat considered "low business value" functions – primarily because business (and end-users) don't directly realize the impact of such services, only the end-result of performance, security and availability.

What they found was that they could (1) consolidate 3 layers of services, (2) puppetize their entire environment, and (3) eliminate service-ip sprawl caused by the growing demands on IP addresses required to scale out its proxy layers. In other words, the desire for process automation through DevOps led to a streamlined, more efficient delivery architecture that benefitted operations, customers, and the business.

red-hat-old-new

Because BIG-IP could provide an integrated service platform upon which multiple application-layer services could be deployed, the need for multiple layers of proxies and load balancers was eliminated, reducing the number of devices through which traffic had to traverse. Performance improved, as did the consistency of operations both by providing a common, integrated platform management interface at the BIG-IP for all application network layer services as well as through Puppet for configuration and continuous deployment management.

It's a win-win that effectively eliminates the need to run the Project Gauntlet of Doom during release cycles because Puppet automates the processes and eliminates the manual collaboration previously required. The end result is faster … everything, across the board.

A presentation from PuppetConf 2012, "Managing F5 LTM with Puppet - Matthew Carpenter and Bret McMillan of Red Hat" is available in video format, including greater detail and color commentary.

Happy Automating!

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.