Software engineering and development has come a long way over the years. We've seen systems progress from mainframes...
to the rise of the x86 architecture. Where developers once had to schedule machine time and run around with punch cards, they can quickly churn out code thanks to advances like tab completion. We've come from extensive development and deployment models to simply forking repositories on GitHub and pushing out releases. Yes, developers have certainly come a long way and with these changes, have placed a great deal of pressure on IT operations and data centers to do the same.
But we are IT operations
For those of us in operations, DevOps expectations are a bigger hurdle for us to overcome. We have production environments to look after; we have strict change management solutions that protect us from ourselves; we are expected to back everything up and restore on demand; we have SLAs we must adhere to, and on top of all this, we are expected to innovate and grow because that's what our CIOs have read in their in-flight magazines -- concluding that innovation and DevOps is what we should do.
It's a bit ironic that one of the answers to these "new" IT operations problems stems from something most businesses have utilized for decades in other departments, such as HR and accounting. I'm talking about policy; more specifically, policy-based computing. By taking the principle of dictating when and how something -- or someone -- should react in situations and applying that to our infrastructure seems to be the answer for how IT operations can speed up deployment, decrease risk and, more importantly, free up IT resources for innovation.
How has VMware responded?
VMware's support of policy-based computing relies heavily on what the company calls the software defined data center (SDDC). SDDCs and policy-based computing are almost one in the same, dictating when, where and how our VMs are created, provisioned, configured and decommissioned. Even before the concept of SDDC existed, VMware had been building its foundation within vSphere. Below are some of VMware's early forays of mixing virtualization with policy to make the life of administrators and operations personnel easier:
Customization specifications: In IT time, customization specifications have been around forever, and. although they are a feature we somewhat take for granted now, they're essentially a policy allowing us to apply different customizations to different operating systems -- allowing administrators to skip mundane tasks such as configuring initial administrative passwords or license keys.
The vSphere Distributed Switch: Introduced in 2009, the vSphere Distributed Switch (vDS) allows administrators to abstract the tasks of creating individual Standard vSwitches on each host and put the burden of the configuration on vCenter. This control plane and data plane model allows us to dictate how we want our networking configured; vCenter -- or control plane -- then pushes the configuration out to each individual host.
DRS and Storage DRS: These two technologies are perhaps some of VMware's biggest leaps when it comes to automation and policy-based computing. When fully automated, Distributed Resource Scheduling (DRS) intelligently places VMs on our hosts and then dynamically balances computing and memory capacities across the cluster. When coupled with resource pools, reservations, shares and affinity rules, DRS helps to ensure that our most important VMs receive the compute and memory resources they need to meet business goals. Storage DRS (SDRS) is a similar concept, but it focuses on data stores the VMs reside on, essentially monitoring the I/O load and capacity of individual or groups of data stores and leveraging Storage vMotion to give VMs the storage performance they require.
Profile driven storage: vSphere's Profile Driven Storage is essentially a vehicle allowing administrators to automate data store selection of provisioning VMs. By gathering information about different storage tiers -- both manually, and automatically through vStorage APIs for Storage Awareness (VASA) -- we are able to create profiles or storage tiers which map to those storage capabilities. While provisioning VMs, we can also assign VMDKs to these tiers, and Profile Driven Storage handles data store selection, ensuring VMs and workloads are properly deployed to storage tiers containing these defined capabilities.
VVOLs: VMware's Virtual Volumes takes Profile Driven Storage one step further. Coupled with VASA 2.0, VVOLs are able to remove the need to setup the predefined buckets and profiles Profile Driven Storage requires, and broadcast this information directly from the array to vCenter. These capabilities are then assigned to VMDKs and are created directly on storage arrays. Selected storage capabilities and features are then automatically assigned to our VMs on the storage array by VASA 2.0.
It's just the beginning
Although these are just a few of the features and benefits vSphere has brought us over the years, they all have one thing in common -- policy. By applying policy to our infrastructure, we are able to speed up provisioning, automate mundane tasks and decrease the "risk" of running a production environment, leaving administrators with more time to innovate, create and, maybe, develop more automation and policy.
The story of policy-based computing and vSphere is only just beginning. One of the key promises of NSX is its ability to reduce network provisioning times, and with vRealize Automation, end users can deploy workloads themselves. Using vRealize Orchestrator can also bridge the gap between the future and now by automating polices throughout data centers. The Virtual Data Center feature, which did not make it into vSphere 6, will bring numerous policy-based rules and automation with it. Collectively, these developments have certainly helped in keeping up with the rapid pace set by developers.