A service can consist of anything from a single VM to a combination of service components, such as:
- Multi-cloud templates
- VM templates
- Amazon Marketplace AMIs
- Virtual service templates
- Cloud templates (CloudFormation and ARM templates)
- OVA/OVF templates
- Custom components — used to represent both non-virtual assets (such as a phone) as well as tasks that modify existing assets (such as the installation of a database instance on an existing server)
A service can be predefined (for example, as a vApp in vCenter) or built from individual components in Commander.
Multi-cloud templates are the recommended service catalog building block. With multi-cloud templates, you can create a single service that can be deployed on multiple datacenters, as well as multiple private, public or hybrid clouds. Multi-cloud templates also make it easier to keep the service catalog up to date.
Blueprints enable you to configure default settings for each component in your service catalog. You can configure options related to:
- Infrastructure—such as a name, description, and customization specification
- Post-provisioning completion workflows, which allow you to install and configure applications
- Resources—such as CPU count, memory, instance type, storage and networking
- Custom attributes—metadata such as project code and cost center
- Groups—such as expiry, rightsizing, power schedule and maintenance groups
- Third-party integrations—such as Puppet classes and groups
Blueprints also enable you to create component-specific request forms, as shown in the image below.
Design considerations
When adding services to the catalog, consider the following:
- Will all services be globally available to all organizations, or will you create some custom services for each organization (or group)?
- Will services be predefined or customizable? Will your catalog contain exactly what your users want, or more generic services that your users can customize at request time? A smaller service catalog that allows user customization of resources, integrations and applications requires less maintenance but can offer the same level of flexibility.
- Do services need to be fenced (network isolation)?
- Do deployed services require a defined naming convention? For example, you may want to name all SQL services requested by Development with a pattern such as DEV-SQL-PRD-001, DEV-SQL-PRD-002, and so on.
- Will users be allowed to change the resource defaults, like adding extra disks, memory or CPUs?
- If you integrate with Puppet or Chef, do you want to allow users to configure this information on the request form?
- What custom metadata do you want to attach to services?
Best practices
- Use multi-cloud templates as the building block for all services, even for single-cloud services, to create an easier-to-maintain service catalog.
- Use the 80/20 rule for your service catalog: include the services that are most often requested.
- Offer only those services relevant to each organization and each user by limiting visibility.
- Name services appropriately.
- Use meaningful icons to represent services.
- Categorize services to make them easy to find.
- Keep templates up-to-date in the service catalog with Commander's template replacement feature.
Examples
With the service catalog, you can:
- Create a service that includes several instances of a database, and install the same base OS for each database by assigning the same completion workflow to each component in the service.
- Create a service that contains everything a new hire needs, such as a desktop machine and installed software applications.
- Create a lab service— everything required to set up a software testing lab environment.
