Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Building cloud-ready, multicore-friendly applications, Part 2: Mechanics of the cloud

Orient yourself and your applications in the cloud

By Guerry Semones, JavaWorld.com, 04/30/09

  • Print
  • Feedback

Page 5 of 6

Another difficulty arises from managing things at the granularity of a virtual machine image. In typical infrastructure-as-a-service cloud environments, you create a virtual machine image and populate that image with services, applications, and configurations. If something changes in your application's configuration, you revise the virtual machine image, a time-consuming and potentially error-laden process. The term image sprawl aptly describes the growing pool of images that result from this model.

Some cloud application platforms provide a finer degree of granularity. With such platforms, you address the virtual machine image as what it should be: an operating system layer plus a cloud application platform agent. The agent oversees the virtual machine, and allows services, applications, and configurations to be deployed, updated, and versioned, and their lifecycles maintained, without changing the underlying virtual machine image. The difference between these two image-management styles is illustrated in Figure 6.

Coarse-grained vs. fine-grained image management

Figure 6. Coarse-grained vs. fine-grained image management. (Click to enlarge.)

Why do I even bring this up in an article primarily focused on developers? Deployment is not a production- and testing-only concern. Anything that affects time usage during development needs to get the hairy eyeball -- at least, my pragmatic-programmer roots think so.

Of course, this level of manageability goes way beyond the developer. I'm aware of one company with over three hundred workers (and over five hundred cores) that manages its private production cloud running multiple cloud applications with less than one-third of an administrator's time.

Load balancing

Cloud platforms use various types of load balancing. It may be as simple as using software- or hardware-based load balancers between the cloud application and its client -- or it could be as sophisticated as the cloud platform utilizing its own built-in software-based load balancing. Load balancing affects both scalability and availability. When your application's work is distributed across many workers, you want to make sure that the resources of each worker in the cloud are fully utilized when needed. It would not help you if some workers were maxed out and others ignored or underutilized while your application is under a spike of heavy load.

The situation gets more complex when you introduce servers with varying capacities and speeds into your cloud. If your cloud is made up of workers that range from older single-core processors up to machines with four or more cores, then you have workers with very different capability footprints. As demand ramps up, then the CPU cores, memory, and other resources should be utilized fairly across the distributed workers. Slower machines should carry the load they are capable of, and faster machines should be utilized more. The old naval adage that the armada is as fast as its slowest ship should not apply here.

Either way, wouldn't it be great if you as a developer did not have to worry about this? Some cloud platforms take care of this for you, so you don't have to sweat the application infrastructure or architecture to make sure the application load balances across the cloud.

  • Print
  • Feedback

Resources

More from JavaWorld