"Der Entwickler ist mit der Cloud näher am Business"

Herr Labourey, wie kamen Sie auf die Idee, Cloud Bees zu gründen?

Als ich Red Hat im April 2009 verliess, interessierte mich die Cloud überhaupt nicht. Ich sah darin nur Geräte, die einfach irgendwo anders installiert waren. Der Groschen fiel, als ich mit einem meiner Kollegen sprach und feststellte, dass die Idee dahinter viel grösser ist. Damit meine ich Konzepte wie Selbstbedienung, Pay-as-you-go, Ressourcen-Sharing und die Möglichkeit, ohne den Umweg über einen Verkäufer einzukaufen und denselben Service einem oder 1000 Anwendern zur Verfügung zu stellen. Ich dachte mir gleich, dass das Konzept, wenn man es auf Software und Server anwendet, auch für die Entwickler von Nutzen sein könnte. Die Entwicklung beschäftigt sich zu viel mit den Servern und verliert sich in Details. Schliesslich verlangt ein Unternehmen zwei Dinge von der Entwicklung: Sie muss mehr Geld einbringen oder Geld einsparen. In diesem Sinne ist der Entwickler mit der Cloud näher am Business. Was ihn interessiert, ist die Programmierung, das Testen und die produktive Umsetzung. Er will sich aber nicht um Load Balancer, SSL oder Firewalls kümmern. Die Cloud ermöglicht jedem einzelnen, von Best Practices der Branche zu profitieren, die so für alle Unternehmensgrössen verfügbar und zugänglich werden. Die Firma entstand aus der Idee, die Entwickler zu entlasten, damit sie sich auf das Wesentliche konzentrieren können. Sie sollten einfach einen «Deploy»-Button erhalten. Danach sollte die Anwendung nachts auf einem oder zu Spitzenzeiten auf 300 Servern laufen können, ohne dass sich der Programmierer darum kümmern muss. Ausgehend von dieser Vision habe ich einen Businessplan erstellt und das erste Team verpflichtet. Im April 2010 waren wir auf dem Markt.

Welche Arten von Unternehmen nutzen Ihre Plattform?

Wir haben verschiedene Arten von Kunden. Zunächst einmal gibt es diejenigen, die sich online registrieren und beginnen, Leistungen zu beziehen, ohne dass wir wissen, was die Nutzer genau tun. Daneben gibt es auch Kunden, die unser Angebot intensiv beanspruchen. Das hat jedoch nicht zwingend mit der Firmengrösse zu tun. Die Firma "Lose it!" zum Beispiel, die eine App zum Abnehmen anbietet, beschäftigt nur vier Mitarbeiter, wickelt aber in Spitzenzeiten 30 000 Transaktionen pro Minute ab. Solche Kunden wollen ihre Rechnung nicht mehr unbedingt jeden Monat bekommen. Wir setzen uns an einen Tisch und stellen den voraussichtlichen Bedarf fest. Die Kunden bezahlen eine Jahrespauschale, die genaue Abrechnung erfolgt danach anhand des tatsächlichen Verbrauchs. Mit diesem Modell haben die Entwickler grössere Freiheiten bei gleichzeitig besserer Kostenplanung.

Arbeiten Sie auch mit Dienstleistern zusammen?

Ja, immer mehr Kunden kommen über Dienstleister zu uns, die die Plattform selbst auch nutzen. Diese Dienstleister haben den Vorteil, dass sie die Projekte ihrer Kunden bereits kennen. Sie wissen ausserdem, dass ihre Kunden gegenüber der Cloud offen sind. Mit unserer Plattform können sie ihren Kunden sagen: "Ab morgen können unsere Berater an Ihrem Projekt arbeiten. Wir müssen Ihnen keine Server bereitstellen oder mit Ihrer IT-Abteilung sprechen. Und wir können Ihre Mitarbeiter integrieren, damit sie im Laufe der Entwicklung Zugang zur Anwendung bekommen." Dies ist eine sehr flexible Vorgehensweise, denn nach Abschluss des Projekts stehen die Tests, der Code und die Produktionsumgebung direkt den Mitarbeitern zur Verfügung. Dies ist ein wichtiges Alleinstellungsmerkmal für Softwareentwicklungsfirmen. Ein Kunde hat kürzlich einen Auftrag erhalten, weil er genau diese Flexibilität bieten konnte, obwohl einer seiner Mitbewerber ein grosser indischer Anbieter war. Ein weiteres noch ziemlich junges Segment sind die klassischen Hoster, die Angebote für die Cloud-Infrastruktur entwickeln und zusätzlich ein PaaS anbieten möchten. Wir bieten diesen Firmen an, unsere Plattform auf ihrer eigenen Infrastruktur laufen zu lassen, während wir uns um deren Verwaltung kümmern. Das vereinfacht die Sache. Für uns ist das Interessante daran, dass wir von der Glaubwürdigkeit der grossen Anbieter und ihrem Vertrauensverhältnis zu den Unternehmen profitieren.

Worin unterscheidet sich die Plattform Cloud Bees vom bekannteren PaaS?

Wir konzentrieren uns darauf, Dienstleistungen von der Entwicklung bis zum Einsatz von Java-Anwendungen anzubieten, was wir als "continous cloud deployment" bezeichnen. Uns ist wichtig, dass die Unternehmen ihre Anwendungsideen rasch in Code umsetzen, und eine kontinuierliche Integration betreiben können. Dazu gehört, dass sie Tests in Echtzeit durchführen und sich vergewissern können, dass der Code jederzeit "releasable" ist. Danach können sie den Code in Produktion geben, ihre Anwendungen einsetzen und skalieren. Was uns von PaaS wie Heroku oder Google App Engine unterscheidet, ist die Tatsache, dass wir uns nicht nur für den Betrieb, sondern auch für die vorgelagerte Entwicklung interessieren. Wie die anderen Plattformen bieten auch wir eine ganze Reihe Zusatzdienste wie beispielsweise SQL-, NoSQL-Datenbanken oder Monitoring über unser Partnernetzwerk an. Auch in diesem Fall behaupten wir, dass die Tools viel einfacher als mit herkömmlicher Software zu handhaben sind. Wenn ein Kunde zum Beispiel das New-Relic-Angebot für die Serverüberwachung möchte, wählt er einfach den gewünschten Dienst aus. Nur wenige Minuten später verfügt er über einen neuen Button für die Überwachung seiner Anwendungen. Dasselbe gilt, wenn er eine Datenbank oder eine IaaS-Lösung von Amazon benötigt. Er hat die Wahl. Wir müssen uns von der Vorstellung verabschieden, dass die PaaS geschlossene Umgebungen seien. Dies ist ein Klischee aufgrund von Force.com, der ersten auf dem Markt erschienenen Plattform mit ihrer eigenen Sprache, ihren eigenen API und ihrer eigenen Datenbank. Dies entspricht nicht mehr der Realität. Wenn wir Cloud Bees betrachten, dann stammt das Versionsverwaltungstool von Subversion oder Git und die kontinuierliche Integration von Jenkins, dem bekanntesten Open-Source-Projekt in dem Bereich, dessen Gründer im Übrigen für uns arbeitet. Es ist also jederzeit möglich, die Umgebung zu migrieren.

Wie sehen Sie die Entwicklung Ihrer beiden Geschäftsbereiche, der Entwicklungsplattform einerseits und dem Hosting andererseits?

Heute macht der Entwicklungsbereich ein Drittel unseres Umsatzes aus. Dies ist ein strategischer, alleinstehender Geschäftszweig. Das grösste Wachstum erwarten wir jedoch im Bereich des Betriebs, da dieser nicht von der Anzahl der Entwickler abhängt, sondern von den Lasten, die explosionsartig steigen können.

Können die Unternehmen, die für die Entwicklung ihrer Anwendungen auf Ihre Plattform zurückgreifen, diese auch auf anderen PaaS installieren?

Ja – und das soll auch in Zukunft so bleiben. Wir haben Partnerschaften mit Mitbewerbern wie Cloud Foundry und Google App Engine gegründet, um die Botschaft zu verbreiten, dass die Cloud keine geschlossene Umgebung ist. Wenn ein Kunde zum Beispiel Git Hub oder sein eigenes Versionsverwaltungssystem benutzen will, so steht ihm dies frei. Wir haben mit den anderen Cloud-Anbietern ein gemeinsames Interesse daran, dass die Cloud als offene Umgebung verstanden wird. Dies ist eine ähnliche Entwicklung wie vor 15 Jahren mit J2EE. Dadurch kam Java auf dem Markt gross heraus, obwohl dieser offene Standard ein Risiko für jeden einzelnen Anbieter nach sich zog.

Was halten Sie von dem Konflikt zwischen Oracle und Google, was die Java-API angeht?

Das ist eine höchst interessante Debatte mit grossen Auswirkungen auf die Freiheit der Entwickler und der IT im Allgemeinen. Die amerikanischen Gerichte müssen darüber entscheiden, ob es möglich ist, eine API neu zu implementieren. Oracle widersetzt sich natürlich nicht der Anwendung seiner API, würde aber gerne verhindern, dass ein anderes Unternehmen sie ein zweites Mal implementieren kann. Wenn ich einen Vergleich mit dem Wetterdienst ziehen darf, könnte man sich vorstellen, dass Meteo Schweiz eine API entwickelt, an die man Abfragen mit Datum und Ort senden kann, um Wetterauskünfte zu erhalten. Wenn man diese API mit einem Copyright versieht, würde das bedeuten, dass ein anderer Wetterdienst seinen Nutzern nicht anbieten dürfte, auf dieselbe Art und Weise Abfragen machen zu lassen. Das wäre jedoch absurd, denn der Wert liegt nicht in der Art, wie die Abfrage gestaltet ist, sondern in den zurückgesendeten Daten und den Zusatzdiensten. Die Idee, API-Schnittstellen mit einem Copyright zu schützen, ist ein überholter Kampf, den sich die IT-Riesen liefern, um ihre einmal gewonnenen Anwender nicht zu verlieren. Der Streitwert ist hoch, da er alle API-Schnittstellen betrifft.

Einer der gegen die Cloud geäusserten Vorwürfe betrifft ja gerade die mangelnden Standards.

Ich meine nicht, dass dies in der derzeitigen Phase der starken Innovationen ein Problem ist. Wenn ich dazu den Fall SaaS betrachte, dann ist die Situation keine andere, als die, die den Anwendern von den installierten Softwareprogrammen her bekannt ist. Es gibt keine Standards, weder für CRM noch für ERP. Was das IaaS und das PaaS angeht, so gibt es auch hier keine echten Normen, ausser neu entstehende De-facto-Standards wie Open Stack oder die API von Amazon. Doch auch dort sehe ich kein Problem, solange wir Tools finden, die Abstraktionsschichten schaffen. Nicht zuletzt finden wir bei den PaaS ja offene Standards wie Java, MySQL, PostgreSQL, Jenkins oder Git.

Heute interessieren sich wohl hauptsächlich weborientierte Technologieunternehmen für PaaS. Glauben Sie, dass auch klassische Firmen diese Plattformen nutzen werden?

Ich meine, dass wir dieselbe Entwicklung wie bei SaaS und IaaS erleben werden. Zu Beginn schienen Amazons Webservices auch nur für Start-ups und Testumgebungen geeignet zu sein. Heute bewegt sich dieses Geschäftsfeld auf dem Niveau von VMware. Die Unternehmen greifen zunehmend auf unterschiedliche Formen der Public Cloud zurück, und zwar häufig ohne das Wissen ihrer IT-Abteilungen. Dieses Phänomen ist als Schatten-IT bekannt. So läuft es auch bei uns. Nur selten wendet sich der CIO an uns, dafür aber die Entwicklungsteams und die Softwarearchitekten, die sich darüber beschweren, wie lange es dauert, bis man intern einen Server erhält. Oder auch die Abteilungsleiter, zum Beispiel im Marketing, die monatelang auf eine mobile Anwendung warten müssen. Sie wenden sich dann an Web- und Mobilagenturen, können danach aber nicht zu ihrer IT zurückkehren, um die App zu installieren oder mit den bestehenden Systemen zu verbinden. An diesem Punkt kommt unsere Plattform ins Spiel. Eine grosse französische Bank beispielsweise hat kürzlich davon Gebrauch gemacht. Sie benötigten nur dreieinhalb Monate von der Idee bis zum Einsatz der ersten Lösung – in derselben Zeit erhielten sie zuvor gewöhnlich einen leeren Server. Das "continous cloud deployment" wirkt sich andererseits auch auf die Art der Entwicklung der Anwendungen aus und bestimmt, wie sie getestet und installiert werden. Mit solchen Umgebungen lassen sich inkrementell neue Funktionalitäten schaffen. Man entwickelt etwas, gibt es in Echtzeit in die Produktion, testet gleichzeitig Alternativen, verwirft, was nicht gut ist und behält das, was funktioniert. Das sind neue Verfahren und entspricht einer ganz neuen Mentalität. Das Ausprobieren verschiedener Ansätze wird wichtiger als die Entwicklung selbst. Ich meine, dass die Unternehmen und ihre IT-Abteilungen Schritt für Schritt diese neue Vorgehensweise übernehmen werden, denn diese Entwicklung findet statt, ob mit ihnen oder ohne sie.