Interview mit Sacha Labourey

Auf dem Weg zur Next-Generation-IT: PaaS, DevOps, Continuous Delivery, Docker, Jenkins…

Hartmut Schlosser
Sacha Labourey

Letzte Woche erreichte uns die Nachricht, dass CloudBees sich zukünftig auf den Markt um den Continuous-Integration-Server Jenkins konzentrieren wird. Im Interview mit JAXenter beleuchtet CloudBees-Gründer Sacha Labourey die Hintergründe der neuen Strategie und gibt eine persönliche Einschätzung, welche Richtung die Next-Generation-IT einschlagen wird. Ganz vorne mit dabei: PaaS, DevOps, Continuous Delivery, Docker, Jenkins…

Hallo Sacha! CloudBees wird sich fortan voll auf Jenkins konzentrieren und den Service RUN@cloud einstellen. Wie kam es zu dieser Entscheidung?

Sacha Labourey: Von Beginn an bestand die Vision von CloudBees darin, eine Umgebung für Unternehmen und DevOps-Spezialisten bereitzustellen, um sofort neue Produkte zu entwickeln und Anwendungen kontinuierlich ausliefern zu können. Wir hatten deshalb einerseits DEV@cloud im Portfolio, um Continuous Integration in der Cloud vorzunehmen. Und andererseits RUN@cloud und WEAVE@cloud für Deployment und Integration.

Nun hat Jenkins im Laufe des vergangenen Jahres für uns ein enormes Wachstum erzielt. Einer der Gründe dafür dürfte im Übergang von Continuous Integration zu Continuous Delivery liegen. Jenkins wird nicht mehr nur auf den Desktops einiger weniger Entwickler eingesetzt, sondern von allen Team-Mitgliedern eines Unternehmens, um im Sinne von Continuous Delivery die Wege von der Entwicklung zur Auslieferung eines Produkts zu verkürzen. Dieser Trend hat die Gespräche mit unseren Kunden radikal verändert.

Viele von uns kommen ja aus der JBoss-Ecke, und wir erkannten deshalb, dass sich um Jenkins herum eine Business-Gelegenheit auftat, die wir nicht verpassen sollten. Gleichzeitig hatten wir unser PaaS-Angebot und liefen Gefahr, keine der beiden Chancen richtig nutzen zu können. Und so war denn eine harte Entscheidung zu treffen, denn wir lieben PaaS und glauben, dass es eine wegweisende Technologie ist. 

Doch war es für unser Unternehmen der richtige Weg, sich zu 200% auf Jenkins zu konzentrieren und sich vom Runtime-Anteil unserer Plattform zu verabschieden. Wichtig ist mir dabei zu betonen, dass wir weiterhin unser DEV@cloud-Angebot im Portfolio führen, das man auch als Jenkins as a Service bezeichnen kann.

Ihr habt auch eine Partnerschaft zwischen CloudBees und Pivotal bekannt gegeben. Gibt es einen Zusammenhang zwischen dieser Kooperation und Eurer Entscheidung, das RUN@Cloud-Geschäft aufzugeben?

Sacha Labourey: Es gibt einen Zusammenhang, allerdings ist dieser nicht besonders groß. In dem Moment, als wir uns dazu entschlossen, die Laufzeit-PaaS aufzugeben, wurden die Diskussionen mit Unternehmen wie Pivotal für uns deutlich einfacher. Wir standen schon seit Längerem mit Pivotal in Verbindung, und sie waren sehr daran interessiert, was bei uns im Hinblick auf Jenkins und DevOps passierte. Es war allerdings schwer, eine Partnerschaft zu schließen, mit der jeder zufrieden gewesen wäre, solange wir die RUN@cloud in der Hinterhand hatten.

Sobald dieses Problem ausgeräumt war, war es deutlich einfacher, eine Einigung zu erzielen. Und ich denke, das war nur die erste von vielen weiteren Partnerschaften im Markt. Aufgrund unserer Fokussierung auf eine Sache wird es sehr leicht werden, sich mit CloudBees zusammenzutun. 

Heißt das, dass Pivotals CloudFoundry für eure Bestandskunden eine Art logischer Ersatz für RUN@cloud darstellt?

Sacha Labourey: Tatsächlich sind viele unserer Kunden in der Public Cloud unterwegs. Der Fokus von Pivotal liegt allerdings nicht so sehr auf der Public Cloud. Sie konzentrieren sich eher auf die Private Cloud und überlassen die Public Cloud ihren Partnern, beispielsweise IBM.

Wir werden unseren Kunden also die Wahl geben, wohin sie migrieren wollen – einige werden zu Diensten von Amazon andere zu Google wechseln wollen, etc. Jedenfalls werden wir sie beim Übergang zu einer dieser Plattformen unterstützen. Es ist aber unwahrscheinlich, dass sie zum jetzigen Zeitpunkt zu Pivotals CloudFoundry wechseln wollen.

Nur um es nochmal klar zu machen: Bei dieser Partnerschaft geht es rein um Jenkins und dessen Wert für Pivotals On-Premises-Kunden. Es ist keinesfalls ein Handel nach dem Motto: Wir stoppen PaaS, um eine Partnerschaft mit Pivotal eingehen zu können bzw. wir stoppen PaaS, wenn unsere Kunden zu Pivotal gehen. Es gibt also keinen Zusammenhang zwischen den Entscheidungen unserer Kunden, den Gründen, warum wir uns auf Jenkins konzentrieren wollen, und der Partnerschaft mit Pivotal. Unsere Fokussierung auf eine Sache hat uns die Möglichkeit einer Partnerschaft leicht gemacht.

Konzentrieren wir uns also auf die Jenkins Company. Zentral ist hier sicherlich euer Enterprise-Jenkins-Angebot. Worin liegt dabei der Unterschied zum Open-Source-Jenkins?

Sacha Labourey: Zunächst einmal sind viele Kunden an Support interessiert. Von diesem Blickwinkel aus unterscheidet sich unser Geschäft nicht großartig von JBoss oder Red Hat. Andere Kunden interessieren sich für die zusätzlichen Features, die wir auf der Basis des quelloffenen Jenkins anbieten. Hier hat CoudBeeds eine Reihe von Plug-ins im Portfolio, die besonders für Unternehmen von Belang sind, z.B. für die lückenlose aktive Kontrolle oder das Cluster-Deployment.

Zuletzt gibt es noch das sogenannte Jenkins Operation Center von CloudBees  – von uns liebevoll auch „Jockey“ genannt. Dieses Tool macht das skalierte Managen und Handhaben von Jenkins möglich. Ein typischer Anwendungsfall in Unternehmen ist beispielsweise dann gegeben, wenn Jenkins von zahlreichen Teams verwendet wird und sich mit der Zeit dutzende, wenn nicht gar hunderte Master und noch einmal mehr Build-Machines angehäuft haben. In dem Fall ist es eine Notwendigkeit, diese zu bündeln und alle Instanzen zu überwachen, damit sichergestellt ist, dass jeweils die richtigen Plug-ins angewendet werden.

Vielleicht entschließt man sich dazu, die Ressourcen zwischen den Mastern zu teilen, anstatt strikt an privaten Ressourcen festzuhalten. Bei einem einzelnen Master will man vielleicht gerade diese teilen – so oder so wird man sich für alle Master dieselben Sicherheitsvorkehrungen wünschen. Genau das sind die Dinge, die das Jenkins Operation Center ermöglicht. Gerade für Unternehmen sind diese Bereiche logischerweise besonders heikel.

Eingedenk eurer Fokussierung auf Jenkins: Können wir für die nahe Zukunft mit neuen Features rechnen?

Sacha Labourey: Oh ja, wir arbeiten zur Zeit extensiv an den Workflow-Features. Viele unserer Kunden betreiben Continuous Delivery mit Jenkins, mussten dafür bisher allerdings allerhand Tricks anwenden und Pipelines nutzen, was ziemlich knifflig werden kann. Großartig war es deshalb, weil Jenkins zahlreiche Konfigurationen und einfach zu integrierende Tools bietet. Die Definition der Pipeline an sich war allerdings vergleichsweise prekär.

Die Open-Source-Community hat bereits extensiv am sogenannten „Jenkins Workflow“ gearbeitet, der beispielsweise einen leistungsfähigen Weg zur Definierung von ausgeklügelten Workflows zwischen Mastern eröffnet. Er soll diesen Herbst veröffentlicht werden, ausprobieren kann man ihn jedoch schon jetzt in den Community-Releases. Des Weiteren wird CloudBees einige Features beisteuern, z.B. die Visualisierung dieser Workflows. Außerdem werden wir einige erweiterte Monitoring-Funktionen implementieren. Es sind also einige coole Dinge in der Mache.

Noch eine Frage zur der alten Hudson/Jenkins-Geschichte. Wir alle erinnern uns daran, wie Oracle Probleme mit der Markenpolitik für Hudson hatte. Vor etwa drei bis vier Jahren gab es deshalb den Jenkins-Fork. Hudson hat sich unterdessen zu einem Eclipse-Projekt entwickelt. Wie siehst du heute die Beziehung zwischen Hudson und Jenkins?

Sacha Labourey: Lustig, dass du das fragst: Das ganze Jahr 2011 über haben wir im Unternehmen darüber diskutiert, was da vor sich geht, ob die Leute zu Jenkins migrieren. Und wir haben uns regelmäßig die Zahlen angesehen, um zu überprüfen, wie wir uns machten. Wenn ich darüber nachdenke, hat bei uns in den vergangenen zwei Jahren keiner mehr darüber geredet. Es sieht also so aus, als hätten wir das hinter uns gelassen.

Wir sehen Hudson nicht, wir hören nichts darüber. Wenn die Leute glücklich mit Hudson sind, so ist das schön für sie. Aber uns betrifft das nicht. Was uns anbelangt, könnte es ein völlig anderes Projekt sein – es würde für uns auch nichts ändern.

Wo siehst du die Zukunft von PaaS-Lösungen? Ist hier nur noch Platz für Big Player wie Amazon, Google, Pivotal oder OpenStack?

Sacha Labourey: Ich denke, es wird definitiv eine Konsolidierung stattfinden. Bei anderen Waren und Dienstleistungen kann man das beobachten, warum also sollte es bei PaaS anders sein? Allerdings glaube ich nicht, dass die Konsolidierung von einem der Big Player bei der Infrastruktur ausgehen wird. Man kann das am Beispiel der SaaS- und Infrastruktur-Anbieter sehen. Sie waren nie in der Lage, Middleware hausintern zu entwickeln; diese musste immer extern angeschafft werden. Wir werden noch sehen, wie sich das entwickelt.

Wenn wir PaaS betrachten, müssen wir aber feststellen, dass dessen Wachstum deutlich langsamer verlief als irgendjemand ursprünglich gedacht hätte. Ein Grund dafür dürfte sein, dass im Markt eine große Verwirrung herrscht. Zunächst einmal existieren viele unterschiedliche PaaS-Lösungen, und jeder braucht deshalb eine gewisse Zeit, um die für ihn richtige zu finden. Zum anderen muss alles bedacht werden, was unter das Stichwort DevOps fällt. Was ist mit Docker? Sollte ich statt einer Orchestrierung lieber Docker verwenden? Etc.

Kurz: Es gibt viele Fragen zu klären und Hindernisse zu überwinden. Und als Entwickler braucht man nun einmal Zeit, um die richtige Lösung zu finden. Man braucht die richtigen Tools. Worauf legt man beim Framework mehr Wert, auf Flexibilität oder Systemgesundheit? Ein bodenloses Thema – und das ist übrigens auch gut so, denn deshalb finden großartige Innovationen statt. In ein paar Jahren, wenn der Markt etwas zur Ruhe gekommen ist, wird er viel leichter zu verstehen sein. Vielleicht wird PaaS auf Docker-Images basieren, was große Flexibilität bedeuten würde. So oder so wird PaaS eine große Rolle spielen. Für einen großen Prozentsatz der Leute ist PaaS alles, was sie brauchen, und gleichzeitig der effizienteste Weg, um ihre Ziele zu erreichen.

Du hast Docker nun mehrmals erwähnt. Wir haben ein steigendes Interesse an dieser Technologie beobachtet. Welche Rolle spielt deiner Meinung nach Docker?

Sacha Labourey: Ja, dieses Interesse an Docker haben wir ebenfalls beobachtet. Wir bieten natürlich auch entsprechende Integrations-Features in Jenkins. Es gibt Leute, die Docker Images auf der Basis von Konfigurationsdateien in Jenkins bauen. Und dann Leute, die Applikationen in einem Docker Image deployen. Das volle Programm sozusagen: Tools, Quellcode, Infrastracture as Code, Docker Binarys, etc. All das kann von Jenkins aus geschehen, die Integration ist hier hervorragend.

Das wiederum hängt mit einem meiner Ansicht nach sehr wichtigen Punkt zusammen: Viele Technologien entwickeln sich parallel zueinander weiter und hängen in gewisser Weise doch zusammen, namentlich Continuous Delivery, DevOps und die Cloud. Wer diese drei definiert, befindet sich in einer mächtigen Position. Wir reden hier von Next-Generation-IT. Weltweit gibt es vielleicht ein oder zwei dutzend Firmen, die im Zentrum dieser drei Technologien stehen und somit bei der Neudefinierung der IT eine Schlüsselposition einnehmen. Dazu gehören Docker, Cloudbees mit Jenkins, Atlassian und natürlich AWS. Ich glaube, alle diese Unternehmen befinden sich in einer großartigen Position, die IT der Zukunft mitzubestimmen.

Sacha, vielen Dank für dieses Interview!

Sacha Labourey is founder and CEO of CloudBees, a Java as a Platform provider funded by Matrix Partners. He was longtime CTO of JBoss, both before and after the company’s acquisition by Red Hat (NYSE: RHT). Sacha played a crucial role in integrating and productizing JBoss software with Red Hat offerings, and later on served as co-GM of Red Hat’s JBoss Middleware division, with joint responsibility for the performance, go-to-market and delivery of JBoss solutions. While at JBoss, he oversaw technical direction of JBoss’ enterprise middleware. Prior to stepping up as CTO, he was JBoss’ first employee in Europe and, as General Manager, led the strategy and the partnerships that helped fuel the company’s growth in the region. He left Red Hat in April 2009, forming CloudBees in April 2010, lead the shift in thinking about public cloud infrastructure with middleware playing a key role in that shift.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: