Enterprise Platform as a Service

Deploying Multi-Tier Application Stacks with Puppet and Chef

In a previous Cisco Data Center blog, we announced our configuration management accelerator for cloud to enable organizations to move beyond monolithic golden templates into a dynamic TOSCA-modeled application design canvas. Cisco Intelligent Automation for Cloud (IAC) has been working for months with PuppetLabs and OpsCode (Chef) and has had multiple successful customer proof-of-concept deployments.

The Cisco configuration management accelerator provides customers with a substantial improvement over the manual process of building and implementing multiple golden templates to build multi-tier application stacks. The application stack is now described, and the description drives implementation.  Changes to the description apply to all future instances, and can even update running instances in continuous delivery scenarios. The benefit is that the description becomes the master plan and machines are consistently and automatically constructed from that master plan without intervention by IT. Software defines the application configuration.

Cisco’s cloud accelerator approach is true to an open philosophy that provides customers with a choice of solutions – not locking them into a single hypervisor, configuration tool, solution path, or even hardware selection. The configuration management accelerators follow directly in the footsteps of our multi-cloud accelerator released last year.  That accelerator enabled Cisco IAC to provision, orchestrate and manage VMware vCloud Director, Amazon EC2, and OpenStack. It has also been extended by customers to include Hyper-V, Azure and Rackspace through the preplanned extensibility built into it.

Our strategy has been to do the same for configuration management. Tools like Altiris and System Center Configuration Manager have been working on the configuration management space for well over a decade through heavyweight configurator tooling. Newer platforms like Puppet, OpsCode Chef, CFengine, Ansible, Salt and others are moving to more descriptive terms, and are putting these into a code repository where they are stored, versioned, forked, and used to configure running systems. It’s an historical software-development paradigm applied to defining compute and application components of the datacenter.

This release of our configuration management accelerator will support Puppet and Chef and is designed to be extensible for other configuration tooling, and we are talking to some partners about adding to it quickly.  We chose Chef and Puppet for the first release because of their leadership in the software-defined application configuration space. Let me give an example that illustrates why we are doing it this way: Cisco IT chose to go with Puppet for our internal deployment, but what happens if Cisco acquires a company that had made a significant investment in Chef? Cisco has been known to buy companies… Even if your organization isn’t as prolific an acquirer as Cisco, it just takes one acquisition to make managing software configuration standards across the post-merger company a nightmare. Or it could simply be that one of your department likes to use Python scripts despite the fact that you’ve deployed and evangelized Chef. So we designed our solution to be able to use either. 

…Or both simultaneously

…In the same virtual datacenter

We didn’t think that an acquisition of a repository of configuration definitions, or a decision to change between configuration tools, should completely destroy the value of the investment already made in the prior platform.

As mentioned above, Cisco IAC’s configuration management accelerator uses TOSCA-based models to define whole application stacks, including the networking connectivity between virtual machines. To make this easy to use, we are bringing out a new drag-and-drop graphical interface to aid in authoring these high-level application models that can be ordered through Cisco’s industry-leading service portal.

But this accelerator is not just about configuration. There’s a process to consider here. Click on the image.

It starts when IAC automatically inspects the Chef and Puppet repositories for available system blueprints. A cloud administrator can view these and approve them for use in application stacks. Once approved, the blueprints are available to application stack designers as icons to drag into the canvas shown in the screenshot above. During this creation phase, the stack designer can place constraints around parameters so that some can be safely exposed to the end users while others are completely hidden and determined programmatically.  Cisco IAC streamlines and automates the vetting and approval process and once approved, blueprints are released to end users for their consumption.

The end result is that whole application stacks become simple items to safely order from our industry-leading service catalog.

But aren’t those blueprints a lot of work to write?

In a session at VMworld this week, VMware mentioned vCAC integration with Puppet and PuppetForge as a source of configuration images. Out of the gate, their users will have access to thousands of Puppet scripts built by the community, which sounds fantastic, and absolutely validates the approach we took.  We just have a different perspective on relevance. The public repositories (PuppetForge, Github, etc.) make their respective tools viable because these repositories are the key to not having to author everything from scratch.  At the same time, only the simplest and probably least valuable blueprints can be downloaded from a public repository and used without modification. Does it have the right parameterization? Does it make assumptions about the available LDAP directory that are not valid in your environment?  Did the author gracefully handle error cases that are unique to your environment? Often not. Our focus has been on the enterprise internal repositories rather than the public ones. The enterprise’s repository is the superset of its own blueprints plus the relevant, customized ones downloaded from the public repositories. In other words, the enterprise repository will likely not have as many blueprints as Github, but will have the ones that matter to the enterprise. 

IAC’s solution inspects one or more enterprise repositories (remember the corporate acquisition point), and exposes services based on those blueprints via the process I described earlier. The result is that only the relevant subset of the applications available from the public repositories show to the stack designers and end users, without thousands of “noise” items.

Oh, yeah.  Hardware.

Cisco is still a major hardware company, and our customers still care about hardware in addition to virtualized infrastructure. Puppet and Chef have no problem configuring bare-metal servers, so why should the cloud management platform?  IAC already does bare metal as well as virtual for IaaS.  Furthermore, in between virtualized network devices, you will usually find physical network devices on which multi-tier applications depend. As our customers’ cloud environments grow in usage, they grow in how dynamically they need to change. Preprovisioning physical network and storage resources for virtualized cloud use cases gets to be a much bigger job when users are ordering more than just virtual machines, so automated physical provisioning becomes more critical. The application stack models may not have an awareness of the physical or virtual nature of the hardware, but the provisioning platform better know what to do when consuming the TOSCA models. If the application stack requires physical provisioning, IAC will do it. Our customers would expect no less from us. We expect no less from ourselves.