It seems to some people that JBoss and Red Hat are late to the Cloud and missing investment. I don't think anything could be further from the truth. I'm going to try to set the record straight here and if you want more details then you should come to JUDCon (free to attend) or JBossWorld, where you'll hear a lot more about Cloud. I'm also going to be slightly lazy here and copy some texts that I've already written on my personal blog around this very subject.

Before going any further I think it's very important to put Cloud into context. As I said back in February, and presented at the Middleware 2020 event, Cloud is not the death of middleware or some grand new approach to distributed systems that breaks the mold. It's a pretty natural evolution if you look at what's been happening with hardware over the last 40 years as well as software, with the likes of SOA, and offshore movements by companies to save costs. But middleware, and more importantly enterprise middleware, will continue to play a critical role here. Now is not the time to throw away investments in software and people by jumping on the latest case of Emperor's New Clothes syndrome:

"Implementations such as Google App Engine are interesting toys at the moment, offering the ability to deploy relatively simple applications that may be based on cut-down APIs with which people are familiar in a non-Cloud environment. But I'm fairly sure that if you consider what consistutes middleware for the vast majority of applications, the offerings today are inadequate. Now maybe the aim is for people who require services such as security, transactions, etc. to reimplement them in such a way that they can be deployed on-demand to the types of Cloud infrastructures around today. If that is the case then it does seem to solve the problem (bare minimum capabilities available initially) but I take issue with that approach too: as an industry we simply cannot afford to revisit the (almost) NIH syndromes that have scarred the evolution of middleware and software engineering in general over the past 4 decades. For instance, when Java came on the scene there was a rush to reimplement security, messaging, transactions etc. in this new, cool language. The industry and its users spent many years revisiting concepts, capabilities, services etc. that existed elsewhere and often had done so reliably and efficiently for decades, just so we could add the "Java" badge to them. OK, some things really did need reimplementing and rethinking (recall what I said about evolution), but certainly not as much as was reworked. This is just one example though: if you look back at DCE, CORBA, COM/DCOM, .NET etc. you'll see it has happened before in a very Battlestar Galactica-like situation."

Now this doesn't mean the exact same middleware platforms we have today will be used in 5 years time. If you look at today's platforms and compare them with their counterparts from 5 years ago there are many changes. Things evolve, not just life, and Cloud is certainly a factor in the evolution over the next few years. But the fundamental requirements placed on middleware in the Cloud will be the same as placed on any kind of distributed system. Yes, there may be architectural changes to better accommodate the large scale nature that Cloud offers, improvements in security (critical if you're going to offload your data and not just stateless computations) and fault tolerance, but underlying them all will be mature implementations from a range of vendors. And JBoss has spent the last few years rearchitecting our application server, for instance, to help us address many of these things. The JBossAS 5 architecture, with the Microcontainer, allows us to have a real services based platform, with minimalist profiles and shared servers, which is precisely what you need in both public and private Clouds.

"What I'm particularly after is a services architecture that CORBA espoused but which many people overlooked or didn't realise was possible, particularly if they spoke with the large CORBA vendors at the time: an architecture where the services could be from heterogeneous vendors as well as being based on different implementation languages. This is something that will be critical for the cloud, as vendors and providers come and go, and applications need to choose the right service implementation dynamically. The monolithic approach won't work here, particularly if those services may need to reside on completely different cloud infrastructures (cf CORBA ORB). I'm hoping we don't need to spend a few years trying to shoehorn monoliths in to this only to have that Eureka moment!"

You should expect a lot more of this from us as we move through JBossAS 6 and into JBossAS 7. We may not be as vocal as some, but we've been tracking these evolutionary changes for a lot longer than most. But of course there are almost daily announcements from others about Cloud-this or Cloud-that. Lots of nice words, but still leaving a lot unstated, and perhaps deliberately so.

"But there are still a number of uncertainties around where this new wave is heading. One of them is exactly what does this mean for applications? On the one hand there are those who believe applications and their supporting infrastructure (middleware) must be rewritten from scratch. Then there are others who believe existing applications must be supported. I've said before that I believe as an industry we need to be leveraging what we've been developing for the past few decades. Of course some things need to change and evolve, but if you look at what most people who are using or considering using Cloud expect, it's to be able to take their existing investments and Cloudify them.

This shouldn't come as a surprise. If you look at what happened with the CORBA-to-J2EE transition, or the original reason for the development of Web Services, or even how a lot of the Web works, they're all examples of reusing existing investments to one degree or another. Of course over the years the new (e.g., J2EE) morphed away from the old, presenting other ways in which to develop applications to take advantage of the new and different capabilities those platforms offered. And that will happen with Cloud too, as it evolves over the next few years. But initially, if we're to believe that there are economic benefits to using the Cloud, then they have to support existing applications (of which there are countless), frameworks (of which there are many) and skill sets of the individuals who architect them, implement them and manage them (countless again). It's outsourcing after all."

The Cloud will be driven by workloads. And if you look at Java specifically, the majority of those workloads run on a Java EE application server of one form or another. That could be a closed source commercial offering, a support-subscription one from ourselves, or even just the free community version(s). Why is this so? Because of what I said earlier: enterprise applications require enterprise middleware. Yes some people try to start of simple with a Web server here and a messaging component there, then throw in a database, transactions and a smattering of security for good measure. And before you know it you're running an application server in all but name, with the headaches of addressing cross-component interoperability that these ad hoc solutions tend to throw in your direction at all times of the day and night.

Now one of the things I hear a lot about the latest range of Cloud hype is "simplicity". But what exactly does this mean? Well in the immortal words of Inigo Montoya: "You keep using that word. I do not think it means what you think it means." If you dig deep into these announcements I don't think it's simplicity for existing workloads. Neither is it simplicity for management. It may be simplicity for POCs though.

"if you want to move to this type of cloud then you'd better be expecting to re-code some or all of your application. Oh joy. Here we go again! Even the tag line of "... write once, deploy anywhere" is a lot of smoke-and-mirrors. "Deploy to any one of four vendor specific Clouds, but don't forget about the lock-in potential there" would be more appropriate."

If you're after simplicity for development then things don't come much simpler than Seam. And regardless of what some may believe outside of the JBoss community, Seam is central to almost everything we are doing, whether or not Cloud related. And guess what? Seam and Weld, the CDI reference implementation, help you avoid the vendor lock-in because they're based on standards. Yes, standards! Those things that many of us take for granted and which some vendors carefully avoid, stymie or simply ignore for expediency. And yes the word standard has a well defined meaning, it's really not open to arbitrary interpretation!

"Maybe it's simply due to where we are inthe hype curve, because I can't believe that developers and users are going to throw away the maturity of thought and process that have been built up over the past few decades concerning standards (interoperability, portability etc.) Or have the wool pulled over their eyes. Of course we need to experiment and do research, but let's not ignore the fact that there are real standards out there that either are applicable today or could be evolved to applicability by a concerted effort by many collaborating vendors and communities. You don't want to deploy your applications into a Cloud only to find that you can't get them back or can't integrate them with a partner or customer who may have chosen a different Cloud offering. That's not a Cloud, that's a prison."

So back to what started this discussion. Are we late to Cloud? Are we ignoring key projects like Seam, when it comes to Cloud? Are we ignoring standards? Is Enterprise Java missing from the Cloud? The answer to all of these questions is a resounding NO. You only have to look at efforts like BoxGrinder, TorqueBox, CirrAS, CoolingTower, Infinispan, the Data Services Platform, HornetQ and many many more to understand why that is the case. Our investments in these areas has increased significantly over the years. What's probably missing is our ability to vocalize these efforts more and evangelize them. But hey, if you're actually working on kick-ass products you tend to find it hard to talk about them as often as you'd like!