First you build your cloud. A week back, I shared my thoughts on how best to do so based on my keynote from the Red Hat Cloud Tour. But that's just the first step. Once your cloud is in place, you need to operate it.
What makes this less than straightforward in a typical enterprise IT environment is that there's a balancing act in play.
Users want the simplicity they get from public cloud providers. They want self-service. They want to be in control. They don't want to think about underlying infrastructure. They want things to just work. In short, they have expectations set by the consumer Web and by the plethora of "magical" iDevices that they increasingly bring to their day jobs.
Historical enterprise IT sat largely in opposition to these user desires. Applications focused on business processes rather than user interaction. Minimizing risk and cost was equated to minimizing user choice of user choice. And a myriad of unavoidable regulatory, compliance, security, and audit needs meant that laissez faire attitudes to where applications ran and data was stored were a non-starter.
Balancing these two sets of desires and requirements requires four capabilities, all of which Red Hat provides:
- Self-service with rich policy
- Application lifecycle management designed for the cloud
- Application portability across clouds
- Proven stack and ecosystem delivering enterprise-class SLAs in the cloud
Self-service is a sine qua non of cloud computing. It's fundamental to eliminating friction between users requesting a service and the IT infrastructure providing that service. Business processes and workflows also need to support rapid servicing provisioning of course; associated manual approval requirements adding days or weeks blunt any positive technology impact. However, even reasonably automated provisioning processes that require admin intervention can add significant latency and limit scalability.
The key in an enterprise context is pairing this self-service to a rich set of policies. Policies specify which standard operating environments (SOE) a user or group of users have access to. They specify where those SOEs may physically run, perhaps based on whether they're being deployed for dev/test or whether they're being put into production. Thus, for example, policies could allow a service to be deployed to a public cloud while it's being developed--using test data--but require that production applications working with customer data be run on-premise.
Traditional enterprise management was "heavyweight." It focused on relatively static environments that had, as their core, large, proprietary legacy servers ministered too by a cadre of specialized sys admins. A cloud environment, on the other hand, is highly dynamic. Workloads are more typically scale-out. They are mobile, often running at different locales at different points in their lifecycle. Application lifecycle management for the cloud needs to take these differences into account. The System Engine component within Red Hat's CloudForms Infrastructure-as-a-Service cloud management software was designed with such cloud requirements in mind.
One of the ways that portability breaks down is that public clouds encourage ad hoc development that doesn't necessarily comply with an organization's standards for applications run on-premise. This may be fine for prototyping or other work that is throwaway by design. However, it's far too easy for prototypes to evolve into something more—as often happened in the case of early visual programming languages—and the result is applications that either have to be rewritten or that may have support, reliability, or scalability issues down the road.
One approach to addressing this problem is to provide consistent runtimes across public and private clouds. Red Hat does this through its Certified Cloud Provider program that provides access to certified Red Hat Enterprise Linux (RHEL) on public clouds. (Pay-as-you-go RHEL is initially available on Amazon. Cloud Access provides a way to transfer on-premise RHEL subscriptions to Premier Certified Cloud Providers.) By running the same runtime across physical servers, multiple virtualization platforms, and public clouds, application certifications and testing need happen only once.
Finally, just because the "cloud" word is getting thrown around doesn't change the needs of either the IT department or the users when it comes to quality-of-service (QoS), security, or reliability. Users may fixate on the simplicity of consuming external computing resources but they expect the high level of availability that they're (hopefully) accustomed to IT providing. And, as an organization starts building a cloud, the goal needs to be to meet or exceed traditional IT operational benchmarks.
This requires no-compromise infrastructure. Cloud management may abstract this infrastructure and it may span multiple underlying technology stacks. But the capabilities of that underlying infrastructure still matter--more than ever. Dynamism and multi-tenancy (whereby disparate users share physical resources) are fundamental to clouds and they amplify any underlying infrastructure weakness. Red Hat has a long history of providing platform software for the most demanding IT environments. The cloud is simply the latest such.
Cloud computing operations requires blending the new and the old. Our expectations as consumers come to the fore. The "Consumerization of IT" phrase is often taken as synonymous with bringing your own iDevice to work. But it equally applies to user expectations of IT as shaped by Google and Facebook. Yet cloud computing doesn't suddenly void all legal, security, customer data, and uptime requirements. Those organizations that hit the right balance will be the most successful ones.
No comments:
Post a Comment