Microservices-basierte Architekturen auf der grünen Wiese zu starten mag ja noch vorstellbar sein. Was aber, wenn es – wie leider so häufig in der Praxis – einen bestehenden, historisch gewachsenen Monolithen gibt, der schon einmal bessere Tage gesehen hat? Wie kann ein möglicher Migrationspfad aussehen und mit welchen Stolperfallen muss dabei gerechnet werden? Im Rahmen des Workshops nehmen wir uns anhand eines konkreten Beispiels einen solchen Monolithen vor, überlegen, welche Services sich sinnvoll herauslösen lassen und welche Patterns dazu verwendet werden sollten. Natürlich ergeben sich durch die neue Architektur auch neue Herausforderungen, denen wir uns stellen müssen. Aber das kann uns natürlich nicht stoppen!
Die gute Nachricht vorweg: Einen einzelnen Microservice zu implementieren ist dank Bounded Context, loser Kopplung und klar definierter Kommunikationsschnittstellen denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und ein einzelner Microservice noch lange keine sinnvolle Anwendung aus! Um am Ende nicht im Chaos zu versinken, benötigt auch eine Microservices-basierte Anwendung eine Architektur und die Verwendung von Patterns. Wie zum Beispiel stellt man die Evolution von Schnittstellen sicher? Oder wie soll die UI eingebunden werden? Welche Aufgaben übernimmt ein API Gateway und wird es überhaupt benötigt? Sollten Microservices synchron oder asynchron kommunizieren? Oder gar beides? Fragen über Fragen, deren Klärung über Erfolg oder Misserfolg der eigenen Anwendung entscheiden kann. Der Workshop gibt einen Einblick in die verschiedenen Herausforderungen bei der Umsetzung einer Microservices-basierten Anwendung und diskutiert verschiedene Lösungsansätze, Patterns und Best Practices. Ein optimaler Einstieg in den Microservices-Summit.
Eine Anwendung basierend auf Microservices mit Java zu entwickeln kann ja so schwer nicht sein. Schließlich gibt es Frameworks wie Spring Boot oder MicroProfile, die dem Entwickler das technologische Rahmengerüst vorgeben. Nur leider ist es damit nicht getan. Wie zum Beispiel sieht der optimale Service-Schnitt aus? Wie kommunizieren die Services untereinander, ohne dabei ihre Unabhängigkeit zu verlieren? Wie soll die Anwendung reagieren, wenn mal ein Service nicht so kann, wie er soll? Und wie bindet man seine Microservices an bestehende Infrastruktur wie Distributed Tracing, Monitoring oder Identity Provider an?
Was sich in der Theorie einfach anhört, bringt in der Praixis so manchen Stolperstein mit sich. Im Rahmen des Workshops werden wir daher gemeinsam eine kleine, auf Microservices basierende Anwendung bauen und zum „Fliegen“ bringen. Angefangen bei der Diskussion über den optimalen Service-Schnitt via Domain-driven Design, über die Integration der Services untereinander via unterschiedlicher Kommunikationspatterns inkl. eingebauter Fehlertoleranz bis hin zur Instrumentalisierung der Services zwecks Laufzeitanalyse und -optimierung, lassen wir dabei kaum ein Thema aus.
Am Ende steht eine Anwendung, die live gehen könnte – naja, fast.
Microservices richtig umgesetzt bedeutet auch die ehemals monolithische Datenbank aufzusplittern. Transaktionen über Servicegrenzen hinweg, stellen somit eine neue Herausforderung dar.
Da hat man einmal eine tolle Idee für eine Mobile-App und möchte sie so schnell wie möglich realisieren, und dann scheitert das Ganze am Ende am passenden Backend. Zu aufwendig und riskant die Anpassung des bestehenden Web-Backends, zu zeitintensiv und teuer die Entwicklung eines neuen Mobile-Backends. Von mangelnder Skalierung, Security und Co. ganz zu schweigen. Aber kein Grund zur Panik: Wo ein Wille ist, ist auch ein Weg. Die Session zeigt, wie bestehende Backends für Mobile-Apps „enabled“ und neue Backends on the fly via Cloud-Anbieter zur Verfügung gestellt werden können. SaaS, PaaS, BaaS und BFF heißen die Akronyme der Stunde. Was nimmt man wann? Auflösung folgt …
Der goldene Schnitt – Wie schneide ich Microservices richtig?OPEN KNOWLEDGE GmbH
Mit Microservices wird versucht, eine Anwendung in möglichst kleine, unabhängige Teile zu schneiden, die dann miteinander kommunizieren. Diese Idee bringt einige Vorteile mit sich. Wie bekommt man es aber hin, dass dabei die Fachlichkeit nicht zerpflückt wird und so der Blick für das große Ganze verloren geht? Wie schneide ich die Services richtig? Und worauf muss bei der Kommunikation der Services untereinander geachtet werden? Der Workshop zeigt, wie Domain-driven Design dabei helfen kann, diese Fragen sinnvoll zu beantworten, und was es sonst noch zu beachten gilt.
Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler technischer Transaktionen an, auch Saga-Pattern genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt seine praktische Verwendung an verschiedenen Beispielen.
Kaum haben wir uns von dem klassischen Monolithen und der zugehörigen Ablaufumgebung namens Application Server zugunsten von Microservices und Embedded Runtimes verabschiedet, taucht am Horizont mit Serverless Applications bzw. Architectures schon die nächste Evolutionsstufe auf. Was bitte ist das jetzt schon wieder? Und wer braucht so etwas? Die Session zeigt, wie sich dank PaaS, BaaS, FaaS und einiger anderer Akronyme Mobile- und Enterprise-Anwendungen Cloud-basiert implementieren lassen – ganz ohne Server! Ganz ohne? Naja, fast.
Die Matrix: Enterprise-Architekturen jenseits von MicroservicesOPEN KNOWLEDGE GmbH
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Getreu dem Motto "choose Microservices for the benefits and not because your codebase is a mess." (Zitat: Simon Brown), beleuchtet die Session typische Problemstellungen aus großen Projekten und zeigt auf, für welche dieser Microservices eine Lösung darstellen und für welche eher nicht. Anhand verschiedener Real-Life-Anforderungen, werden alternative Architekturen als Lösungsansätze gezeigt und bewertet.
Die gute Nachricht vorweg: Einen einzelnen Microservice zu implementieren ist dank Bounded Context, loser Kopplung und klar definierter Kommunikationsschnittstellen denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und ein einzelner Microservice noch lange keine sinnvolle Anwendung aus! Um am Ende nicht im Chaos zu versinken, benötigt auch eine Microservices-basierte Anwendung eine Architektur und die Verwendung von Patterns. Wie zum Beispiel stellt man die Evolution von Schnittstellen sicher? Oder wie soll die UI eingebunden werden? Welche Aufgaben übernimmt ein API Gateway und wird es überhaupt benötigt? Sollten Microservices synchron oder asynchron kommunizieren? Oder gar beides? Fragen über Fragen, deren Klärung über Erfolg oder Misserfolg der eigenen Anwendung entscheiden kann. Der Workshop gibt einen Einblick in die verschiedenen Herausforderungen bei der Umsetzung einer Microservices-basierten Anwendung und diskutiert verschiedene Lösungsansätze, Patterns und Best Practices. Ein optimaler Einstieg in den Microservices-Summit.
Eine Anwendung basierend auf Microservices mit Java zu entwickeln kann ja so schwer nicht sein. Schließlich gibt es Frameworks wie Spring Boot oder MicroProfile, die dem Entwickler das technologische Rahmengerüst vorgeben. Nur leider ist es damit nicht getan. Wie zum Beispiel sieht der optimale Service-Schnitt aus? Wie kommunizieren die Services untereinander, ohne dabei ihre Unabhängigkeit zu verlieren? Wie soll die Anwendung reagieren, wenn mal ein Service nicht so kann, wie er soll? Und wie bindet man seine Microservices an bestehende Infrastruktur wie Distributed Tracing, Monitoring oder Identity Provider an?
Was sich in der Theorie einfach anhört, bringt in der Praixis so manchen Stolperstein mit sich. Im Rahmen des Workshops werden wir daher gemeinsam eine kleine, auf Microservices basierende Anwendung bauen und zum „Fliegen“ bringen. Angefangen bei der Diskussion über den optimalen Service-Schnitt via Domain-driven Design, über die Integration der Services untereinander via unterschiedlicher Kommunikationspatterns inkl. eingebauter Fehlertoleranz bis hin zur Instrumentalisierung der Services zwecks Laufzeitanalyse und -optimierung, lassen wir dabei kaum ein Thema aus.
Am Ende steht eine Anwendung, die live gehen könnte – naja, fast.
Microservices richtig umgesetzt bedeutet auch die ehemals monolithische Datenbank aufzusplittern. Transaktionen über Servicegrenzen hinweg, stellen somit eine neue Herausforderung dar.
Da hat man einmal eine tolle Idee für eine Mobile-App und möchte sie so schnell wie möglich realisieren, und dann scheitert das Ganze am Ende am passenden Backend. Zu aufwendig und riskant die Anpassung des bestehenden Web-Backends, zu zeitintensiv und teuer die Entwicklung eines neuen Mobile-Backends. Von mangelnder Skalierung, Security und Co. ganz zu schweigen. Aber kein Grund zur Panik: Wo ein Wille ist, ist auch ein Weg. Die Session zeigt, wie bestehende Backends für Mobile-Apps „enabled“ und neue Backends on the fly via Cloud-Anbieter zur Verfügung gestellt werden können. SaaS, PaaS, BaaS und BFF heißen die Akronyme der Stunde. Was nimmt man wann? Auflösung folgt …
Der goldene Schnitt – Wie schneide ich Microservices richtig?OPEN KNOWLEDGE GmbH
Mit Microservices wird versucht, eine Anwendung in möglichst kleine, unabhängige Teile zu schneiden, die dann miteinander kommunizieren. Diese Idee bringt einige Vorteile mit sich. Wie bekommt man es aber hin, dass dabei die Fachlichkeit nicht zerpflückt wird und so der Blick für das große Ganze verloren geht? Wie schneide ich die Services richtig? Und worauf muss bei der Kommunikation der Services untereinander geachtet werden? Der Workshop zeigt, wie Domain-driven Design dabei helfen kann, diese Fragen sinnvoll zu beantworten, und was es sonst noch zu beachten gilt.
Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler technischer Transaktionen an, auch Saga-Pattern genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt seine praktische Verwendung an verschiedenen Beispielen.
Kaum haben wir uns von dem klassischen Monolithen und der zugehörigen Ablaufumgebung namens Application Server zugunsten von Microservices und Embedded Runtimes verabschiedet, taucht am Horizont mit Serverless Applications bzw. Architectures schon die nächste Evolutionsstufe auf. Was bitte ist das jetzt schon wieder? Und wer braucht so etwas? Die Session zeigt, wie sich dank PaaS, BaaS, FaaS und einiger anderer Akronyme Mobile- und Enterprise-Anwendungen Cloud-basiert implementieren lassen – ganz ohne Server! Ganz ohne? Naja, fast.
Die Matrix: Enterprise-Architekturen jenseits von MicroservicesOPEN KNOWLEDGE GmbH
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Getreu dem Motto "choose Microservices for the benefits and not because your codebase is a mess." (Zitat: Simon Brown), beleuchtet die Session typische Problemstellungen aus großen Projekten und zeigt auf, für welche dieser Microservices eine Lösung darstellen und für welche eher nicht. Anhand verschiedener Real-Life-Anforderungen, werden alternative Architekturen als Lösungsansätze gezeigt und bewertet.
Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Die Zeiten einfacher Web-Anwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle, wie Web, Desktop, Mobile oder 3rd Party Clients, parallel bedienen zu müssen. Und das mit einer Architektur. Wie aber sieht eine passende Architektur aus? Welche neuen Herausforderungen ergeben sich durch die zusätzlichen Kanäle? Und welche Auswirkungen hat dies auf Aspekte wie Security, Schnittstellendesign oder das Datenmodell? In der Session „öffnen“ wir eine Web-Anwendung und stellen uns den Herausforderungen.
Oftmals wird "Multi-Channel" gleichgesetzt mit Responsive Design. Dies setzt allerdings voraus, dass jeder Channel mehr oder minder dieselben Use-Cases bedient. Ein echter Business-Mehrwert wird aber erst erreicht, wenn jeder Channel seine speziellen Eigenschaften ausspielt, was automatisch eine deutlich größere Flexibilität - auch auf Ebene der Architektur - verlangt. Genau hier setzt die Session an und zeigt, wie eine Architektur aufgebaut sein sollte, die deutlich mehr erlaubt als "nur" Responsive Design.
CQRS (Command Query Responsibility Segregation) als Architektur-Pattern sieht vor, dass lesende (Queries) und schreibende Zugriffe (Commands) in getrennten Subsystemen auf unterschiedlichen Modellen realisiert werden. Während Commands meist asynchron und transaktional angestoßen werden, arbeiten Queries mit denormalisierten Views auf “eventual consistent” Daten. Ziel ist eine hoch skalierbare, hoch performante und sichere Plattform. Was sich zunächst einmal nach zusätzlichem Aufwand anhört, bringt in der Praxis eine Menge Vorteile mit sich. Die Session zeigt die wesentlichen Ideen von CQRS auf und demonstriert anhand eines praktischen Beispiels die Vorteile dieses Ansatzes im Kontext von Web APIs.
Mit dem Begriff „Microservice-Architektur“ wird der Architekturstil beschrieben, bei dem mehrere unabhängige Services eine Applikation bilden.
Aber in welchen Situationen ist die Wahl dieses Ansatzes sinnvoll? Welche Konsequenzen hat es, wenn ich mich dafür entscheide? Wie finde ich den richtigen Service-Schnitt? Und wie baue ich ein passendes Frontend dazu?
Der Vortrag gab einen guten Überblick über die Herausforderungen und deren Lösungsmöglichkeiten und beleuchtete dabei auch Themen wie Testing und Continuous Delivery.
Das „Schwergewicht“ Java EE scheint nicht wirklich mit der Wunderwelt der Microservices und den damit einhergehenden Architekturpatterns zu harmonisieren. Dabei bringt der Java-Enterprise-Standard technologisch gesehen alles mit, was es zur Umsetzung von Microservices benötigt. Wo also liegt das Problem? In der Session werden wir Schritt für Schritt eine monolithische Java-EE-Anwendung „sezieren“ und uns den damit einhergehenden Herausforderungen der neu entstandenen, Microservice-basierten Architektur stellen. Aha-Effekte garantiert!
Die Zeiten einfacher Webanwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle wie Web, Desktop, Mobile oder 3rd-Party-Clients parallel bedienen zu müssen. Und das mit einer Architektur, die am besten auch noch zukünftigen, bisher noch nicht bekannten Anforderungen standhält. Wie aber sieht eine solche Architektur aus? Welche neuen Herausforderungen ergeben sich durch die Öffnung für zusätzliche Kanäle? Und welche Auswirkungen hat das alles auf Themenbereiche wie Security, Schnittstellendesign, Versionierung oder das Domänen- bzw. Datenmodell? Im Rahmen der Session „öffnen“ wir eine klassische monolithische Webanwendung und stellen uns den Herausforderungen.
Monolithische Mehrschichtarchitekturen scheinen ihre besten Tage hinter sich zu haben. Heute muss alles “micro”, „loosely coupled“ und „highly flexible“ sein. Ach ja, “resilient” nicht zu vergessen! Hört sich spannend an, aber was genau bedeutet das eigentlich für uns Entwickler/Architekten? Brauchen wir wirklich neue Architekturen? Und wenn ja, welche Herausforderungen ergeben sich dadurch? Mit welchen Patterns und Best Practices kann man diese Herausforderungen bewältigen? Und wie sieht überhaupt ein möglicher Migrationspfad aus, wenn man nicht das Glück hat, auf der grünen Wiese starten zu dürfen? Fragen über Fragen. Die zugehörigen Antworten auf dem Weg in eine leichtgewichtige(re) Zukunft gibt es in der Session.
Wer Microservices implementiert, wird schnell feststellen, dass ihn viele Herausforderungen erwarten, die er bis dahin nicht gekannt hat. Resilience, Service Discovery, verteilte Autenfizierung, Tracing und Health Checks sind Themen, die man als Entwickler nicht jedes Mal neu erfinden möchte. Aber zum Glück gibt es da etwas von der Eclipse-Foundation – das MicroProfile. Eine Spezifikation, die mit ihren verschiedenen Implementierungen den technischen Herausforderungen von Microservices eindrucksvoll begegnet. Egal ob Health Check, Metrics, Fault Tolerance, JWT Propagation, Configuration, Tracing oder Open API, das MicroProfile hat die passenden APIs im Gepäck. Mit viel Code und wenig Slides wirft dieser Workshop einen Blick auf die jeweiligen APIs, zeigt sie im Praxiseinsatz und stellt Vorteile und Probleme vor.
Jeder redet von Continuous Delivery, aber was macht eine gute Development-, Testing- und Delivery-Pipeline aus? Diese Session soll zeigen, welche Schritte nötig sind, um das Ziel Continuous Delivery zu erreichen. Neben Themen wie Update- und Roll-out-Strategie werden ebenso Crash Reports und Analytics-Möglichkeiten beleuchtet.
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
20161123_API Summit:
Denk man an Web APIs, dann verbindet man das zugehörige Kommunikationsmodell meist mit RESTful Requests & Responses. Dies macht in vielen Fällen sicherlich auch Sinn. Aber eben nicht in allen! Was ist z. B., wenn auf Seiten des Clients komplexe Abfragen anstehen, die sich nicht so einfach über simple “Ressourcen” abbilden lassen. Wie geht man damit um, wenn auf dem Server lang laufende Aktionen angestoßen werden, auf deren Abarbeitung der Client nicht unbedingt warten möchte? Und muss es eigentlich immer clientseitiges “Pull” sein oder macht nicht Serverseitiges “Push” via Websockets in vielen Anwendungsfällen mehr Sinn? Die Session zeigt anhand ausgewählter, praxisnaher Use-Cases, wie man durch verschiedene Pattern das klassische RESTful Request-/Response-Modell seiner Web API sinnvoll erweitern kann und so zu deutlich eleganteren und performanteren Lösungen kommt.
App war gestern: Mobile Engagement als Teil der Enterprise-StrategieOPEN KNOWLEDGE GmbH
„Hilfe, wir brauchen eine App!“ Erschreckend, aber wahr: Nicht selten starten Unternehmen genau so ihre mobilen Projekte. Dabei geht es doch weniger um einzelne Apps, als vielmehr darum, mit einem sinnvollen „Mobile Engagement“ die bestehende Enterprise-(IT-)Strategie gewinnbringend zu ergänzen. Mobile Mehrwerte schaffen ist der Schlüssel zum Erfolg. Doch wie findet man diese? Und hat man sie einmal gefunden, ist dann das Backend überhaupt in der Lage, den neuen Channel „Mobile“ sinnvoll zu bedienen? Keine Frage, eine Mobile-Enterprise-Strategie muss her! Die Session zeigt die typischen Stolpersteine vieler Unternehmern auf dem Weg in die Wunderwelt „Mobile“ und gibt praxisnahe Tipps an die Hand, wie man diese mit ein wenig Planung umgehen kann. Am Ende steht – statt einer Menge Frust – eine gelungenes Mobile Engagement mit Anbindung an das Unternehmens-Backend.
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer cloudspezifischer Architekturmuster? Im Rahmen des Workshops werden wir Schritt für Schritt eine bestehende Enterprise-Anwendung in die Cloud migrieren. Angefangen bei der Nutzung von Cloudinfrastruktur (IaaS) über die Anbindung von Cloudplattformkomponenten (PaaS) und Backend-Services (BaaS) bis hin zu Serverless Functions (FaaS) werden wir für die unterschiedlichen Anwendungsszenarien unserer Applikation passende Architekturansätze entwerfen und deren Vor- und Nachteile diskutieren. Natürlich sprechen wir dabei auch Themen wie Testing, Monitoring und automatisiertes Deployment an.
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?OPEN KNOWLEDGE GmbH
Die Cloud rückt in den letzten Jahren mehr und mehr in den Fokus. Die Möglichkeiten scheinen unbegrenzt: von virtuellen Servern bis hin zur vollständigen Verlagerung der Anwendungslogik in die Cloud (aka Serverless). Doch in welchem Kontext macht welches Szenario wirklich Sinn? Und wie sehen die konkreten Patterns aus? In der Session werden wir eine monolithische Anwendung Schritt für Schritt in die Cloud verlagern und dabei diskutieren, welche Vorteile und Herausforderungen die jeweiligen Schritte für die Anwendungsarchitektur mit sich bringen.
Im Rahmen der Session zeigt Lars Röwekamp an einem Live-Beispiel, wie sich verschiedene Aspekte/Komponenten einer Anwendung in die Cloud verlagern lassen und welche Konsequenzen dies für die Architektur, aber auch für Management und Monitoring mit sich bringt.
Eine richtig gute App zeichnet sich dadurch aus, dass sie deutlich mehr ist, als nur eine responsive Variante des eigenen Webauftritts. Ein „Mobiler Mehrwert“ muss her! Was aber genau ist dieser „mobile Mehrwert“? Und wie (er)finde ich ihn? Reicht ein einfaches Brainstorming? Gibt es Tools, die das Team im kreativen Prozess unterstützen? Und wie stelle ich am Ende sicher, dass auch die Nutzer diesen Mehrwert sehen? All diese Fragen wollen wir an realen Beispielen angehen und dabei auch auf typische Pitfalls eingehen – Aha-Effekte garantiert!
Leider existiert bei vielen Entwicklern der Irrglaube, dass mit dem Launch der eigenen App in einem der App Stores die Arbeit getan sei. Dabei geht der Spaß dann erst richtig los. Nur wer seine App als Produkt und nicht als Projekt versteht, hat auch nachhaltig die Chance auf Erfolg. Die Session zeigt, wie man durch Crash Reporting, App Analytics, geschicktes Einbinden der Usercommunity und ein gut durchdachtes Releasemanagement seine App auch nach dem ersten Launch attraktiv und erfolgreich halten kann.
Mittlerweile ist Apple mit iPad, iPhone, Apple Watch und Apple TV in vier verschiedenen Gerätekategorien vertreten. Dazu kommen teilweise noch mehrere verschiedene Bildschirmauflösungen pro Kategorie. Diese Session soll zeigen, wie man die eigene App auf diese Anforderungen vorbereiten kann und dabei trotzdem nicht alles doppelt schreiben muss. Dazu werden unter anderem die Möglichkeiten von Auto Layout näher beleuchtet – Apples Lösung, um eine einheitliche Oberfläche über alle Gerätekategorien und Auflösungen zu unterstützen.
Der Java-Enterprise-Standard Java EE scheint weder für Microservices-basierte Architekturen noch für die Cloud wirklich gut geeignet zu sein – so zumindest die landläufige Meinung. Zu komplex die Fülle der APIs, zu schwergewichtig die Runtime namens Application Server. Was aber bedeutet das für die vielen, vielen Teams, die seit Jahren entsprechende Erfahrungen aufgebaut haben? Gibt es für sie noch Hoffnung, ihr Expertenwissen auch in zukünftigen Projekten weiter nutzen zu können. Die Session zeigt, wie auch Java-EE-Teams problemlos in die Wunderwelt der Microservices und Cloud eintauchen können, ohne dabei auf ihre jahrelange Enterprise-Erfahrung verzichten zu müssen. Natürlich wartet die eine oder andere Herausforderung, aber ohne wäre es ja auch langweilig.
Believing the analysts Serverless Computing will be the “next big thing”. Thanks to NoOps, writing a serverless function and bringing it to production is quite easy. And also combining some of them to build up a more complex system seems to be not too complicated at all. But what are suitable scenarios for Serverless Computing? When to favor serverless over other architectural approaches and when not? Are there any specific patterns to be aware of when applying serverless? How does the serverless paradigm influence the software lifecycle, e.g. testing and monitoring? A lot of open questions to be answered!
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer Cloud-spezifischer Architekturmuster? Wie kann uns das Cloud Maturity Model dabei helfen? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen des Worskhops werde ich eine klassische Enterprise Anwendung Schritt für Schritt in die Cloud migrieren und dabei die verschiedenen Stufen / Reifegrade des Cloud Maturity Models durchlaufen. Angefangen bei "Lift & Shift" bis hin zu "Cloud Native" und "Cloud Voodoo – aka Serverless".
"Microservices" stellen einen der meist diskutierten IT-Trends der letzten Monate dar. Doch wie designt man den perfekten Service? Oder anders gefragt, wie definiert man seine Grenzen? Als wichtiges Hilfsmittel auf dem Weg zum Erfolg dienen die Bounded Contexts aus Eric Evans Domain-Driven-Design-Ansatz sowie deren zugehörige Kommunikationsmuster.
Im Rahmen der Session wird an einem praktischen Beispiel ein bestehender Monolith seziert und in fachlich sinnvolle Microservices aufgeteilt - Diskussion inklusive.
Für die einen das Allheilmittel gegen die vielfältigen Probleme monolithischer Anwendungen, für die anderen lediglich „alter Wein in neuen Schläuchen“. Wohl kaum ein Architekturansatz polarisiert derzeit so extrem wie Microservices. Doch was steckt wirklich hinter dem „neuen“ Paradigma, welche Vor- und Nachteile bringt es mit sich, und wie wird es in der Praxis bestmöglich umgesetzt? Die Session gibt einen Einblick in die Welt der Microservices im Zusammenspiel mit Java EE. Dabei steht nicht nur die reine Entwicklung im Fokus der Betrachtung, sondern auch Real-Life-Aspekte wie Deployment und Betrieb.
Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Die Zeiten einfacher Web-Anwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle, wie Web, Desktop, Mobile oder 3rd Party Clients, parallel bedienen zu müssen. Und das mit einer Architektur. Wie aber sieht eine passende Architektur aus? Welche neuen Herausforderungen ergeben sich durch die zusätzlichen Kanäle? Und welche Auswirkungen hat dies auf Aspekte wie Security, Schnittstellendesign oder das Datenmodell? In der Session „öffnen“ wir eine Web-Anwendung und stellen uns den Herausforderungen.
Oftmals wird "Multi-Channel" gleichgesetzt mit Responsive Design. Dies setzt allerdings voraus, dass jeder Channel mehr oder minder dieselben Use-Cases bedient. Ein echter Business-Mehrwert wird aber erst erreicht, wenn jeder Channel seine speziellen Eigenschaften ausspielt, was automatisch eine deutlich größere Flexibilität - auch auf Ebene der Architektur - verlangt. Genau hier setzt die Session an und zeigt, wie eine Architektur aufgebaut sein sollte, die deutlich mehr erlaubt als "nur" Responsive Design.
CQRS (Command Query Responsibility Segregation) als Architektur-Pattern sieht vor, dass lesende (Queries) und schreibende Zugriffe (Commands) in getrennten Subsystemen auf unterschiedlichen Modellen realisiert werden. Während Commands meist asynchron und transaktional angestoßen werden, arbeiten Queries mit denormalisierten Views auf “eventual consistent” Daten. Ziel ist eine hoch skalierbare, hoch performante und sichere Plattform. Was sich zunächst einmal nach zusätzlichem Aufwand anhört, bringt in der Praxis eine Menge Vorteile mit sich. Die Session zeigt die wesentlichen Ideen von CQRS auf und demonstriert anhand eines praktischen Beispiels die Vorteile dieses Ansatzes im Kontext von Web APIs.
Mit dem Begriff „Microservice-Architektur“ wird der Architekturstil beschrieben, bei dem mehrere unabhängige Services eine Applikation bilden.
Aber in welchen Situationen ist die Wahl dieses Ansatzes sinnvoll? Welche Konsequenzen hat es, wenn ich mich dafür entscheide? Wie finde ich den richtigen Service-Schnitt? Und wie baue ich ein passendes Frontend dazu?
Der Vortrag gab einen guten Überblick über die Herausforderungen und deren Lösungsmöglichkeiten und beleuchtete dabei auch Themen wie Testing und Continuous Delivery.
Das „Schwergewicht“ Java EE scheint nicht wirklich mit der Wunderwelt der Microservices und den damit einhergehenden Architekturpatterns zu harmonisieren. Dabei bringt der Java-Enterprise-Standard technologisch gesehen alles mit, was es zur Umsetzung von Microservices benötigt. Wo also liegt das Problem? In der Session werden wir Schritt für Schritt eine monolithische Java-EE-Anwendung „sezieren“ und uns den damit einhergehenden Herausforderungen der neu entstandenen, Microservice-basierten Architektur stellen. Aha-Effekte garantiert!
Die Zeiten einfacher Webanwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle wie Web, Desktop, Mobile oder 3rd-Party-Clients parallel bedienen zu müssen. Und das mit einer Architektur, die am besten auch noch zukünftigen, bisher noch nicht bekannten Anforderungen standhält. Wie aber sieht eine solche Architektur aus? Welche neuen Herausforderungen ergeben sich durch die Öffnung für zusätzliche Kanäle? Und welche Auswirkungen hat das alles auf Themenbereiche wie Security, Schnittstellendesign, Versionierung oder das Domänen- bzw. Datenmodell? Im Rahmen der Session „öffnen“ wir eine klassische monolithische Webanwendung und stellen uns den Herausforderungen.
Monolithische Mehrschichtarchitekturen scheinen ihre besten Tage hinter sich zu haben. Heute muss alles “micro”, „loosely coupled“ und „highly flexible“ sein. Ach ja, “resilient” nicht zu vergessen! Hört sich spannend an, aber was genau bedeutet das eigentlich für uns Entwickler/Architekten? Brauchen wir wirklich neue Architekturen? Und wenn ja, welche Herausforderungen ergeben sich dadurch? Mit welchen Patterns und Best Practices kann man diese Herausforderungen bewältigen? Und wie sieht überhaupt ein möglicher Migrationspfad aus, wenn man nicht das Glück hat, auf der grünen Wiese starten zu dürfen? Fragen über Fragen. Die zugehörigen Antworten auf dem Weg in eine leichtgewichtige(re) Zukunft gibt es in der Session.
Wer Microservices implementiert, wird schnell feststellen, dass ihn viele Herausforderungen erwarten, die er bis dahin nicht gekannt hat. Resilience, Service Discovery, verteilte Autenfizierung, Tracing und Health Checks sind Themen, die man als Entwickler nicht jedes Mal neu erfinden möchte. Aber zum Glück gibt es da etwas von der Eclipse-Foundation – das MicroProfile. Eine Spezifikation, die mit ihren verschiedenen Implementierungen den technischen Herausforderungen von Microservices eindrucksvoll begegnet. Egal ob Health Check, Metrics, Fault Tolerance, JWT Propagation, Configuration, Tracing oder Open API, das MicroProfile hat die passenden APIs im Gepäck. Mit viel Code und wenig Slides wirft dieser Workshop einen Blick auf die jeweiligen APIs, zeigt sie im Praxiseinsatz und stellt Vorteile und Probleme vor.
Jeder redet von Continuous Delivery, aber was macht eine gute Development-, Testing- und Delivery-Pipeline aus? Diese Session soll zeigen, welche Schritte nötig sind, um das Ziel Continuous Delivery zu erreichen. Neben Themen wie Update- und Roll-out-Strategie werden ebenso Crash Reports und Analytics-Möglichkeiten beleuchtet.
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
20161123_API Summit:
Denk man an Web APIs, dann verbindet man das zugehörige Kommunikationsmodell meist mit RESTful Requests & Responses. Dies macht in vielen Fällen sicherlich auch Sinn. Aber eben nicht in allen! Was ist z. B., wenn auf Seiten des Clients komplexe Abfragen anstehen, die sich nicht so einfach über simple “Ressourcen” abbilden lassen. Wie geht man damit um, wenn auf dem Server lang laufende Aktionen angestoßen werden, auf deren Abarbeitung der Client nicht unbedingt warten möchte? Und muss es eigentlich immer clientseitiges “Pull” sein oder macht nicht Serverseitiges “Push” via Websockets in vielen Anwendungsfällen mehr Sinn? Die Session zeigt anhand ausgewählter, praxisnaher Use-Cases, wie man durch verschiedene Pattern das klassische RESTful Request-/Response-Modell seiner Web API sinnvoll erweitern kann und so zu deutlich eleganteren und performanteren Lösungen kommt.
App war gestern: Mobile Engagement als Teil der Enterprise-StrategieOPEN KNOWLEDGE GmbH
„Hilfe, wir brauchen eine App!“ Erschreckend, aber wahr: Nicht selten starten Unternehmen genau so ihre mobilen Projekte. Dabei geht es doch weniger um einzelne Apps, als vielmehr darum, mit einem sinnvollen „Mobile Engagement“ die bestehende Enterprise-(IT-)Strategie gewinnbringend zu ergänzen. Mobile Mehrwerte schaffen ist der Schlüssel zum Erfolg. Doch wie findet man diese? Und hat man sie einmal gefunden, ist dann das Backend überhaupt in der Lage, den neuen Channel „Mobile“ sinnvoll zu bedienen? Keine Frage, eine Mobile-Enterprise-Strategie muss her! Die Session zeigt die typischen Stolpersteine vieler Unternehmern auf dem Weg in die Wunderwelt „Mobile“ und gibt praxisnahe Tipps an die Hand, wie man diese mit ein wenig Planung umgehen kann. Am Ende steht – statt einer Menge Frust – eine gelungenes Mobile Engagement mit Anbindung an das Unternehmens-Backend.
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer cloudspezifischer Architekturmuster? Im Rahmen des Workshops werden wir Schritt für Schritt eine bestehende Enterprise-Anwendung in die Cloud migrieren. Angefangen bei der Nutzung von Cloudinfrastruktur (IaaS) über die Anbindung von Cloudplattformkomponenten (PaaS) und Backend-Services (BaaS) bis hin zu Serverless Functions (FaaS) werden wir für die unterschiedlichen Anwendungsszenarien unserer Applikation passende Architekturansätze entwerfen und deren Vor- und Nachteile diskutieren. Natürlich sprechen wir dabei auch Themen wie Testing, Monitoring und automatisiertes Deployment an.
Von „less Server“ bis „Serverless“: Wie viel Cloud soll es sein?OPEN KNOWLEDGE GmbH
Die Cloud rückt in den letzten Jahren mehr und mehr in den Fokus. Die Möglichkeiten scheinen unbegrenzt: von virtuellen Servern bis hin zur vollständigen Verlagerung der Anwendungslogik in die Cloud (aka Serverless). Doch in welchem Kontext macht welches Szenario wirklich Sinn? Und wie sehen die konkreten Patterns aus? In der Session werden wir eine monolithische Anwendung Schritt für Schritt in die Cloud verlagern und dabei diskutieren, welche Vorteile und Herausforderungen die jeweiligen Schritte für die Anwendungsarchitektur mit sich bringen.
Im Rahmen der Session zeigt Lars Röwekamp an einem Live-Beispiel, wie sich verschiedene Aspekte/Komponenten einer Anwendung in die Cloud verlagern lassen und welche Konsequenzen dies für die Architektur, aber auch für Management und Monitoring mit sich bringt.
Eine richtig gute App zeichnet sich dadurch aus, dass sie deutlich mehr ist, als nur eine responsive Variante des eigenen Webauftritts. Ein „Mobiler Mehrwert“ muss her! Was aber genau ist dieser „mobile Mehrwert“? Und wie (er)finde ich ihn? Reicht ein einfaches Brainstorming? Gibt es Tools, die das Team im kreativen Prozess unterstützen? Und wie stelle ich am Ende sicher, dass auch die Nutzer diesen Mehrwert sehen? All diese Fragen wollen wir an realen Beispielen angehen und dabei auch auf typische Pitfalls eingehen – Aha-Effekte garantiert!
Leider existiert bei vielen Entwicklern der Irrglaube, dass mit dem Launch der eigenen App in einem der App Stores die Arbeit getan sei. Dabei geht der Spaß dann erst richtig los. Nur wer seine App als Produkt und nicht als Projekt versteht, hat auch nachhaltig die Chance auf Erfolg. Die Session zeigt, wie man durch Crash Reporting, App Analytics, geschicktes Einbinden der Usercommunity und ein gut durchdachtes Releasemanagement seine App auch nach dem ersten Launch attraktiv und erfolgreich halten kann.
Mittlerweile ist Apple mit iPad, iPhone, Apple Watch und Apple TV in vier verschiedenen Gerätekategorien vertreten. Dazu kommen teilweise noch mehrere verschiedene Bildschirmauflösungen pro Kategorie. Diese Session soll zeigen, wie man die eigene App auf diese Anforderungen vorbereiten kann und dabei trotzdem nicht alles doppelt schreiben muss. Dazu werden unter anderem die Möglichkeiten von Auto Layout näher beleuchtet – Apples Lösung, um eine einheitliche Oberfläche über alle Gerätekategorien und Auflösungen zu unterstützen.
Der Java-Enterprise-Standard Java EE scheint weder für Microservices-basierte Architekturen noch für die Cloud wirklich gut geeignet zu sein – so zumindest die landläufige Meinung. Zu komplex die Fülle der APIs, zu schwergewichtig die Runtime namens Application Server. Was aber bedeutet das für die vielen, vielen Teams, die seit Jahren entsprechende Erfahrungen aufgebaut haben? Gibt es für sie noch Hoffnung, ihr Expertenwissen auch in zukünftigen Projekten weiter nutzen zu können. Die Session zeigt, wie auch Java-EE-Teams problemlos in die Wunderwelt der Microservices und Cloud eintauchen können, ohne dabei auf ihre jahrelange Enterprise-Erfahrung verzichten zu müssen. Natürlich wartet die eine oder andere Herausforderung, aber ohne wäre es ja auch langweilig.
Believing the analysts Serverless Computing will be the “next big thing”. Thanks to NoOps, writing a serverless function and bringing it to production is quite easy. And also combining some of them to build up a more complex system seems to be not too complicated at all. But what are suitable scenarios for Serverless Computing? When to favor serverless over other architectural approaches and when not? Are there any specific patterns to be aware of when applying serverless? How does the serverless paradigm influence the software lifecycle, e.g. testing and monitoring? A lot of open questions to be answered!
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
„Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer Cloud-spezifischer Architekturmuster? Wie kann uns das Cloud Maturity Model dabei helfen? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen des Worskhops werde ich eine klassische Enterprise Anwendung Schritt für Schritt in die Cloud migrieren und dabei die verschiedenen Stufen / Reifegrade des Cloud Maturity Models durchlaufen. Angefangen bei "Lift & Shift" bis hin zu "Cloud Native" und "Cloud Voodoo – aka Serverless".
"Microservices" stellen einen der meist diskutierten IT-Trends der letzten Monate dar. Doch wie designt man den perfekten Service? Oder anders gefragt, wie definiert man seine Grenzen? Als wichtiges Hilfsmittel auf dem Weg zum Erfolg dienen die Bounded Contexts aus Eric Evans Domain-Driven-Design-Ansatz sowie deren zugehörige Kommunikationsmuster.
Im Rahmen der Session wird an einem praktischen Beispiel ein bestehender Monolith seziert und in fachlich sinnvolle Microservices aufgeteilt - Diskussion inklusive.
Für die einen das Allheilmittel gegen die vielfältigen Probleme monolithischer Anwendungen, für die anderen lediglich „alter Wein in neuen Schläuchen“. Wohl kaum ein Architekturansatz polarisiert derzeit so extrem wie Microservices. Doch was steckt wirklich hinter dem „neuen“ Paradigma, welche Vor- und Nachteile bringt es mit sich, und wie wird es in der Praxis bestmöglich umgesetzt? Die Session gibt einen Einblick in die Welt der Microservices im Zusammenspiel mit Java EE. Dabei steht nicht nur die reine Entwicklung im Fokus der Betrachtung, sondern auch Real-Life-Aspekte wie Deployment und Betrieb.
Eine moderne Web Anwendung ohne Unterstützung der Paradigmen „Mobile-First“ und „Offline-First“ scheint heute kaum noch denkbar. Was aber genau verbirgt sich hinter diesen Begriffen und wie lässt sich das ganze realisieren? Reicht es aus, einfach nur das richtige Framework zu verwenden? Oder geht es evtl. nicht doch um deutlich mehr als nur Buzzword-Bingo? Fragen über Fragen, die auf eine Antwort warten.
Offline-first Architekturen: Wer bitte braucht schon InternetOPEN KNOWLEDGE GmbH
Eine Web Anwendung ohne stabile Internetanbindung? Wie bitte soll das funktionieren? Im Gegensatz zum Allways-on Paradigma traditioneller Web Anwendungen, ist beim Offline-first Ansatz eine permanente Netzwerkverbindung nicht Pflicht sondern Kür. Eine optimale User Experience auch bzw. gerade im Falle einer schlechten oder nicht vorhandenen Netzverbindung steht im Fokus des Anwendungsdesigns. „Act locally, sync globally“ statt Request-Response-Modell, heißt die Zauberformel. In seiner Session zeigt Lars Röwekamp, was dies im Detail bedeutet und wie die dazu passenden Architektur- und Kommunikationspattern aussehen. Aha-Effekte garantiert!
Eine richtig gute App zeichnet sich dadurch aus, dass sie deutlich mehr ist, als nur eine responsive Variante des eigenen Webauftritts. Ein „Mobiler Mehrwert“ muss her! Was aber genau ist dieser „mobile Mehrwert“? Und wie (er)finde ich ihn? Reicht ein einfaches Brainstorming? Gibt es Tools, die das Team in dem kreativen Prozess unterstützten? Und wie stelle ich am Ende sicher, dass auch die Nutzer diesen Mehrwert sehen? All diese Fragen wollen wir an realen Beispielen angehen und dabei auch auf typische Pitfalls eingehen – Aha-Effekte garantiert!
Was bringen Micoservicearchitekturen im Enterpriseumfeld? Warum lohnt es sich, in die höhere Komplexität verteilter Systeme und von deren Deployment und Betrieb zu investieren, selbst wenn man nicht skalieren können muss wie Amazon oder Google? Wo sind die Grenzen, welche Patterns sollte man beachten um mit Microservices erfolgreich zu sein?
In diesem Vortrag zeige ich auf, warum es sich meiner Meinung nach auch im Enterpriseumfeld oft lohnen kann Microservice-architekturen in einer ihrer verschiedenen Ausprägungen einzusetzen, was meine Erfahrungen damit sind und was die Vorrausetzungen dafür sind.
Java EE meets Microservices: MicroProfile 2.x to the RescueOPEN KNOWLEDGE GmbH
Die 2016 gegründete und inzwischen in der Eclipse Foundation beheimatete Initiative MicroProfile ist angetreten, die Lücke zwischen dem Enterprise-Java-Standard (Java EE a.k.a. Jakarta EE) und den Praxisanforderungen Microservices-basierter Architekturen zu schließen. Das bestehende Momentum der Java-EE-Community als Hebel nutzen und organisch um den Bedarf der Microservices-Community ergänzen, so lautet der Plan. Und dieser scheint aufzugehen. In nur wenigen Monaten ist es gelungen, eine Reihe sinnvoller Microservices-relevanter APIs mit bestehenden Java EE 7/8 APIs zu kombinieren und diese in regelmäßigen MicroProfile-Releases zu veröffentlichen. Egal ob Health Check, Metrics, Fault Tolerance, JWT Propagation, Configuration, Tracing oder Open API, MicroProfile scheint die richtigen Antworten – sprich APIs – im Gepäck zu haben. Die Session zeigt den aktuellen Stand von MicroProfile und demonstriert dessen Mehrwert anhand praktischer Beispiele.
Mittendrin statt nur dabei: Microservices und TransaktionenOPEN KNOWLEDGE GmbH
Spendiert man jedem Microservice seine eigene Datenbank (Database per Service Pattern), läuft man irgendwann unweigerlich in das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler, technischer Transaktionen an, auch "Saga-Pattern" genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt dessen praktische Verwendung an verschiedenen Beispielen.
Anatomie von Microservice LandschaftenMichael Plöd
Building a Microservice is no hard task these days. With current frameworks it is fairly easy to create a self contained application that exposes Services via a RESTful interface. The Challenge for Microservices lies within the overall landscape: how to they interact with each other? How about service lookup? What about resilience? This session adresses the usual building blocks that are needed for Microservice landscapes and gives an overview of suitable open source frameworks in the market.
Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Nur wenn die Auftrennung der Fachlichkeit in verschiedenen Microservices auch konsequent bis hin zur Ebene der Datenhaltung vollzogen wird, kann die angestrebte Unabhängigkeit der Services zur Entwicklungs- und Laufzeit erreicht werden. Ohne diesen Schritt dagegen würde sich das Problem der starren Kopplung und der damit einhergehenden Abhängigkeiten einer monolithischen Architektur lediglich um eine Schicht nach unten, in die Datenbank, verlagern. Was aber bedeutet das konsequente Einhalten des Database-per-Service-Patterns und einer damit einhergehenden Verteilung der Datenhaltung in der Praxis? Die Session zeigt die wesentlichen Herausforderungen auf und liefert passende Lösungsansätze.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
The Architecture Gathering 2018, München: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise-Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
Continuous Lifecycle 2018, Mannheim: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
=== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ===
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Globale IT-Technologie und IT-Security aus Österreich: Ein Rezept, wie man dieses "Backwerk" erfolgreich anrührt. Univ.Prof. Dipl.-Ing. Dr. Thomas Grechenig (TU Wien), Karl Steiner (COMPRISE GmbH).
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
IT-Tage 2018, Frankfurt: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
=== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ===
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AIOPEN KNOWLEDGE GmbH
Häufig stellt die Entwicklung einer ML-Lösung die Optimierung von Performanz-Metriken wie der "Accuracy" unter Verwendung sehr komplexer Modelle in den Fokus. Fälschlicherweise wird sich damit abgefunden, dass aufgrund der höheren Komplexität die Explainability, also die Frage nach dem "Warum verhält sich mein Modell so und nicht anders?" leiden muss. Die Folgen können schwerwiegend sein und reichen vom unwissentlich gelernten Bias aus tabellarischen Daten bis zu einer hohen Anfälligkeit gegenüber Adversarial-Attacks in Bilddaten des autonomen Fahrens.
Warum meiner Meinung nach die Explainability auch bei komplexen Modellen nicht leiden muss, möchte ich in diesem Vortrag verdeutlichen.
Hierfür werde ich verschiedene XAI-Methoden, wie z.B. die Permutation-Importance und LIME, anhand eines konkreten Anwendungsfalles vorstellen, bewerten und vergleichen. Mein Ziel ist es, für XAI zu sensibilisieren und euch einen Methoden-Kasten an die Hand zu geben, der dazu befähigt, den Blick in die Black-Box zu wagen.
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...OPEN KNOWLEDGE GmbH
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot - KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern. Vorausgesetzt man verfügt über gute Ideen und hinreichend viele und qualifizierte Daten. Aber wie genau kommt man zu diesen Ideen? Und wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Softwareentwicklung ergeben können, und zeigt dafür passende, pragmatische Lösungsansätze auf.
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudOPEN KNOWLEDGE GmbH
Cloud is the new normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer, cloudspezifischer Architekturmuster? Was unterscheidet dabei die verschiedenen As-a-Service-Varianten (IaaS, PaaS, BaaS und FaaS) voneinander und für welchen Anwendungsfall nimmt man was? Fragen über Fragen – aber keine Panik, der Talk liefert Antworten.
SPAGAT ZWISCHEN BIAS UND FAIRNESS
KI soll fair sein. Da sind wir uns alle einig. Entsprechend gilt es, eine „Voreingenommenheit“ der eigenen KI-Lösung zu vermeiden.
Leichter gesagt als getan, denn Bias kann sich an verschiedenen Stellen innerhalb des AI/ML-Lifecycles einschleichen – vom initialen Design bis hin zum produktiven Einsatz des Modells. Diese Stellen gilt es zu identifizieren und im Detail zu verstehen. Denn nicht jede Art von Voreingenommenheit ist automatisch auch böse bzw. unfair.
Die Session zeigt, wie potenzielles Auftreten von unerwünschtem Bias in der eigenen KI-Lösung aufgedeckt und vermieden werden kann.
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data ImputationOPEN KNOWLEDGE GmbH
Leider sind die in der Praxis zur Verfügung stehenden Daten für das Training von Modellen bei weitem nicht so gut und vollständig, wie in den Lehrbüchern. Was also tun? Unvollständige Datensätze ignorieren und damit die zum Training notwendigen Daten deutlich reduzieren? Oder die Lücken besser mit sinnvollen Näherungswerten auffüllen.
Die Session zeigt, ob und wann es sinnvoll ist, fehlende Datensätze aufzufüllen und demonstriert an Real-Life Szenarien verschiedene Verfahren zur sinnvollen Ergänzung fehlender Daten. Neben einfachen Verfahren wie Mean/Median, Random Sample, Mulitple Imputation oder der Interpolationen zeitbezogenen Werte werden auch ML-basierte Imputation-Verfahren wie Regression oder Classification sowie deren potenzielle Einsatzgebiete beleuchtet. Dass fehlende Datensätze im Training auch einen positiven Effekt auf die Qualität des resultierenden Modells haben können, wird ebenfalls gezeigt.
In der Vergangenheit mussten Log-Files von Produktiv-Systemen mühsam von Hand zusammengesucht und danach durchforstet werden. Mit dem Aufkommen von Microservices gibt es jedoch immer mehr Tools, die die Aggregation und das Durchsuchen von Log-Informationen automatisieren. Den Anfang hat der ELK-Stack gemacht. Verteilte Systeme liefern jedoch heutzutage viel mehr relevante und besser aufbereitete Informationen als in den Log-Files zu finden sind. In einigen Situationen sind die in den Log-Files gefundenen Informationen unzureichend oder müssen mühsam extrahiert werden. Aus diesem Grund ist es naheliegend, die benötigten Informationen direkt in einem geeigneten Format bereitzustellen. Heutige Standards wie OpenTelemetry ermöglichen es, Informationen in dem benötigten Format zu sammeln. Werden Log-Files dadurch überflüssig? Die Session regt einen Mindset-Change an, stellt die Herausforderungen vor, die mit den verschiedenen Toolings bewältigt werden können, und erklärt, unter welchen Voraussetzungen auf Logging komplett verzichtet werden kann.
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierter Enterprise-Computing-Lösungen geht. Das gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application-Server deployt werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so mit Hilfe von Nebenprojekten wie Eclipse MicroProfile den Anforderungen moderner Cloud-Native-Anwendungen gerecht zu werden. Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.
From Zero to still Zero: The most beautiful mistakes going into the cloud. OPEN KNOWLEDGE GmbH
"Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Passende Blaupausen dazu gibt es mehr als genug. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloud-Anbieter glauben machen wollen? Natürlich nicht. Diese Session zeigt anhand typischer Antipattern, wie der Weg in die Cloud garantiert im Desaster endet und wie man sich dagegen wappnen kann. Ähnlichkeiten zu existierenden Projekten sind rein zufällig – oder auch nicht.
API Expand Contract ist ein Pattern zur Weiterentwicklung von APIs. Aber was verbirgt sich hinter der Idee? Wie kann ich damit eine API weiterentwickeln, ohne dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoOPEN KNOWLEDGE GmbH
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolithen in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mit Hilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud Native Anwendungen gerecht zu werden.
Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien aka Serverless, eine gute Figur macht.
Machine Learning ist eine Art von Software-Entwicklung, bei der man nicht direkt Code schreibt, sondern ein Modell anhand von Daten trainiert. Das kann in Situationen von Vorteil sein, in denen man keinen passenden Code schreiben kann oder dieser extrem komplex werden würde. TensorFlow ist das bekannteste Framework im Bereich Neuronaler Netzwerke mit dem man solche Modell erzeugen und nutzen kann. TensorFlow.js (https://js.tensorflow.org/api/latest/) implementiert die volle API von TensorFlow mit JavaScript und erlaubt sowohl die Ausführung, als auch das Training von Neuronalen Netzwerken auf jeder GPU.
Im ersten Teil des Workshops werden wir ein Modell zur Bilderkennung in einer grafischen Webanwendung trainieren und in einer eigenen Anwendung zum Laufen bringen. Hier geht es um die Grundlagen von Machine Learning und den Teil der TensorFlow.js API zum Ausführen eines Modells.
Im zweiten Teil werden wir ein eigenes Modell mit der TensorFlow.js API trainieren und als Teil einer JS-Anwendung integrieren.
Es sind keine Vorkenntnisse nötig und zur Teilnahme wird lediglich eine beliebige IDE zur Entwicklung von JavaScript benötigt.
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot: KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern - vorausgesetzt man verfügt über hinreichend viele und qualifizierte Daten.
Aber wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Rolle des KI-Architekten scheint geboren.
Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Software-Entwicklung ergeben können und zeigt dafür passende, pragmatische Lösungsansätze auf.
KI und insbesondere Deep Learning sind der Megatrend. Dank leistungsstarker Frameworks sind erste Schritte schnell gemacht. Leider stößt man aber genauso schnell auch wieder an (seine) Grenzen. Passt das genutzte Modell überhaupt zu meinem Problem? Wie sind die gewonnenen Ergebnisse zu bewerten? Kann durch geschickte Veränderung von Modell-Parametern das Ergebnis weiter verbessert werden? In der Session werden wir unser eigenes Neuronales Netz von Grund auf aufbauen und Schritt für Schritt verbessern. Aber keine Angst: „it’s not rocket science“!
Versteht man seine Anwendung als Kombination (fast) unabhängiger Services, so ergeben sich nicht nur für Entwicklung und Deployment neue Perspektiven.
Denn nicht nur die eigenen Services können internen oder externen Dritten zur Verfügung gestellt werden, sondern auch der umgekehrte Weg ist denkbar.
Eine entsprechend flexible Architektur vorausgesetzt, lässt sich die eigene Fachlichkeit durch 3rd Party Services sinnvoll und gewinnbringend ergänzen, ohne dabei das Rad neu erfinden zu müssen.
Besonders interessant scheint hier das Feld der künstlichen Intelligenz zu sein. Egal ob automatische Texerkennung, Retourenvorhersagen, Qualitätsicherung in der Produktion oder die Vorhersage von Terminen zur Maschinenwartung; die Möglichkeiten scheinen nahezu unbegrenzt.
Die Session zeigt, welche Möglichkeiten heute bereits Out-of-the-Box AI Services bieten und für welche Aufgaben man doch besser einen ML Experten mit ins Boot holen sollte.
Jeder Service für sich kann unabhängig deployed und skaliert werden.
Gerade Cloud Computing erleichtert in vielen Unternehmen die Verwaltung der IT-Infrastruktur. Weil die für die Software benötigte Plattformen so einfach anzumieten sind, werden Developer deshalb immer mehr in die Rolle des DevOps gedrängt -- die Software, die sie entwickeln, soll auch selbst betrieben werden -- You build it, you run it.
Doch diese Strukturierung ist nicht ganz kostenlos - Developer müssen dadurch immer mehr Verantwortung übernehmen. Um dieser Verantwortung gerecht zu werden, muss eine Schwachstelle ausgeschaltet werden: der Mensch. Im Talk gehe ich auf Prozesse der klassischen Softwareentwicklung ein und lege dar, wie diese in dem “You build it, you run it”-Modell verbessert werden.
In modernen Software-Landschaften werden die Fachlichkeiten mit Hilfe von DDD sauber voneinander abgegrenzt und als eigenständige Services umgesetzt.
Was muss in der Entwicklung eines solchen Services beachtet werden, um diese Eigenständigkeit zu gewährleisten und gleichzeitig sicherzustellen, dass alle Services gemeinsam als ein großes Ganzes funktionieren?
Service-Konsumenten sollen Schnittstellen nach Möglichkeit nutzen können, ohne Aufwand beim Anbieter der Schnittstelle zu verursachen. Das Ziel ist es, Features schnell und unabhängig umsetzen zu können.
In dem Vortrag wird vorgestellt, wie man eine hohe Nutzerzufriedenheit durch Consumer-Centric API Design und regelmäßige Produktiv-Deployments erzielt.
Möglich wird das durch ein sauberes API-Design, eine schlanke Microarchitektur und eine hohe Testautomatisierung. An praktischen Beispielen wird gezeigt, wie das erreicht werden kann.
Java scheint mit seinem Memory- und Runtime-Overhead in Zeiten von Cloud-native und Serverless nicht wirklich gut für die Zukunft gerüstet. Erschwerend kommt hinzu, dass viele auf Java basierende Frameworks mit Annotation Scanning, Aufbau von Proxies und Caches das Start- und Speicherverhalten weiter negativ beeinflussen. Bedeutet das das Aus für Java in der Wunderwelt der Cloud? Mitnichten! Projekte wie Quarkus versuchen, Java in der Cloud zur Numero Uno werden zu lassen. Und das auf beeindruckende Art und Weise. Die Session zeigt anhand praktischer Beispiele, was heute bereits möglich ist.
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?OPEN KNOWLEDGE GmbH
Single-Page-Applications -ursprünglich als kleines fancy Frontend gestartet- sind in den letzten Jahren zu großen, schwergewichtigen eigenen Applikationen angewachsen, die fehleranfällig, schwer wartbar und langsam in der Weiterentwicklung sind. Aber woran liegt das eigentlich? Im Frontend gibt es als Abstraktion zumeist nur das Konzept der Komponenten. Eine tiefergehende Analyse der benötigten Bausteine bleibt in der Regel aus. Im Backend hingegen, erfolgen solche Analysen seit Jahren.
Aber lassen sich die Backend-Architektur-Konzepte ohne weiteres für das Frontend übernehmen? Was sind die Herausforderungen, in denen sich moderne Frontends von klassischen Backends unterscheiden? Wo braucht man daher andere Lösungen? Neben der Problemanalyse gibt dieser Talk konkrete Bausteine an die Hand.
Das Product Goal oder "Ohne Ziele laufen eben alle in die Richtung, die ihnen...OPEN KNOWLEDGE GmbH
Der Scrum Guide von 2020 führt das Konzept eines Product Goals ein, um das Scrum Team auf ein größeres, wertvolles Ziel auszurichten. Jeder Sprint sollte das Produkt näher an das übergeordnete Product Goal heranbringen. Aber wie erstelle ich überhaupt ein Product Goal? Was sind Merkmale von einem guten Produkt Goal? Und was ist der Unterschied zu einer Produkt Vision? Brauche ich eigentlich beides oder reicht eins von beiden? Auf diese und weitere Fragen gehe ich in meinem Vortrag ein.
Eine Serverless Function zu schreiben ist denkbar einfach. Und auch die Kombinationen mehrerer FaaS zu einem komplexeren System ist kein Hexenwerk. Was aber, wenn die niedlichen kleinen Funktionen sich zur Laufzeit nicht so verhalten, wie gewünscht? Wie sieht das Monitoring der einzelnen Funktionen und des Systems als Ganzes aus? Und was ist mit Testen? Muss die Funktion dazu immer in der Cloud deployt werden oder kann man das produktive System auch lokal emulieren? Wie wichtig ist der Aspekt der Automatisierung und wie wird diese erreicht? Wie beeinflussen Cold- und Warm-Start das Laufzeitverhalten? Diesen und vielen anderen Herausforderungen wollen wir uns in der Session stellen – Aha-Effekte garantiert!
3. #WISSENTEILEN
ÜBER MICH
Wer bin ich - und wenn ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast
Lars Röwekamp (a.k.a. @mobileLarson)
LR
48. #WISSENTEILEN
Die „Stop Digging“ Strategie
Neue Funktionalität nicht im Monolithen
implementieren sondern in einem eigenen
Microservice
• vorgeschalteter Router als Logik-Dispatcher
• Glue-Code zur Data-Integration
49. #WISSENTEILEN
Die „Stop Digging“ Strategie
Glue-Code als Anti-Corruption Layer, zur
sauberen Trennung der Domain Modelle von
Microservice und Monolith. Datenintegration?
• Aufruf einer Remote API des Monolithen
• direkter Zugriff auf DB des Monolithen
• Halten einer eigenen Daten-Kopie inkl. Sync.
52. #WISSENTEILEN
Die „Stop Digging“ Strategie
pro:
• Monolith wird nicht noch unwartbarer
• Service ist „unabhängig“ vom Monolithen
• Microservices-Erfahrung kann langsam wachsen
contra:
• Probleme des Monolithen bleiben bestehen!
54. #WISSENTEILEN
Die „Split Front/Back“ Strategie
Trennen des Frontends von Business-Logik und
Persistenz.
• aus eins mach zwei
• „natürliche“ Trennung zwischen Presentation-
Logik und Business-Logik nutzen
• Zugriff auf Backend via coarse-grained API
57. #WISSENTEILEN
Die „Split Front/Back“ Strategie
pro:
• Möglichkeit, beide „Welten“ getrennt zu
entwickeln, deployen und skalieren
• Remote API, z.B. REST, für zukünftige
Microservices als positives Abfallprodukt
contra:
• keine finale Lösung sondern eher ein Übergang
59. #WISSENTEILEN
Die „Extract Services“ Strategie
Bestehende Module des Monolithen extrahieren
und in „standalone“ Microservices überführen
• Monolith schrumpft mit jedem Service
• am Ende bleibt kein/ein extrem kleiner Monolith
• Feature Toggles als „Weiche“ nutzen
60. #WISSENTEILEN
Die „Extract Services“ Strategie
Vorgehen beim Herauslösen von Modulen in
eigene Microservices:
• Coarse-grained Interface definieren
• Module standalone lauffähig machen
• ggf. Features in Monolithen “deaktivieren“*
*Achtung: kann teure Rückbaumaßnahmen bedeuten
64. #WISSENTEILEN
Die „Extract Services“ Strategie
pro:
• Step-by-Step Migration
• Monolith verschwindet im Laufe der Zeit
contra:
• Auslagern von Services bedeutet Aufwand
in beiden Welten
66. #WISSENTEILEN
FAQs
• Wie komme ich zu den richtigen Services?
• Was ist die richtige Anzahl an Services?
• Was ist die richtige Migrationsreihenfolge?
• Wie migriere ich die DB richtig?
• Welcher Herausforderungen erwarten mich?
• Und der Monolith? Den gibt es doch auch noch!
76. #WISSENTEILEN
Guter Service, schlechter Service
Polyglot
• “best X for the job“ mit dem Ziel der Skalierung
• Technology
• Data Management
• Business Logic
• Skalierung
77. #WISSENTEILEN
Guter Service, schlechter Service
• hohe Cohesion innerhalb des Service
• lose Koppelung zwischen Services
• Änderungshäufigkeit ähnlich
• businesskritische Prozesse nah beisammen
• Eventual Consistency akzeptabel
• Designe for Failure
83. #WISSENTEILEN
Wie groß ist klein
„A microservices ecosystem (ME) is a platform of
services each encapsulating a business capability.
Developers can build, test and release each
microservice independently.
ME enforces an organizational structure of
autonomous long standing teams, each
responsible for one or multiple services.“
(Zhamak Dehghani, ThoughtWorks)
84. #WISSENTEILEN
Wie groß ist klein
Size of microservice
„guter“
Microservice
Modularisierung
Teamgröße
Austauschbarkeit
Infrastruktur
Verteilte
Kommunikation
Transaktionen &
Konsistenz
91. #WISSENTEILEN
Einflussfaktoren für die Migration
• Lernkurve?
• Risikominimierung?
• Sichtbarkeit / Business Mehrwert?
• Aufwand?
• Bindung von Kapazitäten?
• Abhängigkeiten?
92. #WISSENTEILEN
Phase 1: Warm up
Starten mit einem möglichst einfachen Service*, der
wenig Kopplung zur restlichen Anwendung hat.
• Fokus auf Operational Readiness (CI/CD)
• Fokus auf Microservices Infrastruktur*
• Fokus auf verteilter Architektur*
• Fokus auf Organizational Change *(e.g. Service Mesh)
94. #WISSENTEILEN
Phase 1: Warm up
„alter“ Monolith
mit Funktionalität
Authentication
„neuer“ Monolith
neuer
Authentication
Service
Migration
neue Delivery Infrastructure
95. #WISSENTEILEN
Phase 2: Minimize Dependencies
Wähle Services ohne/mit wenig Rückkoppelungen
zum Monolithen.
• Rückkoppelungen forcieren Abhängigkeiten in
der Entwicklung und der Release-Planung
• minimiere bestehende Abhängigkeiten durch
Anti-Corruption Layer
96. #WISSENTEILEN
Phase 2: Minimize Dependencies
„alter“ Monolith
mit Abhängigkeiten
„neuer“ Monolith
ohne Abhängigkeiten
ausgelagerter Service
mit unidirektionalen
Abhängigkeiten
MigrationMigration
97. #WISSENTEILEN
Phase 2: Minimize Dependencies
„alter“ Monolith
mit Abhängigkeiten
„neuer“ Monolith
ohne Abhängigkeiten
ausgelagerter Service
mit bidirektionalen
Abhängigkeiten und ACL
Migration
ACL
Migration
98. #WISSENTEILEN
Phase 3: Sticky first
Wähle stark verwobene Fachlichkeit und löse diese
sauber auf („DDD ist dein Freund“)
• oft hindern einen unsaubere, historisch
gewachsene Domänenmodelle daran,
weitere sinnvolle Services herauszulösen
99. #WISSENTEILEN
Phase 3: Sticky first
„alter“ Monolith
mit sticky Session
„neuer“ Monolith
ohne sticky Session
ausgelagerte
Services
Migration
Customer
Session
Customer
Profile
Customer
Payment
Method
Customer
Wishlist
100. #WISSENTEILEN
Phase 4: Decouple vertically
Löse Services komplett inklusive „user facing“
Komponenten und DB heraus.
• Bereitstellung von entwicklerfreundlichen APIs
für moderne UIs via Facade Service bringt
lediglich Quick-Wins.
• erst ein Aufsplitten inkl. Trennung der Daten
bringt echten Mehrwert
101. #WISSENTEILEN
Phase 4: Decouple vertically
„alter“ Monolith Services
Migration
„neuer“ Monolith
user
facing
backend
logic
data /
comms
neue
UI / UX
neue API
102. #WISSENTEILEN
Phase 5: Decouple important stuff
Löse Services mit höchstem Mehrwert heraus.
• Es gilt Kosten gegen Nutzen abzuwägen.
• Was ist wichtig?
• Was ändert sich häufig?
• Was muss unabhängig skalieren können?
103. #WISSENTEILEN
Phase 5: Decouple important stuff
„alter“ Monolith
mit wichtigster
Komponente
„neuer“ Monolith
ohne wichtigste
Komponente
ausgelagerte
wichtigste
Komponente
Migration
104. #WISSENTEILEN
Phase 6: Decouple capabilities*
Wäge sinnvoll zwischen Reuse und Rewrite ab.
• nicht blind altem Code übernehmen
• alter Code beinhaltet oft Boilerplate und
berücksichtigt keine Domänengrenzen
• retire and rewrite als Alternative
• IKEA Effekt lässt uns wachsen *(… and not code!)
105. #WISSENTEILEN
Phase 6: Decouple capabilities
„alter“ Monolith „neuer“ Monolith
Customer
Profile
Service
Migration
Pricing
Service
reuse
rewrite
extract?
retire?
neue Services
via reuse oder rewrite
106. #WISSENTEILEN
Phase 6: Go Marco first, then Micro
Starte mit Bounded Contexts (DDD) als
Servicegrenzen und verfeinere später bei Bedarf.
• kleine Service bringen oft neue Abhängigkeiten
• kleine Services spiegeln meist DB Sicht wieder*
Distributed Monolith vs. Microservices
*(Anemic Services)
107. #WISSENTEILEN
Phase 6: Go Marco first, than Micro
Migration
Step 1
Migration
Step 2
„alter“
Monolith
„neuer“
Monolith
Buy
Service
Checkout
Service
Shopping Cart
Service
Hyperlink
108. #WISSENTEILEN
Phase 7: Atomic Evolutionary Steps
Plane die Migration in „atomaren“ Schritten.
Schaffe dabei stabile Zwischenstände.
• Migration kann aus verschiedensten Gründen
gestoppt werden. Rückbau? Chaos?
• Short Term Plans vs. Long Term Plans
117. #WISSENTEILEN
„Welche Services laufen?“
„Sind die Routing-Infos aktuell?“
„Gibt es ‚Chains of Failure‘?“
„Message-Typen im System?“
„Sind die Services sicher?“
„Sind die Daten konsistent?“
119. #WISSENTEILEN
Wo ist mein Service ...
• Anzahl der Service-Instanzen variiert
• Adressen werden dynamisch zugewiesen
• Client muss den „richtigen“ Service finden
• Services registrieren sich bei Registry
• Client fragt bei Registry nach
123. #WISSENTEILEN
Wo ist mein Service ...
Client-Side Service Discovery
• Netflix Eureka / Consul + Ribbon Client
• Apache Zookeeper + Zookeeper Client
Server-Side Service Discovery
• AWS Elastic Load Balancer
• Consul / NGNIX Plus + Consul Templating
124. #WISSENTEILEN
Wo ist mein Service ...
Client-Side Service Discovery
• Netflix Eureka / Consul + Ribbon Client
• Apache Zookeeper + Zookeeper Client
Server-Side Service Discovery
• AWS Elastic Load Balancer
• Consul / NGNIX Plus + Consul Templating
Und was ist mit
Kubernetes?
133. #WISSENTEILEN
Not available, please call later ...
Ziel ist es, ein „elastisches“, sich selbst
regenerierendes System zu schaffen, um so
eine bestmögliche Verfügbarkeit zu
gewährleisten.
137. #WISSENTEILEN
Pattern: Design for Failure
• Fehler als Normalfall nicht als Ausnahme
• Automatische Fehlerbehandlung
• Netflix stellt regelmäßig Systeme ab
138. #WISSENTEILEN
Pattern: Fail sooner than later
• Probleme frühzeitig erkennen
• Fehler gar nicht erst entstehen lassen
• Monitoring von Metrics & Response Times
• Monitoring von Buisness KPIs
147. #WISSENTEILEN
Not available, please call later ...
• DIY Pattern? No way!
• Hystrix, the one and only! Not anymore.
• MicroProfile Fault Tolerance
• Istio Service Mesh
• Traefik Gateway
• …
164. #WISSENTEILEN
Sicher ist sicher! Sicher?
JWT (JSON Web Token)
• neue, einfache und kompakte Specs
• Token plus public & private „Claims“
• digitale Signatur und/oder Encryption
• als Bearer Token und für SSO
174. #WISSENTEILEN
Alles im Blick
• tech. Komponenten (e.g. Request/s in DB)
• Business Metrics (Orders/min)
• semantisches Monitoring als Frühwarnsystem
• Team kann vor dem Fehler einschreiten
• Team kann System permanent verbessern
196. #WISSENTEILEN
Lessons Learned
Priorisierung, welches Modul zu welchem Zeitpunkt
als Microservice rausgelöst werden soll:
• z.B. „einfache“ Module zuerst (Erfahrung
sammeln), „Problemkinder“ danach (Mehrwerte
schaffen)
• Ranking: Change-Frequenz, Ressourcen-
Verbrauch, Skalierung, Kommunikation, ...
197. #WISSENTEILEN
Lessons Learned
Ist das schon alles?
• Zeitpunkt für DB-Migration will gut überlegt sein
• Microservice-Infrastruktur Step-by-Step mit
wachsender Anzahl an Services aufbauen
(Registry, Gateway, Resilience ...)
198. #WISSENTEILEN
Lessons Learned
• Ohne Domain Driven Design geht es nicht
• Ports & Adapter für einfachere Extraktion
• explizite Service/Endpoint Ownership
• Source-Versionierung statt toter Code
• Monitoring ist die Basis für ALLES
• Env-Var Dokumentation ist PFLICHT
199. #WISSENTEILEN
Lessons Learned
• Domäne vor Technologie
• vermeide „Shared Data“
• nutze Events zur Synchronisation von Daten
• nutze Events zur Kompensation (Business-TX)
• gebe Async den Vorzug über Sync
• Testing via Consumer-driven Contracts