In considering simplification, I’ve been thinking about policies. I love the idea of policy-based management and IT systems that implement policy. But isn’t there a risk of policy sprawl? If we allow free reign on policy configuration, we will end up with a huge number of policies. Will we end up with so many possible policy combinations that we have more policies than configuration settings? One way to reduce the possible load from managing policies is to reduce the options within each policy area. Maybe vendors should be defining standard policies and simply letting customers assign those policies. Fewer options lead to less time spent selecting what policy settings to use.
While choice is a good thing, it is also a bad thing. The more choices that are available to us, the more time we must spend identifying the correct choice. This can lead to overanalysis. The cost of this analysis can exceed the benefit it produces. Imagine you need to fill your car up with gasoline and must drive to the service station to find out its price. If there are ten service stations, you could end up driving all over town to save a couple of dollars. You could easily spend more on gas to drive to the cheaper station than you save in cheaper fuel. The same is true of evaluating technologies. Every option you evaluate takes time, and so costs money in addition to delaying a decision. Spending six months to select a product that is 5% better than the average product makes no sense. What about tuning policies? The very problem we are trying to avoid is spending too much time managing each item. Too many options can be a bad thing. Standardization is the key to policy-based management.
Limiting policy choice helps enforce standardization and therefore the benefits of policy-based management. When I first looked at NexGen Storage, now a part of Pivot3, I was surprised that there were only five performance QoS levels. I was also surprised that the levels could not be modified by the user. To reiterate, each stored object can have one of five predefined performance service levels. The value of this system is that it is quick to allocate a performance level for each VM. It is a one-dimensional decision, and each VM fits into one of five buckets. Job done, move on to the next task. This is quite a contrast to configuring older storage systems: no tuning cache size, RAID configuration, or tiering. Yet, it allows differentiated service based on business priorities. Each of these five policies still has a lot of configuration fixed into it to deliver a fixed quality of storage service. The crucial part is that the vendor, NexGen, has done all the work to identify the service levels that are suitable for its product. All the complexity of storage performance is hidden behind a simple selection of policy: policy selected from a very short list. Reducing the number of policy options leads to quicker decision making and more consistent infrastructure.
There is a strong precedent for limiting choice. Cloud providers offer a limited range of fixed configurations. The provider can become very efficient at delivering the fixed configurations. The cloud tenant does not need to know how the configuration is delivered. Tenants do then need to make their applications fit inside the fixed configuration. For most enterprise IT organizations, this would be a huge shift in approach. Enterprise IT has usually crafted an infrastructure to suit the exact needs that the application owner demands. Then, the business points to IT as a huge cost with a vast amount of complexity. The funny thing is that business units often compare the cost of public cloud providers to their in-house IT departments. A lot of the cost of in-house IT is accommodating the perceived uniqueness of each application. Radically simplifying the in-house offerings, to a cloud-like level, could reduce the cost and complexity of running infrastructure.
Naturally, there won’t be a single policy on each object. A VM might have policies for storage performance, a backup, a DR protection, network performance, and security just as a start. There may also be policies about software updates or which data centers the VM may reside in. There may even be a correlation between the policies applied to the hypervisor hosts and those applied to VMs. A VM may be constrained to reside on a hypervisor host that is compliant with the PCI DSS specification, because the application inside the VM holds credit card numbers. With so many policies on objects, it is important that each policy is as simple as possible in order to avoid policy sprawl.
Share this Article:
Latest posts by Alastair Cooke (see all)
- When Every Company Is a Software Company, No Company Is a Software Company - March 20, 2017
- Microsoft’s New Golden Goose Is Azure - March 16, 2017
- It Is in the Cloud—Who Cares If It Goes Down? - March 10, 2017