Cloud computing will bring demand for elastic application platforms.

Promises that cloud computing can save money and reduce time-to-market by automatically scaling applications (either up or down) oversimplify what it takes to develop application architectures to achieve these benefits of elastic scaling. Few of today's business applications are designed for elastic scaling, and most of those few involve complex coding unfamiliar to most enterprise developers. A new generation of application platforms for elastic applications is arriving to help remove this barrier to realizing cloud's benefits. Elastic application platforms (EAPs) will reduce the art of elastic architectures to the science of a platform. 

EAPs provide tools, frameworks, and services that automate many of the more complex aspects of elasticity. These include all the runtime services needed to manage elastic applications, full instrumentation for monitoring workloads and maintaining agreed-upon service levels, cloud provisioning, and, as appropriate, metering and billing systems. EAPs will make it normal for enterprise developers to deliver elastic applications — something that is decidedly not the norm today.

Forrester defines an elastic application platform as:

An application platform that automates elasticity of application transactions, services, and data, delivering high availability and performance using elastic resources.

We see organizations moving toward EAPs by extending their current web architectures, following one or more of four paths:

With the seventh generation of its WebSphere software, IBM redefines the state of the art in Java platforms for the enterprise.

The WebSphere 7 product family provides application development and delivery pros with new ways to optimize their application architectures, more development frameworks, automatic transactional reliability, simpler configuration and management, and improved stack integration for BPM, portal, and eCommerce projects. For shops struggling with scale, complexity, and high performance in their Java applications, WebSphere 7 may offer both relief and a simpler, easier-to-manage stack. WebSphere 7 also lays the foundation for cloud architectures and multicore hardware.

IBM, Oracle, and Red Hat JBoss will play leapfrog in Java platforms for the foreseeable future. But clients should evaluate the three leading vendors of Java platforms based on their primary goals for their software, not just by comparing features (and certainly not by comparing public benchmarks). With WebSphere 7, IBM has created a transaction monitor for Java. This goal reflects IBM's primary goals of reliability, integrity, and manageability in WebSphere. In this way, WebSphere is IBM's CICS for the Internet age.

IBM's second primary goal is to create integrated platform stacks. The WebSphere Process Server-WebSphere ILOG-Business Space-WebSphere Application Server combination is one such stack; WebSphere Portal and WebSphere Commerce are other integrated stacks.

Customers should always check the reality before assuming comprehensive integration in IBM's burgeoning WebSphere portfolio. Stack integration will always be a moving target for customers because IBM adds so many acquisitions every year. But IBM's product management regime makes it fairly easy for clients to identify which IBM stacks have high internal integration and which do not.

As much fun as the juicy details of the Oracle-Google lawsuit are, the meaning of the suit for enterprise application development managers is, well, philosophical. Aside from sweating over the legal status of your Android phone (if you own one), the lawsuit won’t create drama for your shop. But the long-term implications are serious. Henceforth, Java will be a marching band rather than a jazz collective. Oracle’s action will reduce the independent innovation that has made Java what it is, causing developers to seek new ideas from sources outside of Java. Your Java strategy, as a result, will get more complicated.

A little background: Since the late ’90s, the primary source of Java innovation has been open source projects that either fix Java limitations or provide low-cost alternatives to vendor products. But Java’s position as a wellspring of innovation has been declining in recent years as many Web developers shifted their attention to dynamic languages, pure Web protocols, XML programming, and other new ideas. This trend has been particularly pronounced in the client tier for Web applications, where alternative rich Internet application technologies including Ajax frameworks like Dojo and container-based platforms like Adobe Flash/Flex have replaced client-side Java. Java virtual machines are a foundation of these efforts, but the enterprise and mobile Java platforms are not.

In choosing Java’s future course, Oracle had two philosophies to choose from.

Java's future is on my mind lately. Oracle's new ownership of Java prompts a series of "what will Larry do" questions. But more to the point, the research Mike Gualtieri and I have been doing on massively scaled systems makes me worry that Java technology has fallen behind the times.

This is not a "Java is dead" commentary but rather a discussion of issues as I see them. Java technology is alive and vitally important; we all must be concerned if its future direction isn't clear.

For me, Java's 2-gigabyte-per-JVM memory limitation symbolizes this gap. Volumes of application data are rising, but standard Java platforms still have a practical limitation of 2 GB of memory. I spoke with one customer that incorporates a search process into its app that alone requires 20 GB of memory. This customer employs servers with 6 GB of memory each but can only use this memory in 2 GB chunks, each chunk managed by a JVM in a scale-out architecture.

We've done pretty well with 2 GB JVMs until now. But as data volumes grow, this company (and others) are no longer well served by scale-out JVM architectures. Java technology should give shops the choice of scaling up the memory within an individual JVM as well. Why?

Platform-as-a-service -- application development platforms running in clouds -- are entering a new phase of evolution, and not a moment too soon. I've become interested in a new set of products I'm calling "adaptive PaaS" (for lack of a better term) that I think will make the benefits of cloud computing available to a lot more development shops. I'm doing a webinar on this topic May 20th with Appistry's Sam Charrington. I hope you can join the discussion.

As I described in my early reports on PaaS, these products include full development tooling, runtime services, and administration and management tools. While complete, most of these "full PaaS" products are best for new applications, and they incorporate much proprietary technology. Consequence: Many if not most clients are still saying "no" to PaaS for two reasons.

1. Lock-in: PaaS products lock up your code in a single provider's environment.
2. Poor fit: Too many PaaS products just aren't strong for core business applications, particularly for rehosting existing applications.

These limitations often prompt developers who want the flexibility of cloud computing to use IaaS platforms like Amazon EC2 instead of PaaS. With IaaS, developers can code in the language and frameworks they choose, reducing lock-in and ensuring a good platform-application fit. As a result, while we see both interest and adoption of software-as-a-service (full applications) and infrastructure-as-a-service (virtual servers, storage, and networks), PaaS is lagging in adoption.