The Java PaaS Rush – Crossing the Chasm?

As the National Football League (NFL) season opens up and teams are tweaking their rosters, I am pondering a different kind of PaaS rush.

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.

Is Cloud Computing on the developer RADAR? Really?

As kids head back to school, I went back to school as well. I was extended an invitation to attend the No Fluff Just Stuff conference which is a small and compact conference where everyone seems to know everyone else. The attendees all seemed to be hard core developers or architects who seemed to be in tune with the future but mostly focussed on the present.

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?

What about Data Latency and cloud computing?

Over a decade back when we were still in the CORBA days, Peter Deutsch came up with the fallacies of distributed computing. Many distributed systems have been flawed due to willfully ignoring some of the fallacies and expecting technologies to obviate some of the inherent limitations in distributed computing. The premise was that those developers and designers who ignored these fallacies would in effect end up with a distributed system that would have some serious limitations in its functionality sooner or later. It was best to plan for some of these problems which was (and still is) inherent in distributed computing.

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?”.

What is the most important criterion in picking your cloud vendor?

With the recent launch of the Blackberry App World program in line with Apple’s App Store and Microsoft expected to launch it’s own app store in the not too distant future companies are expecting developers to have their own skin in the game. The Blackberry App World program requires a registration fee of 200.00 USD which is no chump change. In return, freelance developers are able to market their applications to the global customer base that they typically would have difficulties reaching without a huge marketing budget. In the ideal scenario, as more applications become available and more users start using it, more developers start participating, creating what I heard as the “flywheel effect” from Wener Vogels, CTO at amazon.com. The faster this flywheel turns, the sooner it will result in a significant drop of prices for everyone involved.

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?

Would you rather own or timeshare?

I just returned from a vacation last week (from which I still need a couple of days to recover) and any discussion on clouds was simply unwelcome. In talking to some developers this week it’s becoming apparent that we’re still at the stage of “why and what is cloud computing” rather than “how to do cloud computing.” There are plenty of cloud storage case studies as opposed to cloud computing. There is undoubtedly a lot of experimenting and early implementations of cloud computing, but, there are lot of developers still wondering about the relevance of cloud computing.

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.

Is it the tail wagging the dog?

The World Mobile Congress which was one of the craziest conferences I attended for it’s sheer size gets underway next week. Good luck finding a room in Barcelona with the conference coinciding with the Valentine’s day weekend.

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?

What’s in a conversation?

As the planning for the Intuit Partner Platform proceeds, the topic of a long-lived transaction popped up. A long-lived transaction, or a conversation is asynchronous by its very nature. Other properties of a conversation is that data flows across multiple organizational boundaries in the same cloud or different clouds. Do we absolutely need to have the ACID properties of a typical transaction associated with it?

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?

Are new/more standards required for the cloud?

A wikipedia search on cloud standards reveals a few standards at different levels of maturity. Apart from http, REpresentational State Transfer (REST) and to some extent OpenID there does not seem overwhelming support amongst cloud vendors. Then there is the newly formed Open Cloud Consortium the goal of which seems to be for interoperability between the clouds and not leave them as islands and there is a real danger of this happening. For example, a salesforce application could very well need access to QuickBooks data from an application in the Intuit Partner Platform(IPP) and currently REST-based APIs seem to be the answer.

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?

Why the @#$% should a developer care about cloud computing?

Is Cloud Computing a fundamental paradigm shift or just old wine in new bottles as far as a developer is concerned?

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?

Unanswered Questions blog

I have been intrigued by the statement “it’s better to have an unanswered question than a unquestioned answer.” Consequently, I’ll be raising questions in my blog that will remain unanswered (by me anyway). Hopefully, these questions are insightful enough.