Developing in the cloud

Mike Milinkovich of Eclipse on their new cloud initiative

JAXenter Editorial Team

At the EclipseCon Europe 2014, head of Eclipse Mike Milinkovich told JAX Editors Diana Kupfer and Hartmut Schlosser about the new Eclipse Cloud Initiative.

JAXenter: Why do you think now is the time for an initiative like this?

Mike Milinkovich: The movement of tools into the cloud is inevitable. I’ve been in the industry long enough to remember when there used to be forty or fifty desktop IDEs. Today you could find forty or fifty web IDEs or web editors. They’re everywhere. One of the reasons why now, and why the way we’re doing this is we think that this whole market is ripe for consolidation. There doesn’t need to be fifty of them, there needs to be five. And one of the reasons why we think that the Eclipse Cloud Development Initiative is important is that if you look at the amount of code, the amount of people and the companies that are participating in it, it is going to be one of the winners.

There doesn’t need to be fifty web IDEs, there needs to be five.

Eclipse is not a software company, it’s a community. So things happen when a critical mass of people of companies and technologies step forward and say they want to do something. We encourage that, of course, that’s what we do in the Eclipse Foundation, and we’re obviously are big believers in Open Source. Why now? Because Codenvy and Pivotal and SAP and IBM step forward at this time with this code and we now hit critical mass. We’ve had Orion for a number of years. Flux has been around for about nine months, the Codenvy project [editor’s note: Eclipse Che] is just coming in, and SAP Dirigible is just coming in. With those four projects, we said: You know what? That’s enough for the critical mass to make a top level project and to build a community around this.

There are many components in this top-level project, from Pivotal, SAP, and so forth. Is there any connecting link between these components?

Milinkovich: Yes, there is. Of course it is early days. There is not a perfect alignment at this point, and there may never be one. There is more than one use case, so there will be more than one architecture. But, we already have some signs of interesting successes. For example, the standard Flux demo is the Eclipse IDE working with with Orion. Codenvy is already using the Orion editor, and they’re already using Flux for doing integration between the graphical UI and the command line interface things that they have. So you can see that there are already instances of reuse and alignment across these projects. It’s going to take time, and there is  work to be done, but there are already signs of early success.

The reason why I asked why now is because, although there is this big market of cloud IDEs, this doesn’t necessarily mean that everyone uses them. You said in a blog post that 99,9% of development is still done on the desktop. So how long do you think it’s going to take until those cloud IDEs take off?

Milinkovich: I think it’s happening. The Orion team often makes this point. John Arthorne said this morning in a panel [at EclipseCon Europe] that if you look at how developers work today, almost everything they do except for source-code editing already happens in the cloud. Continuous Integration, Git, Sonar for code quality – all those tools are things that you interact with and use through your web browser. Your web-browser is the portal to most of your ALM experience if you work as a developer today. Really the only thing left is the actual IDE, the editing of code and that kind of stuff. And there is a number of reasons why it’s becoming easier and better to do that now.

One is: The performance of browsers relative to where they were some years ago has gone up by an order of magnitude. It was V8 that really kicked that [development] off, and other browsers have upped their game in terms of JavaScript performance. Now you can do things in the browser and expect the user experience to be good enough where some years ago it was impossible.

The other thing is that network latency is getting better and better all the time, too. When, some years ago, I first heard about the idea of doing full-fledged web tools in the cloud, I was a skeptic. Maybe even a cynic.


Milinkovich: Because I didn’t believe that it would be performant enough, that the experience for the developer would be good enough. And now I use Orion myself. And I know that you can actually do good code development in your browser and the experience is decent. Things have just gotten better and faster. So, as I said, a couple of years ago I was a real skeptic about the idea of being able to do this in a browser and the web experience. And now I am a believer. Mostly because I’ve actually seen it with my own eyes and used it.

Were you also skeptical because of data privacy concerns?

Milinkovich: Certainly not at that time. That was pre-Snowden. When I run Orion I run it on my laptop as localhost or on a Raspberry Pi. So, I mean, we have Orion Hub we can host Orion in a cloud. Now you see it in technologies like IBM Bluemix. But I think sourcecode is valuable.

“I’m much more concerned about my visa number and my bank account number than my source code.”

It’s not necessarily personally identifiable information or the kinds of things that we typically worry about. Privacy is important because companies don’t want to have their assets stolen. Maybe it’s just me, but I’m much more concerned about my visa number and my bank account number than my source code. These tools – Orion and Che and so forth – can be hosted them in a public cloud, but there are also lots of use cases where you can host them on premises as well. Then you have more control over the privacy and security aspects.

It’s just the first thing people think of when they hear about “the cloud”: They worry about their privacy.

Milinkovich: Particularly in Germany.

That’s true.

Milinkovich: Yeah, you don’t hear that concern quite as much in North America.

The idea to bring Eclipse into the browser is actually quite old.

Milinkovich: I would be careful here. What we are talking about with this technology is not “Eclipse in the browser”.

Well, it’s not exactly the old idea. But in a way, an old dream is coming true with new components.

Milinkovich: One of the things that we learned doing Eclipse from the very beginning was that what you want to do is build a solid platform that is extensible, and that inspires an ecosystem. And what both Che and Orion bring is an extensible platform. So we absolutely hope to see a similar success. Because its open source, you see adoption. But you also see people building their own extensions for the technology to make it useful in ways that we never imagined. When you think of the different things that people build on top of the Eclipse platform, I don’t think anybody would have ever dreamt it. And we absolutely hope to see that happen again.

Eclipse always has been a platform for integrating tools. So history is repeating itself – perhaps in the cloud space now.

Milinkovich: Unfortunately, for good technical reasons the Che project couldn’t use the Eclipse plug-in model in exactly the same way, even though it’s written in Java. But they got pretty close. One of the main reasons why [Codenvy] were interested in bringing Che to Eclipse was that they would like to see lots of people port their Eclipse plug-ins over to the Che platform. They use that to help bootstrap the ecosystem around Che. That’s what we’re hoping to see happen.

Che is a pretty new project and lots of people still wonder what the difference between Orion and Che is. Can you explain it in simple terms?

Milinkovich: Architecturally, Orion is a tool set that runs in your browser, that has a very lightweight connection to a very simple server. And Che, partially because its target market is compiled languages as opposed to interpreted languages, is a much more intelligent and much more involved server with a thinner client. These differences are primarily motivated by the target markets. Orion is primarily focused on the needs of JavaScript, HTML, and CSS, therefore on people that are building web applications who need a really great JavaScript IDE. They have aspirations to extend that into other areas but that’s really what it is now.

SEE ALSO: A chat with Mike Milikovich about the state of Eclipse 

In Che, the focus was on compiled languages right from the beginning. When you are going to support a strongly typed compiled language like Java and you want to give your Java developer a good experience – they are looking for Code Completion, Code Assist, all the things that we have all gotten very used to because of IDEs like Eclipse – you need to have a smart server that is looking at your code, that is building the abstract syntax tree and the analysis of the code. When a person hits the keys to bring up Code Completion, it has to make that interaction super fast so that the user experience is good.

And then the third thing you have to do is you have to be able to build an architecture that allows you to scale that so you can support thousands of developers on a reasonably sized server infrastructure.

There was one interesting point in the panel discussion about the Flux project that connects different tools. The question was: Can NetBeans and IntelliJ be part of this initiative?

Milinkovich: Sure.  If they build the adapters, they can absolutely use Flux. It’s open source. We’re looking for people to use our open source code. Right now it primarily works with Orion, but if someone wanted to make it work with CodeMirror or Cloud 9, there is no reason why that wouldn’t work.

So what are the next steps in this top-level project?

Milinkovich: We have a lot work to do to bring Che and Dirigible in. I mean, you guys have been following Eclipse long enough to know that when a new project comes in, we do our due diligence and so on. That’s a lot of work at the beginning. We have to get through that, and get to the point when go to the Eclipse website and hit “Download” and have Che running on your laptop or running on your server like that [clicks his finger]. That’s going to be job number one for Che and Dirigible. Che is bigger, but they’re both pretty big projects and they both have a lot of code and a lot of dependencies, so it’s going to be quite some work to get them into the Eclipse family. That’s looking inward.

The world of cloud development is “not that smart”

Looking outward we have a lot of work to do to make people aware of Che and make the world of tool vendors and cloud vendors aware that they now have this really cool technology platform that is open source that they could use in their infrastructure. So I would love to see Che show up in, say, Cloudfoundry or someplace like that.

It’s sort of ironic: If you look at the world of cloud development right now – Amazon, Azure, OpenShift, Cloudfoundry, Bluemix, etc. – what’s the first thing they tell you to do when you develop for the cloud? Go download 200 Megabytes of Eclipse on your desktop. That’s really not that smart.

What would be a lot better would be “Hello, welcome to our cloud. Here is you developer credentials”, and – tadaaa – right there is your development environment. That’s the way cloud-development should be. Your cloud-development should be hosted in the cloud that you’re targeting and it’s part of the developer offering for the cloud. That just makes so much more sense. So we have to work on raising awareness and getting some of these companies to start using this. Adoption is what feeds everything else in open source. We need people to use it – because if they use it, they contribute, and that’s how you move the project forward.

So on the one hand it’s about raising awareness for the single projects, but Martin Lippert also said an interesting thing this morning. He said that it’s about creating one product out of these services and projects. Is that sort of a broader vision for Eclipse Cloud Development and other Eclipse initiatives as well?

Milinkovich: Desktop Eclipse has some amazing technology for tooling. But it’s a monolith. I mean it’s written in plug-ins but it’s still a big chunk of code and it’s meant to run on a desktop. Wouldn’t it be cool if you could disassemble that into a collection of microservices that sometimes run on your desktop and sometimes run in the cloud? That sort of architecture plus the ability of Flux that make your code available wherever you want it.

What we want to achieve is a seamless developer experience that lets developers use the tool that they have, in the context that they are in, to do what they need to do. I think it was Martin [Lippert] who said: “I want to do my day to day development on my laptop but if I’m at the airport and there’s a critical bug, I want to be able to fix it on my iPad. And I don’t want to have to think about how I can replicate all the stuff on my iPad. I want to turn my iPad on I want my code exactly the way I left it when I closed the lid on my laptop before I headed for the airport.” That´s what you want. And that’s what we want to build over the next couple of years. It´s a vision – not a promise.

When I ask people here at EclipseCon: “Do you think this is an interesting idea to bring the IDE into the cloud?”, the answer is: I don’t want to code on my iPhone.

Milinkovich: Two things. First: The people who come to EclipseCon are not necessarily the target audience for the tools that we’re talking about – because they are all probably world-class-experts on using the Eclipse IDE. Second, when we say “tools in the cloud”, well, you could get some code on your iPhone, but nobody would do that. It would be some sort of emergency thing. You’re still talking about using your laptop as the main experience for your coding. I think that actually underlines the importance of Flux. There are still going to be cases where even the most die-hard Eclipse fan will do 99% of their programming on their laptop.

“If you’re developing for a cloud,
why wouldn’t your tools be in that cloud?”

But there’s that one percent time when they really are at the airport and they need to get to their code to fix something. This becomes more and more important in cloud delivery where you have Continuous Integration and Continuous Delivery, where backing out a change that broke something is pretty important to happen pretty quickly. I think that if somebody says “Why would I want to code on my iPhone?” I’m pretty sure they actually don’t understand what we’re talking about. Because they are such experts on Eclipse, they’re going to be the last group that switches.

But if you’re developing for a cloud why wouldn’t your tools be in that cloud? If you explain it that way I think it’s easier to understand.

In this way, configuring workspaces for big enterprises will become much easier.

Milinkovich: That is one of the fundamental value propositions for Che. Part of the reason why Che is really interesting is that it’s a platform for configuring a tool chain for a particular ALM and deployment model. Well, you can sit in front of a command line in Che and build a tool chain using Travis and GitHub and so on. It will basically build you a work-space that is pre-configured to make you productive in exactly that. And that is pretty cool.

This cloud development project has the potential to be super important. Especially when you start to see it influencing the architecture of the Eclipse IDE itself. That’s going to be really cool to watch over the next couple of years.

Inline Feedbacks
View all comments