Policies provide consistent controls over what people can do. They limit the options down to the only acceptable ones.
Levels & Types
It's best to apply a policy when:
- You want the policy to apply ALL the time
- There are no exceptions
A policy won't work well when:
- You want the policy to apply MOST of the time
- There are known exceptions
- You need to make case by case decisions
If you find you need to change a policy often then it's time to rethink the level the policy is at.
Policies are hierarchical, a lower level policy cannot override a higher level policy. In the example below you can how the lower level policies are reducing the regions available at each level.
Expect to have the least policies at the Global level with more at the environment level and most at the Catalog level where you are specifying what is needed for a particular solution being deployed in a particular environment.
Broker works out the effective policy on a Catalog item by implementing the Global policy followed by the Environment policy with the Catalog item policy being implemented last.
It is possible to create an effective policy that results in no valid options.
Add a Global Policy when you want that policy to apply ALL the time to every environment and every catalog item.
- For data that always needs to stay in Australia, for example to comply with specific privacy requirements then you would set a Global data sovereignty policy. Remember this would then apply to your development data as well as production. If that doesn't suit perhaps you need separate environment policies.
This is where policies will become really useful but you'll want to remember to leave some room for those tight, end of project processes where more flexibility is likely to be needed. Longer hours and fast turnaround are important options in IT.
- To get real savings from being in cloud you might put an hours of op policy on your dev environment that limited availability to 7 to 7 Monday to Friday. Again think about the exceptions before applying this one.
To apply consistent controls with each deployment record a policy on a Catalog item.
- You may wish to apply a restriction on how much memory can be resized for where you've got a significant SQL server load.