Suche
Mike Milinkovich über die Cloud-Development-Initiative der Eclipse Foundation

IDEs in der Cloud: „Es ist Zeit für eine Konsolidierung!“ [Mike Milinkovich]

Redaktion JAXenter
Milinkovich

Mike Milinkovich, Executive Director Eclipse Foundation

Unter dem Dach der Eclipse Foundation haben die Unternehmen Codenvy, IBM, Pivotal und SAP Ende 2014 eine Initiative für Cloud-basierte Entwicklungswerkzeuge gegründet. Über Ausrichtung und Zielsetzung der Initiative unterhielten wir uns auf der EclipseCon Europe mit Eclipse-Foundation-Direktor Mike Milinkovich. Neben Details zum Top-Level-Projekt Eclipse Cloud Development (ECD) verrät uns Mike auch seine Vision für die Softwareentwicklung in der Cloud.

Eclipse Magazin: Hallo Mike. Warum war es an der Zeit, die Cloud-Development-Industrie-Initiative ins Leben zu rufen?

Mike Milinkovich: Tools verlagern sich zwangsläufig in die Cloud. Ich bin lang genug in dieser Branche unterwegs, um noch zu wissen, dass es einmal vierzig oder fünfzig Desktop-IDEs gab. Heute hingegen gibt es bestimmt vierzig bis fünfzig Web-IDEs bzw. Webeditoren. Sie sind quasi überall. Einer der Gründe, warum wir diese Initiative gerade jetzt gegründet haben, ist deshalb: Es wird Zeit, dass sich dieser Markt konsolidiert! Es sollte keine vierzig oder fünfzig Web-IDEs mehr geben, sondern vielleicht fünf. Wenn man sich die Menge an Code, die Anzahl an beteiligten Personen und Firmen anschaut, steht Eclipse Cloud Development jetzt schon als Sieger da. Deshalb ist die Initiative so wichtig.

Ein weiterer Grund, warum es zum jetzigen Zeitpunkt passiert: Eclipse ist keine Softwarefirma, sondern eine Community. Es wird also nur etwas in die Tat umgesetzt, wenn sich eine kritische Masse an Leuten und Unternehmen engagiert. Wenn das passiert, unterstützen wir die Beteiligten natürlich, denn wir sind offensichtlich starke Befürworter von Open Source. Und gerade haben Codenvy, Pivotal, SAP und IBM die Initiative ergriffen, sodass tatsächlich eine kritische Masse erreicht ist: Orion gibt es ja schon seit einigen Jahren, Flux seit etwa neun Monaten, das Codenvy-Projekt [Che] ist gerade dazugekommen, genauso wie das SAP-Projekt Dirigible. Das war für uns das Signal zu sagen: Das ist genug, um ein Top-Level-Projekt zu gründen und eine Community um diese Projekte herum entstehen zu lassen.

EM: Wie du sagst, sind Orion, Flux, Che und Dirigible Teil des neuen Top-Level-Projekts. Gibt es eine Integrationsmöglichkeit dieser Komponenten untereinander?

Milinkovich: Ja, aber noch steckt das Top-Level-Projekt in den Kinderschuhen. Daher gibt es noch keine perfekte Übereinstimmung, und vielleicht wird es die auch nie geben. Es existiert schließlich mehr als ein Use Case, also wird es auch mehr als eine Architektur geben. Aber wir sehen schon erste kleine Erfolge. In der Flux-Demo wird z. B. die Eclipse-IDE mit Orion verwendet. Codenvy nutzt den Orion-Editor bereits, genauso wie Flux, das sie für die Integration zwischen dem GUI und dem Kommandozeileninterface verwenden. Es gibt also schon Komponenten, die von anderen Projekten aufgegriffen werden. Aber es wird Zeit brauchen, und es liegt noch eine Menge Arbeit vor uns.

Es sollte keine vierzig oder fünfzig Web-IDEs mehr geben, sondern vielleicht fünf.

EM: Es gibt zwar einen großen Markt an Cloud-IDEs, was aber nicht bedeutet, dass sie jeder nutzt. In einem Blog-Post hast du selbst geschrieben, dass 99,9 Prozent der Softwareentwicklung noch immer auf dem Desktop stattfindet. Wie lange wird es dauern, bis diese Cloud-IDEs auch tatsächlich eingesetzt werden?

Milinkovich: Ich glaube, das passiert schon. Darauf weist das Orion-Team oft hin. John Arthorne hat heute Morgen bei der Podiumsdiskussion [auf der EclipseCon Europe] gesagt, dass alles, was Entwickler heute tun – mit Ausnahme von Sourcecode-Bearbeitung – bereits in der Cloud stattfindet. Continuous Integration, Git, Sonar – all das sind Tools, mit denen man über den Webbrowser interagiert. Der Browser ist das Tor zu den meisten ALM-Tools. Das Einzige, was davon ausgenommen ist, ist die eigentliche IDE.

Dabei wird das Kodieren in der Cloud immer einfacher. Ein Grund dafür ist die Performance der Browser, die sich in den letzten Jahren um ein Vielfaches verbessert hat. V8 hat neue Maßstäbe gesetzt, und andere Browser haben in Sachen JavaScript-Performance mitgezogen. Jetzt kann man mehr im Browser erledigen und dabei eine bessere User Experience erwarten, als das noch vor einigen Jahren der Fall war.

Ein anderer Grund sind die Latenzzeiten in Netzwerken, die immer geringer werden. Als ich vor einigen Jahren von der Idee hörte, ausgereifte Webtools zu entwickeln, reagierte ich skeptisch, vielleicht sogar ein bisschen zynisch.

EM: Weshalb?

Milinkovich: Weil ich nicht glaubte, dass sie performant genug und die User Experience für Entwickler gut genug sein würde. Und jetzt nutze ich selbst Orion. Und ich weiß, dass man in der Tat gut im Browser entwickeln kann und dabei eine ordentliche User Experience hat. Es ist einfach alles besser und schneller geworden. Wie gesagt, vor einigen Jahren war ich noch ein richtiger Skeptiker. Doch jetzt glaube ich daran – hauptsächlich deshalb, weil ich die Tools mit eigenen Augen gesehen und selbst genutzt habe.

EM: Warst du auch deshalb skeptisch, weil du um die Datensicherheit besorgt warst?

Milinkovich: Sicherlich nicht zu jener Zeit. Das war vor Snowden. Wenn ich Orion nutze, dann auf meinem Laptop als Localhost oder auf einem Raspberry Pi. Mit OrionHub können wir Orion in der Cloud hosten. Es wird mittlerweile in Technologien wie IBM Bluemix verwendet.

Sourcecode ist zwar wertvoll, enthält aber keine persönlichen Informationen. Datenschutz ist nur deshalb wichtig, weil sich Firmen nicht gerne ihre Assets stehlen lassen. Vielleicht geht es ja nur mir so, aber ich habe mehr Angst um meine Kreditkarten- oder Kontonummer als um meinen Sourcecode. Tools wie Orion und Che können in einer öffentlichen Cloud gehostet werden, aber es gibt auch viele Anwendungsfälle, in denen man sie auf privater Infrastruktur hosten kann. Dann hat man auch mehr Kontrolle über Datenschutz und Datensicherheit.

EM: Datenschutz ist einfach das Erste, woran viele denken, wenn sie von „der Cloud“ hören.

Milinkovich: Besonders hier in Deutschland. In Nordamerika hört man selten solche Befürchtungen.

EM: Eigentlich ist die Idee, Eclipse in den Browser zu bringen, ja relativ alt …

Milinkovich: Da wäre ich vorsichtig: Wir sprechen hier nicht über „Eclipse im Browser“.

EM: Nun, es ist sicherlich nicht die alte Idee, die Eclipse-Desktop-IDE in den Browser zu bringen. Kann man aber nicht sagen, dass das Cloud-Development-Projekt die Erfüllung eines alten Traums mit neuen Komponenten ist? Eclipse war ja immer schon eine Integrationsplattform für unterschiedliche Tools. Diese Erfolgsgeschichte wiederholt sich also vielleicht im Cloud-Bereich.

Milinkovich: Eines, was wir bei Eclipse gelernt haben, ist, dass man eine solide, erweiterbare Plattform bauen sollte, die ein Ökosystem hervorbringt. Sowohl Che als auch Orion sind solche erweiterbaren Plattformen. Wir hoffen also auf einen ähnlich durchschlagenden Erfolg. Weil Eclipse Open Source ist, ist einerseits die Verbreitung groß. Andererseits entwickeln einige Leute auch eigene Erweiterungen für die Technologie, um sie auf eine Weise nützlich zu machen, die wir uns nie hätten vorstellen können. Wir hoffen natürlich, dass das [bei den Cloud-Projekten] ähnlich sein wird.

Leider konnte Che das Eclipse-Plug-in-Modell nicht eins zu eins übernehmen, obwohl das Projekt auch in Java entwickelt wird. Das hat gute technische Gründe. Aber es ist nahe dran. [Codenvy] trug Che der Eclipse Foundation auch deshalb an, weil man sich erhofft, dass viele Leute ihre Eclipse-Plug-ins zu Che portieren. Das Ökosystem um Che soll dadurch erweitert werden.

EM: Che ist ja ein ziemlich neues Projekt, und viele fragen sich, worin der Unterschied zwischen Che und Orion besteht. Kannst du das in einfachen Worten erklären?

Milinkovich: Architektonisch ist Orion ein Tool, das im Browser läuft und eine sehr leichtgewichtige Verbindung zu einem sehr einfachen Server aufweist. Che hingegen verfügt über einen viel intelligenteren und stärker integrierten Server mit einem schmaleren Client, was teilweise damit zu tun hat, dass sein Zielmarkt nicht interpretierte, sondern kompilierte Sprachen sind. Die Unterschiede sind also vor allem den verschiedenen Zielmärkten geschuldet. Orion konzentriert sich hauptsächlich auf die Anforderungen von JavaScript, HTML und CSS, also auf Entwickler, die Webanwendungen bauen und eine wirklich leistungsfähige JavaScript-IDE benötigen. Es existieren zwar Bestrebungen, Orion auf andere Bereiche auszudehnen, aber die bereits genannten machen den Kern dessen aus, was Orion heute ist.

Che legte den Fokus von Beginn an auf die kompilierten Sprachen. Wenn man eine stark typisierte kompilierte Sprache wie Java unterstützen und den Java-Entwicklern ein gutes Entwicklererlebnis zur Verfügung stellen möchte – inklusive Codevervollständigung, Code Assist etc., also all den Dingen, an die wir uns aufgrund von IDEs wie Eclipse mittlerweile gewöhnt haben –, braucht man einen intelligenten Server, der den Code im Blick hat, den abstrakten Syntaxbaum aufbaut, eine Codeanalyse vornimmt und so weiter. Drückt man eine Taste, um die Codevervollständigung aufzurufen, so muss die Interaktion sehr schnell ablaufen, um eine gute User Experience zu erreichen.

Die dritte Herausforderung besteht darin, eine Architektur zu bauen, die so skaliert werden kann, dass die Unterstützung tausender Entwickler auf einer vernünftig dimensionierten Serverinfrastruktur möglich ist.

EM: In der Panel-Diskussion über das Flux-Projekt, das verschiedene Werkzeuge miteinander verbindet, wurde ein interessanter Punkt angesprochen. Die Frage war, ob auch NetBeans und IntelliJ Teil dieser Initiative sein könnten?

Milinkovich: Natürlich. Wenn sie die passenden Adapter entwickeln, können sie Flux problemlos nutzen. Es ist Open Source. Und wir arbeiten für alle Leute, die unseren Open-Source-Code verwenden wollen. Zum jetzigen Zeitpunkt funktioniert Flux vor allem mit Orion. Wenn aber jemand Flux für die Arbeit mit CodeMirror oder Cloud 9 nutzen möchte, sehe ich keinen Grund, warum dies nicht gehen sollte.

Was ist das erste, was man zu hören bekommt, wenn man für die Cloud entwickeln möchte? „Lade 200 MB Eclipse auf deinen Desktop!“ Das ist wirklich nicht besonders clever.

EM: Was sind also die nächsten Schritte in diesem Top-Level-Projekt?

Milinkovich: Wir haben noch eine Menge Arbeit vor uns, um Che und Dirigible einzugliedern. Ihr kennt Eclipse ja nun schon lange genug, um zu wissen: Kommt ein neues Projekt dazu, unterziehen wir die Codebasis einer sorgfältigen Überprüfung, was zu Beginn sehr viel Arbeit bedeutet. Da müssen wir erst einmal durch, bis wir schließlich an einen Punkt gelangen, an dem ein User lediglich die Eclipse-Webseite besuchen und auf „Download“ drücken kann, um Che auf seinem Laptop bzw. Server zum Laufen zu bringen. Das wird zunächst die wichtigste Aufgabe für Che und Dirigible sein. Che ist das größere Projekt, aber beide sind ziemlich umfangreich und verfügen über eine große Codebasis mit zahlreichen Abhängigkeiten. Es wird also einige Mühe kosten, sie in die Eclipse-Familie aufzunehmen. Soviel zur Innenperspektive.

Was die Außenwirkung anbelangt, besteht unsere Aufgabe darin, die Leute auf Che aufmerksam zu machen und der Welt der Tool- und Cloud-Anbieter zu vermitteln, dass ihnen jetzt diese coole Technologieplattform zur Verfügung steht, die Open Source ist und die sie in ihrer eigenen Infrastruktur nutzen können. Ich sähe es also liebend gerne, wenn Che zum Beispiel in Cloud Foundry oder anderen Projekten dieser Art auftauchen würde.

Es ist in gewisser Weise ironisch: Wenn man heute auf die Welt der Cloud-Entwicklung schaut – Amazon, Azure, OpenShift, Cloud Foundry, Bluemix etc. – was ist das erste, was man zu hören bekommt, wenn man für die Cloud entwickeln möchte? „Lade 200 MB Eclipse auf deinen Desktop!“ Das ist wirklich nicht besonders clever. Wäre es nicht viel besser, wenn man sagen könnte: „Hallo, willkommen in deiner Cloud! Hier sind deine Einlogdaten als Entwickler!“ Und schwupps – schon hast du deine Entwicklungsumgebung. So sollte Cloud-Entwicklung aussehen!

Die Cloud-Entwicklung sollte also selbst in der Cloud stattfinden, in derselben Cloud, auf die du abzielst. Sie sollte ein Teil des Entwicklerangebots für die Cloud sein – das würde einfach viel mehr Sinn ergeben. Wir haben daran zu arbeiten, ein entsprechendes Bewusstsein zu schaffen und einige der Unternehmen dazu zu bringen, diese Technologien zu nutzen. In der Open-Source-Welt steht und fällt alles mit der Akzeptanz und Verbreitung von Technologien: Wir brauchen Leute, die die Projekte nutzen, denn wenn sie sie nutzen, tragen sie auch etwas zu ihnen bei – so wird ein Projekt vorangetrieben.

Wäre es nicht großartig, Eclipse in eine Sammlung von Microservices zu überführen, die sowohl auf dem Desktop als auch in der Cloud laufen?

EM: Auf der einen Seite geht es also darum, ein Bewusstsein für die einzelnen Projekte zu erzeugen. Doch heute Morgen erwähnte Martin Lippert noch einen interessanten Punkt: Es gehe auch darum, aus diesen vielen Services und Projekten ein Produkt zu schaffen. Ist das die umfassendere Vision für Eclipse Cloud Development und andere Eclipse-Initiativen?

Milinkovich: Desktop-Eclipse verfügt über einige hervorragende Technologien für Tooling. Aber es ist ein Monolith. Es ist zwar in Plug-ins geschrieben, nichtsdestotrotz handelt es sich immer noch um eine riesige Menge Code, der dafür vorgesehen ist, auf einem Desktop zu laufen. Wäre es nicht großartig, das Projekt in eine Sammlung von Microservices zu überführen, die sowohl auf dem Desktop als auch in der Cloud laufen? Diese Art von Architektur zu haben, plus der Fähigkeit von Flux, den Code wo immer man möchte bereitzustellen? Was wir erreichen möchten, ist eine nahtlose Entwicklererfahrung, die Entwicklern die Flexibilität gibt, das Tool zu nutzen, das sie möchten, in dem Kontext, in dem sie sich gerade befinden, um das zu erledigen, was sie tun müssen.

Ich glaube es war Martin Lippert, der sagte: „Ich möchte meine alltägliche Entwicklungsarbeit auf meinem Laptop erledigen. Aber wenn ich auf dem Flughafen bin und ein kritischer Bug entdeckt wird, will ich in der Lage sein, diesen auf meinem iPad zu fixen. Und ich will nicht darüber nachdenken müssen, wie ich alles auf meinem iPad replizieren kann. Ich möchte mein iPad anwerfen und meinen Code genauso vorfinden, wie ich ihn verlassen habe, als ich meinen Laptop zuklappte und mich auf den Weg zum Flughafen machte.“ So will man das haben. Und so etwas wollen wir im Laufe der nächsten Jahre bauen. Das ist zwar kein Versprechen, aber eine Vision.

Wer fragt: „Warum sollte ich auf meinem iPhone programmieren wollen?“, hat nicht wirklich verstanden, worum es hier geht.

EM: Wenn man sich mit Leuten hier auf der EclipseCon über das Thema unterhält, hört man oft Sätze wie: „Wozu sollte ich auf meinem iPhone programmieren?“ Viele scheinen also noch etwas skeptisch zu sein.

Milinkovich: Dazu fallen mir zwei Dinge ein: Zum einen sind die Besucher der EclipseCon nicht notwendigerweise die Zielgruppe für die Art von Tools, von denen wir hier reden – weil sie wahrscheinlich alle Weltklasseexperten für die Nutzung der Eclipse-IDE sind. Zum anderen: Wenn wir sagen „Tools in der Cloud“, dann kann man natürlich auf dem iPhone programmieren – aber das würde niemand wirklich ernsthaft tun. Es ist ein Szenario für Notfälle, die meiste Zeit würde man nach wie vor am Laptop programmieren. Ich denke, dass unterstreicht noch einmal die Bedeutung von Flux. Es wird immer die eingefleischten Eclipse-Fans geben, die 99 Prozent ihrer Programmiertätigkeit auf ihrem Laptop erledigen. Aber es gibt dieses eine Prozent der Fälle, in denen sie im Flughafen stehen und auf ihren Code zugreifen müssen, um einen Fix zu erledigen.

Und solche Dinge werden immer wichtiger bei Cloud-Auslieferungen mit Continuous-Integration- und Continuous-Delivery-Ketten, bei denen es darauf ankommt, fehlerhaften Code möglichst schnell wieder zu reparieren. Wenn also jemand fragt: „Warum sollte ich auf meinem iPhone programmieren wollen?“, hat derjenige meiner Meinung nach nicht wirklich verstanden, worum es hier geht.

Wenn du aber für die Cloud entwickelst, warum sollten die Tools dann nicht in der Cloud existieren? Ich glaube, aus diesem Blickwinkel heraus wird es besser verständlich.

EM: Ebenfalls überzeugend ist, dass durch Cloud-IDEs eine einheitliche Konfiguration von Workspaces innerhalb großer Unternehmen viel einfacher wird.

Milinkovich: Genau das ist eines der Hauptargumente für den Einsatz von Che. Einer der Gründe, warum Che wirklich interessant ist, besteht darin, dass es eine Plattform für die Konfiguration einer Werkzeugkette für ein spezielles ALM- und Deplyoment-Modell darstellt. Man kann von der Kommandozeile aus seine Werkzeugkette mit Travis, GitHub und so weiter zusammenbauen. Im Grunde wird somit ein Workspace aufgebaut, der so vorkonfiguriert ist, dass er die Entwickler genau für die gewählten Tools produktiv macht. Und das ist ziemlich cool.

Man sieht: Dieses Cloud-Development-Projekt birgt das Potenzial, eine überaus große Bedeutung zu erlangen. Insbesondere wenn es beginnt, die Architektur der Eclipse-IDE selbst zu beeinflussen. Es wird äußerst spannend sein, diese Entwicklung in den kommenden Jahren zu verfolgen.

EM: Mike, vielen Dank für dieses Gespräch!

Mike Milinkovich ist Executive Director der Eclipse Foundation, einer gemeinnützigen Organisation zur Unterstützung der Eclipse-Open-Source-Community und des kommerziellen Ökosystems. Vor der Übernahme der Leitung der Eclipse Foundation führte er als Vizepräsident bei Oracle das Application-Server-Technical-Services-Team. Vorangegangene Engagements umfassen Positionen als Vizepräsident bei WebGain Kanada, Consulting und Training bei Object People, Softwareingenieur bei Object Technology International und Produktmarketing bei IBM.

Verwandte Themen:

Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.