There are three essential components of intelligent workload management (IWM):
- An operating system that enables us to perform a task or set of tasks
- Systems management tools to deploy and move workloads
- The ability to make each workload self-aware, so that it knows its own limitations
It’s this third element that has been missing. In the past we could have created portable workloads, but we had no way to make that workload intelligent. In other words, the workload didn’t contain inherent rules dictating where it could reside, who could use it and how that access should look. The only way to achieve this was to map an identity framework on top of a workload after the fact, and then move both the workload and the framework together as needed. However, this was very costly and time-consuming to manage.
If, however, we could embed identity into the workload itself, we could create opportunities for portability and agility within the context of a business’ security and compliance mandates. These capabilities actually do exist today.
How do you embed intelligent into a workload?
By applying policies to potential situations, we can automatically enable a workload to react “intelligently” to dynamically changing conditions. This can be achieved using a unique identifier. This concept is nothing new. Just as individual processes within a runtime environment have process identifiers, each workload can have a unique identifier, except that this identifier defines the security, identity and performance parameters for the workload.
Once this unique identifier is associated with a workload, it becomes easy to enforce security and compliance policies. With this unique identifier in place, workloads can be managed and tracked within the firewall, between demilitarized zones (DMZ) as well as out to the cloud. For example, a hospital processing medical records can apply unique identifiers to dictate how patient records can and cannot move across the enterprise based on geographic and location restriction to ensure HIPAA compliance.
Through these identifiers, the enterprise also gains forensic evidence to ensure policies are enforced. This approach provides significant benefits across the enterprise that has extended to off-premise nodes. For example, instead of spending weeks pulling together records for auditors, the company could measure and provide the auditor with access to a security and compliance dashboard that monitors activity history in a comprehensive way. Once these provisioning, workflow and audit controls are in place, one would be able to determine the ownership and accountability aspects easily.
What new possibilities do intelligent workloads enable?
The IWM model can also be extremely financial advantageous. Today, it’s essential to be frugal and prudent about the way we execute and pay for workloads. That’s what’s driving the shift from a perpetual licensing model to a consumption-based chargeback model. With IWM, we gain greater visibility into the cost of services (i.e., a collection of workloads delivered as a service). Because we know what the components are that are needed to create a service, we can very swiftly determine their associated costs.
Taking that one step further, we can move directly from the workload build process into the approval process, setting into motion a set of live events to quickly gain financial approval for acquiring a new service. And we can more easily charge individual departments for their usage.
Are you excited about applying such models in your business? What do you see as the possibilities for IWM?
Posted
Jun 17 2010, 08:47 PM
by
DiptoChakravarty