When it comes to launching a successful ITaaS Pilot there are key concepts you must discuss and document before implementation can begin. Let’s discuss the conceptual and architectural definitions required to successfully implement an ITaaS Pilot.
First let me highlight some best practices for you to consider based on Sovereign’s client experiences:
- Use a phased approach; do not wait until the end result is clear.
- Pick a friendly group of users for the Pilot; Dev/QA users and internal IT are excellent resources.
- Keep in mind that service catalog and the initial self-service portal will grow and change as the Pilot progresses and new groups are added.
- Make sure IT remains the central control point of the Pilot – acting as the ITaaS brokers and administrators.
- Expect automation in the Pilot to expose the need for more automation.
- Document risks, costs and successes and socialize within your organization.
- Address organizational alignment challenges that may be exposed during the Pilot.
With the above in mind, let’s discuss the concepts and architectural components that must be defined before your ITaaS solution can be implemented.
ITaaS Solution Overview
The above demonstrates an example of how to define a Pilot solution. You can use this to educate potential users and other key people within your organization on the components, capabilities and benefits of the solution.
As you can see, the image above illustrates an ITaaS Pilot solution that consists of a self-service portal with automated provisioning, using VMware’s vCloud Automation Center (vCAC), with a 6-month subscription to VMware’s Hybrid Cloud Service (vCHS). The resources used to run the provisioned workloads include an on-premise vSphere infrastructure and the off-premise vCHS subscription. This approach allows you to test brokered hybrid cloud services in order to explore the option of leveraging a public cloud provider (vCHS) for some workloads.
The portal, service catalog and automated provisioning, gives the IT organization control as the broker of services, while providing Dev, QA and R&D engineers the ability to self-provision critical resources through the portal. Additionally, core IT engineers can use the portal’s automated provisioning capabilities for other business units; not included as part of the Pilot.
Defining Multiple Tenants Mapped to Business Units
To map the multi-tenanted aspects of the ITaaS Pilot solution to your existing business units requires discussion and planning. The purpose is to create a conceptual model for how the ITaaS solution segregates users and service catalog entries. This chart illustrates this concept:
In this scenario, there are two tenants for the application developers: App1 and App2.
These tenants represent the applications that various developers are working on. Tenants are used to separate users so they can only see and deploy items from the service catalog that pertain to their work. Each item in the service catalog and its provisioning workflows are defined by the blueprints associated with that tenant. Business groups are used to segment the various types of users within the tenant.
For example, Sandbox, Dev, QA and R&D are business units mapped to the organizational structure.
Similarly, tenants: IT Unix and IT Windows, are used to separate catalog items for the Unix and Windows IT teams.
Remember: The above scenario will likely change, but this is a good starting point for the Pilot.
Defining the Service Catalog
Next you will want to define what needs to be in the service catalog for each tenant and which business groups within a tenant should have visibility to these items. Items in the service catalog and the automation workflows for provisioning are defined via blueprints. Since you can use existing vCenter blueprint templates for provisioning, pick an initial set of existing templates to populate the catalog. For example, we defined the following blueprints for both application tenants:
- Windows 2008 server
- Windows 2008 server with SQL
- Multiple Machine Blueprint with 3 Virtual Machines: iiS, app server and SQL
- RHEL server
- RHEL server with MySQL
- Multiple Machine Blueprint representing the LAMP stack
Similarly, we identified blueprints for the IT tenants using existing vCenter templates for Linux and Windows servers.
Ready for Implementation
At this point, the service catalog is defined and ready to go for the Pilot. Users have been identified and grouped into tenants and business groups. Now implementation and configuration of the vCAC software can begin.
Hopefully these concepts and definitions are helpful as you plan a Pilot program for your organization. In an upcoming blog we will discuss the high-level findings, gotchas and successes of our ITaaS Pilot along with the planned next steps.