Wayne:
Thanks for these notes. I will struggle to participate consistently on the phone for the next month given Codenvy's launch cycle.
If I may comment on the thread.
The thread below implies the future is primarily one that is asynchronously decoupled. We talk about migrating our products so that microservices and clients are decoupled from one another. Decoupling of microservices is a key architectural principle. What is not clear yet is whether this decoupling is asynchronous, synchronous, or both. It strikes me that we should probably avoid dictating the form of connectivity to microservices, otherwise we end up biasing one technology choice over another. Users may have different types of experiences depending upon the nature of the connectivity, ultimately allowing the ecosystem to pick and choose how to integrate with services with a variety of technologies to optimize for their particular user scenarios.
Another few points:
1) There are likely going to be three types of microservices, if you will. Those that deal with provisioning (users, workspaces, resources, accounts, permissions). Those that deal with workflows (projects, services, sequences, builders, unit testers, runners, packagers). Those that deal with language services (JDT-style capabilities). It's easy to think about JDT as a service potentially being a nice way to grow in the market, but these types of core microservices may or may not be accessible outside of an authentication context, for a variety of security reasons. So, any discussion about a future of microservices probably has to discuss standardization of provisioning & workflow services, too. This is a bit of a gray area, as again, this wanders a bit into the vendor side of the world. But I again submit that Eclipse as a governing body is one that is expected to release usable, hardened offerings, so we have to account for some of this in the thinking.
2) The thread below discussed JDT services. Che has wrappers around JDT and extended it in its own way, so there is a necessary rationalization that must occur. Codenvy has investments going in ant, maven, gradle. We'd like to get out of having to rationalize JDT and our microservice approach over the long haul. Language services should ideally be built once and reusable by Che & Flux at the same time.