Nicht alle Runtimes sind gleich. Eine wichtige Frage für Entwicklerteams ist: Besitzt die Anwendung eine Coldstart-Phase, die einen ersten Resource Burst verursacht? Es existieren einige Java Frameworks mit Dependency Injection und Annotation Scanning, die eine sehr intensive Coldstart-Phase verursachen. Aufgrund des dynamischen Wirings werden gerade in der Coldstart-Phase viele Ressourcen benötigt, die aber erst einmal komplett hochgefahren werden müssen.

In diesem Artikel werfen wir einen genaueren Blick darauf, wie wir die Java-basierte Anwendung mit Hilfe von Containern und einigen Restrukturierungen in Richtung Microservices deutlich wartbarer und dynamischer gestalten können.

In diesem Artikel zeigen wir, wie sich eine bestehende Java-Applikation innerhalb weniger Minuten so bereitstellen lässt, dass wir uns mit dem Betrieb der Infrastruktur kaum noch auseinandersetzen müssen. Im Laufe des Artikels werden wir auf unterschiedliche Automatisierungsoptionen bei AWS Elastic Beanstalk eingehen. So können wir uns auf die Weiterentwicklung der Applikation selbst fokussieren.

In einer Serie von mehreren Artikeln werden wir die Migration einer „klassischen“ Java-Webanwendung in die AWS-Cloud beleuchten. Dieser erste Artikel behandelt zunächst mögliche Gründe für einen Wechsel, die aktuelle Architektur und eine Migration nach dem „Lift and Shift“-Ansatz. Alle weiteren Artikel optimieren die Anwendung iterativ durch den Einsatz verwalteter Dienste.

Sowohl bei Kunden von Amazon Web Services (AWS) als auch innerhalb von Amazon findet sich eine große Community von Java-Entwicklern. Amazon unterstützt diese Community zukünftig mit Amazon Corretto, einer kostenlosen, plattformübergreifenden Distribution von OpenJDK. Dieser Artikel gibt einen Einblick in die Vorteile und die Details von Amazon Corretto, das derzeit für Java 8 und Java 11 zur Verfügung steht.

Microservices sind ein Softwarearchitektur- und Organisationsansatz, um das Deployment von neuen Software-Releases zu beschleunigen, Innovationen voranzutreiben und die Wartbarkeit und Skalierbarkeit von Software zu erhöhen. Eines der wichtigen Konzepte von Microservice-Architekturen ist es, die einzelnen Bestandteile einer Software in kleine unabhängige Services aufzuteilen, die miteinander über APIs kommunizieren. Dabei liegt die Verantwortung für die einzelnen Services bei relativ kleinen Entwicklungsteams.

Event-driven-Architekturen sind kein neues Architektur-Pattern, haben aber – unter anderem durch das Reactive Manifesto – wieder mehr Aufmerksamkeit erfahren. Der Erfolg von LinkedIn, die stetig wachsende Verbreitung von elastischen Ansätzen in der Cloud und immer stärker zunehmende Datenmengen lassen diese Form der Architektur wieder interessanter werden. Doch wie genau kann so etwas mit modernen Komponenten implementiert werden?

Bis vor Kurzem mussten Entwickler noch selbst Docker auf ihren EC2-Instanzen in Amazon Web Services installieren und das Management der Container vollständig selbst übernehmen. Mit der Einführung der Unterstützung von Docker in Elastic Beanstalk und OpsWorks wurde der Aufwand für die Nutzung von Containern bereits reduziert. Auf der Konferenz „AWS re:Invent 2014“ hat Amazon den neuen EC2 Container Service vorgestellt, der die Hürde für das Betreiben von Software in Docker-Containern noch einmal signifikant senkt.

Das Anliegen von Continuous Delivery ist es, den Auslieferungsprozess von Software nachhaltig zu verbessern. Dafür existieren Technologien wie z. B. die Automatisierung von Tests, Continuous Integration und Continuous Deployment. Das automatisierte Ausrollen von Software über eine Continuous-Delivery-Pipeline ist quasi eine Art Risikomanagement im Softwarebereich.

Cloud Computing hat unbestreitbar erhebliche Vorteile in Bezug auf Kosten, Ausfallsicherheit und Flexibilität. Auch ZANOX möchte – wie andere Firmen auch – von diesen Vorteilen profitieren. Aber ist es ausreichend, wenn ich meine Applikationen einfach in einer Cloud-Umgebung ohne Modifikation laufen lasse? In den allermeisten Fällen lässt sich diese Frage mit einem klaren „Nein“ beantworten. Um die Vorteile einer Cloud-Infrastruktur voll ausnutzen zu können, muss ich auch die entsprechenden Patterns bei der Architektur meiner Applikation verwenden. In diesem Artikel werden einige Best Practices und Patterns beschrieben, um skalierbare, ausfallsichere und verteilte Applikationen zu entwickeln, die global ausgerollt werden können.

Ein aktuelles Hypethema in der Java-Community ist die asynchrone Programmierung sowie die dazugehörigen Plattformen und Frameworks. Diese bieten spannende Lösungswege und neue Denkansätze. Aber sind sie ausgereift genug für die Anforderungen einer Businessanwendung, die ein sehr hohes Maß an Stabilität, Wartbarkeit, Skalierbarkeit und niedrige Latenz erfordert? In vorliegendem Beitrag wollen wir ein Beispielprojekt beschreiben, das ZANOX auf Basis von Vert.x implementiert hat und diese Frage klar mit „ja“ beantwortet. Wir werden im Folgenden Vert.x kurz einführen, dann das Projektsetup und die Integration in die bestehende Infrastruktur erläutern und zum Ende hin auch noch einmal das Monitoring und die Anbindung an andere Messagingsysteme zeigen.