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.
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.
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.
Microservices richtig umgesetzt bedeutet auch die ehemals monolithische Datenbank aufzusplittern. Transaktionen über Servicegrenzen hinweg, stellen somit eine neue Herausforderung dar.
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!
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!
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.
„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.
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.
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.
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.
Microservices richtig umgesetzt bedeutet auch die ehemals monolithische Datenbank aufzusplittern. Transaktionen über Servicegrenzen hinweg, stellen somit eine neue Herausforderung dar.
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!
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!
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.
„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.
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".
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!
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.
Auf gehts 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? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen der Session werden ich 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.
Alles an Metaprogrammierung, was eine klassische Enterprise Java Applikation zur Startup Zeit macht, können wir bereits vorher erledigt haben. Doch wie geht das? Und was können wir von Quarkus in dieser Richtung lernen?
---
Das #Softwarepicknick ist deine digitale Mittagspause mit den Experten der open knowledge GmbH.
Bei diesem meet und eat bringen wir dir hilfreiche Codesnacks und aktuelle Thesen der modernen Softwareentwicklung direkt auf den Tisch
und schaffen eine Wiese für deine konkreten Fragen aus dem Projektalltag.
Die 30-minütigen Sessions bieten dir informative Impulse und die Möglichkeit des direkten Austausches.
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.
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.
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.
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?OPEN KNOWLEDGE GmbH
Herzlich willkommen im Elfenbeinturm! Hier können Sie noch sehen, wie Software- und Systemarchitekturen am Reißbrett entworfen werden. Am Reißbrett? Wirklich? Hatten wir diese Zeit nicht hinter uns gelassen, schon vor vielen Jahren? Sind wir nicht in einer Zeit angekommen, in der agile und eher fachlich orientierte Teams Technologie einfach nutzt? Gänzlich ohne eigene Frameworks und Abstraktionen? Scheinbar nicht – wie viele Unternehmen und damit verbundene Organisationsstrukturen immer noch beweisen. Es wird Zeit, diese historischen Monster endlich in den Ruhestand zu schicken und der Rolle des Enterprise-Architekten ein neues Aufgabenspektrum anzuvertrauen, sodass technologisches Momentum zugelassen und dennoch Wildwuchs vermieden wird. Der moderne Enterprise-Java-Architekt in Zeiten sich auflösender zentralistischer Strukturen – modelliert in einer einzigen Session.
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.
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.
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!
Um agile Entwicklung sinnvoll in einem Projekt zu ermöglichen, spielt die Architektur des Systems eine entscheidende Rolle. In einem agilen Projekt sind Architektureigenschaften wie Installierbarkeit und Prüfbarkeit entscheidend, da die Software in kurzen Abständen regelmäßig geliefert und im besten Fall dem Endnutzer zur Verfügung gestellt wird. Diese kurzen Releasezyklen gelingen nur durch ein hohes Maß an Automatisierung. Agile Projekte benötigen bereits passende Lösungsansätze in der Architektur, die es erlauben eine Continous Delivery Pipeline möglichst einfach zu realisieren; das Architekturmuster „Microservices“ versucht u.A. diesen Anforderungen gerecht zu werden.
Weitere Vorteile des Architekturmusters ergeben sich bei der Skalierung von Projekten. Durch den Einsatz von „Microservices“ können Projekte einfach aufgeteilt und parallel von mehreren Cross-Functional Teams mit agilen Methoden umgesetzt werden.
Die Idee eines Microservice ist nicht neu: das System wird in kleine, losgelöste Anwendungen (sog. Microservices) aufgeteilt. Diese Bausteine stellen Ihre Funktionalität als Service zur Verfügung. Der Vortrag gibt einen Praxiseinblick, auf welche Weise man vom Einsatz des Architekturmusters „Microservice“ in einem agilen Projektumfeld profitieren kann. Es wird aufgezeigt, wo sich in der Praxis Schwierigkeiten ergeben und wie man diesen vorbeugen kann. Der gesamte Vortrag gibt einen grundlegenden Einblick in die agile Entwicklung auf Basis einer Microservice-Architektur.
"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.
Kaps - Es muss nicht immer Kubernetes seinStephan Kaps
In vielen größeren Institutionen gibt es noch jede Menge Software, die eher monolithisch aufgebaut ist, die häufig in Applikation-Servern auf dedizierten virtuellen Maschinen von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. In Fachzeitschriften, Online-Artikeln und Konferenzen wird vorgeführt, wie einfach es doch ist, einen Hello-World Spring Boot Microservice mit mehreren Instanzen auf Kubernetes zu deployen. Doch zurück im Unternehmen wird klar: sollte man es tatsächlich schaffen, alle notwendigen Personen davon zu überzeugen, ab sofort Kubernetes einzuführen, wird das für einen meist auch personell am Limit arbeitenden IT-Betrieb schnell zu einem Projekt mit vermutlich 1-2 Jahren Laufzeit (je nach Erfahrung), mit möglichen Seiteneffekten wie reduzierter Handlungsfähigkeit für das laufende Geschäft und dem Zurückstellen anderer Modernisierungsmaßnahmen. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud Native betrachten und dabei (OpenSource) Werkzeuge kennen lernen für die schrittweise Anpassung der on-premise Infrastruktur, ohne Kubernetes.
In diesem Vortrag erfahren Sie, warum sich der erste Ansatz einer zentralen CI/CD-Installation für alle Teams als problematisch erwies und durch dezentrale Pipelines ersetzt wurde. Danach lernen Sie die Tücken unserer Einführung einer eingekauften API-Management-Lösung kennen, und wieso sich der Kauf von großer On-Premise-Software nur schwer mit den agilen Prinzipien vereinbaren lässt. Der Zuhörer lernt zudem, wie wir im Team mit polyglotter Softwareentwicklung zu kämpfen haben und wie wir permanent gegen Wissensinseln ankämpfen. Zuletzt gehe ich darauf ein, wie wir mit umfassender Architekturdokumentation gestartet und gescheitert sind. Unser neuer Ansatz ist eine leichtgewichtige dezentrale Dokumentation mit AsciiDoc und ein im Team abgestimmter Toolstack, der auch vom Zuhörer adaptiert werden kann. Am Ende der Reise wird der Zuhörer einige Methoden und Tools kennen gelernt haben, um in einem Kontext zu überleben, der an vielen Stellen noch von klassischen Prozessen dominiert wird. Aber eines ist klar: Der Weg Richtung DevOps geht nicht plötzlich, es ist eine Reise mit Umwegen und Hindernissen. Die Reise ist es aber auf jeden Fall Wert!
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.
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!
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".
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!
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.
Auf gehts 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? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS?
Im Rahmen der Session werden ich 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.
Alles an Metaprogrammierung, was eine klassische Enterprise Java Applikation zur Startup Zeit macht, können wir bereits vorher erledigt haben. Doch wie geht das? Und was können wir von Quarkus in dieser Richtung lernen?
---
Das #Softwarepicknick ist deine digitale Mittagspause mit den Experten der open knowledge GmbH.
Bei diesem meet und eat bringen wir dir hilfreiche Codesnacks und aktuelle Thesen der modernen Softwareentwicklung direkt auf den Tisch
und schaffen eine Wiese für deine konkreten Fragen aus dem Projektalltag.
Die 30-minütigen Sessions bieten dir informative Impulse und die Möglichkeit des direkten Austausches.
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.
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.
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.
Der Enterprise-Java-Architekt – eine aussterbende Gattung!?OPEN KNOWLEDGE GmbH
Herzlich willkommen im Elfenbeinturm! Hier können Sie noch sehen, wie Software- und Systemarchitekturen am Reißbrett entworfen werden. Am Reißbrett? Wirklich? Hatten wir diese Zeit nicht hinter uns gelassen, schon vor vielen Jahren? Sind wir nicht in einer Zeit angekommen, in der agile und eher fachlich orientierte Teams Technologie einfach nutzt? Gänzlich ohne eigene Frameworks und Abstraktionen? Scheinbar nicht – wie viele Unternehmen und damit verbundene Organisationsstrukturen immer noch beweisen. Es wird Zeit, diese historischen Monster endlich in den Ruhestand zu schicken und der Rolle des Enterprise-Architekten ein neues Aufgabenspektrum anzuvertrauen, sodass technologisches Momentum zugelassen und dennoch Wildwuchs vermieden wird. Der moderne Enterprise-Java-Architekt in Zeiten sich auflösender zentralistischer Strukturen – modelliert in einer einzigen Session.
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.
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.
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!
Um agile Entwicklung sinnvoll in einem Projekt zu ermöglichen, spielt die Architektur des Systems eine entscheidende Rolle. In einem agilen Projekt sind Architektureigenschaften wie Installierbarkeit und Prüfbarkeit entscheidend, da die Software in kurzen Abständen regelmäßig geliefert und im besten Fall dem Endnutzer zur Verfügung gestellt wird. Diese kurzen Releasezyklen gelingen nur durch ein hohes Maß an Automatisierung. Agile Projekte benötigen bereits passende Lösungsansätze in der Architektur, die es erlauben eine Continous Delivery Pipeline möglichst einfach zu realisieren; das Architekturmuster „Microservices“ versucht u.A. diesen Anforderungen gerecht zu werden.
Weitere Vorteile des Architekturmusters ergeben sich bei der Skalierung von Projekten. Durch den Einsatz von „Microservices“ können Projekte einfach aufgeteilt und parallel von mehreren Cross-Functional Teams mit agilen Methoden umgesetzt werden.
Die Idee eines Microservice ist nicht neu: das System wird in kleine, losgelöste Anwendungen (sog. Microservices) aufgeteilt. Diese Bausteine stellen Ihre Funktionalität als Service zur Verfügung. Der Vortrag gibt einen Praxiseinblick, auf welche Weise man vom Einsatz des Architekturmusters „Microservice“ in einem agilen Projektumfeld profitieren kann. Es wird aufgezeigt, wo sich in der Praxis Schwierigkeiten ergeben und wie man diesen vorbeugen kann. Der gesamte Vortrag gibt einen grundlegenden Einblick in die agile Entwicklung auf Basis einer Microservice-Architektur.
"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.
Kaps - Es muss nicht immer Kubernetes seinStephan Kaps
In vielen größeren Institutionen gibt es noch jede Menge Software, die eher monolithisch aufgebaut ist, die häufig in Applikation-Servern auf dedizierten virtuellen Maschinen von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. In Fachzeitschriften, Online-Artikeln und Konferenzen wird vorgeführt, wie einfach es doch ist, einen Hello-World Spring Boot Microservice mit mehreren Instanzen auf Kubernetes zu deployen. Doch zurück im Unternehmen wird klar: sollte man es tatsächlich schaffen, alle notwendigen Personen davon zu überzeugen, ab sofort Kubernetes einzuführen, wird das für einen meist auch personell am Limit arbeitenden IT-Betrieb schnell zu einem Projekt mit vermutlich 1-2 Jahren Laufzeit (je nach Erfahrung), mit möglichen Seiteneffekten wie reduzierter Handlungsfähigkeit für das laufende Geschäft und dem Zurückstellen anderer Modernisierungsmaßnahmen. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud Native betrachten und dabei (OpenSource) Werkzeuge kennen lernen für die schrittweise Anpassung der on-premise Infrastruktur, ohne Kubernetes.
In diesem Vortrag erfahren Sie, warum sich der erste Ansatz einer zentralen CI/CD-Installation für alle Teams als problematisch erwies und durch dezentrale Pipelines ersetzt wurde. Danach lernen Sie die Tücken unserer Einführung einer eingekauften API-Management-Lösung kennen, und wieso sich der Kauf von großer On-Premise-Software nur schwer mit den agilen Prinzipien vereinbaren lässt. Der Zuhörer lernt zudem, wie wir im Team mit polyglotter Softwareentwicklung zu kämpfen haben und wie wir permanent gegen Wissensinseln ankämpfen. Zuletzt gehe ich darauf ein, wie wir mit umfassender Architekturdokumentation gestartet und gescheitert sind. Unser neuer Ansatz ist eine leichtgewichtige dezentrale Dokumentation mit AsciiDoc und ein im Team abgestimmter Toolstack, der auch vom Zuhörer adaptiert werden kann. Am Ende der Reise wird der Zuhörer einige Methoden und Tools kennen gelernt haben, um in einem Kontext zu überleben, der an vielen Stellen noch von klassischen Prozessen dominiert wird. Aber eines ist klar: Der Weg Richtung DevOps geht nicht plötzlich, es ist eine Reise mit Umwegen und Hindernissen. Die Reise ist es aber auf jeden Fall Wert!
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.
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 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.
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.
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.
Wenn Sie Solr vs. Elasticsearch in Google eingeben, bekommen Sie eine ganze Reihe von Blogs, Artikeln, Vergleichen, Meinungen und Gedanken, die sich diesem Thema widmen. Warum sollten Sie sich dieses Webinar also anhören und ansehen? Weil keiner der Links, die Sie über Google finden, tatsächlich die aktuellen Versionen der beiden Technologien aus dem Bereich Open Source Suchmaschinen abdeckt, sondern auf teilweise sehr betagte Artikel führen. Gerade im Open Source Bereich ist Aktualität jedoch entscheidend, denn hier werden Entwicklungen in teilweise rasantem Tempo vorangetrieben.
Aber nicht nur die Tatsache, dass es sich hierbei um ein tagesaktuelles Webinar handelt, sondern auch die Tatsache, dass es zwei führende Open Source Suchserver gibt, macht die Notwendigkeit, diese beiden Projekte zu vergleichen, offensichtlich. Ist Elasticsearch ein momentaner Trend, dem man folgen sollte? In welchen Gebieten ist Apache Solr die wegweisende Technologie? Gibt es Branchen, in denen sich der Einsatz einer Technologie verbietet oder besonders anbietet? Ist Elasticsearch im Gegensatz zu Solr wirklich schemafrei und warum bringt mir das einen Vorteil? Diesen und noch mehr Fragen werden wir auf den Grund gehen, um Sie letztendlich bei der Beantwortung der Frage zu unterstützen, auf welches Pferd Sie in Ihrem Unternehmen setzen sollten.
Als neutraler Technologieberater, der Partnerschaften zu LucidWorks und Elasticsearch pflegt, sind wir in der Lage, diesen Vergleich technisch, strategisch und konzeptionell zu ziehen. Verpassen Sie diese einmalige Gelegenheit also nicht!
Where are all transactions gone? Was in_der_cloud_alles_verboten_istRamon Anger
Mein Vortrag auf der OOP 2015
Where all the transactions gone?
Was in der Cloud alles verboten ist.
Gegenstand des Vortrags sind neun Dinge, die in der Cloud im Gegensatz zu inhouse-Anwendungen grundlegend anders sind. Darüber hinaus geht der Vortrag kurz auf DevOps für die Cloud und Organisation für die Cloud ein.
Ursprünglich hat mein Kollege Marc Bauer den Vorschlag eingereicht, hatte dann aber leider keine Möglichkeit, den Vortrag selbst zu halten.
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.
Enterprise Cloud Native ist das neue NormalQAware GmbH
CODEx Speakers Night 2019, November 2019, Hannover: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
Abstract: Der Einsatz Cloud nativer Technologien gehört in vielen deutschen Unternehmen mittlerweile zur Normalität. Großartig! Doch bei aller Liebe zur Technologie beobachte ich momentan bei vielen Teams und Kunden einen gewissen Grad an Ernüchterung und Zweifeln was den Einsatz moderner Tools, Techniken und Open Source Bausteinen angeht.
Mit steigender Verbreitung gibt es naturgemäß auch negative Erfahrungen und auch Fehlschläge. Das ist ganz normal! Klar, es gibt viel Raum für Verbesserungen. Um so wichtiger ist es, die aktuellen Trends und Neuerungen im Cloud-native Universum kontinuerlich im Auge zu behalten und diese mutig in das eigene Unternehmen und seine Projekte zu tragen.
Die kontinuierliche Verbesserung der Cloud-native Developer Experience ist einer dieser Bereiche. Schlanke Entwickler-Tools und Ansätze wie Skaffold, Werf, Squash oder TelePresence vereinfachen die Entwicklung und beschleunigen den Inner Development Loop enorm. Zahlreiche neue Serverless und FaaS Frameworks zielen darauf die Verbauungstiefe von Cloud-nativen Anwendungen deutlich zu reduzieren. Die Entwicklung und speziell der Betrieb werden zunehmend einfacher. "Don't do it yourself" heißt die Devise.
Auch das steigende Angebot an essentiellen Infrastruktur-Bausteinen wie Service Meshes, API Gateways und Messaging Systemen gilt es zu beobachten, um moderne Systeme der Zukunft zu bauen. Continuous Security und Continuous Compliance gewinnen im Enterprise Umfeld und speziell bei regulierten Unternehmen immer mehr an Bedeutung, auch hier lassen die passenden Tools und Technologien nicht lange auf sich warten.
Es bleibt also spannend, es gibt viel zu lernen und zu erforschen.
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.
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 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.
stackconf 2020 | SecDevOps in der Cloud by Florian WiethoffNETWAYS
Public Clouds werden mittlerweile von fast allen Unternehmen genutzt. Viele Verantwortliche vergessen dabei jedoch, dass die Sicherheit ihrer Cloud-Umgebungen zu großen Teilen ihre Aufgabe ist – Stichwort Shared Responsibility. Die Security Features, die von den Cloud Anbietern zur Verfügung gestellt werden – Firewalls, Reverse Proxys, Web Application Firewalls – sind zudem nicht auf dem Niveau, das man von ausgereifen On-Premises Lösungen kennt.
Dieser Talk soll Erfahrungen aus Cloud-Projekten im Bankenumfeld weitergeben. Ich werde die wichtigsten Anforderungen und Best Practices vorstellen.
Die deutsche Variante meines Talks "Rapid prototyping with jQuery" gibt eine Einleitung ins Prototyping und geht dann weiter über Lösungsansätze, Einsatzmöglichkeiten und Vorteilen von Prototypen.
Galten “Nanoservices” im Kontext von Microservices noch als Anti-Pattern, kann dieses Muster seine Vorteile im Rahmen von “Serverless”-Backends voll ausspielen. Die Session soll zeigen, welche Vorteile Nanoservices bieten und mit welchen Lösungen sie umgesetzt werden können. Auch wird auf die besondere Rolle von Querschnittsfunktionen wie Authentifizierung und Persistent, sowie Themen des Entwicklungsprozesses wie Deployment- und Testautomatisierung eingegangen. Exemplarisch soll die Umsetzung auf der AWS-Plattform gezeigt werden.
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.
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.
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.
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.
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.
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.
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.
Maschinen haben kein Gewissen. Oder etwa doch? Immer wieder hört man von Fällen, in denen eine KI scheinbar „unethische“ Entscheidungen fällt oder für politische Zwecke missbraucht wird. Angefangen bei genderspezifischer Benachteiligung, über die Generierung und gezielte Verbreitung von Fake-News und Deep-Fakes bis hin zu offenkundigem Rassismus durch eine KI existieren unzählige Beispiele. Was aber genau steckt dahinter und wie können wir uns dagegen verwehren? Die Session zeigt einige populäre Beispiele auf und beleuchtet deren Hintergründe.
Eine KI ist nur so gut wie ihr Modell und die Daten, auf denen dieses basiert. Dies führt immer wieder zu überraschenden, ja sogar erschreckenden Resultaten bei deren Einsatz. Dabei bildet die KI nicht selten lediglich unsere Realität ab und spiegelt somit die Grundwerte unserer Gesellschaft wider, wie populäre Beispiele zeigen. Die Session zeigt einige Beispiele, in denen eindeutig einzelne Gruppen der Bevölkerung benachteiligt wurden, und beleuchtet diese im Detail. Es wird aufgezeigt, wie wir alle durch Fake-News und Deep-Fakes manipuliert werden und welche Initiativen zum Schutz und zur Regulierung angedacht sind.
Die Welt rund um das Frontend befindet sich im ständigen Wandel. Die Leistung der Computer der Konsumentinnen und Konsumenten und auch deren Erwartungen an Software steigen. Während die Server von Webdiensten früher lediglich ein wenig HTML erzeugen mussten, liegt die Logik heutzutage deshalb immer mehr auf dem Client, um eine optimale User Experience sicherzustellen – und das bringt Herausforderungen mit.
Im Talk schauten wir uns einige Trends der Webentwicklung an und analysierten die Probleme, die durch das Aufrüsten der Browser durch Google und Co. gelöst werden.
3. ÜBER MICH
Wer bin ich - und wenn ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast (a.k.a. “stets bemüht“)
Lars Röwekamp (a.k.a. @mobileLarson)
8. #WISSENTEILEN
Wo liegt eigentlich das Problem?
Bedarf in Zeiten von Cloud & Co.
• klein a.k.a. niedriger Speicherbedarf
• schnell a.k.a. geringe Startup Time
• flexibel a.k.a. Modularisierung
9. #WISSENTEILEN
Wo liegt eigentlich das Problem?
Java EE ist
• groß a.k.a. hoher Speicherbedarf
• langsam a.k.a. lange Startup Time
• unflexibel a.k.a. alles oder nix*
* gilt selbst für das stark abgespeckte WebProfile?
12. #WISSENTEILEN
Wo liegt eigentlich noch das Problem?
Java EE ist
• nicht für Microservices & Cloud konzipiert
• auf eine Runtime zugeschnitten
13. #WISSENTEILEN
Aber ist das wirklich ein Problem?*
Java EE ist
• stabil
• verbreitet
• standardisiert
• btw: erstes E in JEE steht für Enterprise
* Warum nicht einfach auf JEE verzichten?
37. #WISSENTEILEN
Variante: weniger ist mehr
PRO
• Standards
• schmal
• schnell
CONS
• Bootstrapping
• eingeschränkt*
• Micro* vs. Makro
* stark abhängig von der jeweiligen Lösung
41. #WISSENTEILEN
Variante: eXtended minimalized Standard
Eclipse MicroProfile Mission
„An open forum to optimize Enterprise Java
for a microservices architecture by
innovating across multiple implementations
and collaborating on common areas of interest
with a goal of standardization.“
55. #WISSENTEILEN
Variante: eXtended minimized Standard
PRO
• Standards
• Micro & Marko
• schmal*
• schnell*
• flexibel
CONS
• Bootstrapping
• je mehr, desto* …
* ist stark abhängig von den eingebundenen APIs
56. #WISSENTEILEN
Enterprise Java in Zeiten von Cloud & Co ….
STANDARDPROPRITARY
SLOW
FAST
… or here
! STANDARD
but SLOW
You are here …
! FAST but
PROPRITARY
…but you want
to be here! ? STANDARD
and FAST
60. #WISSENTEILEN
„I started thinking about my application’s
performance—in this case, the bootstrap time—and
asked myself whether I was happy with the actual time
my application took to start up. The answer was no.
And, nowadays, this is one of the most important
metrics to be considered when working with
microservices, mainly on a serverless architecture.“
Filipe Spolti, Red Hat
85. #WISSENTEILEN
Enterprise Java in Zeiten von Cloud & Co ….
STANDARDPROPRITARY
SLOW
FAST
… or here
! STANDARD
but SLOW
You are here …
! FAST but
PROPRITARY
…but you want
to be here! ? STANDARD
and FAST
86. #WISSENTEILEN
Enterprise Java in Zeiten von Cloud & Co ….
STANDARDPROPRITARY
SLOW
FAST
… or here
! STANDARD
but SLOW
You are here …
! FAST but
PROPRITARY
STANDARD *
and FAST
!Quarkus
aka Voodoo
87. #WISSENTEILEN
Enterprise Java in Zeiten von Cloud & Co ….
Voodoo Regeln
• Support von „leading“ APIs & Frameworks
• Dependency-Auflösung zur Compile-Time
• kurze Turnaround Zeiten via Dev Mode
• native Container-Images mit GraalVM
90. #WISSENTEILEN
„You are NOT Amazon,
Twitter or Netflix.“*
* except you are Amazon, Twitter or Netflix ;-)
91. #WISSENTEILEN
Enterprise Java in Zeiten von Cloud & Co ….
Voodoo Regeln eXtended Version
• “FatJARs are bad.“
• „Layered Containers are good.“
• „Small layered Containers are even better.“
• „Small* layered native Containers are best.“
* Distroless Container Image als extreme Variante