Re: [platform-vision] Meeting minutes (and more), September 10/2014

[Martin Lippert <mlippert@xxxxxxxxx>]

Hey Wayne,

even though there was a follow-up call already, here are some comments about your notes of the first call.


> Microservices was a big topic of discussion. A developer's environment will be a collection of microservices working together with loose coupling on the backend with tight integration on the frontend. Products are a composition of microservices.
> 
> We talked briefly about distribution of microservices. Are they all hosted by a single provider or is there a collection of hosts? 

I think one of the advantages of this async-messaging-service-architecture is that those services can be hosted anywhere. Different providers, companies, etc. can host their own services wherever they want and connect (via the messaging) to the rest of the cloudy tooling. For example a CI server hosting company could run their service in their own environment and connect via messages to the rest of the cloudy tooling.


> We talked about the evolution of the notion of a plug-in. Today, we use the terms plug-in and bundle interchangeably. We discussed how the concept of a plug-in is actually bigger than that when you consider examples like the integration of services running in the cloud. An OSGi bundle might be the integration point between an Eclipse-based IDE and the service, but the service and the collection of technologies that provide various integrations of that service are collectively the "plug-in". Perhaps we need a new word.

I don’t think the word “plug-in” fits nicely into the cloudy world anymore. It works for the Eclipse IDE, maybe for the Orion client, maybe for Che, but I don’t see something like a plug-in for the overall cloud tooling environment. To me it feels like a new feature might come with a service running in the cloud, a web UI for configuring it, an Orion UI plugin for hocking a special action for it up in the Orion UI, or a plugin for Che to do something similar (although I don’t know enough about Che here).

OSGi bundles are a totally different and specific technology that might be used by some of the participants in this tooling world (like the Eclipse IDE), but it certainly isn’t important anymore in the wider cloudy environment architecture, where an OSGi bundle becomes an implementation detail of individual parts. And I assume that many parts of the cloudy tooling environment will be built without coming even near OSGi (and this is not meant as a criticism of OSGi at all).


> Provision, share, and scale are notions that do not apply to the desktop.

I agree, but another thought here is:
There might be options for the desktop IDE to also integrate and benefit from services that are running in the cloud. Maybe that is an optional thing, but that way the desktop IDE would also benefit from scaling benefits in the cloud.


> Much of the discussion on the call was concerned with the cloud space. The vision/strategy must acknowledge a vibrant and growing desktop IDE space. The notion of leveraging microservices applies equally well to the desktop and cloud.

+100


> It may be time to start dropping support for some platforms (Eclipse Platform-specific).

This is brings up an interesting additional question:
What are the additional “platforms” that we need to support from the cloudy perspective?
- different browsers (with different versions)?
- different stacks to operate cloudy services on (pure AWS, Cloud Foundry, OpenShift, whatever…)?


Just a few thoughts and maybe items to chat about and/or discuss. Would be interesting to hear your thoughts…

Cheers,
-Martin