20161123_API Summit:
Denk man an Web APIs, dann verbindet man das zugehörige Kommunikationsmodell meist mit RESTful Requests & Responses. Dies macht in vielen Fällen sicherlich auch Sinn. Aber eben nicht in allen! Was ist z. B., wenn auf Seiten des Clients komplexe Abfragen anstehen, die sich nicht so einfach über simple “Ressourcen” abbilden lassen. Wie geht man damit um, wenn auf dem Server lang laufende Aktionen angestoßen werden, auf deren Abarbeitung der Client nicht unbedingt warten möchte? Und muss es eigentlich immer clientseitiges “Pull” sein oder macht nicht Serverseitiges “Push” via Websockets in vielen Anwendungsfällen mehr Sinn? Die Session zeigt anhand ausgewählter, praxisnaher Use-Cases, wie man durch verschiedene Pattern das klassische RESTful Request-/Response-Modell seiner Web API sinnvoll erweitern kann und so zu deutlich eleganteren und performanteren Lösungen kommt.
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.
Denkt man an Web-APIs, dann verbindet man das zugehörige Kommunikationsmodell meist mit RESTful Requests und Responses. Dies ergibt in vielen Fällen sicherlich auch Sinn, aber eben nicht in allen! Was ist z.B., wenn auf Seiten des Clients komplexe Abfragen anstehen, die sich nicht so einfach über simple “Ressourcen” abbilden lassen. Wie geht man damit um, wenn auf dem Server lang laufende Aktionen angestoßen werden, auf deren Abarbeitung der Client nicht unbedingt warten möchte? Und muss es eigentlich immer clientseitiges “Pull” sein oder ergibt nicht serverseitiges “Push” via WebSocket in vielen Anwendungsfällen mehr Sinn? Die Session zeigt anhand ausgewählter praxisnaher Use Cases, wie man durch verschiedene Patterns das klassische RESTful Request-/Response-Modell seines Web-API sinnvoll erweitern kann, und so zu deutlich eleganteren und performanteren Lösungen kommt.
Die Zeiten einfacher Web-Anwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle, wie Web, Desktop, Mobile oder 3rd Party Clients, parallel bedienen zu müssen. Und das mit einer Architektur. Wie aber sieht eine passende Architektur aus? Welche neuen Herausforderungen ergeben sich durch die zusätzlichen Kanäle? Und welche Auswirkungen hat dies auf Aspekte wie Security, Schnittstellendesign oder das Datenmodell? In der Session „öffnen“ wir eine Web-Anwendung und stellen uns den Herausforderungen.
Oftmals wird "Multi-Channel" gleichgesetzt mit Responsive Design. Dies setzt allerdings voraus, dass jeder Channel mehr oder minder dieselben Use-Cases bedient. Ein echter Business-Mehrwert wird aber erst erreicht, wenn jeder Channel seine speziellen Eigenschaften ausspielt, was automatisch eine deutlich größere Flexibilität - auch auf Ebene der Architektur - verlangt. Genau hier setzt die Session an und zeigt, wie eine Architektur aufgebaut sein sollte, die deutlich mehr erlaubt als "nur" Responsive Design.
CQRS (Command Query Responsibility Segregation) als Architektur-Pattern sieht vor, dass lesende (Queries) und schreibende Zugriffe (Commands) in getrennten Subsystemen auf unterschiedlichen Modellen realisiert werden. Während Commands meist asynchron und transaktional angestoßen werden, arbeiten Queries mit denormalisierten Views auf “eventual consistent” Daten. Ziel ist eine hoch skalierbare, hoch performante und sichere Plattform. Was sich zunächst einmal nach zusätzlichem Aufwand anhört, bringt in der Praxis eine Menge Vorteile mit sich. Die Session zeigt die wesentlichen Ideen von CQRS auf und demonstriert anhand eines praktischen Beispiels die Vorteile dieses Ansatzes im Kontext von Web APIs.
Da hat man einmal eine tolle Idee für eine Mobile-App und möchte sie so schnell wie möglich realisieren, und dann scheitert das Ganze am Ende am passenden Backend. Zu aufwendig und riskant die Anpassung des bestehenden Web-Backends, zu zeitintensiv und teuer die Entwicklung eines neuen Mobile-Backends. Von mangelnder Skalierung, Security und Co. ganz zu schweigen. Aber kein Grund zur Panik: Wo ein Wille ist, ist auch ein Weg. Die Session zeigt, wie bestehende Backends für Mobile-Apps „enabled“ und neue Backends on the fly via Cloud-Anbieter zur Verfügung gestellt werden können. SaaS, PaaS, BaaS und BFF heißen die Akronyme der Stunde. Was nimmt man wann? Auflösung folgt …
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.
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.
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.
Denkt man an Web-APIs, dann verbindet man das zugehörige Kommunikationsmodell meist mit RESTful Requests und Responses. Dies ergibt in vielen Fällen sicherlich auch Sinn, aber eben nicht in allen! Was ist z.B., wenn auf Seiten des Clients komplexe Abfragen anstehen, die sich nicht so einfach über simple “Ressourcen” abbilden lassen. Wie geht man damit um, wenn auf dem Server lang laufende Aktionen angestoßen werden, auf deren Abarbeitung der Client nicht unbedingt warten möchte? Und muss es eigentlich immer clientseitiges “Pull” sein oder ergibt nicht serverseitiges “Push” via WebSocket in vielen Anwendungsfällen mehr Sinn? Die Session zeigt anhand ausgewählter praxisnaher Use Cases, wie man durch verschiedene Patterns das klassische RESTful Request-/Response-Modell seines Web-API sinnvoll erweitern kann, und so zu deutlich eleganteren und performanteren Lösungen kommt.
Die Zeiten einfacher Web-Anwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle, wie Web, Desktop, Mobile oder 3rd Party Clients, parallel bedienen zu müssen. Und das mit einer Architektur. Wie aber sieht eine passende Architektur aus? Welche neuen Herausforderungen ergeben sich durch die zusätzlichen Kanäle? Und welche Auswirkungen hat dies auf Aspekte wie Security, Schnittstellendesign oder das Datenmodell? In der Session „öffnen“ wir eine Web-Anwendung und stellen uns den Herausforderungen.
Oftmals wird "Multi-Channel" gleichgesetzt mit Responsive Design. Dies setzt allerdings voraus, dass jeder Channel mehr oder minder dieselben Use-Cases bedient. Ein echter Business-Mehrwert wird aber erst erreicht, wenn jeder Channel seine speziellen Eigenschaften ausspielt, was automatisch eine deutlich größere Flexibilität - auch auf Ebene der Architektur - verlangt. Genau hier setzt die Session an und zeigt, wie eine Architektur aufgebaut sein sollte, die deutlich mehr erlaubt als "nur" Responsive Design.
CQRS (Command Query Responsibility Segregation) als Architektur-Pattern sieht vor, dass lesende (Queries) und schreibende Zugriffe (Commands) in getrennten Subsystemen auf unterschiedlichen Modellen realisiert werden. Während Commands meist asynchron und transaktional angestoßen werden, arbeiten Queries mit denormalisierten Views auf “eventual consistent” Daten. Ziel ist eine hoch skalierbare, hoch performante und sichere Plattform. Was sich zunächst einmal nach zusätzlichem Aufwand anhört, bringt in der Praxis eine Menge Vorteile mit sich. Die Session zeigt die wesentlichen Ideen von CQRS auf und demonstriert anhand eines praktischen Beispiels die Vorteile dieses Ansatzes im Kontext von Web APIs.
Da hat man einmal eine tolle Idee für eine Mobile-App und möchte sie so schnell wie möglich realisieren, und dann scheitert das Ganze am Ende am passenden Backend. Zu aufwendig und riskant die Anpassung des bestehenden Web-Backends, zu zeitintensiv und teuer die Entwicklung eines neuen Mobile-Backends. Von mangelnder Skalierung, Security und Co. ganz zu schweigen. Aber kein Grund zur Panik: Wo ein Wille ist, ist auch ein Weg. Die Session zeigt, wie bestehende Backends für Mobile-Apps „enabled“ und neue Backends on the fly via Cloud-Anbieter zur Verfügung gestellt werden können. SaaS, PaaS, BaaS und BFF heißen die Akronyme der Stunde. Was nimmt man wann? Auflösung folgt …
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.
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.
Leider existiert bei vielen Entwicklern der Irrglaube, dass mit dem Launch der eigenen App in einem der App Stores die Arbeit getan sei. Dabei geht der Spaß dann erst richtig los. Nur wer seine App als Produkt und nicht als Projekt versteht, hat auch nachhaltig die Chance auf Erfolg. Die Session zeigt, wie man durch Crash Reporting, App Analytics, geschicktes Einbinden der Usercommunity und ein gut durchdachtes Releasemanagement seine App auch nach dem ersten Launch attraktiv und erfolgreich halten kann.
Das „Schwergewicht“ Java EE scheint nicht wirklich mit der Wunderwelt der Microservices und den damit einhergehenden Architekturpatterns zu harmonisieren. Dabei bringt der Java-Enterprise-Standard technologisch gesehen alles mit, was es zur Umsetzung von Microservices benötigt. Wo also liegt das Problem? In der Session werden wir Schritt für Schritt eine monolithische Java-EE-Anwendung „sezieren“ und uns den damit einhergehenden Herausforderungen der neu entstandenen, Microservice-basierten Architektur stellen. Aha-Effekte garantiert!
Microservices richtig umgesetzt bedeutet auch die ehemals monolithische Datenbank aufzusplittern. Transaktionen über Servicegrenzen hinweg, stellen somit eine neue Herausforderung dar.
App war gestern: Mobile Engagement als Teil der Enterprise-StrategieOPEN KNOWLEDGE GmbH
„Hilfe, wir brauchen eine App!“ Erschreckend, aber wahr: Nicht selten starten Unternehmen genau so ihre mobilen Projekte. Dabei geht es doch weniger um einzelne Apps, als vielmehr darum, mit einem sinnvollen „Mobile Engagement“ die bestehende Enterprise-(IT-)Strategie gewinnbringend zu ergänzen. Mobile Mehrwerte schaffen ist der Schlüssel zum Erfolg. Doch wie findet man diese? Und hat man sie einmal gefunden, ist dann das Backend überhaupt in der Lage, den neuen Channel „Mobile“ sinnvoll zu bedienen? Keine Frage, eine Mobile-Enterprise-Strategie muss her! Die Session zeigt die typischen Stolpersteine vieler Unternehmern auf dem Weg in die Wunderwelt „Mobile“ und gibt praxisnahe Tipps an die Hand, wie man diese mit ein wenig Planung umgehen kann. Am Ende steht – statt einer Menge Frust – eine gelungenes Mobile Engagement mit Anbindung an das Unternehmens-Backend.
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!
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.
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.
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.
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.
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.
Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler technischer Transaktionen an, auch Saga-Pattern genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt seine praktische Verwendung an verschiedenen Beispielen.
„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.
Der Java-Enterprise-Standard Java EE scheint weder für Microservices-basierte Architekturen noch für die Cloud wirklich gut geeignet zu sein – so zumindest die landläufige Meinung. Zu komplex die Fülle der APIs, zu schwergewichtig die Runtime namens Application Server. Was aber bedeutet das für die vielen, vielen Teams, die seit Jahren entsprechende Erfahrungen aufgebaut haben? Gibt es für sie noch Hoffnung, ihr Expertenwissen auch in zukünftigen Projekten weiter nutzen zu können. Die Session zeigt, wie auch Java-EE-Teams problemlos in die Wunderwelt der Microservices und Cloud eintauchen können, ohne dabei auf ihre jahrelange Enterprise-Erfahrung verzichten zu müssen. Natürlich wartet die eine oder andere Herausforderung, aber ohne wäre es ja auch langweilig.
Web-APIs sind das aktuelle Trendthema in den IT-Abteilungen. Als primärer Kommunikationspartner für Fat-, Mobil- und Web-Clients sind Web-APIs das Rückgrat moderner verteilter Anwendungen. Sind synchrone Requests via REST und GraphQL oder Push-Notifications via Server-Sent Events und WebSocket die bessere Wahl? Welches Austauschformat sollte man wählen? Wie sieht gutes "Error Handling" aus? Und was ist mit Themen wie Security und Versionierung?
Lebensnahe Beispiele, jede Menge Best-Practices und viel Code, der nahtlos in eigene Projekte übernommen werden kann, bilden die Grundlage für die Session.
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.
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.
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.
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.
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.
Web-APIs sind das aktuelle Trend-Thema in den IT-Abteilungen. Als primärer Kommunikationspartner für Fat, Mobil und Web-Clients sind Web-APIs das Rückgrat moderner verteilter Anwendungen. Sind synchrone Requests via REST und GraphQL oder Push-Notifications via Server-Sent Events und WebSocket die bessere Wahl? Welches Austauschformat sollte man wählen? Wie sieht gutes „Error Handling“ aus? Und was ist mit Themen wie Security und Versionierung? Lebensnahe Beispiele, jede Menge Best-Practices und viel Code, der nahtlos in eigene Projekte übernommen werden kann, bilden die Grundlage für die Session.
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.
Leider existiert bei vielen Entwicklern der Irrglaube, dass mit dem Launch der eigenen App in einem der App Stores die Arbeit getan sei. Dabei geht der Spaß dann erst richtig los. Nur wer seine App als Produkt und nicht als Projekt versteht, hat auch nachhaltig die Chance auf Erfolg. Die Session zeigt, wie man durch Crash Reporting, App Analytics, geschicktes Einbinden der Usercommunity und ein gut durchdachtes Releasemanagement seine App auch nach dem ersten Launch attraktiv und erfolgreich halten kann.
Das „Schwergewicht“ Java EE scheint nicht wirklich mit der Wunderwelt der Microservices und den damit einhergehenden Architekturpatterns zu harmonisieren. Dabei bringt der Java-Enterprise-Standard technologisch gesehen alles mit, was es zur Umsetzung von Microservices benötigt. Wo also liegt das Problem? In der Session werden wir Schritt für Schritt eine monolithische Java-EE-Anwendung „sezieren“ und uns den damit einhergehenden Herausforderungen der neu entstandenen, Microservice-basierten Architektur stellen. Aha-Effekte garantiert!
Microservices richtig umgesetzt bedeutet auch die ehemals monolithische Datenbank aufzusplittern. Transaktionen über Servicegrenzen hinweg, stellen somit eine neue Herausforderung dar.
App war gestern: Mobile Engagement als Teil der Enterprise-StrategieOPEN KNOWLEDGE GmbH
„Hilfe, wir brauchen eine App!“ Erschreckend, aber wahr: Nicht selten starten Unternehmen genau so ihre mobilen Projekte. Dabei geht es doch weniger um einzelne Apps, als vielmehr darum, mit einem sinnvollen „Mobile Engagement“ die bestehende Enterprise-(IT-)Strategie gewinnbringend zu ergänzen. Mobile Mehrwerte schaffen ist der Schlüssel zum Erfolg. Doch wie findet man diese? Und hat man sie einmal gefunden, ist dann das Backend überhaupt in der Lage, den neuen Channel „Mobile“ sinnvoll zu bedienen? Keine Frage, eine Mobile-Enterprise-Strategie muss her! Die Session zeigt die typischen Stolpersteine vieler Unternehmern auf dem Weg in die Wunderwelt „Mobile“ und gibt praxisnahe Tipps an die Hand, wie man diese mit ein wenig Planung umgehen kann. Am Ende steht – statt einer Menge Frust – eine gelungenes Mobile Engagement mit Anbindung an das Unternehmens-Backend.
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!
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.
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.
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.
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.
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.
Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler technischer Transaktionen an, auch Saga-Pattern genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt seine praktische Verwendung an verschiedenen Beispielen.
„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.
Der Java-Enterprise-Standard Java EE scheint weder für Microservices-basierte Architekturen noch für die Cloud wirklich gut geeignet zu sein – so zumindest die landläufige Meinung. Zu komplex die Fülle der APIs, zu schwergewichtig die Runtime namens Application Server. Was aber bedeutet das für die vielen, vielen Teams, die seit Jahren entsprechende Erfahrungen aufgebaut haben? Gibt es für sie noch Hoffnung, ihr Expertenwissen auch in zukünftigen Projekten weiter nutzen zu können. Die Session zeigt, wie auch Java-EE-Teams problemlos in die Wunderwelt der Microservices und Cloud eintauchen können, ohne dabei auf ihre jahrelange Enterprise-Erfahrung verzichten zu müssen. Natürlich wartet die eine oder andere Herausforderung, aber ohne wäre es ja auch langweilig.
Web-APIs sind das aktuelle Trendthema in den IT-Abteilungen. Als primärer Kommunikationspartner für Fat-, Mobil- und Web-Clients sind Web-APIs das Rückgrat moderner verteilter Anwendungen. Sind synchrone Requests via REST und GraphQL oder Push-Notifications via Server-Sent Events und WebSocket die bessere Wahl? Welches Austauschformat sollte man wählen? Wie sieht gutes "Error Handling" aus? Und was ist mit Themen wie Security und Versionierung?
Lebensnahe Beispiele, jede Menge Best-Practices und viel Code, der nahtlos in eigene Projekte übernommen werden kann, bilden die Grundlage für die Session.
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.
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.
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.
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.
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.
Web-APIs sind das aktuelle Trend-Thema in den IT-Abteilungen. Als primärer Kommunikationspartner für Fat, Mobil und Web-Clients sind Web-APIs das Rückgrat moderner verteilter Anwendungen. Sind synchrone Requests via REST und GraphQL oder Push-Notifications via Server-Sent Events und WebSocket die bessere Wahl? Welches Austauschformat sollte man wählen? Wie sieht gutes „Error Handling“ aus? Und was ist mit Themen wie Security und Versionierung? Lebensnahe Beispiele, jede Menge Best-Practices und viel Code, der nahtlos in eigene Projekte übernommen werden kann, bilden die Grundlage für die Session.
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.
JSF 2.x hat mit einem verbesserten GET-Support und View-Parametern inzwischen schon einiges zum Thema RESTful zu bieten. Das Open-Source-Projekt PrettyFaces geht noch einen Schritt weiter, in dem es erlaubt, fast beliebige RESTful URLs zu erzeugen. Zudem bietet PrettyFaces noch weitere hilfreiche Goodies. In dieser Session wird auf die Konfiguration und die Verwendung von PrettyFaces im Detail eingegangen und aufgezeigt, wie sich zudem ganz einfach die SEO-Eigenschaften (Search Engine Optimization) der Applikation verbessern lassen.
Im Kontext von APIs kommt derzeit keiner an REST (Representational State Transfer) vorbei. REST gilt als leichtgewichtige, skalierbare und schnell erlernbare Alternative zu SOAP, die sich die vorhandene Infrastruktur des WWW zunutze macht. In der Praxis hat aber auch REST seine Schwächen. So ist gutes API-Design häufig eine Herausforderung. Für mobile Anwendungen ist REST zu starr und geht nicht effizient genug mit Bandbreite um.
Im Vortrag werden Stärken und Schwächen von REST aufgezeigt und mit GraphQL eine Alternative speziell für den mobilen Kontext vorgestellt.
REST APIs liegen im Trend und werden daher in vielen Projekten eingesetzt. REST besitzt Schwächen, die bei falschem Einsatz schnell sichtbar werden. Dieser Vortrag zeigt die Probleme und Schächen von REST und beschreibt die Alternativen: GraphQL, JSON Path und GRPC.
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!
Logdaten sind wie das Rohöl. Erst die Verarbeitung macht sie richtig wertvoll. Mit Logstash, Elasticsearch und Kibana hat uns und die Community genau dafür ein starkes und äußerst agiles Dreiergespann geschenkt. Logstash für Datenakquisition und Normalisierung. Elasticsearch für Indexierung, Speicherung und Suche. Und nicht zuletzt Kibana für Visualisierung. Das ist das Fundament für viele hoch aktuelle und interessante Anwendungsfälle, die Echtzeitfähigkeit und Agilität erfordern: Sentiment Analyse, Systemüberwachung oder Benutzertracking. In diesem Webinar lernen Sie, wie Logstash, Elasticsearch und Kibana installiert und konfiguriert werden. Gerüstet mit diesem Wissen können Sie eigene Projekte zur Datenanalyse umsetzen!
Folgendes erfahren Sie aus dem Webinar:
• Das Ökosystem rund um Suche, Big Data, Analyse
• Alles alter Käse? Oder was Logstash, Elasticsearch und Kibana anders machen.
• Was ist Elasticsearch?
• Elasticsearch Setup durchführen
• Was ist Logstash?
• Logstash Setup durchführen
• Was ist Kibana?
• Kibana Setup durchführen
• Berechtigungen abbilden
• Demonstration
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!
Steven Schuurman, CEO von Elasticsearch, hat es in einem Blog als die „wahrscheinlich wichtigste Ankündigung seit Gründung der Firma“ genannt. Gemeint hat er Marvel. Marvel ist ein neues Tool, das ein Monitoring eines Elasticsearch-Clusters ermöglicht. Dieses beinhaltet Informationen über Elasticsearch, Lucene und das System selbst. Ein Tool, welches ein so umfangreiches Monitoring für Elasticsearch anbietet, ist einzigartig auf dem Markt.
Alle Metriken zu sammeln, zu visualisieren und miteinander in Zusammenhang zu bringen gibt Ihnen Einblicke in Elasticsearch-Cluster, die so vorher mit großem Aufwand verbunden waren. Zustand, Verfügbarkeit, Nutzung, Auslastung Ihrer Umgebung können Sie nun bequem über ein einziges Tool beobachten – in Echtzeit oder auch historisch.
Dieses Webinar gibt Ihnen einen Überblick über die Möglichkeiten, die Ihnen Marvel bietet, die Installation in einem Cluster, die Verwendung von Marvel sowie die Analyse Ihres Clusters.
Inhalte des Webinars:
• Was ist Marvel?
• Die Funktionsweise von Marvel
• Installation von Marvel
• Abgrenzung zum ELK-Stack
• Vorteile gegenüber anderen Monitoring-Ansätzen
• Die wichtigsten Metriken
• Customizing Marvel
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.
Das Online-Magazin auf www.chefkoch.de hat inzwischen etwa ca. 6000 Artikeln, ca. 15 RedakteurInnen und ca. 2 Mio. monatliche Leser. Grund genug, das zugrundeliegende CMS, eine 10 Jahre alte Eigenentwicklung, auf eine moderne Basis zu stellen: Drupal8! Das neue System soll bald online gehen, es gibt also viel zu erzählen: Welche Herausforderungen gab es bei der Planung und Durchführung des Projektes? Welche technischen Entscheidungen haben wir getroffen und was haben wir (gutes und schlechtes) über Drupal und seinen Code gelernt? Ein Vortrag mit viel Wert für jeden, der selbst an einem CMS arbeitet!
Dieser Vortrag von der SEO Campixx 2019 befasst sich mit der effektiven Erfassung, Verwaltung und Optimierung großer URL-Inventare.
Das Ziel: Weniger irrelevante URLs, gezieltere Optimierung der übrigen URLs, um höhere und mehr Rankings bei Google & Co, mehr Übersicht und erfolgreichere Optimierungsschleifen im Website-Team und dadurch ein besseres Kosten/Nutzen-Verhältnis für das Unternehmen zu erreichen.
Eico Schweins ist Online Marketing-Berater und Coach (https://be-visionary.de). Zuvor war er als Senior Online Marketing Consultant bei Turbine Kreuzberg GmbH und Head of PR und Kommunikation bei Performics (früher: AKM3 GmbH) aktiv. Als Dozent lehrt er Online Marketing an der Universität Münster. Eico hat in den letzten Jahren v.a. mittelständische und Großunternehmen dabei unterstützt, ihr Online Marketing aufzubauen und dessen Effektivität zu steigern.
Es wird endlich Zeit die eigene Webseite aufzuräumen! Dominik erzählt euch, wie ihr am besten vorgeht.
Dominik Wojcik der Geschäftsführer der Online-Marketing-Agentur Trust Agents aus Berlin auf der SEOkomm 2016.
In diesem Webinar haben wir das Thema ABAP & Performance behandelt. Im Detail sind wir auf folgende Themen eingegangen:
- Skill
- Detect
- Optimize
Skill: Welche Skills sind notwendig? Wie erlange ich diese Skills? Welche Plattformen, welche Netzwerke sind sinnvoll?
Detect: Welche Tools stehen in einem SAP System zur Verfügung?
Optimize: Welche Möglichkeiten der Performanceoptimierung sind möglich und sinnvoll?
Ähnlich wie Web APIs jenseits von REST & Request/Response (20)
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AIOPEN KNOWLEDGE GmbH
Häufig stellt die Entwicklung einer ML-Lösung die Optimierung von Performanz-Metriken wie der "Accuracy" unter Verwendung sehr komplexer Modelle in den Fokus. Fälschlicherweise wird sich damit abgefunden, dass aufgrund der höheren Komplexität die Explainability, also die Frage nach dem "Warum verhält sich mein Modell so und nicht anders?" leiden muss. Die Folgen können schwerwiegend sein und reichen vom unwissentlich gelernten Bias aus tabellarischen Daten bis zu einer hohen Anfälligkeit gegenüber Adversarial-Attacks in Bilddaten des autonomen Fahrens.
Warum meiner Meinung nach die Explainability auch bei komplexen Modellen nicht leiden muss, möchte ich in diesem Vortrag verdeutlichen.
Hierfür werde ich verschiedene XAI-Methoden, wie z.B. die Permutation-Importance und LIME, anhand eines konkreten Anwendungsfalles vorstellen, bewerten und vergleichen. Mein Ziel ist es, für XAI zu sensibilisieren und euch einen Methoden-Kasten an die Hand zu geben, der dazu befähigt, den Blick in die Black-Box zu wagen.
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...OPEN KNOWLEDGE GmbH
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot - KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern. Vorausgesetzt man verfügt über gute Ideen und hinreichend viele und qualifizierte Daten. Aber wie genau kommt man zu diesen Ideen? Und wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Softwareentwicklung ergeben können, und zeigt dafür passende, pragmatische Lösungsansätze auf.
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudOPEN KNOWLEDGE GmbH
Cloud is the new normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer, cloudspezifischer Architekturmuster? Was unterscheidet dabei die verschiedenen As-a-Service-Varianten (IaaS, PaaS, BaaS und FaaS) voneinander und für welchen Anwendungsfall nimmt man was? Fragen über Fragen – aber keine Panik, der Talk liefert Antworten.
SPAGAT ZWISCHEN BIAS UND FAIRNESS
KI soll fair sein. Da sind wir uns alle einig. Entsprechend gilt es, eine „Voreingenommenheit“ der eigenen KI-Lösung zu vermeiden.
Leichter gesagt als getan, denn Bias kann sich an verschiedenen Stellen innerhalb des AI/ML-Lifecycles einschleichen – vom initialen Design bis hin zum produktiven Einsatz des Modells. Diese Stellen gilt es zu identifizieren und im Detail zu verstehen. Denn nicht jede Art von Voreingenommenheit ist automatisch auch böse bzw. unfair.
Die Session zeigt, wie potenzielles Auftreten von unerwünschtem Bias in der eigenen KI-Lösung aufgedeckt und vermieden werden kann.
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data ImputationOPEN KNOWLEDGE GmbH
Leider sind die in der Praxis zur Verfügung stehenden Daten für das Training von Modellen bei weitem nicht so gut und vollständig, wie in den Lehrbüchern. Was also tun? Unvollständige Datensätze ignorieren und damit die zum Training notwendigen Daten deutlich reduzieren? Oder die Lücken besser mit sinnvollen Näherungswerten auffüllen.
Die Session zeigt, ob und wann es sinnvoll ist, fehlende Datensätze aufzufüllen und demonstriert an Real-Life Szenarien verschiedene Verfahren zur sinnvollen Ergänzung fehlender Daten. Neben einfachen Verfahren wie Mean/Median, Random Sample, Mulitple Imputation oder der Interpolationen zeitbezogenen Werte werden auch ML-basierte Imputation-Verfahren wie Regression oder Classification sowie deren potenzielle Einsatzgebiete beleuchtet. Dass fehlende Datensätze im Training auch einen positiven Effekt auf die Qualität des resultierenden Modells haben können, wird ebenfalls gezeigt.
In der Vergangenheit mussten Log-Files von Produktiv-Systemen mühsam von Hand zusammengesucht und danach durchforstet werden. Mit dem Aufkommen von Microservices gibt es jedoch immer mehr Tools, die die Aggregation und das Durchsuchen von Log-Informationen automatisieren. Den Anfang hat der ELK-Stack gemacht. Verteilte Systeme liefern jedoch heutzutage viel mehr relevante und besser aufbereitete Informationen als in den Log-Files zu finden sind. In einigen Situationen sind die in den Log-Files gefundenen Informationen unzureichend oder müssen mühsam extrahiert werden. Aus diesem Grund ist es naheliegend, die benötigten Informationen direkt in einem geeigneten Format bereitzustellen. Heutige Standards wie OpenTelemetry ermöglichen es, Informationen in dem benötigten Format zu sammeln. Werden Log-Files dadurch überflüssig? Die Session regt einen Mindset-Change an, stellt die Herausforderungen vor, die mit den verschiedenen Toolings bewältigt werden können, und erklärt, unter welchen Voraussetzungen auf Logging komplett verzichtet werden kann.
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierter Enterprise-Computing-Lösungen geht. Das gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application-Server deployt werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so mit Hilfe von Nebenprojekten wie Eclipse MicroProfile den Anforderungen moderner Cloud-Native-Anwendungen gerecht zu werden. Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.
From Zero to still Zero: The most beautiful mistakes going into the cloud. OPEN KNOWLEDGE GmbH
"Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Passende Blaupausen dazu gibt es mehr als genug. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloud-Anbieter glauben machen wollen? Natürlich nicht. Diese Session zeigt anhand typischer Antipattern, wie der Weg in die Cloud garantiert im Desaster endet und wie man sich dagegen wappnen kann. Ähnlichkeiten zu existierenden Projekten sind rein zufällig – oder auch nicht.
API Expand Contract ist ein Pattern zur Weiterentwicklung von APIs. Aber was verbirgt sich hinter der Idee? Wie kann ich damit eine API weiterentwickeln, ohne dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoOPEN KNOWLEDGE GmbH
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolithen in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mit Hilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud Native Anwendungen gerecht zu werden.
Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien aka Serverless, eine gute Figur macht.
Machine Learning ist eine Art von Software-Entwicklung, bei der man nicht direkt Code schreibt, sondern ein Modell anhand von Daten trainiert. Das kann in Situationen von Vorteil sein, in denen man keinen passenden Code schreiben kann oder dieser extrem komplex werden würde. TensorFlow ist das bekannteste Framework im Bereich Neuronaler Netzwerke mit dem man solche Modell erzeugen und nutzen kann. TensorFlow.js (https://js.tensorflow.org/api/latest/) implementiert die volle API von TensorFlow mit JavaScript und erlaubt sowohl die Ausführung, als auch das Training von Neuronalen Netzwerken auf jeder GPU.
Im ersten Teil des Workshops werden wir ein Modell zur Bilderkennung in einer grafischen Webanwendung trainieren und in einer eigenen Anwendung zum Laufen bringen. Hier geht es um die Grundlagen von Machine Learning und den Teil der TensorFlow.js API zum Ausführen eines Modells.
Im zweiten Teil werden wir ein eigenes Modell mit der TensorFlow.js API trainieren und als Teil einer JS-Anwendung integrieren.
Es sind keine Vorkenntnisse nötig und zur Teilnahme wird lediglich eine beliebige IDE zur Entwicklung von JavaScript benötigt.
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot: KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern - vorausgesetzt man verfügt über hinreichend viele und qualifizierte Daten.
Aber wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Rolle des KI-Architekten scheint geboren.
Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Software-Entwicklung ergeben können und zeigt dafür passende, pragmatische Lösungsansätze auf.
KI und insbesondere Deep Learning sind der Megatrend. Dank leistungsstarker Frameworks sind erste Schritte schnell gemacht. Leider stößt man aber genauso schnell auch wieder an (seine) Grenzen. Passt das genutzte Modell überhaupt zu meinem Problem? Wie sind die gewonnenen Ergebnisse zu bewerten? Kann durch geschickte Veränderung von Modell-Parametern das Ergebnis weiter verbessert werden? In der Session werden wir unser eigenes Neuronales Netz von Grund auf aufbauen und Schritt für Schritt verbessern. Aber keine Angst: „it’s not rocket science“!
Versteht man seine Anwendung als Kombination (fast) unabhängiger Services, so ergeben sich nicht nur für Entwicklung und Deployment neue Perspektiven.
Denn nicht nur die eigenen Services können internen oder externen Dritten zur Verfügung gestellt werden, sondern auch der umgekehrte Weg ist denkbar.
Eine entsprechend flexible Architektur vorausgesetzt, lässt sich die eigene Fachlichkeit durch 3rd Party Services sinnvoll und gewinnbringend ergänzen, ohne dabei das Rad neu erfinden zu müssen.
Besonders interessant scheint hier das Feld der künstlichen Intelligenz zu sein. Egal ob automatische Texerkennung, Retourenvorhersagen, Qualitätsicherung in der Produktion oder die Vorhersage von Terminen zur Maschinenwartung; die Möglichkeiten scheinen nahezu unbegrenzt.
Die Session zeigt, welche Möglichkeiten heute bereits Out-of-the-Box AI Services bieten und für welche Aufgaben man doch besser einen ML Experten mit ins Boot holen sollte.
In modernen Software-Landschaften werden die Fachlichkeiten mit Hilfe von DDD sauber voneinander abgegrenzt und als eigenständige Services umgesetzt.
Was muss in der Entwicklung eines solchen Services beachtet werden, um diese Eigenständigkeit zu gewährleisten und gleichzeitig sicherzustellen, dass alle Services gemeinsam als ein großes Ganzes funktionieren?
Service-Konsumenten sollen Schnittstellen nach Möglichkeit nutzen können, ohne Aufwand beim Anbieter der Schnittstelle zu verursachen. Das Ziel ist es, Features schnell und unabhängig umsetzen zu können.
In dem Vortrag wird vorgestellt, wie man eine hohe Nutzerzufriedenheit durch Consumer-Centric API Design und regelmäßige Produktiv-Deployments erzielt.
Möglich wird das durch ein sauberes API-Design, eine schlanke Microarchitektur und eine hohe Testautomatisierung. An praktischen Beispielen wird gezeigt, wie das erreicht werden kann.
Java scheint mit seinem Memory- und Runtime-Overhead in Zeiten von Cloud-native und Serverless nicht wirklich gut für die Zukunft gerüstet. Erschwerend kommt hinzu, dass viele auf Java basierende Frameworks mit Annotation Scanning, Aufbau von Proxies und Caches das Start- und Speicherverhalten weiter negativ beeinflussen. Bedeutet das das Aus für Java in der Wunderwelt der Cloud? Mitnichten! Projekte wie Quarkus versuchen, Java in der Cloud zur Numero Uno werden zu lassen. Und das auf beeindruckende Art und Weise. Die Session zeigt anhand praktischer Beispiele, was heute bereits möglich ist.
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?OPEN KNOWLEDGE GmbH
Single-Page-Applications -ursprünglich als kleines fancy Frontend gestartet- sind in den letzten Jahren zu großen, schwergewichtigen eigenen Applikationen angewachsen, die fehleranfällig, schwer wartbar und langsam in der Weiterentwicklung sind. Aber woran liegt das eigentlich? Im Frontend gibt es als Abstraktion zumeist nur das Konzept der Komponenten. Eine tiefergehende Analyse der benötigten Bausteine bleibt in der Regel aus. Im Backend hingegen, erfolgen solche Analysen seit Jahren.
Aber lassen sich die Backend-Architektur-Konzepte ohne weiteres für das Frontend übernehmen? Was sind die Herausforderungen, in denen sich moderne Frontends von klassischen Backends unterscheiden? Wo braucht man daher andere Lösungen? Neben der Problemanalyse gibt dieser Talk konkrete Bausteine an die Hand.
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.
Eine Serverless Function zu schreiben ist denkbar einfach. Und auch die Kombinationen mehrerer FaaS zu einem komplexeren System ist kein Hexenwerk. Was aber, wenn die niedlichen kleinen Funktionen sich zur Laufzeit nicht so verhalten, wie gewünscht? Wie sieht das Monitoring der einzelnen Funktionen und des Systems als Ganzes aus? Und was ist mit Testen? Muss die Funktion dazu immer in der Cloud deployt werden oder kann man das produktive System auch lokal emulieren? Wie wichtig ist der Aspekt der Automatisierung und wie wird diese erreicht? Wie beeinflussen Cold- und Warm-Start das Laufzeitverhalten? Diesen und vielen anderen Herausforderungen wollen wir uns in der Session stellen – Aha-Effekte garantiert!
3. Lars Röwekamp (a.k.a. @mobileLarson)
ÜBER MICH
LR
#WISSENTEILEN
Wer bin ich - und wen ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Author, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast
• mehrfacher Vater, einfacher Ehemann
5. Das kleine REST 1x1
#WISSENTEILEN
REpresentational State Transfer is about ...
• Architectural Design Style
• Client-Server
• Stateless
• Cache
• Uniform Interface
• Layered System
6. Das kleine REST 1x1
#WISSENTEILEN
REpresentational State Transfer
• Identifikation durch URL
• Manipulation durch Representation
• Selbstbeschreibende Messages
• Hypermedia
/orders/123JSON/XML
GET, POST, PUT, DELETE
Media Types, Headers, ...References
7. Das kleine REST 1x1
#WISSENTEILEN
... /orders/ ... /orders/123
Liste aller Bestellungen einzelne Bestellung 123
erzeuge neuen Bestellung ERROR
ändere „Liste“ von
Bestellung
ändere Bestellung 123 sonst ERROR
lösche alle Bestellungen lösche Bestellung 123
Nomen
GET
POST
PUT
DELETE
Single Item URIList URI
Plural
8. Das kleine REST 1x1
#WISSENTEILEN
Golden rules of REST
• „We only need two URLs“
• „Verbs are bad, nouns are good“
• „Plurals are even better“
• „The web is your friend“
• „There is always a root (associations)“
• „There is always a parameter (complex stuff)“
9. Das kleine REST 1x1
#WISSENTEILEN
„There is always a root“
• GET /orders/123/ingredients
• GET /orders/123/ingredients/456
• GET /orders/123/ingredients/milk
• PUT /orders/123/ingredients/milk
• POST /orders/123/ingredients/milk
• DELETE /orders/123/ingredients/milk
10. Das kleine REST 1x1
#WISSENTEILEN
„There is always a parameter“
• Path für Ressource Identifier
• Query für Abfrageparameter, Filter, etc.
• Body für Ressource-spezifische Logik
• Header für globale, plattformweite Parameter
12. Das kleine REST 1x1
#WISSENTEILEN
Headers? Pro Tipp: Use them!
• Version-Header
• Location-Header
• Accept-Header
• Content-Type
• Link-Header
• X-Custom-Header (Override Method, Limit, ...)
13. Das kleine REST 1x1
#WISSENTEILEN
Status Codes? Pro Tipp: Use them!
• 1xx: Hold on ...
• 2xx: Here you go!
• 3xx: Go away!
• 4xx: You f#!?ed up!
• 5xx: I f#!?ed up!
14. Das kleine REST 1x1
#WISSENTEILEN
Status Codes? Pro Tipp: Use them!
• 1xx: Hold on ...
• 2xx: Here you go!
• 3xx: Go away!
• 4xx: You f#!?ed up!
• 5xx: I f#!?ed up!
(http://restlet.com/http-status-codes-map)
15. Das kleine REST 1x1
#WISSENTEILEN
HATEOAS? Pro Tipp: ... WAIT!
• What the heck is Hateoas?
17. #WISSENTEILEN
REST & Hateoas
„If the engine of application state (and
hence the API) is not driven by hypertext,
then it cannot be RESTful and cannot be a
REST API.“
Roy Fielding
19. #WISSENTEILEN
REST & Hateoas
„A REST API should be entered with no
prior knowledge beyond the initial URI ...
From that point on, all application state
transitions must be driven by the client
selection of server-provides choices ...“
Roy Fielding
24. #WISSENTEILEN
REST & Hateoas
// Response with link header for HYPERMEDIA navigation
// after calling „GET .../orders?page=10“
HTTP/1.1. 206 Partial Content
[various other headers]
Link: <.../orders?page=1>; rel=„first“
<.../orders?page=9>; rel=„next“,
<.../orders?page=11>; rel=„prev“,
<.../orders?page=17>; rel=„last“
Wait, does this
make sense?
26. REST & Pagination
#WISSENTEILEN
Wie navigiere ich durch Ressourcen?
• Path Parameter?
• Query Parameter?
• Client Side Calculation?
• Server Side Calculation?
27. #WISSENTEILEN
REST & Pagination
// List page 4 of offers
// Is page a query parameter?
GET /offers?page=4 HTTP/1.1
// Or is page a „virtual“ resource?
GET /offers/page/4 HTTP/1.1
BTW: what does
„page 4“ mean?
28. #WISSENTEILEN
REST & Pagination
// List next 5 offers starting from offer 10
// Or is page x a result of offset and limit?
GET /offers?offset=10&limit=5 HTTP/1.1
// Response with success code and link header for
// navigation purpose
HTTP/1.1. 206 Partial content
Link: <.../orders?offset=0&limit=5>; rel=„first“
<.../orders?offset=5&limit=5>; rel=„prev“,
<.../orders?offset=15&limit=5>; rel=„next“,
<.../orders?offset=40&limit=2>; rel=„last“
BTW: What‘s about
filtering, sorting, ....
30. REST & Queries
#WISSENTEILEN
Was ist eigentlich mit ...
• komplex(er)en Anfragen?
• eingeschränkten Rückgabeobjekten?
• (alternativen) Sortierungen?
• alternativen Rückgabeformat?
Und wie sieht es mit „allgemeiner“ Suche aus?
31. #WISSENTEILEN
REST & Queries
// FILTERING: List of paid orders (2015-12-20)
// Common Style
GET /orders?date=20151220&status=payed HTTP/1.1
[various other headers]
32. #WISSENTEILEN
REST & Queries
// FILTERING: Details of order 3: product, date & status
// Facebook Style
GET /orders/3?fields=product,date,status HTTP/1.1
[various other headers]
GET /orders/3?fields=item.product,date,status HTTP/1.1
[various other headers]
// LinkedIn Style
GET /orders/3:(product, date, status) HTTP/1.1
[various other headers]
33. #WISSENTEILEN
REST & Queries
// FILTERING: Details of order 3
// without date, status
GET /orders/3?exclude=date,status HTTP/1.1
[various other headers]
// predefined payload (compact = product, date, status)
GET /orders/3?style=compact HTTP/1.1
[various other headers]
BTW: what does
„compact“ mean?
34. #WISSENTEILEN
REST & Queries
// FILTERING: Details of order 3
// using PREFER HEADER for response payload definition
GET /orders/3 HTTP/1.1
Content-Type: application/json
Prefer: return=compact-format
HTTP 1.1 200 OK
Content-Type: application/json; charset=utf-8
Preference-Applied: return=compact
35. #WISSENTEILEN
REST & Queries
// SORTING: List of 10 orders sorted by date and item
// SQL Style
GET /orders?sort=date+DESC,item+ASC&count=10 HTTP/1.1
// Sort and asc/desc combination, ascending as default
GET /orders?sort=date,item&desc=date&count=10 HTTP/1.1
// use prefix „-“ for descending, ascending as default
GET /orders?sort=-date,item&count=10 HTTP/1.1
36. #WISSENTEILEN
REST & Queries
// FORMATS: List of orders in alternative format xml
// Google style
GET /orders?alt=xml HTTP/1.1
// Foursquare style (v1)
GET /orders.xml HTTP/1.1
// Digg style
GET /orders?type=xml HTTP/1.1
Accept: application/xml
37. #WISSENTEILEN
REST & Queries
// FULL TEXT SEARCH: Fulltext search for „coffee“
// Global style
GET /search?q=coffee HTTP/1.1
// Scoped style
GET /orders/search?q=coffee HTTP/1.1
GET /orders?q=coffee HTTP/1.1
// Formatted style
GET /search.xml?q=coffee HTTP/1.1
GET /orders/search.xml?q=coffee HTTP/1.1
38. #WISSENTEILEN
REST & Queries
// ADVANCED SEARCH: „coffee with milk for 2 €“
// Query for ...
GET /orders?type=coffee&ingredient=milk&price=2 HTTP/1.1
BTW: AND or OR or
AND/OR?
39. #WISSENTEILEN
REST & Queries
// ADVANCED SEARCH: „coffee WITH milk for LESS THAN 2 €“
// Query for ...
GET /orders?
query=type=coffee+ingredient=milk+price<=2
Build your own
„Query Language“?
42. #WISSENTEILEN
RQL
// ADVANCED SEARCH: „coffee WITH milk for LESS THAN 2 €“
// RQL query ... (must possibly be encoded!)
GET /orders?query=
and(eq(type,coffee),
or(eq(ingredients,MILK),lt(price,2))
// RQL alternative query – FIQL (URI friendly) - ...
GET /orders?query=
type==coff*;(ingredients==MILK,price=lt=2)
49. GraphQL
#WISSENTEILEN
Wer genau ist eigentlich dieser „Luke“ und in
welchen Filmen hat er mitgespielt?
• GET .../film/1
• GET .../film/2
• GET .../film/3
• GET .../people/1/films (if offered via Endpoint)
50. GraphQL
#WISSENTEILEN
Wer genau ist eigentlich dieser „Luke“ und in
welchen Filmen hat er mitgespielt und auf
welchen Schiffen ist er gefahren?
• GET .../starship/12
• GET .../starship/22
• GET .../peolple/1/starship (if offered)
51. GraphQL
#WISSENTEILEN
Wie alt ist Luke und welche Haarfarbe hat er?
Mit welchem “Spruch“ wurden die Filme
eröffnet in denen er mitgespielt hat?
Und wie teuer waren überhaupt die Schiffe auf
denen er gefahren ist?
• GET .../#1?F#CKING/detail (n+1 problem?)
• GET .../#1?F#CKING/all (job problem)
53. GraphQL
#WISSENTEILEN
GraphQL Motivation
„ We see a conflict between the desire to load
all information in a single round trip while
keeping REST resources well isolated.”
(Facebook, 2012)
60. GraphQL
#WISSENTEILEN
Wie alt ist Luke und welche Haarfarbe hat er?
Mit welchem “Spruch“ wurden die Filme
eröffnet in denen er mitgespielt hat?
Und wie teuer waren überhaupt die Schiffe auf
denen er gefahren ist?
62. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
63. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
64. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
65. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
66. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
67. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name=„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
68. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
69. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
70. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
71. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
72. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
73. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
74. #WISSENTEILEN
GraphQL
Wie alt ist Luke und welche
Haarfarbe hat er?
Mit welchem “Spruch“ wurden
die Filme eröffnet in denen er
mitgespielt hat?
Und wie teuer waren
überhaupt die Schiffe auf
denen er gefahren ist?
{
person(name:„Luke“) {
haircolor,
age
films {
name,
openiningCrawl
}
starships {
name,
price
}
}
}
78. GraphQL
#WISSENTEILEN
Woher weiß das Backend was ich will?
• API Schema als gemeinsame Basis
• Query als Anfrage vom Client
• Step 1: parse (Query into AST)
• Step 2: validate (against Schema)
• Step 3: execute (Resolve Functions)
79. #WISSENTEILEN
GraphQL
// A very simple GraphQL schema example
type Character {
name: String! // non nullable
appearsIn: [Episode]! // array of ..., non nullable
}
type Starship {
id: ID! // unique ID
name: String!
length(unit: LengthUnit = METER): Float // parameter
}
83. GraphQL
#WISSENTEILEN
Muss ich das alles selber „bauen“?
• Nein! Es gibt ...
• Clients, Server, DB, Libraries, Tools ...
für Java, JavaScript, Python, Ruby, PHP,
C/C++, GO, Scala, .Net, SQL, ...
> http://graphql.org
> https://github.com/chentsulin/awesome-graphql
84. GraphQL
#WISSENTEILEN
Ist das wirklich so einfach?
• relative neue Technologie (im Fluss)
• Chaching?
• Dupletten?
• Information Hiding?
• Versionierung (vs. deprecated)
91. Sync vs. Async
#WISSENTEILEN
Asyn Kommunikation
• via Messaging und Events
• lose Kopplung durch Queues & Topics
oder durch Event Observer
• ein Sender, 0 is N Receiver
• garantierte Auslieferung möglich
• garantierte Auslieferung erzeugt Overhead
114. Web Sockets
#WISSENTEILEN
Web Sockets 1x1
• Paradigmenwechsel in der Kommunikation
• Abkehr vom klassischen Request/Response
• Client meldet sich am Server an
• Full duplex „real time“ Kommunikation
• Session kann durch beide beendet werden
122. Web Sockets
#WISSENTEILEN
Can i use Web Sockets ... (Server Side)
• Java EE 7
• Spring
• Apache ActiveMQ, Caucho Resin,
Jetty, Netty, vert.x, jWebsocket
and many more ...
(see also https://dzone.com/asset/download/253)