The water wheel of upgrades
The benefits of Infrastructure as a Service (IaaS) come as a breath of fresh air to IT shops that have been trapped on the water wheel - making little or no progress in endless cycles of hardware and software maintenance and upgrades.
Plenty of times we have seen a core component upgrade (e.g. the hypervisor) send concentric upgrade ripples to the other interdependent components - the management software, the server hardware, the network switches, and the backup software. And in enterprise environments, with treacle approval processes and arrow-slit change windows, it is not uncommon for the upgrade of the last component to be followed by the next major version upgrade of the core hypervisor again. "How is all this undifferentiated heavy lifting adding any real value?" cry the IT execs.
Benefits of IaaS
On-premises solutions of converged infrastructure (e.g. VCE and FlexPod) and hyper-converged infrastructure (e.g. Nutanix, VRTX and VSAN) can go a long way to address the upgrade challenges, with fewer components to upgrade or well published upgrade versions and processes. So too with Infrastructure as a Service, which essentially offloads the maintenance upgrades, planning and deployment burden to the provider. IaaS provides organisations tangible value in the areas related to infrastructure management. Granted the consumer now needs to be more flexible in wearing the maintenance windows decreed by the provider, but adaption to this new status quo is mostly an annoyance rather than chronic pain. And so dreaming of skipping merrily through the land of chocolate, the decision is made to move to IaaS...
Challenges of moving to IaaS
However, quickly following that decision to move into IaaS, there is the realisation that there is a whole host of additional considerations that require attention. IaaS providers must be compared, and the differences between their propositions compared - SLAs, cost models, contract terms, and penalty clauses. Circuits need to be provisioned or bolstered, along with estimates of how much additional bandwidth is required, without any real idea of traffic volumes. Some initial assumptions may need to be revisited, and where Operating Systems versions are not supported, some applications may have to be upgraded or patched before they can be migrated. And so at the end of all this, it is actually not surprising if no-one gets round to considering right-sizing (optimising the allocation of CPU, memory and disk resources) of the virtual machines; or if they do consider it, there is not enough time left to do it prior to migration.
Inefficiency is OK on-premises
With an on-premises model, infrastructure capacity supply must necessarily exceed demand to account for the fact that request, procurement and provisioning cycles are measured in months' duration. The oversupply is also reflected down at the individual virtual machine level, where guest virtual CPU, memory and storage are provided in abundance because supporting processes to modify allocated resources are not dynamic enough, and resources are often 'squirrelled away' because application owners recognise the finite capacity of the whole system.
Inefficiency in cloud means cost
In an IaaS delivery model, this oversupply of virtual machine resources results in an inflated OPEX which quickly becomes a painful budget issue. It is not an unnatural reaction for an organisation to assume that "we will just right-size once we have completed the IaaS migrations". However, our experience has shown time and again, that it is not necessarily that straight forward. Even with a plan of which resources to shrink (or grow), unanticipated additional obstacles appear. In some cases the provider will be able to modify CPU and memory allocations simply enough (even if it is not a dynamic process). However, moving storage performance tiers or shrinking data volumes is where the limitations are exposed of the underlying commodity components selected by the provider. Given unlimited funds, the provider probably would have chosen the latest and greatest storage systems that present all the storage resources as a single virtualised pool of capacity. However, as a commercial proposition, certain trade-offs are understandably made. These trade-offs often translate to manual processes for storage modifications, which may also require additional software to achieve the volume re-configurations. This involves time and effort from the provider and hence cost. And in some situations the result is that for some virtual machines, the payback period from IaaS efficiency savings versus cost to effect the changes turns out to be several years, and is understandably unpalatable. "Boy, I wish we had right-sized before we moved..."
It is amazing what a difference a bit of forethought and planning make. Using data visualisation techniques, technical data can be coupled with billing information to ensure that the highest value optimisations are made the focus (thinking about the payback period). Also, developing and validating a process that is inclusive of the relevant stakeholders (especially enterprise application owners) and ensures service performance is baselined before and after the re-configurations, both go a long way. In our experience, if the project is run with these principles in mind it is possible to achieve OPEX savings of up to 40% - and that is never frowned upon!
Keep on improvingIt is unlikely that you will see such dramatic OPEX savings following the first right-sizing phase, but there are definitely additional areas you can focus on from hereon in:
- Build in a process to check periodically for further right-sizing opportunities - usage patterns of systems and applications change over time.
- Keep aware of new services - the IaaS provider may release new service offerings that provide better value or a more appropriate service level (at a better price).
- Move up the value chain - IaaS should only be the on-boarding point for cloud services. As the opportunities present themselves, find ways to consume higher value services such as managed database, CRM, application integration, directory service, etc.
- Make IT the broker of services to the business - establish a capability whereby IT processes are modified to 'make the business want to come to IT for any cloud service' and build a Cloud Management Portal to aggregate internal and external IaaS, PaaS and SaaS.
- Demand innovation from your provider or move your services to another provider.
What are your experiences with moving to IaaS? Are you seeing the cost savings you were expecting? Feel free to share your experiences.