Cloud Operating Model – How Does Your Cloud Run?
Wow, lots of excitement this week with all the news in the cloud space. All very interesting and very much validating of the work that our Intelligent Automation Solutions Business Unit is doing around automation of the cloud. Now on to actually showing ROI right now for your CIO.
We in the Cisco Intelligent Automation Solutions Business Unit define the cloud operating model as a set of behaviors that define the operational characteristics of your private or public cloud. Our Cisco Intelligent Automation for Cloud models a private cloud operation through a set of behaviors around the following areas:
- Catalog of Services
- Tenant / Organization Model
- Site / POD model
- Lease/Capacity management
- Network Segregation
- Lifecycle management
- Administrative capabilities
- Image Management
- Storage and Network Automation
Let’s take a look at each of these items and show how this work in our Intelligent Automation for Cloud Starter Edition:
Catalog of Services:
In the Starter Edition we have the concept of 3 core services (Provision a VM, Provision a VM and PXE boot it, and PXE boot a physical server). We find these basic single VM and physical services are critical to the early “crawl” stage of a cloud. The catalog can be the same across all “consumers” or allow variation across organizational / tenant constructs. In the Starter Edition, we have implemented a single catalog across all the organization units.
Tenant / Organization Model
The tenancy model of a cloud is a critical design time consideration. The Starter Edition is targeted for a single company, with any number of organizations to which end users can be assigned. The Starter Edition is not build out of the box for a multi-tenant cloud (although many of our customers extend the Starter Edition into multi-tenant environments. My next blog (with a guest co-author) will go into this in much greater detail)
Site / Pod Model
A cloud needs to have a deployment model that aligns the functionality with the infrastructure model. The Starter Edition is set up for a single UCS POD and single vCenter instance. This in effect limits the Starter Edition to a single site, which is perfectly fine for most IT shops starting their cloud journey.
Ensuring that once a VM is “spun up” that it is not lost for good and consume capacity when perhaps it is no longer needed is a top of mind concern of many cloud architects. In the starter edition the lease management is accomplished by a choice at order time (or through lifecycle services) to have a specific time for the lease of the particular VM or physical server. What happens to the end user as they approach the lease termination point is two reminder emails at pre-set times before termination. In addition there is a period post termination where the VM is powered down and only a lease extension can “reactivate control”. After the final expiration time the VM is then deleted. Capacity management is indeed a complex topic with many levels of consideration. The Starter Edition has basic capacity management in that the self service and automation framework cannot provision over the top of the pool of resources available. We also show resource utilization in the Starter Edition cloud through the System Resources console.
Different organizations (and tenants) may require some form of network isolation. Sometimes a single flat zone for an R&D cloud is good enough. Sometimes you want separation by organization or by tier in the application. If you are a service provider, you may require complete virtualized network separation through a highly functional and differentiated network container. Since the Starter Edition is focused on the entry cloud for enterprises, we have implemented a multi-organization cloud through assigning network VLAN to specific organizations in the cloud.
Our starter edition cloud has 3 basic roles: cloud administrator, organization administrator and end user. Obvious the operating model gets more complex as you move toward unified infrastructure management (pod administrator), multi-tenancy (tenant administrator), and business centricity (business account manager).
Those end users will demand the ability to control the state of their infrastructure. Lifecycle management that provides the self service is critical to the low cost nature of end users controlling their resources.
Making a cloud easy to manage from an administrator perspective is critical. This extends from installation wizard, to post installation administrative console for changing the configuration of the cloud.
Image (and Template) Management
This is a fascinating area of standards. When you think about designing your cloud operating model, do you want to maintain a standards library of images (OS + application) and limit the options available to end users, or do you want to give some the ability to build images and load into the cloud, or do you decide to make it wide open and give the users the ability to create their own images in a self service fashion. In the Starter Edition we begin with the administrating controlling the library of images and other key templates available to end users: a great place to start gaining control of image sprawl.
Storage and Network Automation
Full Infrastructure as a Service requires Storage and Network automation to support the rich set of services in your private cloud. However, many cloud program entry points can be very successful based upon pre-provisioning storage and network. Over time and with the move to multi-tenancy you will want to perform the storage and network automation and self service.
With this blog about cloud operating model, you can see the nuances and some of the simple but yet very impactful decisions you will need to make about your operating model. Stay tuned for my next blog on multi-tenancy.Tags: