In vielen Kundenprojekten ist der Wunsch zu beobachten, von klassisch betriebenen Anwendungen sofort in die Cloud oder zumindest nach Kubernetes zu migrieren. Vielleicht schwingt dabei der Wunsch mit, Zeit zu sparen, indem Zwischenschritte ausgelassen werden. Oder man ist sich sehr wohl bewußt, dass man in Gewissen Bereichen versäumt hat, Know-How aufzubauen und in Modernisierung zu investieren.

Wir empfehlen regelmäßig zumindest kleine Zwischenschritte einzuplanen, um Erfahrungen mit der Erstellung aber auch dem Design von Anwendungen für Container- und Cloudumgebungen zu sammeln. Das gilt um so mehr, wenn das Unternehmen sich nicht ganze Teams, die sich nur um Infrastruktur und Support kümmern können, leisten möchte.

Eine gute Möglichkeit zum Start stellt der Einsatz von Docker Containern ohne automatischen Orchestrator wie Kubernetes, Mesos oder Docker-Swarm dar. Dabei wählt man typischerweise eine Anwendung aus, die nicht absolut essentiell ist, und optimalerweise bereits von einem Team mit modernen Technologien und vor allem Mindset entwickelt und betreut wird.

Mit verhältnismäßig wenig Infrastruktur können dann auch bereits Patterns aus der Cloud-Welt verprobt werden und entsprechende Erfahrungen mit den notwendigen Umsystemen und Prozessen gewonnen werden. Wichtig ist dabei, dass man den Schwenk auf fertige Lösungen vornimmt, und nicht mit eigenen Mitteln Dinge nachbaut und wartet, die ein Orchestrator mitliefert.

Hat man sich für traefik als Reverseproxy und Loadbalancer entschieden, um Container verfügbar zu machen, kann man bereits von vielen Vorzügen profitieren.

Ein Kunde wünschte sich Canary-Deployments auszuprobieren, und das allein mit traefik. Wie so ein Canary oder A/B Deployment mit traefik umgesetzt werden kann, zeigt der folgende Beitrag.

Distanzierung zur TrioN Consulting Heek

Aus aktuellem Anlass stellen wir klar:

Bei der trion development GmbH aus Münster handelt es sich um ein eigenständiges Unternehmen, das nicht mit der Marke "TrioN Consulting" aus Heek-Nienborg in Vebindung...

Bei Drone CI handelt es sich um einen OpenSource continuous integration (CI) Server. Dabei setzt Drone CI auf die Ausführung des Builds mittels Containern. Typischerweise werden dabei Docker oder Kubernetes als Container Plattform eingesetzt.

Eine Buildpipeline wird in YAML definiert, dabei können sowohl services definiert werden, die im Build verwendet werden, als auch persistente volumes und natürlich die Buildabläufe als steps.

Als Standard-Verfahren für Datei-Uploads kommt bei Nest.js-Anwendungen typischerweise ein Datei-Upload als multipart/form-data mit Hilfe der Multer-Bibliothek zum Einsatz. Dies ist jedoch nicht immer passend: Die Verwendung von multipart/form-data kommt typischerweise im Kontext von HTML Formularen vor. Ohne HTML Formular und eingebaute Logik eines Browser ist die Verwendung auf Clientseitig teilweise umständlich zu implementieren.

Im Kontext von Microservice Architekturen liegen manchmal Daten vor, die zwar als einzelne Verarbeitung behandelt werden sollen, die jedoch mit einem klassischen File-Upload Formular wenig zu tun haben.

Bei Nest.js kommt die aus dem Node / Express Umfeld bekannte Multer Bibliothek für Multipar-Uploads zum Einsatz. Mit einzelnen Binary-POSTs kann sie jedoch nicht umgehen.

In diesem Artikel werden wir einen Datei-Upload implementieren, der ohne Multer auskommt und stattdessen die Dateien direkt als Binärdaten einließt.

Ein typisches Java Projekt besteht nicht nur aus dem eigenen Code, sondern in der Regel auch vielen externen Bibliotheken als Abhängigkeiten.
Diese Abhängigkeiten machen dabei in einem Microservice mehr als 90% Anteil am gesamten Code aus. Die Wartung erfolgt zwar durch den jeweiligen Hersteller, jedoch muss das Projekt Team darauf achten, dass entsprechende Aktualisierungen auch im Projekt aufgenommen werden. Kritisch wird es dann, wenn Sicherheitsupdates zwar verfügbar sind, jedoch nicht die zugehörige Maven oder Gradle Konfiguration aktualisiert wird.

Um das Problem zu lösen gibt es verschiedene Ansätze mit einem unterschiedlichen Automatisierungsgrad. Wir wollen einen pragmatischen Ansatz vorstellen, der sich in der Praxis sehr bewährt hat und seinerseits keine zusätzlichen Abhängigkeiten einführt.

Dank Spring Boot ist die Erstellung von Java basierten Anwendungen und Microservices extrem leicht geworden: Mit Spring Initializr ( https://start.spring.io ) ist eine API Anwendung schnell erstellt. Sinnvolle Standardeinstellungen und eine gute Entwicklerproduktivität machen Spring Boot auch im weiteren Verlauf eines Softwareprojekts zu einer beliebten Plattform.

Doch was ist, wenn man von den vorgegebenen Pfaden abweichen will?
Spring Boot zeigt sich hier flexibel: Am Beispiel von YAML als Datenformat für unsere Anwendung schauen wir uns das einmal genauer an.

Auch wenn Microservice Architekturen und damit einhergehend Single-Module-Repositories im Trend liegen, gibt es immer wieder Gründe für ein Multi-Module Projekt. Sogar bei Microservice als Deployment.
Wenn es nun darum geht, die Code-Coverage zu ermitteln, um diese bei GitLab CI anzuzeigen oder Trends zu ermitteln, muss man sich etwas behelfen. GitLab CI ist im Verglech zu Jenkins nämlich deutlich dünner ausgestattet, so dass eine Fancy Plugins die Arbeit abnehmen. Damit ist Jenkins nicht automatisch besser oder GitLab CI schlechter, als Jenkins: Die Ausrichtung ist einfach anders.

Im folgenden betrachten wir einmal, wie die modulübergreifende Auswertung von Code Coverage, erhoben mit dem JaCoCo Maven Plugin, aussehen könnte. Der Ansatz lässt sich natürlich auf andere Coverage-Tools und Sprachen analog übertragen.

React Native oder NativeScript? - Eine komparative Analyse für Enterpriseanwender
Im Bereich der mobilen Anwendungsentwicklung von nativen Apps gibt es viele Wege, die zum Ziel führen. Aus bereits im Vorfeld beschriebenen Gründen [1] [2] konnten wir diese Auswahl an Wegen für die meisten praktischen Anwendungsfälle bereits auf die beiden Cross-Platform-Frameworks React Native und NativeScript reduzieren.

Aber welches der beiden Frameworks sollte man denn nun für die eigene Anwendung verwenden? Die Lösung dazu und die Antwort auf weitere Fragen werden in dieser Analyse behandelt.

Für die Lesenden, die sich zunächst einmal grundlegend mit den beiden Frameworks auseinandersetzen möchten, haben wir bereits jeweils einen Artikel zu React Native[1] und einen zu Native Script [2] vorbereitet.

OpenID Connect und OAuth2 sind vielleicht etwas moderner und hipper als das bereits etwas in die Jahre gekommene SAML 2 Protokoll. Soll jedoch im Enterpriseumfeld eine Anwendung in bestehende Landschaften integriert werden, führt selten ein Weg an SAML 2 vorbei. Das gilt um so stärker, wenn es sich um eine Branche mit hohem Sicherheitsbedarf wie Luftfahrt, Banken oder Versicherungen handelt.

Keycloak hat sich als zuverlässige und gleichzeitig sehr leicht zugängliche Plattform zur Umsetzung von OpenID Connect oder SAML erwiesen. Dabei kann Keycloak sowohl produktiv eingesetzt werden, als auch sehr komfortabel als lokale Testumgebung für Entwicklung und Test verwendet werden. Zur Integration von Keycloak in Spring Boot existieren neben einem Keycloak Modul auch Spring-Security-SAML bzw. OAuth2 Client und Resourceserver.

Gerade wenn es um das Thema Security geht, bringen automatisierte Tests ein wichtiges Sicherheitsnetz für die Software. Wir wollen Keycloak als SAML 2 IdP verwenden und mit einer Spring Boot Anwendung Authentifizierung mit SAML 2 als Beispielanwendung für automatisierte Integrationstests verwenden. Ein - relativ einfacher - Weg wäre, Keycloak als Docker Container im Rahmen der CI-Pipeline mit Jenkins, Bamboo oder GitLab-CI bereitzustellen, so dass die zu testende Software darauf zugreifen kann. Allerding verliert man damit die Möglichkeit, die Tests lokal genauso zu entwickeln und zu validieren, wie sie nachher in der Buildserver Umgebung laufen.

Eine Alternative stellen Testcontainers dar. Die allgemeine Verwendung von Testcontainers wurde bereits in Testcontainers mit JUnit 5 erläutert. Nun schauen wir uns an, wie Keycloak, Testcontainers und Spring Boot SAML 2 zusammen eingesetzt werden kann.

Mobile Entwicklung für Enterprise Anwendungen
Bei der mobilen App-Entwicklung gibt es heutzutage viele verschiedene Optionen. Im letzten Artikel [3] wurde bereits React-Native als ein Weg zum Ziel beschrieben. Dort wurde die insbesondere für Enterprise-Anwendungen größtenteils fehlende MVC-Trennung angemerkt. Eine weitere Alternative mit anders umgesetzter Separation of Concerns ist NativeScript [1].

In diesem Artikel wollen wir eine Basis für App-Entwicklung aller Art mit NativeScript legen, daher ist der gesamte Quellcode auf GitHub verfügbar [2]. Er kann direkt ausgechecked und auf die eigenen Bedürfnisse ausgebaut werden. Das spart Zeit beim initialen Setup.