Your Cloud Journey and Roadmap with Intelligent Automation for Cloud (Part 3 of a 4 part series “Who moved the IT cheese while I was getting production back up?”)
(with contributions from my teammates Mike Eisenstein and Jim Kao)
This blog guides you through the considerations after you have taken the first step in your Journey to Cloud with the Cisco Intelligent Automation for Cloud Starter Edition.
Once you have deployed the Starter Edition, you can take some time to experience the benefits and begin to start noting where you need your company’s cloud roadmap to go next. What are the key things that you, your business, your users, and your operations need to take them to the next level? Many of these will be in the next edition from Cisco, others will require building an integration into a system that is critical such as your ERP environment to enable chargeback. Let’s break the discussion in some key areas:
Starter Edition works with UCS and vCenter. While Cisco would like to see your entire datacenter filled with UCS and Nexus, we do realize that you may have other vendors on your approved buying list. You may decide you want to leverage your Cloud Portal, Process Orchestrator, and Server Provisioner across a number of computing hardware vendors. We have customers who provision both physical and virtual servers across Cisco and other vendors. It is one of most common heterogeneous integrations that we do. This allows the end user to order compute as a service with little regard to which flavor the physical server is.
vCenter is supported in the Starter Edition. Cisco’s Intelligent Automation strategy is to support over time any number of hypervisors. This can include HyperV, Linux, Xen, and KVM as well as proprietary flavors of Unix such as those from Oracle, HP, and IBM. If the virtualization layer has an API and we can perform lifecycle management of the virtualization construct, then IA for cloud can be used to provision virtual resources. Many industry verticals have large concentration of IBM, or HP, or Oracle. IAC can work with these environments very easily. If you need your cloud to run on vCloud Director, Openstack or other virtual machine manager above the hypervisor, you will need the IA for Cloud 3.X edition.
Starter Edition supports simple assignment of organizations to pre-provisioned vLANs within a flat network. Many first-phase private clouds will work perfectly well with this topology. Simple private clouds in their second-phase, and companies with more complex structures will likely want to segregate network traffic across different network containers. You may want to do this within your enterprise or you may be a service provider looking to offer different cloud services to different customers with complete traffic separation. The next edition of IA for Cloud 3.1 will support basic network automation and the minor release after that will support tenant controlled network container provisioning and lifecycle management. This of course works first on a pure Cisco network, but development is already underway to support heterogeneous network architectures through a combination of native product support and SDKs that will support abstracting multiple vendors’ network products.
The Starter Edition assumes that storage allocations are managed by vCenter. Oftentimes the next step is to provision storage volumes or LUNs, and related network constructs on the fly as infrastructure is being provisioned. Let’s separate day 1 storage configuration from day 2 and beyond lifecycle management of storage. Many storage vendors have tools or APIs that can accomplish day 1 and day 2 storage provisioning. Not everything you can automate is worth automating. Automating Day 2 and beyond storage lifecycle operations is critical for IaaS. Your choice of storage can range from EMC (and vBlock) to NetApp (and Flexpod) to Hitachi Data Storage, to 3Par and other storage vendors. Most if not all have well formed APIs or command lines than can be used to provision as needed.
Application (and the OS)
Why do our users need these virtual or physical servers? It is invariably for the Application. Many customers place a high priority on image management and configuration management of the provisioned systems. Image management, in our definition, includes the creation of the basic image (Operating System and Application components), and management of the “coarse grained” representation of that image. An example might be this version of JBOSS on top of that version of Linux. We define configuration management as the “fine grained” control of the actual configuration state of those OSes and applications. Some solutions do both of these within the same product. We see them as two separate but closely related disciplines. A cloud solution that allows an end user to create an image from a library of components like one would design a car on an auto-dealer’s web site offers flexibility and self-determination that end-users greatly appreciate. Of course after that there are the system admins who will want to control the configuration state of that image. We have customers do both of these, integrated into our cloud automation solution, including standards libraries.
Cloud Operating Model
The Cloud Operating Model we refer to here is how your cloud runs and serves its client base. It stands above the platform software implementing the service catalog, self service, service item, resource pools, and orchestration. A good example would be the lease management capability of Starter Edition. Other examples would be subscription limits by customer/organization type, or specific enhancements around lifecycle management of resources. Another large change in operation model would be the ability to provision an n-tier application across 3 network tiers with a single push of a button. Alternatively it might be fulfilling the request of “I need 4 servers of this type” with one self-service offer. The 800 pound gorilla of cloud operating model is the virtual data center. Cisco IT, being a visionary, implemented this construct within two months of, and on the same infrastructure as, its first private cloud built on IAC. This Operating model construct allows any organization (or individual — an organization of one) to reserve a set of cloud resources for use as they need it. The virtual data center operating model means that they pay for these resources whether they use them or not. At Cisco we have over 80 virtual data cetners running in our cloud. This is a very powerful construct that can keep business-unit IT and end-users from going off in an uncontrolled way into the public cloud. Generally the operating model of your cloud is very rich from a functionality point of view and hence is harder to pre-package into an out of the box product. Many enhanced elements of the cloud operating model will be built into our next edition; others will await you and your services provider to implement your specific needs.
IT Operational System Integration
Remember to leverage what you have learned over the past 20 years in IT operations management. Integrating into the CMDB and ticketing system for incident, configuration and change management is critical to shops that are ITIL (or variant) compliant. The Starter Edition has “change management points” that make it easy to do some of this and we will continue to intelligently build the integration points to hook into and automate your favorite systems. One key example is monitoring or service assurance. Being able to monitor and show that the cloud resources are performing well are key, as well as being able to identify what end user services are impacted when performance degrades. These integrations are important because you may be driving other IT operational processes and your cloud should not live outside of those (at least not past the first 3-6 months of using the Starter Edition).
Business System Integration
There are those who say it is not a cloud if your self service click does not have a price associated to every change or consumption unit. This may be right, but many shops are not yet ready for charge back. More common is to spread out the IT spend uniformly and then have a few key areas have variable charges. If you are an enterprise you may be more interested in just simply showing the end users, their managers, and key upper level roles who is consuming what. This is called Showback. After this you may want to do some form of Chargeback where the individuals or business units are charged with the responsible cost. If you are a service provider you take this a step further with Billing. Key in thinking about this area is 3 core concepts: Metering, Rating and Billing. Metering is where the cloud system keeps track of who orders what and uses how much, similar to that meter on the side of your house, the one that may be “smart” now. After you have the raw data that shows who ordered what, you can then apply a rating table against that consumption data and come up with a daily, monthly, quarterly or yearly economic charge. Finally you take that charge and get your end user to pay through the lifecycle of billing, including funding source (aka credit card or purchase order) and all the downstream issues such as reconciliation, etc. There are many solutions in this space that Intelligent Automation for Cloud can integrate to including on premise (deployed in your datacenter) or out in the cloud (such as billing handled through a cloud SaaS billing service).
Portal Views and Roles
As you explore the Starter Edition and the 3 roles it came with (end user, cloud admin, and organization admin) and the portlets and tabs in the product, you may realize you would like more views of resource availability or consumption or other roles that match your organization model. Many of these portlets and roles will come in the next version of IA for Cloud, but some that are specific to your organization will require you to get your creative hand out and innovate/build, or locate and customize JSR portlets available from the open source community.
Hybrid clouds are a very powerful concept. We see that many IT shops are primarily looking at private or public cloud as a key driver for their first moves into cloud (driven by different tradeoffs of security, speed, cost, etc…), but are very interested in the capability of running a hybrid cloud. Being able to place workloads into different clouds is something that will grow in importance. Perhaps a company would like to burst out into a public cloud provider when they run out of space in their datacenter. It can be compute, or just storage that is burst out. Most public clouds have well formed APIs and the integration into those services is very straightforward technically, but it requires clear thinking around the governance and policies around when you move workload outside the firewall or back into the firewall. Will you take advantage of IaaS pricing arbitrage and save a few pennies per hour? This is up to you, the technology can accomplish this when your business is ready to leverage this model.
Platform as a Service (PaaS) & Application as a Service
We see two core use cases here. One is what we call Silicon Valley PaaS, where developers (Not just in Silicon Valley) write applications that scale themselves as needed within each of their services or tiers. The application will call out the IaaS API and automatically spin up say a dozen more instances of their web server when the application senses it needs more capacity to handle the user load. In this use case, the cloud operating model needs to have an API that can be used for the application to drive. IA for cloud has an API that can be used here and we will be enhancing that API over the next few release to meet the needs of PaaS on IAC’s northbound side. The other type of PaaS is what we call Enterprise PaaS, also known as enterprise applications as a service. Many IT organizations are not yet at the point where developers are controlling infrastructure through the API, but just need Websphere, Databases, or Sharepoint provisioned as a Service when needed. This is applicable within the enterprise as well as within a service provider commercializing a variety of applications in a SaaS offering. In this situation you take our IA for Cloud solution and add in image and configuration management and then top that off with some enhanced services and ordering portals and you have Enterprise PaaS, AaaS or SaaS depending on your definition. Our hyper-extensible nature makes it easy to drive the solution architecture to meet your needs.
There is a lot you can do in your cloud. This is because you are not just automating data center resource provisioning, but that automation, self service, and new operating model allow you to change the way you look at and run your business. This can seem like a multitude of possibilities and it is. They key next step is to start from your corporate objectives and derive the key drivers for your cloud. With those key drivers, your trusted advisers, Cisco Product and Service organization and / or your delivery partners can hold a workshop where all of these business, technical, operating, and functionality drivers are discussed and architected into a model for your cloud. This would include your cloud roadmap of functionality, key use cases, integrations, and how that would build out over time. Cloud is not a one and done, but a journey.