adesso Blog

In meinem Blog-Beitrag möchte ich mit euch ein paar Gedanken zur Anwendungssicherheit in Microservices-Architekturen teilen. Dabei werde ich auf die Verlagerung von Security-Funktionalitäten in Frameworks und in den Infrastruktur-Stack eingehen und erkläre, was das Ganze für Security-Expertinnen und -Experten sowie Entwicklungsteams bedeutet. Zudem gehe ich auch auf die durchaus schon lange bekannten Herausforderungen stark verteilter Systeme ein.

Ja, richtig gelesen, es gibt Alternativen! Obwohl der Platzhirsch Spring sich bei Java-Anwendungen großer Beliebtheit erfreut, sollte man nicht vergessen, dass es daneben auch noch andere Frameworks gibt, die einen Blick wert sind. In diesem Blog-Artikel soll es um Micronaut gehen, ein noch vergleichsweise junges Framework, welches jedoch einige interessante Eigenschaften hat, die es besonders im Cloud-Umfeld zu einem echten Rivalen gegenüber Spring machen. Wir implementieren in diesem Artikel eine Anwendung einmal mit Spring Boot und einmal mit Micronaut. Danach vergleichen wir die beiden Ansätze und schauen, wo welches Framework überlegen ist.

Bei der Migration von Legacy-Anwendungen vom IBM Mainframe in eine Linux basierte Infrastruktur stellen einen die meist rechenintensiven und damit häufig auch langläufigen Batch-Verarbeitungen bzw. Tasks vor die Aufgabe der Definition einer geeigneten Zielarchitektur. Eine mögliche Antwort gibt dieser Blog-Artikel.

Bei der Entwicklung von Anwendungen in einer Microservice-Architektur muss man mit wesentlich komplexeren Laufzeitumgebungen zurechtkommen als bei monolithischen Anwendungen. Im Gegensatz zu einem Monolithen kann eine Microservice-Architektur nur in Teilen verfügbar sein. Continous Deployment einzelner Microservices führt dazu, dass es keine einheitliche Gesamtversion des Systems mehr gibt. Irgendwie muss man sich hier Übersicht verschaffen. Wenn das schon während der Entwicklung in den anfangs noch nicht so stabilen Integrations- und Testsystemen gelingt, vermeidet man viel Aufwand für spätere Fehlerdiagnose.

Nachdem ich im ersten Teil meiner Blog-Serie „Technische Dinge für nichttechnische Leute“ verschiedene Datenformate näher beleuchtet und deren Unterschiede erklärt habe, möchte ich euch nun das Thema „Microservices“ genauer vorstellen.

In einer verteilten Architektur spielt die Kommunikation der verteilten Services eine zentrale Rolle. Wie sollen die Services miteinander reden? Sollten sie synchron kommunizieren? Oder asynchron über einen Messaging-Mechanismus? Wie so oft ist dies keine einfache Entscheidung zwischen zwei Alternativen, die Abhängig vom jeweiligen Kontext getroffen werden muss. Dieser Artikel beschreibt einige Kommunikationsmuster zwischen verteilten Services.

In verteilten Systemen ist es selbstverständlich, dass viele verteilte Komponenten an der Beantwortung eines einzelnen eingehenden Requests beteiligt sein können. Insbesondere für Debugging-Zwecke ist es unabdingbar, dass ein solcher Request
innerhalb des verteilten Systems über alle beteiligten Komponenten hinweg nachvollzogen werden kann. Dieser Artikel geht auf die Traceability von Requests und Fehlern in verteilten Systemen ein und gibt einige Tipps und Tricks mit, um eine Lösung auf Basis von Spring Cloud Sleuth umzusetzen.