Making a case for the custom cloud

Cloud computing is broadly defined as an IT model that grants specific users both the permission and the ability to request a certain amount of computing resources through an automated interface. The resources are then expected to be delivered shortly thereafter through an automated provisioning process.

Details and constraints of this definition of cloud computing — whether in the location, quantity, or specific composition of these resources — have been debated for months in the industry, even while the model continues to gain traction and market popularity. However, a few features of this concept remain clear:

  • To the user, the quantity of resources available appears to be limitless. While that’s clearly not true, the size of the cloud so far exceeds the needs of each individual user that it is “effectively limitless,” gated only by the permissions given to that individual.
  • The request is immediately fulfilled, within a short window of minutes or hours, relative to the weeks or months required in the past.
  • The user can leverage more — or fewer — resources over time, according to the capacity management expertise of the cloud administrators and their own workloads’ needs.
  • The cost to the user of consuming cloud resources, in place of traditional physical resources, is greatly reduced.
  • There are some tradeoffs in exchange for the benefits. For example, the user may no longer have knowledge of (or control over) the precise physical location, neighboring workloads, hardware, hypervisor, and various other components that are now optimized by the cloud management environment.

The benefits, particularly for a large swath of reasonably low-risk and intermittent workloads, are clearly beneficial to all concerned. The user gets what he or she needs, and IT has the freedom to manage the aggregate of all cloud services to best optimize their environment.

Users get what they need

Most depictions of the quintessential cloud user paint him or her ambiguously enough to allow for every role or function — from a researcher needing to run an immediate, complex statistical calculation, to a developer who routinely tests her code on fresh instances of an environment, and even to a marketing team member who needs to provision enough “Web site capacity” to support another 1,000 concurrent users.

While this seems fanciful in a world of primarily infrastructure-as-a-service clouds, even the most basic clouds, such as those supporting development efforts, still have a diverse set of users. Some developers, when writing code, might need a Software Development Environment (SDE) linked to a runtime environment that supports multi-tier applications (say, an application server and a database).

Other people in QA might need a single instance of an application, rapidly reconstructed. Scalability testers would need simulation environments to test thousands of users and transactions.

Add to this same cloud a group of research-and-development (R&D) users who require a few advanced statistical packages on top of an operating system, or financial analysts who need to run simulations, and you’re already up to half a dozen different cloud service configurations.

That doesn’t even begin to account for differences in size of instances, monitoring and service level agreement (SLA) requirements, or security and compliance options.

However, even in these simple cases, it is clear to see that a “useful” cloud service to each of these different theoretical users varies wildly. It would do no good to provide each of them with a nice, clean instance of Red Hat Enterprise Linux 6.0 and send them on their way. The users each need a very specific cloud service to truly meet their needs.

Serving the masses

What might have been untrue for countless architectural efforts throughout time is actually true for the cloud: If you build it, they will come. And with them, will come tremendous diversity in requests. You have three major options for addressing this diversity:

  • Take it or leave it — Give users a basic, standard cloud service with no customization, regardless of what they want.
  • A thousand shades of cloud — Give users precisely what they want, creating a library of images to meet each need.
  • The modular cloud service — Construct a modular way of giving each user what they want by piecing together component parts on demand.

Option 1: Take it or leave it

If you commit to the admittedly beautiful dream of standard images, you will realize some pleasant benefits. If these images include only an operating system, configured to your company’s standards, then you have significantly lowered the diversity in your environment and simplified its management. If you manage to build a handful of standard, full-stack images, then these small library images might be relatively easy to manage.

The downsides are clear. By shifting the burden of conformity to the user, IT basically requires the user to meet its needs, not the other way around. What’s more, users, who are now often application administrators, are left with the burden of installation and configuration post-provisioning to put together the proper cloud service they need.

A large chunk of users will turn away, knowing the cloud environment doesn’t fulfill their requirements. Many of the benefits of cloud, which are achieved through scale and consolidation, are less forthcoming when fewer users patronize the environment. They may find other ways to achieve their ends, through public clouds or by maintaining physical environments.

As the population of users grows and diversifies, pressure will increase to expand the library of images — which brings us to option 2.

Option 2: A thousand shades of cloud

One request begets another, and users begin to ask for tweaks and changes to make the cloud service better for them. While a hard line on customization might be easy to describe in principle, it is much harder to implement in practice. There are always urgent or high-priority exceptions or high-profile requests that cannot be denied.

Once that image has been tweaked, why not make it available to the next fellow who wants the same modification? Rapidly, the numbers balloon. The users are getting what they want — but at what expense?

Image libraries are not trivial to manage. Patches need to be applied and updates managed. Effectively, these hundreds of images become a whole new set of software stacks that needs to be managed on an ongoing basis, alongside the very instances of themselves that fill the cloud infrastructure. It’s a challenge most IT groups are loathe to undertake — and for good reason.

Option 3: The modular cloud service

The third option enables the greatest user customizability — and interestingly, the greatest administrator customizability, as well. If all cloud services can be constructed of many component parts — operating systems, applications, middleware, databases, monitoring tools, and so on — then a system can be created by which each part can be independently selected by the user and then put together, on demand, by the cloud provisioning system.

A frivolous analogy might be a trip to the ice cream shop. The customer can select one, two, or three scoops of ice cream, a topping flavor (hot fudge or caramel), some dry toppings (chocolate chips or peanuts), whipped cream, and a cherry. Each customer builds the sundae that appeals to his or her individual requirements, whether that person wants a chocolate explosion or a fruity treat.

On the other hand, the ice cream shop proprietor decides what ice cream flavors to stock, what sizes to sell, what toppings to offer, and so on. She can even create arbitrary requirements such as “every sundae gets two cherries” or “no more than one topping per scoop of ice cream.”

The ice cream shop owner has control over what she offers her customers, so they cannot just barge in and demand gummy bears on their treat. However, those customers, within preset boundaries, have freedom of choice. In the cloud, the same is true.

Through a service catalog — the menu of options of the cloud world — IT can set the choices, role-based permissions, and hard-and-fast rules of the environment. And, through the portal, users can configure their own services to meet their needs.

As no images exist, there is no image management problem. But the trick lies in having a robust, automated provisioning engine, a modular way of describing cloud services, and a service catalog in which to translate these descriptions into offerings for each user.

Lilac Schoenbeck is VP of Product Management and Marketing at iland. Lilac has more than 12 years of experience with product marketing, strategy, business development, and software engineering in the grid, virtualisation, and cloud domains. She has worked for IBM, Fortisphere, Innosight, and the Globus Alliance and holds an MBA from MIT Sloan School of Management and a Computer Science degree from Pacific Lutheran University.