F5 Friday: How to Stop Running the Project Gauntlet of Doom with DevOps
#devops #video #puppet #stack 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.
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!