User Tools

Site Tools


Dave Orme muses about agile and functional programming.

My current work emphasizes SOA applications using Scala, Kubernetes, and AWS with a React-based SPA front-end. I'm also interested in progressive web applications and developer tools.


Scala, Clojure, and FP


The Cloud

Data-First Development

Older work

Coconut Palm Software home

Donate Bitcoin:



Kubernetes, Docker, Streaming Data, Spark, Scala, Clojure, OSGi, Karaf, GCP, AWS, SQL


Everything I say here is my own opinion and not necessarily that of my employer.


E4 - An End-to-end Cloud Computing Platform

Eclipse and Android have a long history of playing nicely together. So it was only natural that I would buy an Android phone (since ERCP wasn't available when I was looking).

I was expecting good things. But I wasn't expecting to be blown away by Android's implementation of cloud computing. In the end, I was blown away and more.

This is my story of why I was blown away by all of the nice little things that Google did, and how I think that the larger application architecture implemented by Google's platform (delivered on Android or not) represents a potentially huge opportunity for E4.

GPhone 1.0 - Representative of an Eclipse opportunity

My T-Mobile G1 is the first thing I've seen that is more useful to me than a PalmOS device for actually organizing my life.

There are two ways of looking at the reasons why this phone serves me better than a PalmOS device: a user's point of view and a technical architecture point of view.

The user's view

The PIM applications are excellent. They aren't perfect, but they are excellent. But there are lots of excellent PIM applications out there, so this part of the G1 experience is actually fairly unremarkable.

The remarkable part of the GPhone experience is that from a user's point of view, there is almost no difference between using GMail on the phone and using the web app. They're both fast, and they are automatically in sync with each other.

The same is true of the calendar application and Google Calendar. From a user's point of view, the whole notion of “syncing my PDA” just disappears.

The first big deal is that my data is just there where and when I need it, no matter where I happen to be. There is no manual sync step. It's hard to overstate how much more productive this makes me.

The second big deal is that the applications integrate with each other, both on the phone and on the web. For example, if I get a meeting request in GMail, it (usually) helpfully offers to put it on my GCalendar, which is then automatically synced to the calendar app on the phone.

Just like Eclipse 2.0 and Eclipse 3.0 achieved a large productivity boost using lots of little features, the same can be said of the G1 combined with Google's suite of online applications. It's the first really well delivered proof of the benefits that I think “cloud computing” should deliver.

The architect's view

How does this all work?

The data actually lives both on the phone and in the cloud: on Google's servers. (Well, most of it anyway. GMail only keeps your most recent email actually on the phone. But for the purposes of this article, that's an implementation detail)

Then the phone and the web applications are automatically synced periodically. This is done often enough that they are rarely out of sync.

So there's actually a rich graphical application running on the phone. It's synced using the phone's internet connection with the corresponding Google application. In an enterprise environment, it would also be synchronized with Notes, Outlook, etc.

The result is that email on the phone is actually a suite of 2-3 applications (mobile, web, desktop) that all automatically stay in sync with each other. They all feel like they are really one application and it's mostly impossible to say (from a user's point of view) where the data actually is stored.

But as described above, the mail client and the calendar integrate too. The integration appears to happen both in the web app and on the phone, but from the user's perspective it's all seamless since everything is synchronzed. From the user's point of view, their data is just always available, whenever and wherever they need it.

So from the user's point of view, again, the data lives in “the cloud”, as-in the network cloud. And local replication and queuing are used to give the illusion of being online all the time, even if there happens to be no signal at a given moment.

The Eclipse Opportunity

The trend is for data to be available anywhere, all the time. “Cloud computing” is the catch phrase that to me really signifies a very specific style of (often mobile) distributed computing architecture that enables this kind of integrated application suite.

If I wanted to deliver a service myself that does this, there's a whole lot of pieces to the puzzle. But it's really hard to go wrong choosing Eclipse RCP. This is because at a minimum, you can build both a desktop and a Web 2.0 version of the same application from the same code base (not 100% reuse, but close). Shortly, ERCP will let you build the mobile version for some phones too with a very high level of reuse. And today, you can also reuse a lot of the core functionality and do an Android UI with a really significant amount of code reuse.

So one code base can deliver all aspects of a cloud-based architecture if it's built on Eclipse.

So what is “cloud computing”, really? The fact that your application might be hosted on Amazon EC2 or some other service is merely a coincidence of the economies of scale that make it cheaper to pay someone else to run the data center, keep the backups, provision servers, and so on than to do it oneself. In the media, “cloud computing” sometimes refers to the hardware infrastructure that enables “cloud computing” applications.

But at Eclipse, we're all about the applications. So that's the sense in which I'm talking about “cloud computing”. We are a platform for creating applications serving everything from the mobile space all the way through desktops and servers, now to Web 2.0 applications.

With E4, we now have all the pieces in place needed to build successful “cloud computing” application suites.

In my view, this sort of evolution is just a logical next step for the computer industry.

And in my view, Eclipse is ideally positioned to lead this charge.


Cloud computing is trendy. Jumping on a trend for trend's sake is probably self-defeating. But I think that Eclipse can make a really good case that if we are not the only end-to-end stack serving every aspect of a cloud-based application, that we're the most mature and successful.

I think we should ride this wave for all it's worth.



blog/e4_-_end-to-end_cloud_computing_platform.txt · Last modified: 2014/10/17 22:08 (external edit)