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.
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.
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.
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
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.
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.
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Production-ready Infrastruktur in 3 WochenAndré Goliath
Es gibt sie doch noch: Projekte die man auf der grünen Wiese starten darf - incl. Infrastruktur. Nur AWS als Cloud Provider ist gesetzt. In dieser Session gebe ich nach den ersten Wochen Einblicke und Lessons Learned, wie wir vom Zustand eines weißen Blatt Papiers auf ein Account- und Infrastruktur-Setup gekommen sind, mit dem wir zumindest mal sofort loslegen können ohne die üblichen „Abkürzungen“ bei Qualität und Featureumfang zu gehen. Ein wesentlicher Teil davon ist das Tooling von gruntwork.io, welches in diesem Kontext kurz vorgestellt wird. [Disclaimer: Wir sind auch nur normale Kunden mit einer gruntworks-Subscription ohne weitere Connections dorthin – diese Session wird also explizit keine gruntwork.io Werbeveranstaltung, auch wenn sich das inhaltlich nicht 100%ig vermeiden lässt]
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im ÜberblickKarin Patenge
Ein Key-Value Store mit nativer Unterstützung für JSON, der auch Graphen und SQL “kann”. Der Foliensatz enthält detaillierte Informationen zur Nutzung der Oracle NoSQL DB aus Sicht der Anwendungsentwicklung als auch aus Sicht der Administration / des Betriebs.
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
Kubernetes ermöglicht eine Automatisierung der Bereitstellung, Skalierung und Verwaltung von verteilten Docker-Container. Der Einstieg, die Umsetzung und Wartung hingegen ist eine extreme Herausforderung und kostet am Ende nicht nur viel Geld, sondern auch Ihre Nerven. Microsoft Azure bietet mit den Azure Kubernetes Services (Kurz AKS) die Erlösung, der soeben genannten Schmerzen. In dieser Session zeigt Ihnen der Docker- und Azure-Experte Gregor Biswanger einen Überblick von Kubernetes und wie einfach Azure für uns eine Kuberenetes-Landschaft herbeizaubern kann.
Oracle does support Docker for a couple of products since a while. In theory, a simple "docker run" instantiates a container from a docker image. But why isn't the DB container ready in a few seconds? Where does my Oracle DB image come from and what happens if the container is stopped again? The functional scope as well as the size of Oracle database container presuppose that one or the other thoughts about the use and the operation are made in advance. This includes topics such as data persistence, licensing and other operational aspects. This presentation explains how Oracle databases can be installed, configured and operated as containers in a Docker Image.
Automatisiertes disaster recovery testing mit der oracle cloudTrivadis
Der Oracle Backup Service ist die ideale Plattform für Oracle Datenbanksicherungen in die Cloud. Zusammen mit dem Compute Cloud Service hat man eine ideale Plattform für regelmässige Restore- und Recovery Tests.
IPv6 Integration im Datacenter - wie komplex ist es wirklich?Swiss IPv6 Council
Ein Anlass des Swiss Ipv6 Councils am 24. März 2014, 18 Uhr.
Referent: Ben Mathis, Leiter IT Plattform, Aspectra
Die Neugier von Ingenieuren zur Technologie stand am Anfang des Projekts, IPv6 in die beiden Datacenters der Aspectra AG zu integrieren. Inzwischen ist die erste Integrationsstufe abgeschlossen und die zweite in Arbeit. Rückblickend zeigt uns Ben Mathis, Leiter IT Plattform Aspectra AG, auf, welche Herausforderungen sich stellten und welche Entscheidungen der Schlüssel zur erfolgreichen IPv6 Integration waren. Genügend Zeit für Fragen bleibt selbstverständlich auch.
Inhalt:
- Die Motivation
- Die Strategie
- Die Implementierung
- 5 Do's und 5 Dont's
- Die offenen Punkte
Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbHagilemethoden
Slide of a workshop about DevOps with Docker in German.
DevOps mit Docker - ein Workshop für Softwareentwickler und Systemadministratoren
Docker zieht seit einiger Zeit viel Aufmerksamkeit auf sich, hauptsächlich weil es das aktuelle sehr populäre Thema DevOps adressiert. Bei Docker handelt es sich eine offene Plattform für Software-Entwickler und Sysadmins, mit der sie Software annähernd überall bauen, ausliefern und betreiben können. In diesem Workshop werden Sie lernen wie Software-Container gebaut, ausgeliefert, konfiguriert und betrieben werden. Der Vortragende wird sie anhand von praktischen Beispielen an seinen Erfahrungen teilhaben lassen.
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.
Weitere ähnliche Inhalte
Ähnlich wie Ready for the Future: Jakarta EE in Zeiten von Cloud Native & Co
Production-ready Infrastruktur in 3 WochenAndré Goliath
Es gibt sie doch noch: Projekte die man auf der grünen Wiese starten darf - incl. Infrastruktur. Nur AWS als Cloud Provider ist gesetzt. In dieser Session gebe ich nach den ersten Wochen Einblicke und Lessons Learned, wie wir vom Zustand eines weißen Blatt Papiers auf ein Account- und Infrastruktur-Setup gekommen sind, mit dem wir zumindest mal sofort loslegen können ohne die üblichen „Abkürzungen“ bei Qualität und Featureumfang zu gehen. Ein wesentlicher Teil davon ist das Tooling von gruntwork.io, welches in diesem Kontext kurz vorgestellt wird. [Disclaimer: Wir sind auch nur normale Kunden mit einer gruntworks-Subscription ohne weitere Connections dorthin – diese Session wird also explizit keine gruntwork.io Werbeveranstaltung, auch wenn sich das inhaltlich nicht 100%ig vermeiden lässt]
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im ÜberblickKarin Patenge
Ein Key-Value Store mit nativer Unterstützung für JSON, der auch Graphen und SQL “kann”. Der Foliensatz enthält detaillierte Informationen zur Nutzung der Oracle NoSQL DB aus Sicht der Anwendungsentwicklung als auch aus Sicht der Administration / des Betriebs.
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
Kubernetes ermöglicht eine Automatisierung der Bereitstellung, Skalierung und Verwaltung von verteilten Docker-Container. Der Einstieg, die Umsetzung und Wartung hingegen ist eine extreme Herausforderung und kostet am Ende nicht nur viel Geld, sondern auch Ihre Nerven. Microsoft Azure bietet mit den Azure Kubernetes Services (Kurz AKS) die Erlösung, der soeben genannten Schmerzen. In dieser Session zeigt Ihnen der Docker- und Azure-Experte Gregor Biswanger einen Überblick von Kubernetes und wie einfach Azure für uns eine Kuberenetes-Landschaft herbeizaubern kann.
Oracle does support Docker for a couple of products since a while. In theory, a simple "docker run" instantiates a container from a docker image. But why isn't the DB container ready in a few seconds? Where does my Oracle DB image come from and what happens if the container is stopped again? The functional scope as well as the size of Oracle database container presuppose that one or the other thoughts about the use and the operation are made in advance. This includes topics such as data persistence, licensing and other operational aspects. This presentation explains how Oracle databases can be installed, configured and operated as containers in a Docker Image.
Automatisiertes disaster recovery testing mit der oracle cloudTrivadis
Der Oracle Backup Service ist die ideale Plattform für Oracle Datenbanksicherungen in die Cloud. Zusammen mit dem Compute Cloud Service hat man eine ideale Plattform für regelmässige Restore- und Recovery Tests.
IPv6 Integration im Datacenter - wie komplex ist es wirklich?Swiss IPv6 Council
Ein Anlass des Swiss Ipv6 Councils am 24. März 2014, 18 Uhr.
Referent: Ben Mathis, Leiter IT Plattform, Aspectra
Die Neugier von Ingenieuren zur Technologie stand am Anfang des Projekts, IPv6 in die beiden Datacenters der Aspectra AG zu integrieren. Inzwischen ist die erste Integrationsstufe abgeschlossen und die zweite in Arbeit. Rückblickend zeigt uns Ben Mathis, Leiter IT Plattform Aspectra AG, auf, welche Herausforderungen sich stellten und welche Entscheidungen der Schlüssel zur erfolgreichen IPv6 Integration waren. Genügend Zeit für Fragen bleibt selbstverständlich auch.
Inhalt:
- Die Motivation
- Die Strategie
- Die Implementierung
- 5 Do's und 5 Dont's
- Die offenen Punkte
Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbHagilemethoden
Slide of a workshop about DevOps with Docker in German.
DevOps mit Docker - ein Workshop für Softwareentwickler und Systemadministratoren
Docker zieht seit einiger Zeit viel Aufmerksamkeit auf sich, hauptsächlich weil es das aktuelle sehr populäre Thema DevOps adressiert. Bei Docker handelt es sich eine offene Plattform für Software-Entwickler und Sysadmins, mit der sie Software annähernd überall bauen, ausliefern und betreiben können. In diesem Workshop werden Sie lernen wie Software-Container gebaut, ausgeliefert, konfiguriert und betrieben werden. Der Vortragende wird sie anhand von praktischen Beispielen an seinen Erfahrungen teilhaben lassen.
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“!
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!
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.
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.
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.
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".
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.
8. Controller
Manager
Scheduler
API Server
etcd (k/v-Store) Cloud Controller Mgr*
Control Plane (Master Noder) Worker Node 1
Worker Node 2
kubelet
kubelet
Container Runtime
Container Runtime
kube-proxy
kube-proxy
k8-Objects*
k8-Objects*
End User
Developer
kubectl
cli/api/
dashboard
Kubernetes Cluster
(ideas taken from DevOps Mojo by Ashish Patel)
*optional
Data Plane (Worker Nodes)
9. Seien wir doch mal ehrlich …
Bedarf in Zeiten von Cloud & Co.
• klein aka niedriger Speicherbedarf
• schnell aka geringe Startup Time
• flexibel aka Modularisierung
10. Seien wir doch mal ehrlich …
Jakarta EE ist eher
• groß aka hoher Speicherbedarf
• langsam aka lange Startup Time
• unflexibel aka alles oder nix*
* gilt selbst für das stark abgespeckte WebProfile?
+++ BREAKING NEWS: Jakarta EE 10 führt minimalistisches CORE Profile ein +++
18. Aber ist das wirklich ein Problem?*
Enterprise Java ist
• stabil
• verbreitet
• standardisiert
• btw: erstes E in JEE steht für Enterprise
* Warum nicht einfach auf verzichten?
19. Jakarta EE - The Missing Pieces
Was fehlt für Distributed Runtimes?
• Monitoring aka Health Checks & Metrics
• Distributed Tracing
• Distributed Config Mgt
• Fault Tolerance aka Resilience
• Security Context Propagation
20.
21.
22. Wie war das noch mit dem
Jakarta EE Core Profile?
32. Jakarta EE & MicroProfile
PRO
• Standards
• Micro & Makro
• schmal*
• schnell*
• flexibel
CONS
• Bootstrapping
• je mehr, desto* …
* ist stark abhängig von den eingebundenen APIs
34. Jakarta EE in Zeiten von Cloud & Co ….
fat & slow mid-sized & kinda fast
„we ARE here“
„we CAME from here“
35. Jakarta EE in Zeiten von Cloud & Co ….
fat & slow super slim & turbo fast
„we ARE here“ „we DREAM to be here“
„we CAME from here“
mid-sized & kinda fast
37. „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 is one of the most important
metrics to be considered when working with
microservices, mainly on a serverless architecture.“
Filipe Spolti, Red Hat
38. Aus der Rubik: „Spaß beim Startup …“
internal
once
element
Metadata
Processing
at Startup
41. Was bedeutet das für Cloud-native?
„Container First“ Ansatz von Quarkus
• schmale Pakete == kleine Container Images
• schnelle Boot Time == sofortiges Scale-up
• geringer RSS* Speicher == mehr Container**
*RSS = resident set size (all RAM consumed by a process),
** mehr Container bei gleichem RAM
44. Quakus Voodoo #1
Build-Time Optimization
Ein Großteil der „möglichen“ Dynamik zur
Laufzeit wird gar nicht benötigt. Daher lässt
sich die Auflösung deren Abhängigkeiten in
die Compile-Time verschieben.*
*@Inject, @Observes, @Path, @GET, …
55. Quarkus Voodoo #2
Ahead-of-Time Compilation
„Write once, run anywhere“ ist in Zeiten von
Containern und damit einheitlichen Laufzeit-
umgebungen optional.*
*Ahead-of-Time Compilation statt dynamisches scannen / laden von Klassen
72. Jakarta EE in Zeiten von Cloud & Co ….
fat & slow super slim & turbo fast
Jakarta EE & MicroProfile plus Quarkus / AoT*
Old School J2EE
mid-sized & kinda fast
76. „You are NOT Amazon,
Twitter or Netflix.“*
* unless you are Amazon, Twitter or Netflix ;-)
77. Enterprise Java in Zeiten von Cloud & Co ….
Voodoo Regeln eXtended Version
• “FatJARs are evil.“
• „Layered Containers are good.“
• „Small layered Containers are even better.“
• „Small* layered native Containers are best.“
* Distroless Container Image als extreme Variante
79. „FATJars verlängern die
DEV Roundtrips unnötig.
Daher ist besser mit
mehreren unterschiedlichen
Layern zu arbeiten.“
*Don't Put Fat Jars in Docker Images:
https://phauer.com/2019/no-fat-jar-in-docker-image/