Whether working with bare-metal servers or virtual machines; provisioning applications and infrastructure traditionally are independent tasks that are completed by different data center teams. Infrastructure is usually provisioned manually. Applications are customarily provisioned via golden templates. As customers look to move automation beyond infrastructure to include applications, the maintenance complexity and manual “last mile” configuration associated with application golden templates is no longer a sustainable solution.
The situation has made Puppet and Chef popular. Both assist with automating the infrastructure life cycle as well as rapid application deployment. But some system admins prefer to use Puppet. Some prefer Chef. Cloud admins want to use Amazon, vCloud Director or OpenStack. What to do?
Cisco lets you use either or both and makes it easier to automate application delivery thanks to the Cisco Application Stack Accelerator for Intelligent Automation for Cloud (IAC). With this cloud accelerator, those “last mile” deficiencies are practically eliminated.
Bringing together the knowledge of infrastructure and application specialists, this solution automates the design and configuration of application stack components. The result is an application blueprint that consistently delivers applications within minutes, across multiple cloud platforms, to the exact design and specification of the application architect.
Watch these two videos to better understand application blueprints as well as how they can be consumed by Cisco IAC.
Video #1 clarifies what an application blueprint does and how to design and configure them
Video #2 walks you through how to deliver fully configured multi-tier cloud applications with Cisco IAC
Why is this important? Customers tell us that they struggle with multiple requests for virtually the same application. One particular customer, discovered that they had 250 requests for the same application in a two month period. Each one of these requests took IT four to six weeks to deliver before the project could begin. This not only shows down IT but your business as well.
Using Cisco IAC and the Application Stack Accelerator, you can automate the design, configuration and consumption of applications via the Cisco IAC portal. The result? Customers get their application within 30-40 minutes instead of four to six weeks resulting in projects starting sooner. IT spends less time spinning up multiple versions of virtually the same application allowing them to focus on new innovative services. Bottom line: your business experiences agility, speed, and efficiency.
Industry analysts forecast that four out of every 10 companies will be utilizing a private cloud by the end of 2014. With cloud automation becoming this prevalent, you owe it to yourself to learn how Cisco IAC and the Application Stack Accelerator can speed up the design, configuration and consumption of applications within your organization.
Together, this solution can help you deploy applications efficiently; reduce complexity and ensure that applications are deployed to the architect’s exact design and specification.
A number of key applications consumed by businesses through premise-based deployments are now available from the cloud. Irrespective of where you are in the evolution to the cloud, here are five services that are worth your attention.
The Cisco IT Elastic Infrastructure Services program, or CITEIS, is our internal implementation of Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) resources in a private cloud. CITEIS is designed to provide a consumer-type IT experience to our developers while Cisco IT maintains governance and control over the infrastructure. Read More »
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.
Recently, I wrote an article on PaaS for IT BusinessEdge entitled the road PaaS, understanding your post IaaS options. Here’s an excerpt.
The Road to PaaS
PaaS is an enticing proposition that has generated a lot of market buzz.
But PaaS forces tradeoffs and it shouldn’t be seen as a one-size-fits-all proposition.
To understand, I like to draw the distinction between what I call “Silicon Valley PaaS” and “Enterprise PaaS.” The majority of the discussion in the market today revolves around the Silicon Valley PaaS pattern, which is a truly abstracted “black box” approach to software platforms.
This form of PaaS exposes a set of standardized services to which you write your applications, completely sheltering developers from the underlying complexity below the PaaS abstraction.
It makes a lot of sense for brand-apps built with modern frameworks like Python and Ruby in greenfield development environments that are highly standardized.
The basic premise of the post is that PaaS for an enterprise is VERY different from PaaS for a Silicon Valley start up. And nowhere is it more different than in the network requirements.
The PaaS customer is a developer who will code an application, use the underlying services offered by the PaaS stack, such a database, storage, queueing, etc. The developer deploys the code, selects a few options and code is live.
So what’s going on with the network? Well, the PaaS layer will need to auto-scale, fail-over and deliver performance at some level. It may need it’s own domain as well. That PaaS layer will need to talk to underlying network services such as firewalls, switches, etc. That PaaS really needs access to infrastructure models that deliver network containers to whatever PaaS abstraction the PaaS layer has.
Hard enough to do when all the containers are the same, as it would be in a Silicon Valley PaaS offering.
It doesn’t work with the existing enterprise platforms. This is a big opportunity for innovation