The presumed "elasticity" of cloud technology tends to fall apart whenever the bindings change. That is, when a virtual machine or virtualized application relies upon the specific configuration of the hardware providing its infrastructure, it isn't exactly cloud-like when you have to migrate that element to a new host. You often find yourself rewriting some configuration file or maybe even engineering some one-time script. You don't have to write an instruction manual every time you stretch a rubber band.
In rethinking its approach to making it easier for you to rewrite and reconfigure components that are said to be elastic, VMware has decided to engineer an administrative system that dispenses with the notion altogether. Call it a "zero-step process." In its place, the company's vFabric Application Director, which VMware We introduced you to vFabric App Directorannounced last October and is generally releasing this morning, substitutes this process for application deployment with a procedure that's reminiscent of drawing an org chart in Visio.
It's called blueprinting. You draw a chart of the components that your cloud-based application will rely upon, wherever it happens to migrate to within your cloud infrastructure. It's a map of the virtual app. When the component migrates, the vFabric system takes over the process of marrying the map to the new configuration of its supporting hardware.
Modern business applications don't really run on the operating system's infrastructure anymore - the platform has become completely virtual. So the paradigm of using the OS to figure the app is now broken, states VMware group product manager Shahar Erez in an interview with ReadWriteWeb. "Ten years ago, when you developed an application, you went to the procurement team and asked for a huge server to be provisioned for you. Today, you either use a credit card or provision a VM with a click of a button. You start working on that, config that application and move it around, without caring if that physical component runs, breaks, if it's an HP or a Dell server - all that is irrelevant for me in building that application."
Erez demonstrated the entire blueprinting process for me over the course of 15 minutes. For someone who manages cloud infrastructure day-to-day, it might not take any longer. The basic building blocks - the grey chrome squares in the diagram - represent individual virtual machines. You drag them into the canvas from the Logical Templates bin, which contains a list of VMs organized by their OS configuration. As you create more VM classes for your enterprise, you configure new templates for them, which will appear here. Like drawing a relationships diagram of database tables, you double-click on the top of each virtual component to place your cursor there and rename it. Placement of the components in the diagram is completely arbitrary; you arrange them as though you were composing a presentation.
The green boxes dragged into each of these grey blocks come from the Services bin. They represent the servers and middleware components that provide the service layer through the operating system. In this example, Apache Web Server, JBoss, and MySQL all qualify.
"When we finish building the blueprint, this is a logical representation. We still don't describe where it's running, how it's running - all these things are only going to be in the late binding," explains Erez. "So when we finish building the blueprint, we can save it, provide it in a catalog to your builders, your building release team, they can pick it up where they want and place it anywhere they want. So it can support any vCloud instantiation; but we have to go broader than that, to pretty much any cloud that you want it to run on."
VFabric accomplishes this by means of VMware's patent-pending cloud abstraction layer, Erez goes on. "We don't touch the infrastructure. We work with the cloud API, [which] uses whatever APIs we need to instantiate a machine - it doesn't matter whether it's a vSphere machine or [Amazon Machine Image] or maybe Hyper-V one day, because we don't deal with the actual machine. We interact with the cloud API... At no point in time does the user dealing with App Director need to worry [about] what is the underlying infrastructure or who is the underlying cloud."
The application relationships are represented by the dashed arrows. In this example, the AppTier component running JBoss relies on the Apache server to be running, and the DBTier component running MySQL relies on JBoss. The predecessors need to be running ahead of them, so the dependencies denote the start order. "Each of the elements that we just placed on the topology map comes with a best practices provisioning script," explains Erez. This way, the IT guru will be able to review these default settings prior to any of these components ever being deployed, and specify at the blueprint stage which settings may be overridden at deployment time.
Any business logic which needs to be run by a service (for instance, a JBoss WAR file) can be loaded into the service during deployment by adding its orange box from the Application Components bin. Enabling a class of component to become clustered is as simple as clicking on its associated component's cluster icon (in the upper right corner), and choosing the number of units in the cluster.
Once the blueprint is complete, the designer has the option to publish it for anyone in the organization to use for later deployment, or to deploy the system immediately. During the deployment phase, App Director previews how the execution will take place with a NASA-style diagram - this isn't the one you drew yourself as a blueprint, but rather an extrapolation of that blueprint into a workflow, where the X-axis represents time consumed.
Then when VM systems are deployed, you can monitor their status and progress through this All Deployments screen. Of course, the entire App Director service may be run through a modern Web browser, which does mean it can run in a tablet - Erez' demonstration was using Safari on Mac, though it could very easily have been Safari on iPad.
"The reality is, provisioning a new application in enterprise IT takes anywhere between four days for a very small application, to eight weeks," states VMware's Shahar Erez. "Which really doesn't make sense. When you talk about the problems of the cloud, and the cloud getting infrastructure up and running very fast, you're really alleviating a portion of that wait time. On the other hand, we accelerating the development cycle, and then we're stuck in the middle with getting the code to run on that available infrastructure. And that problem is what's delaying getting your business value out to the market sooner. This is the gap that we're trying to bridge."