<img src="https://certify.alexametrics.com/atrk.gif?account=VdU0q1FYxz20cv" style="display:none" height="1" width="1" alt="">
Embotics Cloud Management Blog

A Checklist for Mapping your Cloud Management Implementation

MApping your Cloud Management ImplementationCloud management is a critical business operation, but few organizations have the time or expertise to build a cloud management program that meets not only today’s needs, but the rapidly changing needs of tomorrow.

The benefits of cloud management are clear: increased scalability, flexibility, availability and productivity. When embarking on your self-service provisioning implementation journey, it’s crucial to ensure that whatever you implement, your cloud infrastructure seamlessly integrates into existing systems and processes. You’ll also want to leverage the automation and APIs of complementary tools that you may already own and deliver broad multi-vendor support as well as an extensible architecture.

Managing your cloud environment calls for IT organizations to work with business units to ensure their needs and expectations are met and that your cloud resources remain visible, trackable, and adhere to your corporate governance policies and best practices.  

Too often, building a sound cloud management program doesn’t happen smoothly, but there are steps you can take to ensure a successful transition. In reality, cloud management challenges are met on a reactive basis by organizations. And these ad hoc solutions can lead to cloud management implementations that result in duplicate capabilities, nonstandard approaches, process inefficiencies, and the creation of shadow IT.

If you’re the driver behind the implementation process, you can show that IT provides inherent business value and will be an enabler to the business, ensuring cost savings and efficient use of resources while also providing clear and accurate insight into IT costs and service levels.

We’ve developed this cloud implementation checklist to make introducing a Cloud Management Platform (CMP) successful:

How to Implement Cloud Self-Service ProvisioningLet’s look at each of the steps in detail:

Identify and categorize your user groups and organizations (tenants/departments/projects), determine the resources required for each organization and, if so desired, set quotas.

Organizations form the basis of a multi-tenant model and consist of a group of users with a common business purpose. By taking the time to create organizations within your environment, you can:

  • ensure that user groups can access only the resources assigned to them
  • set up distinct cloud automation configurations for your user groups
  • delegate administrative tasks to consumers, allowing you to lighten the load on the CMP administrators

Organization membership affects what each user sees and what they can do in the Service Portal.  Each organization can have distinct service ownership and configuration. You assign an organizational role to each user, and if required, you can make the members of multiple organizations have different roles within each organization. For example, a user may need a Delegated Admin role in one organization, but a Customer role in another organization.

If a user requires visibility of VMs and other services across multiple organizations at the same time (for example, an IT admin), they can be assigned an individual role outside of an organization. 

Once you have established the organizations and placed users into them, you can then consider setting quotas. Quotas allow you to limit the compute resources granted to an organization, so you can assign available resources to your consumer groups based on their business requirements.

vCommander Quota ConfigurationQuotas can be either resource-based, limiting the number of vCPUs, the amount of RAM and the amount of storage that can be provisioned by an organization (or more granularly members of the organization), or cost-based, allowing you to limit the daily cost of the VMs for an organization and its members.

Once quotas are assigned, you can use them to determine whether a service request (both new services and change requests) can be approved. For example, you may want any service request that exceeds an organization's quota to be rejected automatically. Or, you may want a second level of approval for requests that will exceed quota.

Determine whether your user groups and organizations fall into the default cost model or if they will require their own pricing structure.

Most CMPs provide default cost models, which contain distinct CPU, memory, storage, operating system, support and custom costs. These models allow you not only to assign different costs to high-end versus low-end compute resources, to different hypervisor platforms, or to different groups of consumers, but also to generate historical information that can assist you in managing your virtual infrastructure resources.

vCommander Cost ModelsTo ensure that you’re correctly representing the costs that a particular organization or team are consuming, it may be necessary to create custom pricing structures. These may represent additional IT support costs, backup costs and software application licensing costs.

What service catalog offerings do they require, and what should the request form look like for each?

Different organizations, and even users, will probably require different methods for provisioning new systems. These differences are typically not limited to provisioning methodologies. For example, approvals, machine naming, network configuration, resource allocation, service levels, resource location, and the management functions users can perform after machines are provisioned, are just a few of the hundreds of attributes that can differentiate services provided for different businesses.

vCommander Service CatalogThe ultimate goal of the service catalog is to be the link between the enterprise and the IT Organization. So it’s important to spend time with each group to understand their needs, and ensure that the systems placed within the service catalog correctly represents the provisioning requirements. You’ll also want to ensure that the provisioning forms contain only the options that are required rather than overloading the forms with unnecessary selections that would slow the provisioning process down, or create wasted resources.

Define placement rules. Where, by default, should workloads be provisioned based on the requesting user group and organization?

The needs and goals of each organization differ. This makes it impossible to adopt a one-size-fits-all cloud strategy—or even the same strategy for each workload within an organization. It’s important to understand the workload attributes unique to each organization, such as:

  • Performance
  • Security
  • Integration
  • Data volume

You’ll also need to consider any cumulative impacts that the placement decisions may incur.

Other non-technical factors that may affect the placement decisions include business considerations, such as: the primary use cases that need to be enabled or enhanced, the time to market, agility, and any legal, regulatory or organizational governance requirements.

What is your default naming convention for VMs and services? Is there one per user group and organization?

A critical foundation for your cloud governance initiatives is that of tagging your cloud resources and creating a consistent naming convention that you can apply globally across all of those resources. A naming convention that adds metadata specific to each organization helps you better categorize the cloud resources for cost allocation, reporting, chargeback and showback, cost optimization, compliance, and security.

Automating this naming convention avoids individuals using variations of the tags, which can make it difficult to achieve accurate reporting. A good place to start with naming is to include the environment that the resource is to be used in (dev, prod, stage, test), the operating environment, the billing center (cost center, region, owner, etc.), the application it is to be used for (app, service, etc.), and any compliance or optimization tags (hippa, data residency, etc.). So, for example a system with the following criteria;

  • a development system on a windows server
  • for a medical application
  • placed in a European datacenter
  • by cost center of 8660

Could be named : Dev-win2k-8660-Medapp-Eur.

This naming is automatically created based on the information gathered from the service provisioning form and can use any custom attributes that have been configured to form the name. This avoids the need for users to type in any information.

What approval workflows are needed? Are they conditional by size restrictions or cost?

The request and approval process is often one of the primary efficiency bottlenecks in self-service environments. The problem is that supervisors and managers tend to be busy. A time consuming or manual approval process might get placed on the back burner in favor of more pressing tasks, and that’s only amplified when multiple approvals are required.

Tasks such as creating requests for new virtual machines, and getting those requests approved are best handled by an automated process. This is especially true for requests requiring chains of approvals from multiple people, where you can simplify the process to the point that approval requires nothing more than clicking on a link within an email message.

vCommander Workflow StepsIf quotas have been set up for organizations or individuals, the process can be streamlined even more with the automated provisioning request that requires no approval, as long as the request is within quota for either the cost or the resources.

What types of post-processing (for example, network settings, adding the VM to a domain, installing software, and/or agents, etc.) are required?

Automation doesn’t stop with request approval. CMPs can automatically deploy approved service requests with their relevant components after the deployment of a new service request, or after fulfillment of a service change request.


Automated tasks include:

  • Assigning IP addresses
  • Installing operating systems and patches
  • Installing any required applications, including network security applications

These workflows allow you to carry out tasks such as connecting together multiple components (e.g. a database server, a web server, and a tomcat server) and configuring and assigning IP addresses to them all, or updating a CMDB that the new VM is available.

Who (administrators, superusers, managers, etc.) should receive notifications when a service request is made, approvals are required, VM/service expirations are about to occur, etc., and when?

As already discussed, there can be a lot of planning involved around correctly establishing approvals and pre-provisioning workflows, which may be triggered when new service requests and change requests are made by users. However, although these can help manage the service and change request processes, you still need to clearly define:

  • who needs to be notified when a request is made?
  • is that purely just a notification, or is approval required?
  • is the requirement for an approval based on a condition, such as:
  • does the request push the user/organization beyond their quota limit?
  • does the cost of the request require their manager’s approval?
  • does the amount of resource requested need IT’s approval?
  • who needs to approve the request; is that a single person, or a group of people (where anyone in the group can approve the request)?
  • are approvals from multiple people/groups required?

The same type of action definition is required for services/VMs that are reaching their expiry date, establishing who should be notified, whether users are allowed to extend the expiry date and if so how many times, and whether or not notifications/approvals are required for extensions.

 All possible requirements need to be discussed by the business teams involved, and may need to be defined per organization, group and/or user.

Are any custom attributes required for provisioning, billing, picklists, organizational identifiers, etc.?

Custom attributes allow you to provide more management information about your virtualized infrastructure. These can be designed such that budget or profit center code information for a VM or an asset number for an infrastructure element can be applied and then used in reporting, in workflows and in script execution.

vCommander Custom AttributesYou can also create relationships between attributes used on service request forms, so that the value selected for one custom attribute affects the selectable values for one or more other custom attributes. Creating these relationships means that you can prevent requesters from making invalid form choices.

Is change management, configuration management, lifecycle management, and/or capacity planning required? If so, what information is needed?

A cloud management orchestration engine provides an easy mechanism to automate changes for both production and engineering instances. This allows you to have strict controls around who must approve changes, and who can schedule changes to occur in a pre-defined maintenance window or alternatively have more lenient controls for some workloads. For example, automatically performing any requests to downsize an instance, but enforcing approvals for instance upsizing or when requests exceed any pre-defined resource or cost quota.

There are also tangible costs associated with creating a virtual machine. Implementing automated lifecycle management will alert administrators and owners as the expiry date approaches and provide one-click ability for owners to extend the VM’s life if necessary. So again, it’s important to sit down with the key stakeholders and establish the correct defaults for expiry of different workloads, or who can automatically implement rightsizing recommendations and changes to configurations.

Summary

As ever, technology should be deployed with a clear business purpose behind it. Too often the IT department takes a technology-oriented approach and focuses on the “what” without considering the “who” and “why”. 

A CMP that is providing self-service is ultimately exposed to end users, and so IT needs to take an “outside-in” approach to the process of adoption, and place themselves in the end-users’ shoes, ensuring that the configuration options created throughout the steps outlined above meet the end-users’ needs. This allows users to truly provision for themselves wherever possible. They’ll appreciate it, and use the system to its maximum, taking the load off ITs shoulders.

If you would like to see a customized demonstration of of how easy it can be to implement a CMP, and roll out self-service provisioning, schedule a demo with one of our Solutions Architects today.

Request Demo

Topics: Service Catalog Self-Service Provisioning Workflow Cloud Management lifecycle management