By identifying the capabilities of each deployment destination and the requirements of a service, placement attributes help ensure that service requests are deployed to the best destination. For example, placement attributes can help Commander decide whether to deploy to public or private cloud, or which datacenter or geographic region is best suited to a service, as shown in the image below.
You can configure two types of placement attribute:
- Fixed Requirement: If a destination doesn't provide this capability, it's filtered out of the list of valid destinations.
- Selectable Values: A prioritized list of capabilities. Destinations providing one or more of these capabilities are given a placement rating.
Design considerations
Once you've configured placement attributes, you assign placement attribute values to deployment destinations and published services. When you assign a placement attribute value to a deployment destination, you're identifying the capabilities of that destination, to help ensure that services are deployed to the best destination. When you assign a placement attribute value to a published service, you're identifying the requirements of that published service, to help ensure that services are deployed to the best destination.
You can enable requesters to specify placement requirements for new services. Consider the following:
- You can also enable users to select a destination by adding the Destination form element to the request form. For more information, see Service Request Form Elements.
- Placement attributes are service-level attributes and must be added to service-level forms. Placement attributes can't be added to blueprint forms. Because service-level forms are assigned to users, adding a placement attribute to a form means that it's displayed whenever a user requests any service.
Best practices
The Commander REST API v2 enables you to create placement attributes and apply them to deployment destinations and published services. This can help with adding placement attributes to existing destinations and services, as well as easing the onboarding process. For examples, see the built-in help for the Commander Legacy API PowerShell client.
Examples
Let's say a service must be hosted in the UK, and while it can be deployed either on-premise or in a public cloud, an on-premise destination is preferred.
Three destinations are available to users requesting this service. The following diagram shows that the UK datacenter is the best destination, because it provides both data sovereignty and the preferred deployment environment.
However, per-destination quota limits have been configured for the requester's organization. Because this service would cause the requester to exceed quota limits on the UK datacenter, the UK datacenter is no longer the best destination. The AWS - EU (London) destination is now chosen, because it satisfies the data sovereignty requirement, and the requester has sufficient quota.
See Configure Placement Attributes to learn how to set up this and other examples, such as:
- All Oracle database instances must be deployed on a specific cluster that's licensed for Oracle.
- All services requiring backup must be deployed to a destination that supports backup.
- Requester selects the service level, which affects where the service can be deployed.
