The industry consensus is that the PaaS market in general is growing slowly and lagging the hype curve. However,  there is already a host of Paas vendors with some form of enterprise Java support,  just like in the hey days of the Java Application Servers. From Google with it’s App. Engine to even Microsoft making a play for Java developers on Microsoft Azure, there is a whole bunch of platforms including Amazon, CloudBees, Cloud Foundry, Cumulogic, Force.com, OpenShift and the list goes on.

I could make a detailed comparison of the different platforms (I’ll save that for JavaOne 2011). Instead, I am left marveling at how Java, or more accurately the Java  ecosystem, has been able to spur the recent growth of the PaaS market despite being considered old at a decade and half. No doubt that many of these PaaS platforms support other languages as well like Ruby, Python and so on, but it seems like the defacto choice for enterprise deployment is .jar, .war or .ear files, or some flavor of that. Consequently, PaaS vendors are opening up their platforms to Java developers including supporting the APIs that Java developers are familiar with and hope that they come in droves when they make a move to the cloud.

OScon Java had it’s share of talks on Java. The “Good, Bad, and Ugly of Java” talk went into how the designers of Java mostly made good choices in the initial design of the language that has withstood the test of time and made huge inroads into the enterprise. The talk by Twitter about using the JVM for better performance and to tap into a large developer population while keeping the operations folks happy at the same time since they understood JAR files, how to interpret GC logs, etc. goes to say how important are the aspects of familiarity and not introducing something fundamentally new within the enterprise.

Given a choice between agility and familiarity enterprise developers pick familiarity for a variety of reasons. Of course if you can add in agility as well that the cloud in general and PaaS  in particular provides to an existing environment, it becomes a very compelling value proposition to enterprises.

It would be disingenuous to claim that Java is the only agent that might facilitate the crossing of the PaaS chasm. The gradual embrace of Open Source in the enterprise, the variety of technological improvements and a motivation to control costs will help in the growth of PaaS. Enterprises realize that getting to PaaS i.e. migrating apps. to PaaS is expensive and time consuming and are holding off on migrating to PaaS en mass. This could be substantially eased by significantly reducing the learning curve and not having to introduce entirely new design paradigms.

Many of the PaaS vendors are taking the familiar application development lifecycle and products (like the Tomcat server) that Java developers know and love and adapting it to the cloud. From providing a version control system (like git or svn) to being able to analyze logs, deploy newer versions and even rollback to earlier versions all with a few clicks, the goal seems to become a part of the PaaS rush that Java and other developers are poised to make.

The sessions I attended were varying in technical depth, but, mostly had stuff and minimal fluff. I did manage to pick up some great nuggets. It was definitely worth my time. I was at a 60-minute expert panel where questions ranged from the future of Java after Sun is consumed by Oracle, future of Java 7, scripting languages, deployment, EJBs, Rich Internet Applications including Flex and JavaFX and the gamut.

What surprised me most was that there was not a single question on the cloud and the word was barely even mentioned. It did come up once as a substitute term for the internet.

While Amazon and Infrastructure as a Service has made a huge dent on startups and small companies and IT organizations for the ability to outsource the data center, I think the cloud has made a very minimal impact on the developer mindshare — for now anyway.

The reasons for this are certainly varied. Developers are probably waiting for the hype to die down to make an assesment of the reality. Unlike evolving distributed system models, from socket programming, to RMI, to web services and so on, the cloud does not seem to be introducing a new programming paradigm. The developer tools are still evolving and there does not seem to be a set of APIs for the cloud other than the Platform as a Service which are relevant to that particular platform alone.

In my informal conversations with the attendees, there were lot of other things besides the cloud that occupied their minds. So, the question that was foremost in my mind after attending the conference was “Is Cloud Computing on the developer RADAR? Really?” Or was it too small a sample size to be representative?

One of these fallacies is that “Latency is zero“. In traditional computing, the compute and data was typically hosted on the same system and the data latency was determined by the storage disks and the data bus speeds.  It was a simple matter of buying better hardware to overcome data latency if it was ever an issue. In cloud computing and especially when we get to network of clouds with data expected to flow around different clouds, latency (however minimal it is) could be an  issue depending on the data being manipulated, the network speeds and so on. Add to this the fact that the entire data or part of the data should be encrypted and decrypted when it moves around unreliable and public networks, and the fact that data needs to be streamed, latency will soon add up and could become a serious issue.

In the web era, many companies like Akamai have specialized in making data available closer to use and minimizing network latency. Some of these and other companies are already looking into this issue vis-a-vis the cloud, but, just the other day when I was twiddling my thumbs waiting for a not-so-big file to upload from my desktop to my EC2 machine instance, I was wondering how many of those dabbling with cloud computing would eventually be faced with the same question that I did, “How does Data Latency affect my cloud solution or design?”.

In my previous blog I alluded to the different taxonomies of cloud computing and how as a developer Platform as a Service might be more interesting. There are more 1-off applications in an Infrastructure as a Service (IaaS) cloud rather than a Platform as a Service (PaaS) cloud. However, applications deployed in a PaaS cloud are more focussed on solving a (or a set) of business problem(s) for a typically large community of users. Drawing a comparison to the  app stores,  the goal of Platform as a Service is to offer a superior platform (technology matters, but, is not the main focus)  that helps leverage the ecosystem and the community.

How important is it for you application to leverage an existing platform and an existing user base? Is it important enough that it might become the sole criterion to choosing a particular cloud vendor?

This vacation was a little bit different in that we (actually my wife flat refused) did not sit through a 90-minute timeshare presentation. However, having sat through a number of presentations, we’ve certainly pondered and sometimes come very close to buying a timeshare ownership.

The analogy between cloud computing and a timeshare ownership is pretty remarkable. There are some major differences as well, but, work with me here. To own properties at different vacation spots would be a major investment upfront and significant investments to maintain and upgrade throughout the life of ownership. It would also lead to poor occupancy unless it’s converted to some type of rental property. Plus for argument sake (or not) consider that these properties significantly depreciate in value. When you factor this depreciation cost, timeshare ownerships seem very promising.

The promise of cloud computing and storage is to decrease the initial investment, or what is referred to as Capital Expenditure or simply CapEx. The running investement thereafter, referred to as Operational Expendire or OpEx needs to be controlled or maintained. A timeshare certainly offers this. Also, it’s less riskier to dump a timeshare ownership rather than a property that you own.

However, there is a concern of security and privacy and being able to interoperate between different clouds. The concrens of security and privacy could be significantly alleviated with appropriate technologies. Since you end up buying a fractional ownership, you are much less vested in the upkeep of the property that you end up using and this could be a huge issue with a timeshare ownership of a property versus timeshare ownership of storage or compute cycles. You buy a timeshare ownership with an agency and the sales pitch is that they have working arrangements with other agencies to be able to use the properties that thet control. However, the reservation and billing procedures are significantly convoluted that it may not be easy to transfer your ownership to that favorite property easily. Likewise, with the lack of standards in cloud computing it may be very difficult to transfer the ownership.

The main allure of cloud computing is the promise of infinite scale. The analogy somewhat breaks down here. I guess there is a reaching argument to be made that you could buy more weeks of a timeshare ownership much more easily than to buy more properties, but, maybe you can help me fill this in.

As the mobile platforms start to dominate information consumption and information manipulation, what are its implications on the backend?

The Apple’s Appstore, the Android market, the Blackberry business solutions, and other mobile applications is rendering platforms relevant again.

Is it the case of the tail wagging the dog, or from a developer perspective is it a different paradigm?

Gregor Hohpe of Google has written in a very succinct manner about why Starbucks does not use Two-phase commit. The asynchronous fashion of coffee ordering and delivery could be solved by a correlation identifier which is roughly the name of the customer and the drink scribbled on the coffee cup. Since I am not a big fan of Starbucks, don’t understand why anyone has to pay a fortune for a cup of so-so coffee and most importantly don’t like to pay for wi-fi, I’ll take this metaphor to Panera Bread. When the customer places the order, (s)he  is handed a token which vibrates and lights up when the order is ready. Out-of-order delivery is almost the rule than the exception, but, the “take order and deliver” conversation with the customer is complete when (s)he picks up the order and places the lighted token in the bin. It is by no means a perfect protocol and depending on the speed and scheduling of the workers, it’s likely that a similar order placed ahead of another order might be delivered later than the order which was placed later. But, does it matter as long as the customer is sitting for a few extra minutes next to a cozy fireplace and enjoying a drink? The article also talks about compensating transactions to deal with some of the issues. However, the main goal of maximing throughput without compromising customer satisfaction entirely seems to be achieved. This form of a conversation is probably acceptable for ordering coffee or small ticket items.

Can a similar conversation be applied when a customer is buying a car? There a various regulatory requirements that need to be complied with during the process of “take order and deliver”. For example, unless a valid driving license is produced, customer may not be able to take vehicle for a test drive and obviously until there is a valid proof of auto insurance, the vehicle cannot be driven out of the dealers lot. There are still some optimizations that could be made — the credit check, application and approval for an auto loan could happen whilst he customer is doing the test drive or is doing the price negotiations.

How could you capture the true essense of a conversation on the cloud? The Web Services Choreography Description Language (WS-CDL), the Web Services Business Process Execution Language(WS-BPEL) and Web Services Transactions (WS-Transactions) can all be used to capture the context of a conversation or depending on the the nature of the conversation you could prefer to go the Starbucks or the Panera way.

What’s your definition of a conversation?

As a member of the very first joint Working Group between W3C and IETF chartered to form a standard on XML Digital Signatures, I do have first hand knowledge of the long and arduous road in forming a new standard. However, the ability to reach consensus and being able to provide a level playing field among a number of players is a critical goal of the standards process. The oft-mentioned criticism of too many standards, many of them ad hoc than de jure pervading the world of web services for instance was targeted by the WS-I and OASIS whose goals was to disambiguate the standards and create targeted profiles aimed at interoperability. Some of the profiles like the WS-I Basic profile and the SAML profile are the basis for many web services today.

Standards is a typically time-consuming process and perhaps there is a little patience on the part of the vendors these days. But, a large part of the cloud can benefit from standards. For example, standards for billing, security and privacy, Workflow and orchestration, SSO and the list goes on … Is there a cloud profile(s) in the offing that can benefit the cloud vendors and the developers in the long run?

This depends on the definition of Cloud Computing of course. Rather than getting caught in terminology, let’s take the metaphor of the transportation industry.

The users of the the cloud are the commuters. It’s a significantly different user experience to travel by a car than to take the public transport. The massive public transport infrastructure that is being built by the Amazons, EMCs, Microsofts and so on is making commuters wonder about owning a car, finding a parking space, and so on versus a “pay as you go” fee. The infrastructure is infinitely scalable in theory.

On the other hand there are quasi-public transportation services that is offered by some companies. They may utilize the existing infrastructure or provide their own infrastructure. Their promise to the commuters is to take away the commute headache. Their goal is to offer simple to luxurious transportation and to make money by offering a number of bundled services. They also deal with the necessary but mundane aspects of multi-tenancy, billing, security, privacy and guarantee a SLA. The equivalent of this in the cloud computing world are the Googles, Intuits, and Salesforces.

Microsoft, with it’s Azure platform is both an infrastructure and a platform provider.

As a software developer whose role is analogous to a service builder or a developer, the Amazon model is not very interesting. Yes, there is serious money to be made by offering the massive infrastructure and very interesting to the big companies, but, only marginally interesting to a developer. It’s also interesting to the user or the commuter since the commuting woes could be significantly alleviated. However, it’s the ability to provide niche or even broad-based services that will make the “mom and pop” companies or the independent developer thrive.

As discriminating commuters are attracted by these specialized transportation services, they might be willing to try some of the newer services, like paying for an in-seat video, purchasing gourmet meals and so on. As a services developer, the frustration is the lack of standards which makes it very difficult to package the same service with more than one of these specialized transportation companies or even integrate these diverse services that is leading to the notion of the “walled garden.”

Clearly Cloud Computing means different things to different participants. Rather than belaboring this metaphor any further, let me end this with should the developer really give a @#$% to Cloud Computing?