Introduction If you’re thinking of implementing a private/hybrid infrastructure as a service (IaaS) platform, then one of the key considerations is how to operate the platform. I’ve been researching online to see if there are any industry standards in this … [More]
By Dan Card 119 0
IntroductionIf you’re thinking of implementing a private/hybrid infrastructure as a service (IaaS) platform, then one of the key considerations is how to operate the platform. I’ve been researching online to see if there are any industry standards in this area and have found any detailed analysis to be lacking. VMware and IBM provide some guidance which appears to be aimed at a policy and people perspective, but I’ve not found much that describes these activities at the process and procedural level. In this article I’ll explore the creation of a virtual server on a private cloud tenant to see how this fits in with ITIL guidance when considering change management. The word Cloud can be used to describe a number of different solutions. For the purpose of this article we are looking at Cloud from an infrastructure perspective. VMware’s definition of cloud computing (one that I and the industry seem to agree with), has the following characteristics:
- Resource on-demand
- Pay for what you use
- Accessible as a loosely-coupled service
- Scalable and elastic
- Improves economics due to shared infrastructure and elasticity
ITIL Lifecycle ElementsA typical ITIL service management lifecycle would normally contain the following processes -
Cloud Platform solution componentsTo understand one of the key differentiators between traditional IT and Cloud based computing is the concept of multi tenancy. The following diagram shows the distinct layers that make up a cloud solution. In this example we are going to talk about the customer facing “tenant” and “platform” layers. A key differentiator between traditional and cloud computing is the introduction of an additional layer - tenancy. Traditionally we would use a standard Change Management Process across the board, however in a cloud environment one of the elements we are looking for is agility and self-service. This is because in a “cloud” environment we have further layers of abstraction to consider:
- Platform Change Management - changes to the hardware or software that provides the cloud services e.g. hardware, hypervisor, management systems, web portal etc
- Tenant Change Management - changes that affect the environment provided through a tenant abstraction which may include tenant configuration and virtualised guest services
Example Requirement – Single Server DeploymentTake the following scenario: Note: for the purposes of this article I’ve provided a simple view without refining other process interactions such as configuration management, service level management etc. Jane is a member of the applications development team at a fictitious company called BlueStar. Jane is working on a project where a single virtual server is required. This project has a valid business case and has been approved by the programme governance board. In a traditional environment a service design package would be created, acceptance criteria fulfilled, a normal change raised/reviewed/approved, a server be procured, the server deployed, tested, handed over to support and change closed. Now how would that work in a cloudy world?
Public CloudJane would log into a self-service portal and request a single virtual machine from the Cloud Service Catalogue. In a public cloud system e.g. Azure/AWS/vCHS out-of-the-box, after specifying a few details a server would be provisioned granting Jane administrator rights to that server. She would be billed on a pay-as-you use basis, it would be accessible as a loosely-coupled service (vpn/internet access/api’s etc.).
Private CloudIn this example I’m using VMware vCAC, vCO and a pseudo ITSM tool. Jane has project/financial approval to proceed, Jane logs into vCAC and goes to the service catalogue (I’ll refer to this as the cloud service catalogue as this doesn’t replace the technology of business service catalogue). Jane requests a single virtual machine and provides the relevant details. This initiates a workflow which registers a standard change in the ITSM suite/CMP. Due to the nature of the IaaS system operating as a utility, the act of deploying a virtual server is pre-authorised in the change management process (CMP) (essentially this can now be managed through the Request Fulfilment process). We have options, we could simply log the change, and provision the server is an automated/routine manner and provide change feedback through to close via a workflow. We could also use approval mechanisms to provide an additional level of governance and control. Whichever method is used the provision of a new server is in line with ITIL good practise. Utilising technology we can also integrate with other processes in an automated manner, for example as part of the automated deployment of the virtual server we may have included a software agent which provides integration to a configuration management system, we would also be able to notify different process owners of the action either in real time or via reporting mechanisms.
Change Governance, Control & Lifecycle ManagementIn this example we have utilised project and programme management to provide a level of governance and control rather than utilise the change approval board. This does however highlight some potential areas for concern. Below are just some of the concerns that may exist in relation to cloud and service management:
- Does the project/programme board ensure that the service provision aligns with the enterprise IT strategy?
- Are existing services analysed to check if functionality already exists?
- Is risk and security considered thoroughly prior to authorising the provision of a new server?
- How will testing be conducted?
- It is assumed that the service template (Virtual Machine) will be in a highly tested and verified state so this shouldn’t be a problem, however the changes in configuration and application load may have far and wide reaching implications. This would suggest that post deployment the standard/normal/emergency change route would still be required.
- What continual governance process will be used to assess system/platform usage?
- How do we ensure financial approval is in place?
- How do we conduct demand management in a fully autonomous environment?
- Peak Demand vs. Average Demand etc.
- How do we communicate with our customers to understand demand?
- Does our chargeback model accommodate standby/overcapacity?
- Does providing “room to grow” capacity negate the benefits?
- Do we have a good supply chain and integration model for rapidly bolstering our IaaS platform?
Strategy, Design, Change, Release and DeploymentThere are a number of policies, processes and procedures that play a part in the fully defined and managed change world. I have provided a subset of activities that need to be considered:
- Service Portfolio Updated
- Service Design Package (SDP)
- Capacity Planning
- Request for Change (RFC)
- Release and Deployment
- Change Closure