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.
- 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.
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?
- 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.
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.