"Java-Entwickler sind wieder cool – zumindest wenn sie es wollen!" - JAXenter
Sacha Labourey über die Kooperation zwischen CloudBees und Verizon

"Java-Entwickler sind wieder cool – zumindest wenn sie es wollen!"

Hartmut Schlosser
©Shutterstock/ Lightspring

Kaum ein IT-Sektor ist derzeit so in Bewegung wie der des Cloud Computing. Für den Enterprise-Bereich spannend sind die Potenziale, die etwa in der gewonnenen Flexibilität und Skalierbarkeit der IT liegen – Assets, die allerdings erst von wenigen Unternehmen wirklich ausgereizt werden. Der Cloud-Markt ist also noch weit davon entfernt, konsolidiert oder gesättigt zu sein, und gerade Enterprise-Cloud-Anbieter leisten immer noch nicht viel mehr als Pionierarbeit.

Ein interessanter Trend scheint sich nun dahingehend abzuzeichnen, dass große Telekommunikationsunternehmen ihre Infrastruktur für Cloud-Computing-Angebote vorbereiten, um sie mit spezialisierten Services von Partnerunternehmen wie Oracle, SAP, VMware anzureichern. In diesem Sinne lässt die gestrige Nachricht über die Kooperation von PaaS-Anbieter CloudBees mit Verizon Enterprise Solutions aufhorchen.

CloudBees CEO Sacha Labourey

Wir sprachen mit CloudBees CEO Sacha Labourey, der Java-Community auch bestens als langjähriger CTO von JBoss bekannt, über diese neue Allianz, deren Ziel darin besteht, die Platform-as-a-Service von CloudBees auf der neuen Verizon Cloud verfügbar zu machen.

Die Verizon Cloud ist eine IaaS- und Cloud-Storage-Plattform, die sich derzeit im Beta-Stadium befindet. Durch die Integration der CloudBees PaaS sollen Verizon-Kunden in die Lage gesetzt werden, auf der Verizon-Infrastruktur die CloudBees Enterprise-Services zu nutzen.   

Sacha Labourey bezeichnet die Partnerschaft im Gespräch mit JAXenter als strategisches Unterfangen, das CloudBees-Ökosystem durch gezielte Kooperationen auszubauen.

Sacha Labourey: Wir haben zwar unseren direkten Go-to-Market-Kanal, der über die AWS läuft. Doch bietet Verizon uns die Möglichkeit, neue Kundenkreise aus verschiedenen Regionen zu erschließen.  Wir führen auch Gespräche mit anderen Anbietern über Kooperationen, die komplementär zur Verizon-Zusammenarbeit sind.

Nun kann man CloudBees sicherlich als einer der innovativsten PaaS-Anbieter bezeichnen, der mit seinen Services DEV@cloud, RUN@cloud und WEAVE@cloud den gesamten Application Lifecycle für das Entwickeln und Deployen von JVM-basierten und anderen Anwendungen (PHP, JavaScript, Node-js) in der Cloud abdeckt. Für Labourey ist der Faktor, als zentraler Bestandteil einer Continuous Delivery Pipeline dienen zu können – etwa durch den integrierten CI-Server Jenkins -, einer der Haupttrümpfe der CloudBees PaaS.

Wir bieten bekanntlich eine Platform-as-a-Service, aber wir bieten mehr als das – wir decken den gesamten Application Lifecycle ab. Immer mehr Unternehmen freunden sich mit den Ideen des „Continous Delivery“ an, da sie bemerken, dass sie zu langsam dabei sind, Wertschöpfungen von der initialen Projektplanung bis zur Auslieferung eines Produktes zu realisieren.

Einige Unternehmen versuchen, Continuous Delivery über Tools direkt in die unternehmensweite Arbeitsumgebung zu integrieren. Was wir aber sehen, ist, dass diese Veränderungen in vielen Unternehmen eine lange Zeit in Anspruch nehmen. Vielleicht sprechen wir hier von einem 10-Jahres-Rhythmus. Für einige Projekte könnte es indes interessant sein, hierfür die Cloud zu nutzen, denn mit der Cloud kann Continous Delivery unabhängig von der eigenen IT implementiert werden, ohne etablierte Prozesse zu stören. Man profitiert sofort von Continuous Delivery, während interne Veränderungsprozesse parallel laufen können.

Interessanterweise bringt Sacha Labourey noch den Faktor Java ins Spiel: Für Verizon sei auch CloudBees’ Verankerung im Java-Ökosystem interessant gewesen, da man sich so eine der größten Enterprise Communitys erschließe.

Ich denke, dass einer der Faktoren, der Verizons Interesse an CloudBees geweckt hat, unsere Java-Expertise ist. Sie haben verstanden, dass Java wichtig für ihre Zielgruppe ist. Wir sind darüber hinaus ein echter Service – keine Software -, und Verizon wird nicht plötzlich den Fokus ändern und selbst eine PaaS aufbauen, sondern von unserem bereits existierenden Service profitieren wollen.

Wie sieht Labourey generell die Position der Java-Community in Anbetracht der rasanten Entwicklung der Cloud- und Webtechnologien sowie des Booms der dynamischen Sprachen? 

Wir glauben bei CloudBees, dass wir dazu beigetragen haben, dass Java-Entwickler wieder cool sind – zumindest wenn sie es wollen. Früher waren viele der agilen Continuous-Delivery-Techniken nur mit anderen Sprachen möglich. Es gab kaum Out-of-the-box Build-Chains, bei denen Java-Entwickler den nötigen Grad an Freiheit hatten. Dank der Cloud und dank den PaaS-Anbietern – darunter CloudBees, aber auch andere -, und dank Tools wie Jenkins stehen jetzt Pipelines zur Verfügung, die Java-Entwickler deutlich effizienter machen.   

Ebenfalls großartig ist, dass Java-Entwickler sich jetzt mehr an der „Philosophie“ Java und an der JVM orientieren, anstatt sich strikt an die Sprache Java zu halten. Die Art und Weise, wie Software paketiert wird, und die Funktionsweise der JVM sind wichtiger geworden als Sprachen, die schließlich kommen und gehen. Selbst wenn ein großer Teil der Entwicklung auf der JVM immer noch in Java realisiert wird, so finden einige der spannendsten Innovationen doch anderswo im JVM-Ökosystem statt: beispielsweise bei Vert.x, Scala, Play und so weiter. 

Bei CloudBees betrachten wir Java als unsere größte Priorität, und ich glaube, es war sehr wichtig für Verizon, einen Anbieter zu gewinnen, der die Community gut kennt, denn sehr viele Unternehmen da draußen setzen auf Java und die JVM.

Positive Aussichten also, die Labourey der Java Community attestiert. Initial konzentriert sich die Kooperation mit Verizon auf CloudBees‘ RUN@cloud-Angebot, mit dem das Deployment von Anwendungen im Sinne einer PaaS möglich ist. Eine Erweiterung dieses Fokus ist laut Labourey aber durchaus denkbar, um die Idee des Continous Delivery weiter auszubauen.

Der Zeitpunkt der öffentlichen Verfügbarkeit des CloudBees-Services auf der Verizon Cloud steht noch nicht fest. Zu rechnen ist mit einer weiteren Anreicherung des Verizon-Angebotes durch zusätzliche Kooperationen, bestätigt sind bereits Oracle, SAP, Cloud Foundry und Engine Yard. Diese sieht Labourey indes nicht als Wettbewerber sondern als Ergänzungen:

Nicht viele Anbieter verfügen über Kooperationen mit Oracle, SAP und anderen in der Cloud – das alleine ist ein großer Erfolg. Ich denke nicht, dass die anderen Partnerschaften Wettbewerb für uns bedeuten, sondern dass sie sehr komplementär zu unserem Angebot stehen.  Heute schon nutzen unsere Kunden Datenbanken wie Oracle, einige nutzen Anwendungen, die mit SAP-Lösungen verbunden sind. Es gibt hier ganz deutlich einen hohen Grad an komplementärem Potenzial in diesen Systemen.

Und so verlagern denn auch die klassischen Enterprise-Urgesteine wie Oracle und SAP ihre Angebote in die Cloud, operieren auf Telekommunikationsinfrastruktur à la Verizon und verbinden sich mit spezialisierten Service-Providern wie CloudBees. Das ist die Schöne Neue Welt der Enterprise Cloud – und das JVM-Ökosystem ist mittendrin.

Sacha Labourey ist Gründer und CEO des PaaS-Anbieters CloudBees. Als langjähriger CTO von JBoss spielte Labourey eine signifikante Rolle bei der Entwicklung der JBoss Middleware und deren Integration in die Red-Hat-Plattform. Labourey gründete 2010 das Unternehmen CloudBees mit dem Ziel, den Paradigmenwechsel der Middleware-Architekturen hin zu Public-Cloud-Infrastrukturen anzuführen.

Aufmacherbild: Cloud computing symbol representing data resources von Shutterstock / Urheberrecht: Lightspring 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

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