Interview mit Sascha Möllering

Befreiungsschlag: „Es zählt nur noch der Container und die Schnittstelle“

Redaktion JAXenter

Docker etabliert sich immer stärker als Plattform für das Deployment und den Betrieb von verteilten Anwendungen, die immer öfter Cloud-Plattformen als Basis nutzen. Wie aber lassen sich Docker und die Cloud kombinieren? Anhand konkreter Beispiele wird sich Sascha Möllering in seinem Talk auf der DevOpsCon mit dieser Frage beschäftigen. Schon vorab gibt er im Interview einen Ausblick auf das Thema.

In deinem Talk beschäftigst du dich mit den Möglichkeiten, die Container-Software Docker in verteilte Cloud-Anwendungen einzubinden. Wo liegen die größten Vorteile dieser Kombination? 

Sascha Möllering: Docker und „die Cloud” passen von den grundlegenden Paradigmen sehr gut zusammen. Ziel ist es jeweils, eine elastische Architektur zu schaffen, die schnell skaliert und Ausfälle einzelner Services problemlos verkraften kann. Besonders spannend ist die Frage, welche Services der Cloud-Implementierung ich nutze und welche Teile der Infrastruktur ich selbst baue? Durch Docker und die von der Community gepflegten Docker-Images ist es deutlich einfacher, Infrastruktur selbst auszurollen. Dadurch ist es nicht mehr unbedingt notwendig, die herstellerspezifische Implementierung von Infrastrukturkomponenten zu nutzen. Damit kann ich eine Architektur schaffen, die relativ unabhängig vom eigentlichen Cloud-Provider ist.

Wie reibungslos funktioniert das heute schon?  In deinem Talk sprichst du die Beispiele Amazon Web Services und Microsoft Azure an…

Sascha Möllering: Docker wurde schon früh durch die Amazon Machine Images (AMIs, Linux Image von Amazon) unterstützt und ist inzwischen sehr gut im AWS-Ökosystem integriert. Für OpsWorks gibt es schon länger entsprechende Chef Cookbooks. ElasticBeanstalk hat seit kurzem eine direkte Anbindung zwischen dem Elastic Load Balancing (ELB) und den Containern. Auf der re:invent 2014 hat AWS mit dem EC2 Container Service (ECS) zudem einen eigenen, sehr ambitionierten Service vorgestellt, der das Container-Management signifikant vereinfacht. Eine Sache, die ich leider immer noch vermisse, ist eine Private Docker Registry als Managed Service. So etwas ist mit Hilfe von CloudFormation schon recht einfach umsetzbar. Vermutlich wartet Amazon noch auf die „neue” Registry-Implementierung in Go, die viele Probleme der aktuellen Registry lösen wird. Die meisten werden wahrscheinlich das Problem mit dem Löschen der Images aus der Registry kennen.

Die Integration in Azure ist leider noch nicht ganz soweit, aber dennoch vielversprechend, wenn einige Hürden beim initialen Setup genommen wurden. Bei Azure bin ich sehr gespannt, was genau die sogenannten Hyper-V Container sind und wie man diese nutzen kann.

Du gehst auch auf die Gefahr des Vendor-Lock-ins ein. Wie kann die Kombination von Docker und der Cloud auf lange Sicht die Unabhängigkeit sichern? 

Sascha Möllering: Die entscheidende Frage an dieser Stelle ist, wie weit die herstellerspezifische Implementierung des Infrastrukturbausteins geht. Eine Abgrenzung lässt sich relativ gut anhand von Amazon RDS und Amazon Kinesis machen: RDS ist eine vollständig von AWS verwalteter Service für relationale Datenbanken, was beispielsweise Read-Replicas oder Replikation über die Grenzen von Availability Zones hinaus umfasst. RDS umfasst unterschiedliche Datenbank-Engines (z.B. Postgres), was bedeutet, dass sich die API zur Applikation hin nicht ändert. Dieser Service abstrahiert weite Teile der Komplexität des Managements einer Datenbank in einem verteilen System. Die Schnittstelle zur Nutzung durch Applikationen bleibt aber gleich. Kinesis hingegen bietet eine eigene API und ein eigenes SDK. An dieser Stelle ist der Vendor-Lock-In deutlich höher.

Dennoch kann durch eine dünne Abstraktionsschicht und weitere Mechanismen gewährleistet werden, dass die selbe Applikation auch ohne Probleme beispielsweise mit einem Apache Kafka funktionieren kann. Schwieriger wird es natürlich, wenn die Management- und Orchestrierungstools selbst proprietär sind und herstellerspezifische Formate nutzen. AWS beispielsweise hat mit dem ECS einen Service vorgestellt, der sehr verlockend ist, weil er eine tiefe Integration in die AWS-Infrastruktur (ELB, CloudWatch) bietet.

Das Beschreibungsformat für die Container und die Beziehungen zwischen diesen ist natürlich AWS-spezifisch. Mein Wunsch an dieser Stelle wäre, dass die Community ein Format definiert, das alle Anbieter solcher Tools implementieren, damit der Wechsel zwischen den einzelnen Orchestrierungsplattformen möglichst einfach durchführbar ist.

Welche spezifischen Best Practices kannst du in Hinblick auf Java-Anwendungen empfehlen?

Sascha Möllering: Nach einer gefühlten Ewigkeit mit JavaEE und all den Schwierigkeiten, die diese Spezifikation und die Implementierung in Form von Application-Servern mit sich gebracht hat, empfinde ich den Ansatz, kleine Services als Fat-JAR mit REST-API auszuliefern, als Befreiungsschlag. Wir haben wirklich sehr gute Erfahrungen mit Jetty, Vert.x und Spring Boot als Basisframeworks für unsere zustandslosen Applikationen gemacht. Diese Applikationen schneiden wir so groß wie nötig und so klein wie möglich. Die Anforderungen in Bezug auf Ressourcen sind gering.

Diese Applikationen sind leicht verständlich und eine Re-Implementierung mit einem anderen Framework beziehungsweise einer anderen Sprache ist mit geringem Aufwand durchführbar. Ein Nachteil dieses Vorgehens ist allerdings, dass Entwicklern deutlich mehr Verantwortung übertragen wird. So wird beispielsweise das JMX-Monitoring nicht mehr zentral durch einen Service durchgeführt, sondern die Applikation ist selbst für das Bereitstellen von Metriken verantwortlich.

Manche sehen in Docker eine revolutionäre Technologie, die die Art und Weise, wie Software zukünftig ausgerollt wird, fundamental verändert. Andere betrachten es lediglich als nützliches Tool für bestimmte Zwecke. Wie ist da deine Position?

Sascha Möllering: Docker ist nur eine Implementierung, die durchaus in ein paar Jahren durch eine anderen Containertechnologie abgelöst werden kann. Viel wichtiger finde ich das zugrundeliegende Paradigma: Es zählt nur noch der Container und die Schnittstelle. Wie die Applikation im Container implementiert ist, ist nicht mehr relevant. Der Service kann auf Basis der JVM zum Beispiel in Python, PHP, Go, Rust oder Ruby implementiert werden. Das ist nur noch ein Detail. Dadurch, dass alle Applikationen gleich deployt werden, wird der Deploymentprozess deutlich verschlankt. Das sehe ich als einen der wichtigsten Vorteile dieser Technologie.

 

Sascha Möllering ist Softwarearchitekt und Senior Software Engineer mit den Schwerpunkten JBoss Middleware, DevOps und Mobile-Development bei der Zanox AG in Berlin. Zuvor war er bei der Allianz Managed Operations & Services als Solution Architect für Konzeption, Aufbau und Betriebssteuerung des JBoss Middleware Stacks von RedHat verantwortlich. Zu diesem Zeitpunkt brachte Sascha Möllering bereits Consulting-Know-how aus Unternehmensberatungen wie z. B. Accenture Technology Solutions und Cirquent mit. Neben seiner beruflichen Tätigkeit schreibt er regelmäßig zu Java- und JBoss-Themen im Java Magazin und seinem Blog.

 

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: