How it Works: VMware’s Own Internal Self-Service Cloud
One of the hottest new products in the vFabric portfolio is vFabric Application Director. Many at VMware are excited about it simply because of what it means to our everyday work life. Earlier this year, we published a story on “How VMware IT Reduced Provisioning Time by 80% Using vFabric Application Director and More.” Now that number is up to 90%. Here’s an overview of what the business workload lifecycle management implementation looks like under the hood.
To achieve it, VMware IT automated several key processes across organizations including:As shared in the earlier post, our goal was to automate the end-to-end application life-cycle management in a private cloud and eventually across the clouds. Automation by definition speeds things up and makes them less error prone, but in this case, it also meant that VMware’s IT organization could decouple itself from the everyday operations of the app and product teams it serviced. This split between IT and DevOps is a goal for many organizations today who are looking to be more agile, save money and maintain strong IT governance.
- Cloud & Catalog Management
- Workload Blueprint Design
- Workload Automation
- Self-service Portal
- Change Management
Naturally, we looked first to eating our own dogfood and built these processes on top of several VMware products including VM Studio, vCloud Director, vFabric Application Director, vCenter Orchestrator and Service Manager.
Cloud and Cloud Management
To populate the vCloud catalog, your virtualization infrastructure admin (VI admin) in the IT organization creates templates using VMware Studio, and is responsible for uploading them to vCloud Director. The catalog contains all the core building blocks that users will use to assemble their applications. Catalog items include middleware components such as web servers, app servers, message queues and databases but can also include much smaller components such as scripts or fully built applications depending on the services your organization requires. To enable the catalog, you need to have permission as a catalog administration so that you can add middleware components like app server, web server, message queue etc.
|Want to hear more directly from Thirumalesh? See his complete case study presentation live at VMworld EMEA next week. Register now OPS-CIM2646 – Cloud Application Platform Automation on vSphere Infrastructure Leveraging Application Director : Real-World Example of Running a 4 Billion-Dollar Business (VMware IT) Tuesday, Oct 9, 11:00 AM – 12:00 PM, Hall 8, Room C3|
- Map application requirements for your organization
- Identify operating system requirements to support the applications
- Identify compatible patches/packages required for the applications
- Determine storage, CPU, memory requirements
- Build vAppTemplates using VMware Studio appliance
- Validate generated artifact
- Upload vAppTemplate to vCloud Director
- As a catalog admin, add middleware services
- Add tags to identify middleware services
- Define which platforms these middleware services can be deployed
Workload Blueprint Design
A blueprint design is a visual representation of a complete application topology and installation template for a specific application that can include complex application structures with various interactions. Blueprints can be revised to scale vertically and horizontally and are deployable across different environments for usage throughout the application development, test and production lifecycle. The application and product development teams, generically referred to as DevOps, assemble these blueprints without the direct help of IT. Users access the catalog prepared by IT on vCloud Director through Application Director. This creates a nice end-user experience and also creates an important division of work between IT and DevOps where DevOps is the consumer of the service catalog and IT is the provider.
- DevOps architect and revise blueprints on Application Director
- IT accesses running applications directly on vCloud Director
Workload automation replaces the manual tasks that IT repetitively does to deploy application infrastructure for application teams. Since application needs vary greatly, we needed to ensure that workload automation covered a broad list of requirements including:
- Orchestrated provisioning including dependency management and configuration
- Invokes different modules using script, SSH, REST and SOAP communication protocol
- Be initiated by user activity
- Communicate with users using User Interface and email
- Maintain provisioning context
- Manage exceptions and compensate (undo) already executed activities
- Retry activities if needed
- Allow user based exception management
A front-end webstore to the entire solution, the self-service portal replaces help-desk systems and puts DevOps in the driver seat for requisitioning their infrastructure, designing their applications and initiating provisioning. For a video on how this looks to the end-user, check out the video Self-Service Application Deployment with VMware Application Director.
- DevOps initiate provisioning requests
- Approval managers (can be IT or DevOps) approve/decline requests (optional)
- IT Administrators can grant access to user and approvers
Change management is a key challenge as frequently IT will need to update the components running across provisioned applications to new versions to keep up with IT policies and software and security patches. As IT does this separately (for more on this subject, see last week’s post on Application Director and Puppet), blueprints are affected and will need to stay in sync with deployed environments. Therefore, a change management system is needed to version control changes to workflows and blueprints as well as keep environments and blueprints in sync.
- DevOps change/update blueprints in Application Director
- IT changes workflows on vCenter Orchestrator
- IT changes to vAppTemplates on in VM Studio and updates vCloud Director
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)