Kolumne

EnterpriseTales: Cloud-native mit Java EE

Lars Röwekamp

Durch Zufall lief mir auf der diesjährigen JavaLand-Konferenz in Brühl Sebastian Daschner, seines Zeichens Java Champion und Autor des Buchs „Architecting Modern Java EE Applications“, über den Weg. Sebastian nimmt am Java-Community-Process teil, ist in den JAX-RS-, JSON-P- und Config-Expert-Groups vertreten und entwickelt an diversen Open-Source-Projekten. Für seinen Beitrag in der Java-Community und im Java-Ökosystem wurde er mit den Titeln Java Champion, Oracle Developer Champion und JavaOne 2016 Rockstar ausgezeichnet (https://blog.sebastian-daschner.com).

Die Chance, mit Sebastian zu sprechen, wollte ich natürlich nicht ungenutzt lassen und habe ihn zu einem spontanen Interview gebeten. In diesem Interview klärt er uns unter anderem darüber auf, warum Entwickler in Zeiten von Cloud auf deutlich mehr Aspekte schauen müssen. Sie müssen sich um mehr als nur die Codebasis kümmern. Außerdem sprechen wir über Sicherheit, Infrastructure as Code und wie damit in der Containerwelt umgegangen werden sollte.

Lars Röwekamp: Hallo Sebastian! Vielen Dank, für das spontane Interview für „EnterpriseTales“. Du hast gerade deinen Talk „12 factor, cloud native Java EE with Kubernetes“ gehalten. Und auch in deinem Buch „Architecting Modern Java EE Applications“ geht um Java EE in der Cloud. Warum dieses Thema? Ist das nicht eher die Ecke von Spring Boot und Spring Cloud?

Sebastian Daschner: Genau das war auch die Idee beziehungsweise die Motivation für meinen Talk. Ich wollte zeigen, dass es absolut möglich ist, cloud-native Enterprise-Anwendungen mit Java EE zu schreiben und in die Cloud zu bringen. Ich bin daher in meinem Talk nicht nur auf die vielen coolen Features von Java EE 8 eingegangen, sondern darüber hinaus vor allem auch auf die Twelve-Factor App, also die Methode beziehungsweise Empfehlung, wie Anwendungen am besten als Software as a Service für die Cloud entwickelt werden können, und habe gezeigt, dass dies bestens zu Java EE passt. Wer heute eine Enterprise-Anwendung entwickeln und in die Cloud bringen möchte, muss sich um deutlich mehr Aspekte Gedanken machen als nur um die Codebasis. Buzzwords wie Resilience, Reactivness und Scalability sowie deren Integration in die eigene Java-EE-Anwendung bestimmen 2018 den Alltag eines Enterprise-Entwicklers.

Röwekamp: Dann sollten sich Enterprise-Entwickler heutzutage nicht nur mit der Fachlichkeit von Anwendung beschäftigen, sondern auch mit Docker und Co. auskennen? Du merkst, ich spiele mit der Frage auf das Thema Dev vs. Ops vs. DevOps an.

Daschner: Es macht durchaus Sinn, dass sich Softwareentwickler mit der Thematik auskennen, da Docker mittlerweile in nahezu allen großen Unternehmen zum Einsatz kommt und ein Entwickler wissen sollte, wie sich seine Software zur Laufzeit zusammensetzt und wie sie zum Einsatz kommt. Ich persönlich spreche in diesem Zusammenhang auch gerne von der Rolle des DevOps Engineers in Abgrenzung zum reinen Enterprise Developer.

Röwekamp: Ok, kannst du den zukünftigen DevOps Engineers denn ein paar Tipps mit auf den Weg geben, wie sie möglichst „gute“ Container bauen?

Daschner: Einer der wichtigsten Tipps, den ich hier geben kann, ist sicherlich, dass man die Copy-on-Write-Layer im Auge behält. Man sollte dabei insbesondere darauf achten, dass man das Docker Image nicht unnötig aufbläht. Wenn man beispielweise Software installiert und dazu in einem Kommando temporäre Dateien hinzufügt, sollte man diese im selben Kommando auch wieder aufräumen, also bevor der Layer ins Docker Image commitet wird.

Röwekamp: Gibt es noch weitere Tipps, die du mit uns teilen möchtest?

Daschner: Fast noch wichtiger ist, dass Dateien, die sich häufig ändern, also beispielsweise Deployment-Artefakte, sich möglichst am Ende eines Docker-Files befinden. Durch diese Maßnahme nutzt man das Copy-on-Write-Filesytem und das Caching von Docker zum eigenen Vorteil, da durch die optimierte Reihenfolge verhindert wird, dass der Rest des Image bei jeder Änderung neu gebaut werden muss. Hält man sich an diese Regel, können auch sehr große Images, bei denen sich aber nur wenig ändert, extrem schnell gebaut und transferiert werden. Hält man die sich ändernden Dateien dann noch möglichst klein, geht es noch schneller. Als Faustregel kann man also sagen: Große Dateien, die sich wenig ändern, an den Anfang stellen und kleine Dateien, die sich häufig ändern, ans Ende.

Röwekamp: Nochmal zum Thema Security. Die Security sollte Teil des Containers sein. Infrastructure as Code war hier das Schlagwort. Siehst du hier den Entwickler beziehungsweise DevOps Engineer in der Verantwortung, oder sollte es eher unternehmensweite Richtlinien für „sichere“ Container geben?

Daschner: Beides. Es macht durchaus Sinn, dass sich das Unternehmen mit dem Thema Security auseinandersetzt und entsprechende Guidelines entwickelt. Zusätzlich kann es, allein schon aus Sicht der Wartbarkeit, sinnvoll sein, dass es unternehmensweite Base Images gibt, die den Aspekt der Security bereits abdecken. So kann zum Beispiel sichergestellt werden, dass die Images benötigte Zertifikate oder sicherheitsrelevante Software beinhalten.

Röwekamp: Aber steht das nicht im Konflikt mit dem Paradigma der generellen Unabhängigkeit der Teams im Umfeld von Microservices?

Daschner: Das ist richtig, widerspricht der Vorgehensweise aber aus meiner Sicht nicht. Auch im Umfeld von Microservices kann man durchaus die eben beschriebenen Base Images anbieten. Den Teams sollte allerdings die Freiheit gelassen werden, für ihren speziellen Service eigenständig zu entscheiden, ob das Image inklusive der sich darin befindenden Security eins zu eins übernommen wird, oder ob es Anpassungen im Bereich der Security und anderer vorgegebener Aspekte vornehmen möchte. Dass die am Ende zur Verfügung gestellte Sicherheit des Containers ausreichend ist, wird durch entsprechende Akzeptanzkriterien sichergestellt. Nur wenn diese erfüllt werden, geht der Container in Produktion. Gleiches gilt natürlich auch für die fachlichen Akzeptanzkriterien.

Röwekamp: Die Cloud bietet uns einen Strauß an Möglichkeiten. Angefangen bei Bare Metal, also reiner Hardware, über VMs bis hin zu Rundum-sorglos-Paketen bleibt kein Wunsch offen. Ich kann via Docker und Kubernetes dafür sorgen, dass meine Enterprise-Anwendung skaliert oder alternativ auf Dienste wie Beanstalk setzen, die mir diese Aufgaben abnehmen. Wie stehst du dazu? Mehr Kontrolle oder mehr Komfort?

Daschner: Mein Ansatz ist – und das ist auch meine Empfehlung an Unternehmen – möglichst viel Kontrolle in der eigenen Hand zu behalten und somit auch entsprechende Flexibilität. In deinem konkreten Beispiel wäre dies also die Variante mit Docker und Kubernetes oder abstrakter formuliert: eine Variante mit Containern und Containerorchestrierung.

Röwekamp: Kannst du das noch etwas genauer begründen?

Daschner: Ich möchte durch diesen Ansatz vermeiden, dass ich mich zu stark von einem einzelnen Cloud-Anbieter und seinem proprietären Angebot abhängig mache. Das ist im Grunde genau die gleiche Situation, wie wir sie vor Jahren bei den Application-Servern vorgefunden haben. Wenn ich bereit bin, mich auf die Frameworks, Libraries und APIs des Herstellers einzulassen, laufe ich automatisch in einen Vendor Lock-in. Setze ich dagegen auf einen Standard, also im Fall der Application-Server auf einen Java-EE-Server, kann ich bei Bedarf mit sehr geringem Aufwand den Hersteller wechseln. Genau diese Situation erleben wir heute mit den verschiedenen Cloud-Anbietern. Wenn ich mich auf die proprietären Dienste eines einzelnen Anbieters einlasse, dann komme ich da später nur mit sehr viel Aufwand wieder raus. Wenn ich dagegen bei demselben Anbieter auf Standards oder De-facto-Standards setze, ist ein Wechsel zu einem anderen Anbieter bei Bedarf relativ einfach möglich.

Röwekamp: Das klingt nachvollziehbar. Siehst du noch weitere Gründe?

Daschner: Was noch hinzukommt, ist die Flexibilität bezüglich der Technologie. Nutze ich die Convenient-Dienste des Cloud-Anbieters, bin ich automatisch auf einen eingeschränkten Technologiestack festgelegt. Setze ich dagegen Container ein, bin ich in der Wahl der Technologie frei. Egal ob Java, Node.js oder Python, innerhalb meines Containers kann ich einsetzen, was immer ich für sinnvoll halte und auf einer Linux VM lauffähig ist.

Röwekamp: Was wäre denn dein bevorzugtes Tool für die Containerorchestrierung?

Daschner: Wenn es um Containerorchestrierung und -skalierung geht, steht Kubernetes sicherlich ganz weit oben auf der Liste. Kubernetes hat sich nach meinem Empfinden in den letzten Jahren zu einem De-facto-Standard entwickelt.

Röwekamp: Muss ich das Rad wirklich neu erfinden, oder wäre ein bisschen Komfort nicht doch schön? Ich denke an die Open-Source-Containermanagementplattform OpenShift von Red Hat. Könnte das eine Alternative für Unternehmen sein, denen Ressourcen fehlen, um sich mit den Details von Containern und deren Orchestrierung auseinanderzusetzen?

Daschner: Gerade OpenShift sehe ich durchaus als sinnvolle Alternative an, da dieses Tool direkt auf Kubernetes aufsetzt und unter anderem genau aus diesem Grund eine starke Verbreitung gefunden hat. OpenShift fügt zu den Features von Kubernetes zusätzlich jede Menge Cross-cutting Concerns hinzu, mit denen sich große Unternehmen beschäftigen müssen. Beispielsweise werden durch die Plattform Aspekte wie Userzugriff oder Projektzugriff geregelt, und das in einer deutlich umfangreicheren Art und Weise als es Kubernetes out of the Box mit sich bringt. OpenShift liefert somit viele Convenient-Layer, die ich im Enterprise-Umfeld benötige.

Röwekamp: Dann bedanke ich mich bei dir für das Interview und die vielen Tipps rund ums Thema „Java EE in der Cloud“. Ich freue mich auf die kommenden Monate und Jahre, die sicher extrem spannend werden. Und für alle Leser gilt wie immer: Stay tuned and engage (und lest Sebastians Buch, es lohnt sich)!

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: