JCON2017-ERSTEKOSTENLOSE 6 KONFERENZFÜRDIEJAVA … · e e!...

www.java-pro.de

ww

w.jcon.o

ne

NEU!

www.jc

on.one

Juni-August 20172 /GRUNDLAGEN •PRAXIS •ARCHITEKTUR •AGILE • INNOVATION

6JCON2017 - ERSTEKOSTENLOSEKONFERENZFÜRDIE JAVA-COMMUNITY 14

EINSTIEG INDIEWELTDERMICROSERVICESMITSPRINGCLOUD

MicroservicesundContainer

24. - 26. Oktober 2017UFA-PALAST inDüsseldorf

Kostenlos für alleMitglieder einer JavaUserGroup !

Neuer Termin:

SERVERLESS - FUNKTIONENOHNESERVERMITAWS-LAMBDA

20

24

33

38

51FAKTORMENSCH ! -WIEDERHOLBAREPROJEKTERFOLGEMITSCRUM

10REACTIVE-WEBSERVICESMIT LAGOM

ww

w.java

-pro

.de

CONTAINERISIERTEANWENDUNGENMITKUBERNETES

PERANHALTERDURCHDENCLOUD-NATIVE-STACK

CONTAINER-ORCHESTRIERUNGMITAPACHEMESOS

ROAVAwww.java-pro.deMagazin für professionelle JavaEntwicklung in der Praxis

3JAVA-PRO.DE 2-2017

#JAVAPRO #Editorial

Microservices und ContainerBest-Practice für Microservices und Container-Orchestrierungssysteme

In der zweiten Ausgabe der JAVAPRO dreht sich alles um Micro-services und Container. Container und moderne Microser-vice-Architekturen sind inzwischen State-of-the-Art. Ihr Einsatz stellt jedoch völlig neue Anforderungen an die IT-Infrastruktur darunter. Sollen Systeme dynamisch skalieren, kommen Cont-ainer-Orchestrierungslösungen wie Kubernetes und Apache Mesos ins Spiel, mit denen sich Container managen, warten, überwachen und ganze Cluster hochverfügbar betreiben lassen. Das in dieser Ausgabe vorgestellte Mesos beispielsweise ist für sehr große Cluster ausgelegt, die aus mehreren tausend Hosts bestehen können.

Der Funktionsumfang moderner Orchestrierungslösungen ist inzwischen gewaltig. Die Möglichkeit, Container und ganze Cluster allein mit einem Skript erzeugen und managen zu können ist schon faszinierend, insbesondere für Java-Entwickler die mit Hardware und IT-Infrastrukturen eigentlich nicht so viel am Hut haben. Der Einstieg in die Cloud- und Containerwelt sollte damit recht einfach gelingen.

Wer den ausfallsicheren Betrieb einer Produktivanwendung und ganzer Cluster sicherstellen möchte, muss sehr viel tiefer in die Materie einsteigen. Nicht ohne Grund sprechen wir von Cont-ainer-Betriebssystemen. DC/OS zum Beispiel setzt sich aus über 30 Open-Source-Projekten zusammen. Den gesamten Funkti-onsumfang von heute auf morgen kennen und nutzen zu können ist utopisch. Cloud-Architekten sollten sich intensiv in die verwen-deten Lösungen einarbeiten und sehr viel experimentieren.

Sebastian DippoldChefredakteurJAVAPRO

Magazin

Verlag:IT Press & Media GmbHMergenthalerallee 73-7565760 EschbornTelefon: +49 (0) 61 96 - 20 48 010Telefax: +49 (0) 61 96 - 20 48 019E-Mail: [email protected]: http://www.java-pro.de

Chefredakteur: Sebastian Dippold (V.i.S.d.P.)

Redaktion:[email protected]

Gestaltung, Layout, Produktion:IT Press & Media GmbHMergenthalerallee 73-7565760 Eschborn

Illustrationen:Pixabay (Public Domain)Erscheinungsweise: Vier mal jährlichGründungsjahr: 2017Preis: kostenfreiDie nächste Ausgabe erscheint am 15. August 2017.

Copyright (c) 2017. IT Press & Media GmbH

Alle Rechte vorbehalten.Java(TM) ist ein eingetragenes Wa-renzeichen der Oracle Corporation.Javapro ist ein unabhängiges Maga-zin und wird nicht von der Oracle Cooperation gesponsert.

Namentlich gekennzeichnete Artikel geben nicht unbedingt die Meinung der Redaktion wieder.

Impressum

Ganz nach dem Motto „Designed to fail“ eignet man sich die nötige Erfahrung an. Ganze Server-Infrastrukturen werden per Skript erzeugt, Container mit Microservices deployt, mit Orche-strierungssystemen überwacht und wenn sich das System nicht optimal verhält, wirft man es einfach weg und baut es neu.

Wer ein Produktivsystem entwickelt, sollte jedoch bereits über die entsprechende Erfahrung verfügen. Unsere Autoren raten dazu, von Anfang an zahlreiche Konzepte zu berücksichtigen und das gesamte System sorgfältig zu planen. Denn spätere Änderungen an einem Produktivsystem, das ist uns aus der Java Entwicklung bestens bekannt, sind erfahrungsgemäß problema-tisch und teuer. Das gilt auch für komplexe Cloud-Infrastrukturen.

In dieser Ausgabe stellen wir populäre Container-Orchestrie-rungssysteme vor und sie erhalten dazu zahlreiche wichtige Tipps und Empfehlungen für die Praxis.

JAVAPRO PARTNER NETWORK

GOLD PARTNER

SILBER PARTNER

Die JAVAPRO wird von den Mitgliedern des JAVAPRO Partner Network finanziert und aktiv unterstützt.

Dadurch sind wir in der Lage, redaktionell unabhängig zu arbeiten und die JAVAPRO

kostenlos für die gesamte Java-Community zu produzieren sowie

die Java Konferenz JCON 2017 zu veranstalten, an der alle Mitglieder einer Java-User-Group

kostenlos teilnehmen können.

Mit freundlicher Unterstützung unserer Partner.

www.java-pro.de/partner

Werden auch Sie Mitglied des JAVAPRO Partner Network und unterstützen Siedie JAVAPRO - Das kostenlose Fachmagazin für die Java Community.

ROAVA

JAVAPRO - Ausgabe 2/2017

4 5JAVA-PRO.DE 2-2017 JAVA-PRO.DE 2-2017

44MOBILE APP DEVELOPMENTSichere Mobile-App-Bereitstellungerfordert PlattformansatzDie Stärken von Mobile-Plattformen bei der Entwicklung und Integ-ration von mobilen Anwendungen in Backend-Systemen.

47AGILEAgilität gestern und heute - NeueHerausforderungen erfordern neues Denken

Warum die Einführung agiler Methoden wie Scrum die gesamte Firmenstruktur und -kultur beeinflusst.

51AGILEFaktor Mensch! - WiederholbareProjekterfolge mit ScrumScrum funktioniert - aber erst, wenn alle Beteiligten die gleiche Vision teilen und die Grundlagen tief verinnerlicht haben.

54REzESSIONENBuchvorstellung: Agile Teamslösungsfokussiert coachen

Agile Arbeitsweisen aus der Sicht eines Coaches.

3MAGAzINEditorial

3MAGAzINImpressum

6MAGAzINJCON 2017 - Erste kostenloseKonferenz für die Java-Community

Endlich eine für alle Mitglieder einer Java-User-Group kostenlose Java-Konferenz.

7MAGAzINJAVAPRO kostenlos -wie geht das?

Kostenloses JAVAPRO Magazin und die für Java-User-Group kosten-lose Konferenz JCON - möglich dank des JAVAPRO-Partner-Network.

inhalt

20CLOUD & CONTAINER

ContainerisierteAnwendungen mit Kubernetes

Von Thomas FrickeKubernetes ist eine von Google entwickelte Open-Sour-ce-Lösung für das automatisierte Deployen, Skalieren und Managen containerisierter Anwendungen über unterschied-liche Cluster und Nodes hinweg und derzeit eines der am schnellsten wachsenden Software-Projekte. Dieser Artikel bietet einen ausführlichen Überblick über Kubernates.

24CLOUD & CONTAINER

Per Anhalter durch denCloud-Native-Stack

Von Mario-Leander ReimerCloud-Größen wie Google, Twitter und Netflix haben die Kern-Bausteine ihrer Infrastruktur quelloffen verfügbar gemacht. Das Resultat aus vielen Jahren Cloud-Erfahrung ist nun frei zugänglich, jeder kann selbst Cloud-Native-An-wendungen entwickeln - Anwendungen, die in der Cloud zuverlässig laufen und fast beliebig skalieren. Die Bausteine wachsen zu einem großen Ganzen zusammen.

10FRAMEWORKSReactive-Webservicesmit Lagom

Alles Nötige in einer Toolbox, Vorauswahl moderner Techniken und in kurzer zeit von null auf hundert.

14FRAMEWORKSEinstieg in die Welt derMicroservices mit Spring CloudSchritt für Schritt vom ersten eigenen Microservice bis zur Produktionsreife.

20CLOUD & CONTAINERContainerisierte Anwendungenmit KubernetesAutomatisiertes Deployen, Skalieren und Managen containerisierter Anwendungen mit Kubernetes.

24CLOUD & CONTAINERPer Anhalter durch denCloud Native StackMit dem Cloud-Native-Stack eigene Cloud-Native-Anwendungen entwickeln, die zuverlässig laufen und fast beliebig skalieren.

33CLOUD & CONTAINERContainer-Orchestrierungmit Apache MesosContainer mit DC/OS auf Basis von Mesos managen, überwachen, Prozesse automatisieren und ganze Cluster ausfallsicher betreiben.

38CLOUD & CONTAINERServerless - Funktionen ohne Servermit AWS LambdaWie man sich mit serverlosen Anwendungen nicht mehr um den Betrieb von Infrastrukturen kümmern muss.

inhalt

33CLOUD & CONTAINER

Container-Orchestrierungmit Apache Mesos

Von Dr. Jörg Schad und Johannes UntersteinsCluster-Infrastrukturen sind heute sehr viel komplexer als noch vor 10 Jahren. Microservices, Container und Big- Data-Anwendungen stellen hohe Anforderungen an die Infrastruktur. Container allein reichen jedoch nicht aus. Mit Container-Orchestrierungs-Systemen wie DC/OS auf Basis von Mesos lassen sich Container managen, überwachen, warten, Prozesse automatisieren und ganze Cluster ausfallsicher betreiben.

38CLOUD & CONTAINER

Serverless - Funktionen ohneServer mit AWS Lambda

Von Frank PientkaNicht nur die Softwareentwicklung, sondern auch der IT-Be-trieb ist einer ständigen Weiterentwicklung unterworfen. Ohne eine Virtualisierung geht nicht nur in Java heute gar nichts. Mit AWS Lambda gibt es jetzt die Möglichkeit der serverlosen Datenverarbeitung, um sich auf die Umsetzung der Anforde-rungen konzentrieren zu können, anstatt sich um den Betrieb von Infrastrukturen kümmern zu müssen.

Cloud-Native Infrastrukturbausteine und Dienste. Im DC/OS-Dashboard laufen alle Informationen zusammen. Lambda in Aktion mit weiteren AWS-Diensten.


Links:Kostenlos für alle Mitglieder einer Java-User-Group

Die gesamte zweitägige JCON-Hauptkonferenz (24. – 25. Okt.) inklusive den parallel stattfindenden Cloud & DevOps Day, Big Data Day, JavaFX Day und Mobile & IoT Day, ist für alle Mitglieder einer Java-User-Group (JUG) völlig kostenlos. Buchen kann man das JUG-Ticket mit einem Buchungs-Code, der bereits an alle offiziellen Java-User- Groups versendet wurde. Insgesamt sind 650 JUG-Tickets verfügbar. Wer Interesse hat, sollte sich in jedem Fall möglichst früh sein Ticket sichern. Für Teilnehmer die nicht Mitglied in einer Java-User-Group sind, kostet das Tages-Ticket zum Frühbucherpreis 199 Euro.

Der dritte Tag, der sich an Software-Architekten, Projektleiter und IT-Entscheider richtet und an dem professionelle Workshops stattfinden, ist für alle Teilnehmer kostenpflichtig und kostet ebenfalls 199 Euro. Damit ist die JCON 2017 auch für Teilnehmer, die nicht Mitglied einer Java-User-Group sind, vergleichsweise sehr günstig. Die Frühbucherpreise gelten noch bis zum 10. August 2017. Für Unternehmen, die fünf Teilnehmer und mehr anmelden möchten, gibt es Sonderkonditionen.

Alle Themen rund um Java

Die JCON-Hauptkonferenz beschäftigt sich mit allen wichtigen Themen, die für die professionelle Entwicklung mit Java wichtig sind. Der Fokus liegt dabei aber klar auf Java Core, Serverside Java und Java Enterprise, Web-Entwicklung sowie Architekturen, insbesondere Microservices. Parallel findet am ersten Konfe-renztag ein spezieller Cloud & DevOps Day und ein Big-Data Day statt. Am zweiten Tag ein JavaFX Day sowie ein Mobile & IoT Day. Am dritten Tag stehen mit dem Architecture Day, dem Agile Day und Workshop Day vor allem Architektur- und Projektmanage-mentthemen auf dem Plan.

Java- und Eclipse-Starter Konferenz

Parallel zur JCON findet die Java- und Eclipse-Starter Konferenz XDEVCON 2017 statt. Die XDEVCON ist seit 7 Jahren die Top-Kon-ferenz für Rapid-Application- und Cross-Platform-Development mit Java und Eclipse. Die XDEVCON richtet sich an Anwender, die möglichst schnell und reibungslos auf Java umsteigen möchten, häufig mit dem ziel wichtige Altanwendungen ablösen und auf Java migrieren zu können. Auf der XDEVCON wird deshalb über-wiegend Java- und Eclipse-Grundlagen-Know-how vermittelt. Die Teilnehmer erfahren, wie man Projekte mit Java und Eclipse startet, wie man HTML5- Anwendungen und Mobile-Apps entwi-ckelt, wie man Hibernate zur Datenbankentwicklung einsetzt, Reports erzeugt und fertige Anwendungen ausliefert oder in der Cloud betreibt. Damit ist die XDEVCON die perfekte Ergän-zung zum JCON-Programm, das sich überwiegend an erfahrene Java-Entwickler und Architekten richtet.

Endlich eine echte Community-Konferenz

Die JCON wurde in enger Abstimmung mit Oracle aus der Taufe gehoben, mit dem ziel eine echte Community-Konferenz als Gegenpol zu den überwiegend kommerziell getriebenen Java-Konferenzen zu schaffen. Sebastian Dippold, Chefredakteur der JAVAPRO: „Es gibt bekanntlich bereits erfolgreiche Java-Kon-ferenzen in Deutschland. Diese haben jedoch das Primärziel vor allem einen glücklich zu machen: den Veranstalter. Teilnah-megebühren jenseits der tausend Euro gelten mittlerweile als normal und werden von größeren Unternehmen auch bezahlt. Die Mehrheit der Java-Community, insbesondere die zahlrei-chen Mitglieder der Java-User-Groups (JUG), wird dadurch aber ausgeschlossen. Für die meisten sind solche Teilnahmegebühren schlicht und einfach zu hoch. Vor allem Mittelständler, die oft nur eine kleine IT-Abteilung besitzen, können aus unserer Erfahrung nur wenig Verständnis dafür aufbringen, warum ihre Entwickler

so teure Konferenzen besuchen sollten. Dabei wäre es gerade für kleinere Unternehmen umso wichtiger, dass ihre Mitarbeiter auf dem neuesten Stand der Entwicklung sind und von neuesten Innovationen und Trends möglichst frühzeitig erfahren. Denn gerade diese Entwickler sind es, die sich hochmotiviert in den Java-User-Groups zusammenschließen, um sich aus eigener Begeisterung für Java in ihrer Freizeit zu treffen und auszutau-schen. Wir sind der Meinung, dass dieses Engagement sehr viel stärker honoriert werden sollte und wir den Java-User-Groups unbedingt den zugang zu topaktuellem Experten Know-how sehr viel leichter machen müssen. Genau das ist das ziel der JCON 2017. Während andere Veranstalter die Java-User-Groups eher als potentielle Umsatzquelle betrachten, werden wir allen Mitgliedern einer Java-User-Group die kostenlose Teilnahme an der JCON 2017 ermöglichen. Das passt exakt zur JAVAPRO-Phi-losophie. Auch beim Java-Hersteller Oracle ist man vom JCON-Konzept begeistert. Deshalb hat Oracle von Anfang an die volle Unterstützung zugesagt. Und auch die Eclipse Foundation steht hinter dem Konzept.“

Wir wollen Code sehen!

Das Interessanteste für Entwickler auf einer Konferenz ist Code. Bei vielen Entwicklerkonferenzen kann man bei Live-Coding- Sessions

jedoch nur zuhören, denn oft ist in der Mitte des Saals auf der viel zu kleinen Leinwand der Code schon nicht mehr lesbar. Genau deshalb findet die JCON 2017 in einem Multiplex-Kino statt, das Platz für bis zu 1.200 Teilnehmer bietet. Auf den Kino-Großlein-wänden kann man selbst in den hintersten Reihen Programm-code noch sehr gut erkennen. Das hat entscheidende Vorteile. Die Teilnehmer bekommen nicht nur mehr mit, sondern bleiben insgesamt aufmerksamer, entspannter und der gesamte Konfe-renzbesuch wird effektiver. Beste Rahmenbedingungen also für eine erfolgreiche Java-Konferenz.

Location Multiplex-Kino

Die JCON 2017 findet im Multiplex-Kino UFA-Palast in Düssel-dorf statt, das sich direkt neben dem Hauptbahnhof befindet und damit hervorragende Anreisemöglichkeiten bietet. In der unmit-telbaren Umgebung befinden sich zahlreiche Hotels, die aktuell noch ausreichend Kapazitäten bieten können.

http://jcon.onehttp://jcon.one/partner.htmlhttp://xdevcon.de

#JAVAPRO #JCON

JCON 2017 - Erste kostenlose Konferenz für die Java CommunityPassend zum kostenlosen JAVAPRO-Magazin findet vom 24. bis 26. Oktober 2017

im Multiplex-Kino UFa-Palast in Düsseldorf die erste große, für die Java-Community

völlig kostenlose Java-Konferenz statt – die JCON 2017. Alle Mitglieder einer Java-

User-Group (JUG) können kostenlos teilnehmen. Insgesamt sind 650 JUG-Tickets

verfügbar. Hauptsponsoren sind Oracle und die Eclipse Foundation.

#JAVAPRO #PartnerNetwork

JAVAPRO kostenlos –wie geht das? Die JAVAPRO wird von den Mitgliedern des JAVAPRO-Partner-Network finanziert

und aktiv unterstützt. Dadurch ist es möglich, die JAVAPRO als redaktionell unab-

hängiges Magazin zu produzieren und der gesamten Java-Community kostenlos zur

Verfügung zu stellen - sowie mit der JCON 2017 eine Java Konferenz zu veranstalten,

an der alle Mitglieder einer Java-User-Group (JUG) kostenlos teilnehmen können.

Magazin Magazin


Links:

Dass Software als Open-Source und damit völlig lizenzkosten-frei verfügbar ist, ist für Entwickler mittlerweile das normalste der Welt. Niemand hinterfragt heutzutage mehr, wie das möglich ist, wer die Entwicklung finanziert und welche Motive Contributors damit verfolgen. Dass ein Fachmagazin für Java (JAVAPRO) völlig kostenlos erhältlich sein kann, sorgt dagegen bei vielen Entwick-lern für große Verwunderung. Fast alle, mit denen wir uns auf den vergangenen Konferenzen darüber unterhalten haben, waren erstaunt.

Dabei funktioniert die JAVAPRO nach demselben Prinzip wie ein Open-Source-Projekt. „Contributor“ bedeutet Mitwirkender, Beiträger, aber auch Spender. Auch die Partner des JAVAPRO-Part-ner-Network sind Contributers, die das JAVAPRO-Projekt - ein freies Fachmagazin für die Java Community sowie eine Java Konferenz, an der alle Mitglieder einer Java-User-Group kostenlos teilnehmen können - finanziell, mit Ressourcen, Manpower oder ihrem eigenen Netzwerk unterstützen.

In dieser Rubrik stellen wir regelmäßig Partner des JAVAPRO-Part-ner-Network vor.

Oracle

Oracle bietet Produkte für alle Bereiche der IT in Unternehmen jeglicher Branchen: Applikationen, Plattform und Infrastruktur. Dies umfasst die Oracle Datenbank, Middleware, Applikationen und Hardware (Oracle-Engineered-Systems, Server, Storage, Netzwerkkomponenten und industriespezifische Produkte). Dazu Support und Services.

Als einziges Unternehmen bietet Oracle auch ein volles Spek-trum an Cloud-Angeboten: Software-as-a-Service (SaaS), Plat-form-as-a-Service (PaaS) und Infrastructure-as-a-Service (IaaS). Diese integrierten Cloud-Angebote ermöglichen es Kunden ihre Innovationszyklen zu minimieren, da sie leicht zu verwalten und schnell zu integrieren sind. Dadurch wird zeit- und kostenaufwän-diges Testen vermieden. Weiterhin können Aufgaben zwischen On-Premise-IT-Umgebungen und der Oracle-Cloud verschoben werden - sicher und zuverlässig. Neben den reinen Cloud-Ange-boten können Kunden ein hybrides IT-Modell einsetzen, bei dem einzelne IT-Resourcen in der Oracle-Cloud laufen und andere im eigenen Rechenzentrum. Dabei können beide als eine Umge-bung verwaltet werden. Einzigartig ist das Konzept „Cloud at Customer“, bei dem Kunden bestimmte Oracle-Cloud-PaaS und -IaaS Angebote im eigenen Rechenzentrum nutzen können um Aspekte wie firmen- oder länderspezifische Vorgaben zu erfüllen. zum Einsatz kommt dabei die Oracle Cloud-Machine. Kunden erhalten damit die gleiche Software, Services, Funktionalität und Bedienungsfreundlichkeit wie in der Oracle-Public-Cloud. Inklu-sive Abrechnungsmodell.

Oracle Produkte werden von Ingenieuren und Entwicklern von Beginn an so entwickelt, dass sie für die unterschiedlichen

Nutzungsmodelle geeignet sind. Flexibilität, Anwenderfreund-lichkeit, nahtlose Kompatibilität, Erweiterbarkeit und Agilität stehen im Vordergrund.

Java ist die weltweite Nummer 1 bei den Programmiersprachen. Java kann Kosten senken, Innovation vorantreiben und Anwen-dungsservices verbessern, und zwar als Programmiersprache nach Wahl für das Internet der Dinge (IoT), Unternehmensarchi-tektur und Cloud-Computing.

Peakwork AG

Die 2009 gegründete Peakwork AG ist der Software-Spezialist für die Reiseindustrie. Mit der weltweit einzigartigen Player- Hub-Technologie hat Peakwork ein dynamisches Produktions- und Vertriebsnetzwerk für die Touristik geschaffen, das globales Angebot und Nachfrage verbindet.

Führende internationale Reiseveranstalter und Leistungsträger setzen bei der dynamischen Reiseproduktion auf die Peakwork Lösungen für Dynamic Packaging mit Anbindung an welt-weite Hotel- und Flug-Anbieter. Der flexibel und international skalierbare Reisevertrieb ist für massiven Traffic konzipiert und profitiert insbesondere durch die Anbindung an die globalen Metasearcher.

Die Player-Hub-Technologie ist in ca. 30 Märkten weltweit erfolg-reich im Einsatz. Peakwork beschäftigt rund 200 Mitarbeiter an sieben Standorten in Deutschland, Großbritannien, Spanien, USA und Singapur.

XDEV Software Corp.

Die XDEV Software Corp. ist Mitglied der Eclipse Foundation, Hersteller der freien Eclipse Distribution RapidClipse sowie der neuen Java-In-Memory-Datenbank Jetstream.

RapidClipse ist eine freie Eclipse-Distribution, die bereits alle für Java wichtigen Plugins enthält, Eclipse an vielen Stellen verbes-sert und mit zahlreichen Tools erweitert. Dazu zählen u.a. ein professioneller GUI-Builder auf Basis von Vaadin, mit dem sich HTML5-Oberflächen grafisch designen lassen sowie die für JPA-Entwickler stark verbesserten Hibernate-Tools. RapidClipse ermöglicht Cross-Platform-Development. Jedes Projekt lässt sich aus ein- und derselben Code-Base heraus als HTML5-Web-An-wendung, Mobile-App für Android und iOS sowie als klassische Java-Desktop-Applikation deployen. RapidClipse ist über den Eclipse-Marketplace oder direkt unter www.rapidclipse.com zum freien Download verfügbar.

Jetstream ist eine Java In-Memory-Datenbank, die für Microser-vice-Architekturen entwickelt wurde. Anstatt Tabellen werden Entity-Klassen direkt als Datenmodell verwendet. zur Lauf-zeit ermöglicht Jetstream den gesamten Entity-Graphen zu

persistieren. Vorteil: Kein OR-Mapping, JPA-Komplexität entfällt, kein zweites Datenmodell, kein Netzwerkflaschenhals, keine zusätzliche Abfragesprache. Die Daten befinden sich im RAM und zugriffe darauf erfolgen direkt in Java, je nach Anwendungs-fall zehn bis tausend Mal schneller im Vergleich zu RDBMS. Benö-tigte Daten werden automatisch lazy nachgeladen. Jetstream selbst ist winzig und lässt sich nahtlos in jede Java Anwendung einbinden. Dadurch ist Jetstream prädestiniert für den Einsatz als leichtgewichtige Storage-Engine in Microservices.

XDEV ist nicht nur Tool-Hersteller, sondern auch Software-Dienst-leister. Als Java-IDE- und Datenbank-Hersteller verfügt XDEV über enormes Java- und Datenbank-Know-how. zudem entwi-ckelt XDEV für europäische Kunden ausschließlich in Deutsch-land. Deshalb ist XDEV für viele Kunden Entwicklungspartner Nummer eins, wenn es um die Realisierung von Individualsoft-ware auf Basis von Java oder um Migrationsprojekte geht.

BOS-it GmbH und Co.KG

Die BOS-it GmbH und Co.KG ist ein Schulungsspezialist mit Hauptsitz in Hamburg und einer zweigstelle in Berlin. BOS-it führt vorwiegend Kurse für Hersteller wie Oracle, VMWare, Microsoft, Nexenta oder Citrix durch. Mit der Gründung im Jahr 2000 stand die Ausbildung von Solaris-Systemadministratoren im Geschäftsmittelpunkt, der sich mit der Erfolgsgeschichte von Java auf die Ausbildung von Entwicklern erweitert hat.

Die BOS-it ist heute nicht nur „Oracle Authorized Oracle Reseller“ in Deutschland, Großbritannien, Belgien und den Niederlanden, sondern betreibt an beiden Standorten auch das jeweilige „Oracle Approved Oracle Education Center“ für Solaris, Java und MySQL. Hier erhalten die Kunden die Ausbildung direkt aus erster Hand vom Hersteller, vom Einsteiger, über den Profi bis hin zum Architekten. Die Teilnehmer werden individuell beraten, um den Bedarf sowie den richtigen Ausbildungspfad zu ermit-teln. Anschließend werden sie von echten Profis gezielt für ihre späteren Tätigkeiten ausgebildet. Auch Herstellerzertifizierungen sind Teil des Portfolios. Diese besondere, individuelle Betreuung von Kunden, ist sicher einer der Gründe für den Erfolg der BOS-it und die hohe Anzahl von Stammkunden im Ausbildungsbereich.

Neben Oracle-Standardschulungen ergänzen speziell entwi-ckelte Firmenschulungen das Kerngeschäft der BOS-it. Diese werden wahlweise bei BOS-it oder beim Kunden vor Ort durch-geführt. Dafür stellt BOS-it bei Bedarf auch die nötige technische Infrastruktur zur Verfügung.

zusätzlich zum klassischen Schulungsgeschäft sind in den letzten zwölf Jahren auch die Geschäftsbereiche Consulting und Entwick-lung stark gewachsen und gehören heute zu den tragenden Säulen der Firma. Jeder Trainer ist zugleich auch Berater und kann für Projekte engagiert werden.

Alles in allem steht die BOS-it in allen drei Geschäftsbereichen für Professionalität, Individualität und Integrität.

Quality First Software GmbH (QFS)

QFS ist ein deutscher Software-Hersteller mit Hauptsitz im Münchener Süden mit großer Expertise auf dem Gebiet der Qualitätssicherung. Die Firma und ihr Hauptprodukt QF-Test sind seit über 15 Jahren im Markt fest etabliert. QF-Test war das erste professionelle Werkzeug zur Testautomatisierung von Applikationen mit Java-Swing Oberfläche. Inzwischen haben sich Funktionsumfang und Technologien des Test-Tools kontinuierlich und kundennah weiterentwickelt. Heute umfasst QF-Test neben System- und Lasttests für Java/Swing die Unterstützung von Eclipse/SWT/RCP-Anwendungen und das browserübergreifende Web-Testen inklusive AJAX sowie ab QF-Test 4.0 auch JavaFX.

Mehr als 1.000 Kunden in über 50 Ländern, verteilt über alle Bran-chen und Firmengrößen, vertrauen QF-Test - von kleinen, mittel-ständischen Unternehmen bis hin zu HP, Audi, EADS sowie akade-mischen und öffentlichen Institutionen. Sie schätzen vor allem die leichte zugänglichkeit des Produkts für Tester wie Entwickler, die Stabilität und Flexibilität des Produkts, den schnellen, kompe-tenten Support und den individuellen und zuvorkommenden Service.

QFS selbst legt höchsten Wert auf Qualität: hinsichtlich des eigenen Produkts QF-Test, der Arbeits- und Lebensqualität der Mitarbeiter - vor allem aber in Bezug auf eine persönliche, vertrauensvolle und beständige Beziehung mit den Kunden. QF-Test auf einen Blick:

• Volle Unterstützung von Java (Swing, FX, Eclipse/SWT/RCP),HTML und AJAX, direkter zugriff auf Java undBrowser-DOM, Groovy & Jython integriert.

• Abstraktion komplexer GUI-Komponenten und -Hierarchien, generische Komponenten: Keine Einzelpflege bei Änderungen. Mit Unit-Tests kombinierbar (über Jenkins und andere Continuous- Integration-Tools).

• Benutzerfreundlich für schnellen Einstieg, robuste Tests mit zuverlässiger Wiedererkennung für geringen Wartungsaufwand.

• Modularisierung erlaubt die Gliederung und Vereinfachungumfangreicher Tests.

• Schneller und kompetenter Support direkt vom Hersteller.

www.oracle.com/dewww.xdev-software.comwww.peakwork.comwww.bos-it.dewww.qfs.de

Magazin Magazin


#JAVAPRO #Reactive #Webservices #Lagom

Reactive-Webservicesmit LagomBei Bibliotheken und Frameworks für Microservices gibt es inzwischen eine recht

stattliche Auswahl. Lagom möchte Entwicklern eine weitere Variante bieten: Alles

Nötige in einer Toolbox, eine Vorauswahl moderner Techniken und Ansätze sowie

eine möglichst kurze Zeit von null auf hundert bei der Entwicklung.

Autor:

Dr. Stefan Schlott ist Advisory Consultant bei der Firma BeOne Stuttgart GmbH und dort als Entwickler, Archi-tekt und Trainer im Java-Umfeld tätig. Security und Privacy gehören ebenso zu seinen Schwerpunkten wie skalierbare Architekturen und das breite Feld der verschiedenen Webtechnologien.

Einmal jährlich ist er zusätzlich als Dozent bei der Dualen Hochschule Baden-Württemberg aktiv.

Reactive mit Java

Die Macher von Lagom haben in das Framework all das zusammengetragen, was ihrer Meinung nach für den Bau von modernen, verteilten Architekturen nötig ist - quasi als Servier-vorschlag, aber ohne dem Nutzer die Möglichkeit zu nehmen, auf andere Techniken auszuweichen und möglichst ohne ihm unnötige Einschränkungen aufzuerlegen. Diese Idee ist auch Urpsrung des Namens: Das schwedische Wort Lagom bedeutet grob übersetzt: „nicht zu viel, aber auch nicht zu wenig“. Lagom wurde entlang der Ideen des Reactive-Programming-Para-digmas entworfen, was insbesondere bedeutet, dass quasi alle Aufrufe asynchron ablaufen und der eigene Code mit dieser

FRAMEwORKs FRAMEwORKs

Asynchronität umgehen muss. Wer also bisher noch keine Berührpunkte mit der CompletionStage von Java 8 hatte, hat hier ausgiebig Gelegenheit sie kennen zu lernen.

Apropos Java 8: Auch wenn der Unterbau von Lagom zu großen Teilen in Scala geschrieben ist (und die Firma Lightbend, die hinter Lagom steht, einen Schwerpunkt auf Scala legt), bietet Lagom zunächst nur eine Java-API. Erst mit Version 1.3 ist auch eine Scala-API nachgekommen. Die Unterschiede der beiden APIs sind so gestaltet, dass sie die Sprachgegebenheiten und die Sprachkultur berücksichtigen. Man fühlt sich in beiden Sprach-welten zu Hause.

Die Java-API macht ausgiebig von den Sprach- und Biblio-theks-Features von Java 8 gebrauch. zielgruppe sind momentan ganz klar Java-Entwickler, die entweder eine neue Anwendung auf einem State-of-the-Art Technik-Stack aufsetzen wollen oder einen bestehenden Monolithen Schritt für Schritt refactorn wollen.

Start!

Ein neues Lagom-Projekt setzt man am einfachsten mit Hilfe des Project-Starters auf: Auf der Seite http://developer.lightbend.com/start/ lässt man sich ein Lagom-Projekt mit den gewünschten Package-Namen generieren. Das Template für Scala benutzt (wie für Scala üblich) sbt als Build-System, beim Java-Template kommt Maven zum Einsatz.

Die Frage nach dem Build-System geht hier tatsächlich über eine reine Geschmacksentscheidung hinaus: Vieles von der „Magie“ von Lagom ist durch Plugins in das Build-System realisiert, sie machen hier weit mehr aus als nur das Herunterladen von Abhängigkeiten und Setzen eines geeigneten Classpaths. Dies wird schnell klar, wenn wir die neu erzeugte Anwendung mittels mvn lagom:runAll starten: Das Kommando startet sämtliche Microservices der Anwendung und zusätzlich Testinstanzen benötigter Dienste, per Default Cassandra und Kafka sowie eine Service-Discovery und ein Eingangs-Gateway, welches Anfragen auf die einzelnen Microservices weiterleitet. Außerdem sorgt das Build-System dafür, dass bei Code-Änderungen die betroffenen Microservices automatisch übersetzt und neu gestartet werden. Dieses Feature erlaubt äußerst bequemes Entwickeln und Testen - jede Codeänderung ist sofort nach einem Reload sichtbar.

Interface und Implementierung

Importiert man das Projekt-Gerüst in seine IDE, sieht man eine Reihe von Unterprojekten: Jeder Microservice in Lagom besteht nämlich aus zwei Teilprojekten, einem Interface-Teil und einer Implementierung. Der Interface-Teil definiert die Schnittstelle zu einem Microservice. Hierzu schreibt man ein Interface zum Service inklusive der notwendigen Transfer-Objekte. Für einen Konsumenten des Service bringt das den Vorteil, bereits zur

Compile-zeit über Fehler informiert zu werden, die durch Ände-rung an der Schnittstelle entstehen. Natürlich wird es dadurch nötig, dass Server und Konsumenten eine gemeinsame Abhän-gigkeit auf das Interface-Projekt haben, was zunächst wie eine enge Kopplung der Projekte aussieht - ein Umstand, den man mit Microservices eigentlich unbedingt vermeiden will. Das Inter-face-Projekt sollte jedoch keinerlei Logik enthalten und ist letzt-lich nicht mehr als eine in Code gegossene Interface-Definition - API und Datenformate sind ohnehin implizite Abhängigkeiten, die immer vorhanden sind.

Das Interface-Projekt bietet dafür noch viele weitere Möglich-keiten zur Beschreibung der Schnittstelle, beispielsweise die Möglichkeit, die „Wire Representation“ zu definieren. Der Default für Lagom ist es, Nachrichten als JSON-Objekte zu übermitteln. Doch man ist nicht auf JSON festgelegt: Durch einen MessageSe-rializer können beispielsweise pro Service oder pro Objekttyp andere Repräsentationen implementiert werden. Auch Cont-ent-Negotiation ist möglich. Weiterhin ist ein Konzept zur Ver- sionierung von Services vorgesehen.

Sehen wir uns das Interface-Projekt helloworld-api näher an - hier eine vereinfachte Variante des generierten Projekts. zent-rales Interface ist HelloService:

(Listing 1) – HelloService.java

public interface HelloService extends Service { ServiceCall<NotUsed, String> hello(String id);

@Override default Descriptor descriptor() { return named(„hello“).withCalls( pathCall(„/api/hello/:id“, this::hello) ).withAutoAcl(true); }}

Jede Funktion des Microservices ist eine Methode mit einem Rückgabewert vom Typ ServiceCall. Die Abbildung auf URL-Endpunkte erfolgt in der Default-Implementierung von descriptor(), Parameter der Methoden werden in der URL mit Doppelpunkt-Platzhaltern notiert. Auch der Name des Service (helloservice) für die Service-Discovery wird hier festge-legt. Per Default sind die Service-Endpunkte von außen nicht erreichbar; der Methodenaufruf withAutoAcl(true) erlaubt einen zugriff auf alle definierten URLs.

Die beiden Typ-Parameter von ServiceCall geben den Eingabe- und Ausgabedatentyp an: Hier können entweder Basistypen wie String verwendet werden oder aber komplexere, passend seri-alisierbare Datentypen (im Beispiel GreetingMessage). Werden keine Daten erwartet bzw. zurückgegeben, kommt der spezielle Typ NotUsed quasi als Platzhalter zum Einsatz. Im Implementie-rungsprojekt des Microservices wird das eben definierte Inter-face implementiert:


(Listing 2) – HelloServiceImpl.java

public class HelloServiceImpl implements HelloService { @Override public ServiceCall<NotUsed, String> hello(String id) { return request -> return CompletableFuture.completedFuture(„Hello, „ + id); }}

Jede Methode führt die tatsächliche Implementierung nicht direkt aus, sondern liefert quasi ein „Kochrezept“ hierfür: Der Rückgabewert ServiceCall ist nämlich nichts anderes als ein Lambda, welches von der Eingabe (vom Typ des ersten Typpa-rameters) auf eine CompletionStage des zweiten Typparameters abbildet. Die gesamte Verarbeitung erfolgt also asynchron. In unserem simplen Beispiel wird direkt ein erfülltes Future zurück-geliefert. Komplexere Abläufe, in denen auf Rückgabewerte anderer asynchroner Funktionen gewartet wird, werden mit den verschiedenen then Methoden der CompletionStage verkettet. Diese Folgen von .thenApplyAsync mögen am Anfang etwas ungewohnt scheinen, durch die Gleichmäßigkeit der Struktur bleibt der Code aber gut lesbar. Nun muss unsere Service-Imple-mentierung noch registriert werden. Dies geschieht durch in der Implementierung einer Modul-Klasse:

(Listing 3)

public class HelloModule extends AbstractModule implements ServiceGuiceSupport { @Override protectedvoidconfigure(){ bindService(HelloService.class, HelloServiceImpl.class); }}

Sollte dieses Projekt mehrere Interfaces implementieren, können diese natürlich hier ebenfalls registriert werden. zuletzt muss dieses Modul noch in der Konfigurationsdatei applications.conf registriert werden:

(Listing 4)

play.modules.enabled += sample.helloworld.impl.HelloServiceModule

Wer bei der Struktur des Projekts und beim obigen Kürzel an das Play-Framework denkt, liegt richtig: Das Web-Anwendungs-Fra-mework Play bildet zusammen mit der Aktorenbibliothek Akka einen robusten und erprobten Unterbau für Lagom.

Einen Service konsumieren

Nehmen wir an, wir wollen den eben beschriebenen Service in einem zweiten Microservice verwenden. Wir erstellen hierfür

zwei neue Subprojekte greetingapi und greeting-impl; in der Implementierung wollen wir den helloService verwenden, daher fügen wir dessen API zu den Paketabhängigkeiten hinzu:

(Listing 5) – pom.xml

<dependency> <groupId>${project.groupId}</groupId> <artifactId>hello-api</artifactId> <version>${project.version}</version></dependency>

Erstellen wir ein einfaches Interface:

(Listing 6) – GreetingService.java

public interface GreetingService extends Service { ServiceCall<GreetingData, String> greet();

@Override default Descriptor descriptor() { return named(„greeting“).withCalls( Service.restCall(Method.POST, „/api/greet“, this::greet) ).withAutoAcl(true); }}

Hier kommt für die Parameter ein Nicht-Standard-Datentyp GreetingData zum Einsatz, den wir ebenfalls im Interface-Pro-jekt definieren:

(Listing 7) – GreetingData.java

@Immutable @JsonDeserializepublicfinalclassGreetingData{ publicfinalStringname; publicfinalStringmessage;

@JsonCreator public GreetingData(String name, String message) { this.name = Preconditions.checkNotNull(name, „name“); this.message = Preconditions.checkNotNull(message, „message“); }}

Die resultierende Klasse besitzt unveränderliche Members sowie alles, was für eine Wandlung nach JSON (und zurück) nötig ist. Nun zum eigentlich spannenden Teil, der Implementierung des Service:

(Listing 8) – GreetingServiceImpl.java

public class GreetingServiceImpl implements GreetingService { finalHelloServicehelloService;

@Inject

FRAMEwORKs

public GreetingServiceImpl(HelloService helloService) { this.helloService = helloService; }

@Override public ServiceCall<GreetingData, String> greet() { return (greetingData) -> helloService.hello(greetingData.name).invoke() .thenApply(greeting -> greeting + „\n“ + greetingData.message + „\n“); }}

Unser Service möchte den HelloService verwenden, daher lassen wir uns diesen per Dependency-Injection in unsere Klasse reichen. Unter der Haube steckt als Implementierung die Service-Discovery, der zugriff übers Netz, die Abbildung auf URLs, die Serialisierung und Deserialisierung sowie weitere Logik wie das Cirucit-Breaker-Pattern. Letzteres sorgt dafür, dass für den Fall, dass der Dienst nur langsam oder gar nicht reagiert, keine weiteren Anfragen gestellt werden, sondern direkt lokal mit einem Fehler quittiert werden, bis sich der Dienst erholt hat.

Mit helloService.hello(greetingData.name).invoke() wird unser helloService aufgerufen. Da sämtliche I/O-Vor-gänge asynchron bearbeitet werden, ist der Rückgabewert nicht direkt das Ergebnis, sondern ein Future hierfür. Um unser gewünschtes Ergebnis zusammenzubauen, muss auf das Future eine weitere Aktion folgen, welche ausgeführt wird, sobald das Future des Microservice-Aufrufs erfüllt ist - dies erledigen wir mittels thenApply. Voilà! Wir haben unseren ersten Microservice benutzt!

Bleibt nur noch die Implementierung des Moduls und dessen Angabe in der Konfigurationsdatei applications.conf wie im ersten Service. Im Modul wird einerseits unser neuer Service (wie bereits gesehen) registriert; ausserdem muss der helloService als Microservice-Client gebunden werden:

(Listing 9) – GreetingServiceModule.java

public class GreetingModule extends AbstractModule implementsServiceGuiceSupport { @Override protectedvoidconfigure(){ bindClient(HelloService.class); bindServices(serviceBinding(GreetingService.class, GreetingServiceImpl.class)); }}

Falls das Kommando mvn lagom:runAll weiter im Hintergrund lief, konnten wir schön beobachten, wie nach jeder Code-Ände-rung ein entsprechender Reload stattfand: Unsere Änderungen waren unmittelbar testbar. Nun können wir unseren Gree-ting-Service ausprobieren:

(Listing 10)

$ curl -H „Content-Type: application/json“ -X POST -d ‚{„name“:“world“, „message“:“Have fun with Lagom!“}‘ http://localhost:9000/api/greet

Hello, worldHave fun with Lagom!

Erst der Anfang!

Die Kapselung von Services in Interfaces erleichtert das Erstellen von Microservices erheblich - es abstrahiert weg von der „Leitungskommunikation“, ermöglicht eine komplett asynchrone Verarbeitung und bietet passende Werkzeuge für das Behandeln von Fehlersituationen.

Der Werkzeugkasten von Lagom bietet aber noch weitaus mehr: Dienste können nicht nur nach dem Request-Reply-Prinzip antworten, es gibt auch die Möglichkeit, Datenströme als Antwort zu modellieren. Für die Verarbeitung von Daten nach der CQRS-Idee (Command Query Responsibility Segregation) gibt es Bibliotheksfunktionen und eine Standardimplementie-rung, welche die Daten in Cassandra speichert. Werden mehrere Instanzen eines Microservices gestartet, so bilden diese auto-matisch einen Cluster, in welchem die Verarbeitung der eigenen CQRS-Nachrichten verteilt werden.

Lagom bietet auch eine Message-Broker-API, um das Verteilen von Benachrichtigungen an andere Services mittels einer persis-tenten Nachrichten-Queue zu ermöglichen. Als Standard kommt hier Kafka zum Einsatz. Die Verwendung eines Message-Brokers geht Hand in Hand mit dem CQRS-Ansatz. Gemeinsam lassen sich sehr robuste Anwendungen erstellen.

zu guter Letzt ist auch die Service-Discovery ein modularer Bestandteil. Standardimplementierungen sind für eine statische Konfiguration sowie für Lightbends Produkt Conductr verfügbar. Implementierungen für beispielsweise zookeeper oder Consul sind jedoch in der Community bereits in Arbeit.

Fazit:

Alles in allem hat Lagom das zeug, Entwicklern an vielen Stellen begeisterte „Ja, genau so!“-Ausrufe zu entlocken und das Erstellen von microservicebasierten Anwendungen zu erleichtern. Sehr reizvoll ist die Tatsache, dass die verschiedenen Konzepte wie asynchroner Service-zugriff, CQRS oder Messaging hinter generischen APIs stecken, hinter denen die spezifischen zugriffe auf die im Einzelfall gewünschten Services stecken. Sie sind eine schöne Abstraktion für alle Werkzeuge die man benötigt, um Reactive-Microservices zu bauen.

FRAMEwORKs


#JAVAPRO #Microservices #Spring

Einstieg in die Welt derMicroservices mit Spring CloudMit Hilfe von spring Initializr, einem Online-Generator zum Erzeugen von

service-Hüllen auf Basis des Micro-Frameworks spring Boot, und den zahlreichen

spring-Guides ist ein erster eigener Microservice schnell erzeugt. Doch wie geht es

weiter? Dieser Artikel beschreibt verschiedene Komponenten, mit deren Hilfe man

schritt für schritt der Produktionsreife näher kommt.

Autor:

Max Wenzel arbeitet als freiberuflicher Softwareent-wickler und -architekt. Er unterstützt seine Kunden in den Bereichen Microservices und Big Data. Sein neuestes Steckenpferd sind die Themen Machine Learning und Künstliche Intelligenz. Wenn er nicht gerade beim Kunden vor Ort ist, findet man ihn auf Entwicklerkonferenzen oder einem Meetup – immer in dem Bemühen, sein Fachwissen auf aktuellem Stand zu halten und sich mit anderen Entwicklern auszutauschen.

ist, dass alle Einstellungsmöglichkeiten der Clients von Anfang an zentral in einer Versionsverwaltung vorgehalten werden. Nun genügt es den Clients mitzuteilen, unter welcher Adresse sie den Config-Server erreichen. Per Default fragen die Services diesen nur beim Start an. Eine Abfrage in Intervallen nach etwaigen Konfigurationsänderungen ist aber ebenso möglich.

Eureka

Damit die Services sich gegenseitig finden, wird eine zentrale Registrierung benötigt, bei der die Instanzen sich anmelden. Heureka kommt aus dem Altgriechischen und heißt so viel wie „Ich habe es gefunden“. Die Service-Discovery Eureka wurde, wie etliche andere Module in diesem Umfeld, ursprünglich von Netflix entwickelt. Der Filme-Anbieter gilt mit seiner Stre-aming-Plattform als einer der Pioniere im Bereich der Micro-services und hat zahlreiche seiner intern entwickelten Projekte inzwischen als Open-Source zur Verfügung gestellt. Ein Eure-ka-Server ist schnell aufgesetzt. Dem Client muss man nur noch mitteilen, wo er die zentralinstanz findet. Registriert er sich bei Eureka, übermittelt er Informationen über die Adresse unter der erreichbar ist, seine Startseite sowie eine Health-URL. Im Standard nutzt Eureka einen Heartbeat des Clients, um zu entscheiden ob dieser aktiv ist. Default sind hier 30 Sekunden. Der Client kann aber leicht auch so konfiguriert werden, dass er über die Health-check-URL detaillierte Informationen zu seinem momentanen Status liefert. Aktuell liegt Eureka noch in der Version 1.0 vor. Für die kommende Version sind etliche Verbesserungen vorgesehen.

in einzelner Service lässt sich leicht manuell konfigurieren: Typischerweise Datenbankverbindung, Verbindung zum

Message-Broker, Security-Credentials etc. Doch was, wenn sich die Datenbankverbindung ändert und diese Information in vielen Services auf unterschiedlichen Umgebungen landen muss? Alle einzeln anzupassen und dann wieder zu deployen ist fehleran-fällig und zeitintensiv.

Hilfe bietet hier das Projekt Spring Cloud Config. Es bietet server- und clientseitige Unterstützung, um die notwendige Service-Kon-figuration zu externalisieren. Der Konfigurations-Server muss dabei nur wissen, wo er die Client-Parameter finden kann. Es existieren verschiedene Möglichkeiten, diese zu hinterlegen. Im Standard gibt man dem Server ein Git-Repository mit, welches sich auch lokal auf der Festplatte befinden kann. Vorteil dabei

E

FRAMEwORKs

So erhält momentan noch jeder Client alle Informationen, die der zentralinstanz vorliegen. Da im Normalfall nur eine Teilmenge benötigt wird, soll es dem Client künftig möglich sein, dem Server mitzuteilen welche Informationen er benötigt. So erhält er zum Beispiel nur die Adresse eines bestimmten Webservices. Des Weiteren pullen aktuell die Clients Eureka, um sich über Updates zu informieren. In der neuen Version pusht der Server diese Informationen. Verbesserungen sind außerdem im Bereich der Replikation und der Auto-Skalierbarkeit vorgesehen. Und: Ist das aktuelle Dashboard noch eher rudimentär, soll dann auch die Einsicht in etliche zusatzinformationen möglich sein. Beispiels-weise können über ein Audit-Log alle Änderungen an der Regis-trierung eingesehen werden.

Hystrix

Circuit Breaker gehören zu den sogenannten Stabili-tätsmustern, das dazu dient, wiederkehrende Verbindungs-fehler zu einer Ressource aufzuspüren und den zugriff darauf für eine bestimmte zeit zu blockieren. Nachzulesen in dem sehr empfehlenswerten Buch „Release It!“. Hystrix ist eine Gattung der Stachel-schweine - sowie der Name der Netflix-Bibliothek, die das Circuit-Breaker-Muster implemen-tiert. Das Framework dient dazu, Services in verteilten Systemen vor Ausfällen externer Abhängigkeiten zu schützen bzw. solche Probleme besser zu kontrollieren und zu monitoren. Kaska-dierende Fehler (wie bei einem Dominoeffekt führt der Ausfall eines Dienstes zum Ausfall weiterer Dienste) werden vermieden. Beantwortet ein externes System innerhalb eines konfigurier-baren zeitfensters zu viele Anfragen nicht oder nur mit einem Fehlerstatus, so werden die Anfragen an dieses System langsam zurückgefahren. Nun können zum Bespiel aufgestaute Anfragen abgearbeitet werden und die Selbstheilungskräfte des Systems greifen. So ist auch das Bild des Circuit Breakers zu verstehen: Bei Problemen im Netzwerk löst [1] die Sicherung aus und wird erst wieder geschlossen, wenn das verursachende Problem nicht mehr auftritt. Bei dem aufrufenden Service müssen natürlich entsprechende Fallback-Mechanismen implementiert sein, aber auch hier unterstützt die Bibliothek.

Hystrix kommt zusammen mit einem Dashboard, dem alle entscheidenden Hystrix-Metriken entnommen werden können. Im Standard kann so nur ein Service überwacht werden. Netflix Turbine bündelt die Informationsflüsse unterschiedlicher Service-Instanzen. So können auch ganze Service-Cluster in einem Dashboard verwaltet werden, wie in dem Beispielbild von der Projektseite gut zu erkennen ist.

Ribbonz

Skalierung macht erst dann wirklich Sinn, wenn auch ein intel-ligentes Load-Balancing genutzt wird. So können die Anfragen verteilt und unter Volllast stehende Server aus der Schusslinie genommen werden. Ribbon bietet clientseitiges Load-Balan-cing, um mit einem Service-Cluster zu kommunizieren. Dabei erhält jeder Client die Adressen der einzelnen Service-Instanzen. Diese können nach Bedarf auch in zonen gruppiert werden. Der Client kann nun nach beliebigen Kriterien wie Round-Robin oder einer gewünschten zone entscheiden, welche Instanz er anfragt. Dabei werden Statistiken zu dem Antwortverhalten erstellt, so dass der Client bei Folgeaufrufen Server mit problematischen Antwortzeiten ausklammern kann. Nutzt man Ribbon zusammen mit Eureka, so wird die Serverliste automatisch zur Verfügung gestellt. (Abb.1)

Feign

Feign stammt ebenfalls aus der Netflix-Schmiede und ist ein Webservice-Client, der das Erstellen von Anfragen an Webser-vices erleichtern soll. Da er sehr einfach mit Eureka und Ribbon zusammen verwendet kann, erhält man so einen HTTP-Client mit eigenem Load-Balancing. Wird zusätzlich Hystrix genutzt, ist es möglich, auch auf Service-Ausfälle adäquat zu reagieren.

Zuul

Clientseitiges Load-Balancing funktioniert für die Kommunikation interner Services - gewöhnlich verborgen hinter einer Firewall. Externe Clients dagegen bringen ihre eigenen, zusätzlichen Anforderungen an Sicherheit, Payload und Protokolle mit sich. Ein Edge-Server kann die Aufrufe dieser Clients an die Services bündeln und bearbeiten. Hier können API- und Protokoll-Über-setzungen vorgenommen und Sicherheitsaspekte behandelt werden.

zuul ist so ein Edge-Server, die Eingangstür von externen Aufrufen an das eigene Backend. Der Name des Frameworks ist dem gleichnamigen Torwächter-Dämon aus dem Film „Ghostbusters“ entliehen. zuul ermöglicht dynamisches Routen der Anfragen, Monitoring und unterstützt in Punkto Sicherheit. zusätzlich

Dashboard zur Cluster-Überwachung (Abb. 1)

FRAMEwORKs

16 JAVA-PRO.DE 2-2017

Literatur:

existiert ein Embedded-Re-verse-Proxy auf Basis von zuul. Dabei werden Anfragen eines UI-Clients zu einem oder mehreren Backend-Ser-vices durch den Proxy geleitet. Probleme mit Cross-Origin Resource Sharing (CORS) und der Same-Origin-Policy werden so umgangen.

Dank Ribbon erhält man Load-Balancing frei Haus dazu und Hystrix unterstützt in Sachen Fehler-Handling.

Sleuth und Zipkin

Solange man mit einem Monolithen arbeitet, ist die Analyse einer Anfrage relativ banal: Welches Problem auch immer auftreten mag, die Verantwortung liegt im Monolithen. Verteilte Systeme aber ändern alles. Sleuth ist der englische Ausdruck für Detektiv oder auch Schnüffler. Spring Cloud Sleuth unterstützt verteiltes Tracing und hilft, nicht nur das spezifi-zierte, sondern vor allem auch das reale Verhalten des Systems zu verstehen. Der Weg einer einzelnen Anfrage über mehrere Instanzen hinweg wird dabei als Trace bezeichnet, während der Sprung von einer Instanz zur Nächsten ein Span ist. Sleuth instru-mentalisiert automatisch verschiedene Kommunikationswege in einem Spring-Cloud System: • Anfragen über einen Message-Broker wie Kafka

oder RabbitMQ • HTTP-Header, die von Spring MVC Kontrollern

empfangen werden• Anfragen über den zuul Proxy-Mechanismus• Anfragen eines Rest-Templates

Sleuth erweitert die Log-Nachrichten jeweils mit einer Span- und einer Trace-ID. Mit einem geeigneten Analyse-Tool können die Log-Files auf diese IDs hin untersucht und ausgewertet werden. Um ein Ausufern der dabei gesammelten Daten zu vermeiden, kann konfiguriert werden, dass beispielsweise nur 10 Prozent der Anfragen so instrumentalisiert werden.

Doch das Sammeln der Daten ist nur eine Seite der Medaille. Die andere ist das Verstehen dieser Daten. Dazu kann zipkin verwendet werden. Es basiert auf dem Konzept von Google Dapper und wurde ursprünglich bei Twitter entwickelt. zipkin speichert die von Sleuth generierten Daten standardmäßig in einer MySQL-Datenbank oder hält die Informationen im Arbeits-speicher vor. Das mitgelieferte Dashboard ermöglicht es, diese Daten dann zu analysieren und abzufragen.(Abb.2)

Was fehlt?

Noch bevor man die erste zeile Code schreibt, sollte man sich über zwei Punkte Gedanken machen, die gerne erst im Nachhi-nein implementiert werden - was dann oft unnötig kompliziert und fehleranfällig ist. zum einen ist dies das Thema Logging. Um schnell und einfach die Log-Meldungen potentiell sehr vieler Instanzen auszuwerten, ist eine zentralisierte Lösung unab-dingbar. Großer Beliebtheit erfreut sich hier zum Beispiel der sogenannte ELK-Stack. Er besteht aus der Suchlösung Elasticse-arch, Logstash zum Einsammeln der Log-Files von den Servern und Kibana als grafischem Dashboard zur Analyse der in Elastic-search gespeicherten Log-Meldungen. Von vornherein berück-sichtigt werden sollte auch das Thema Security, das oft sträflich vernachlässigt wird. Hier sei exemplarisch auf Spring Cloud Vault und Spring Cloud Security verwiesen.

Fazit

Als Architektur-Design sind Microservices immer noch recht neu. Micro-Frameworks wie Spring Boot, Grails, Play, Payara Micro, Dropwizard, WildFly Swarm oder Lagom buhlen um die Gunst der User. Jedes Framework bietet andere Vor- und Nachteile, will ausprobiert und verstanden werden. Es bleibt abzuwarten, welche Lösungsansätze sich nachhaltig durchsetzen werden. Auch in der Spring-Cloud-Welt ist noch viel Bewegung. Daher nie vergessen: Alles ist im Fluss!

1 Nygard, Michael T.: Release It! : Design and Deploy ProductionreadySoftware.1.Aufl.2007,ISBN:978-0-978-73921-8

Zipkin-Dashboard zur Datenanalyse (Abb. 2)

FRAMEwORKs

CON2017

www.jcon.oneJCON#

www.jcon.oneJCON#

Copyright (c) 2017. IT Press & Media GmbH. Alle Rechte vorbehalten.Java(TM) ist ein eingetragenes Warenzeichen der Oracle Corporation.

Earlybird

bis 10. August 2017 !

Veranstalter: IT Press & Media GmbH

Freie Java Community Konferenz

FÜR ALLE JAVA USER GROUPMITGLIEDER KOSTENLOS !

650 JUG-Tickets verfügbar!

SILBER PARTNER: BRONZE PARTNER:SILBER PARTNER: SILBER PARTNER: SILBER PARTNER:

ROAVAGOLD PARTNER:POWERED BY: GOLD PARTNER:

CON2017

DIE JCON 2017

� � </> � �

� � � � ��

3Power-Tage

8Kinos

80+Speaker

100+Sessions

600+Teilnehmer

CON2017

� ��

TRACKS

2Konferenzen

besuchen

Haben Sie Fragen zur JCON 2017 ? Wir beraten Sie gerne!

Fon: +49 (0)6196 – 204801 – 0 | E-Mail: [email protected]

www.jcon.one

JCON 2017

XDEVCON 2017 - Java & Eclipse Starter Conference

Dienstag, 24. Oktober Mittwoch, 25. Oktober Donnerstag, 26. Oktober

HAUPT-KONFERENZ09:00 - 19:00 Uhr

EXPO09:00 - 19:00 Uhr

CLOUD DEVOPS DAY&

10:30 - 19:00 Uhr

JAVA-FX DAY10:30 - 19:00 Uhr

BIG-DATA DAY10:30 - 19:00 Uhr

MOBILE IOT DAY&

10:30 - 19:00 Uhr

AGILE DAY09:00 - 16:00 Uhr

WORKSHOP DAY09:00 - 16:00 Uhr

ARCHITECTURE DAY09:00 - 16:00 Uhr

JAVA-STARTER DAY09:00 - 19:00 Uhr

BEST-PRACTICE DAY09:00 - 19:00 Uhr

WORKSHOP DAY09:00 - 16:00 Uhr

JCON#

1-TAGES-PASS

TAG 1

24. Oktober

Haupt-KonferenzCloud & DevOps Day

Big-Data DayXDEVCON 2017

Normalpreis249 €

Earlybird bis 10. August

199 €

JUG-Mitglieder

FREI !

1-TAGES-PASS

TAG 2

25. Oktober

Haupt-KonferenzJavaFX Day

Mobile & IoT DayXDEVCON 2017

Normalpreis249 €


199 €

JUG-Mitglieder

FREI !

1-TAGES-PASS

TAG 1

26. Oktober

Workshop DayAgile Day

Architecture DayXDEVCON 2017

Normalpreis249 €


199 €

2-TAGES-PASS

TAG 1 - 2

24. - 25. Oktober

Haupt-KonferenzCloud & DevOps Day

Big-Data DayJavaFX Day

Mobile & IoT DayXDEVCON 2017

Normalpreis449 €


349 €

JUG-Mitglieder

FREI !

3-TAGES-PASS

TAG 1 - 3

24. - 26. Oktober

Alle Sessions derJCON 2017

XDEVCON 2017

Normalpreis499 €


399 €

JUG-Mitglieder

199 €

OVERVIEW

TICKETS

Für die Buchung eines JUG-Tickets benötigen Sie einen Buchungs-Code, den Sie von Ihrer JUG erhalten.

JUG-Tickets

Alle Preise verstehen sich zzgl. der gesetzl. MwSt.


#JAVAPRO #Container #Kubernetes

Containerisierte Anwendungen mit Kubernates Kubernetes ist eine von Google entwickelte und derzeit am schnellsten wachsende

Open-source-Lösung für das automatisierte Deployen, skalieren und Managen

containerisierter Anwendungen über unterschiedliche Cluster und Nodes hinweg.

Autor:

Thomas Fricke ist CTO der Endocode AG, beschäftigt sich seit vier Jahren mit Containern und hat sich davor 10 Jahre mit Virtualisierung und 25 Jahre mit Linux auseinandergesetzt. Mit mehreren gefühlt hunderten Jahren Operations und Entwicklungserfahrung hat er diese Themen in den letzten Jahren intensiv begleitet. Dabei sieht er so alt gar nicht aus.

Middleware, die eine Datenhaltung außerhalb von Kubernetes realisieren, Applikationen die schnell angepasst, aber deren Daten nicht kritisch waren.

Bei Kunden konnten wir erleben wie selbst Grenzfälle, etwa Daten-banken in Kubernetes oder SAP R/2 (sic!) Systeme auf Windows in virtuellen Maschinen, sich trotz der fehlenden Konformität zu den 12-Factor-Apps6 (eine Entwicklungsmethode für skalierbare Web-Applikationen in der Cloud) leichter betreiben lassen als auf herkömmliche Weise. Aus der Sicht von Projekten ist dies das einzig relevante Kriterium.

Einer der aktuell spannendsten Aspekte ist die Integration von GPUs7 (Global Processing Unit) und für neuronale Netze spezia-lisierte Hardware in Kubernetes. Mehrere Rechner eines Clusters bilden durch das GPU ein Netzwerk, bei dem auf jedem Rechner ein Client läuft, der für Rechenoperationen herangezogen werden kann. Neuronale Netze benötigen für die Trainings-phase eine deutlich höhere Rechenleistung als für das Abrufen des Gelernten. Bei einigen tausend GPUs ist es also dringend geboten, die Rechenleistung auf verschiedene Probleme zu verteilen, um die Balance zwischen Lernzeit und Clustergröße an die aktuelle Last anzupassen. Das ist der Ausgangspunkt für Kubernetes und hier kann es alle operativen Stärken jetzt auf GPUs ausspielen.

Operations

Kubernetes ist ein Google-Projekt, der Nachfolger des internen Borg-Projekts8, das zu tief in die Infrastruktur integriert ist, um als Open-Source-Projekt in die Freiheit entlassen zu werden. Bei Google werden damit zuerst Operationsaspekte abgedeckt.

• Entkopplung von Entwicklung- und Hardware-Management:Fokus ist die Bereitstellung von Applikationen ohne Umwegüber System- Management.

• Spezialisierung innerhalb Operations auf Cluster, Maschine

eit Docker1 die Linux-Container-Technologie populär gemacht hat, ist das Ökosystem um Container explodiert.

Hat vor einem Jahr auf Konferenzen noch die Frage gestanden, ob Container in Produktion eingesetzt werden können, ist das „Ob“ heute kein Thema mehr. Es wird in diesem Jahr nur noch diskutiert, auf welche Weise Container in die bestehenden Infra-strukturen integriert werden und wie die existierenden Prozesse auf die kommende Containerisierung ausgerichtet werden können. Dabei ist Kubernetes2 eines der sich am schnellsten entwickelnden Projekte auf GitHub. Es bringt unter der Gover-nance von Google alle drei Monate einen neuen Release hervor und überzeugt trotz der hohen Entwicklungsgeschwindigkeit bereits bei Alpha- und Beta-Feature mit hoher Stabilität. Auch konservative Branchen, wie Banken und Versicherungen starten Projekte, um aus Angst vor der disruptiven Energie der Fintechs endlich ihre Prozesse zu modernisieren und die Release-zyklen von teilweise immer noch zwölf Monaten endlich in das agile zeitalter zu führen, damit sie wenigstens tages- oder wochenak-tuelle Updates liefern können.

Die Frage der Orchestrierung von Containern ist derzeit im Fokus der Debatte. Docker Swarm, Kubernetes, Mesosphere3 DC/OS4 oder Exoten wie RancherOS5 sind die Kandidaten für das verteilte Betriebssystem der zukunft.

Der primäre Fokus für Container waren zunächst zustandslose Applikationen ohne eigenen Datenbestand, Webserver oder

S

CLOUD & CONTAINER

und Application Management: Jedes Team kann sich relativ autonom um seine Problemstellung kümmern.

• Rollouts, Monitoring und Health-Management werden indas Management Framework integriert:Damit brauchen Applikationen nur noch Checkpoints zur Verfügung stellen, das Framework kümmert sich um die Integration in den Gesamtprozess.

• Übergang zur Immutable-Infrastruktur:Nur wenn Rollouts vollständig automatisiert sind und ein Eingriff durch Admins nicht nur unnötig, sondern auch unerwünscht ist, lässt sich jederzeit die Integrität der Platt-form garantieren.

Architektur

Kubernetes hat eine klassische Master-Worker-Architektur9 (Abb. 1). Auf dem Master laufen alle zentralen Dienste, auf den Workern die ausführenden Pods, Netzwerk-Services, Proxies und Prozesse zur Erfassung der Ressourcen und zum Monitoring.

Pods, Services, Deployments, ConfigurationMaps und Secrets

Mit diesen Instrumenten eignet sich Kubernetes hervorragend zur Integration in Continuous-Integration-Pipelines. Das ermög-licht DevOps-Umgebungen und löst das Problem der Integra-tion der in Images abgelegten Artefakte und der Verbreitung von Passwörtern nur auf den unbedingt notwendigen Kreis von Applikationen. Pods können als kleinste Einheit definiert, konfigu-riert und in Deployment-Pipelines propagiert werden. Üblicher-weise werden Pods in Deployments als Templates verpackt und mit einem impliziten ReplicaSet skalierbar und resilient gemacht.

Listing (1)

apiVersion: extensions/v1beta1kind: Deploymentmetadata:name: nginx-deploymentspec:replicas:3template: metadata: labels: app: nginx spec: containers: - name: nginximage:nginx:1.7.9 ports:-containerPort:80

Services referenzieren die Pods über das Label mit dem Wert Key (hier app)und dem Wert (hier nginx). zusätzlich wird der interne targetPort 80 auf einen externen Port 8000 und einen

nicht spezifizierten Nodeport abge-bildet. Über type: LoadBalancer kann ein externer Service, etwa ein F5 oder HaProxy die Verbindung ins Internet herstellen.

Listing (2)

apiVersion: v1kind: Servicemetadata:name: nginx-servicespec:type: NodePortports:-port:8000targetPort:80 protocol: TCPselector: app: nginxtype: LoadBalancer

Konfigurationen lassen sich in Config-Maps ablegen, Passwörter, Certificates und Tokens in Secrets.

Listing (3)

apiVersion: v1kind: Secretmetadata: name: mysecrettype: Opaquedata: username: YWTRtaW4=password:MWYyZDFlMmU2N2Rm

Damit lassen sich in Abhängigkeit von der Umgebung die Secrets als separate Instanzen in Container-Dateien oder Environ-ment-Variablen zusteuern.

Kubernetes Architektur. (Abb. 1)

CLOUD & CONTAINER


Resilience und Skalierbarkeit

Ein weiterer wichtiger Aspekt bei Borg, der in Kubernetes Eingang gefunden hat, ist die Widerstandsfähigkeit, die „Resi-lienz” gegen Ausfälle von Hardware. Grundsätzlich ist Resilienz mit Skalierbarkeit eng verbunden und beruht auf der Fähigkeit ohne Verzögerung weitere Instanzen einer Software zur Verfü-gung stellen. Eine Eigenschaft, die unbedingt in die Orchestrie-rung integriert werden sollte. Tatsächlich ergeben sich jedoch konzeptionelle Schwierigkeiten, die bereits im CAP-Theorem (in verteilten Systemen ist es unmöglich Konsistenz, Verfügbarkeit und Ausfalltoleranz gleichzeitig zu garantieren) angelegt sind und dazu geführt haben, dass praktisch jede Datenbank ihre eigenen synchronen und asynchronen Replikationsmethoden mitbringt. Gegenwärtig gibt es erste Bestrebungen, auch Daten-banken in Kubernetes zu integrieren. Obwohl die Bestrebungen schon weiter gediehen sind als bei anderen Projekten, sind wir von einer halbwegs generischen Lösung noch weit entfernt.

Ein weiterer wichtiger Aspekt ist die Abbildung von URIs auf Services. Dafür gibt es in Kubernetes zwei Konzepte. Ein Service vom Typ Loadbalancer kann ausgelesen werden, um einen externen Loadbalancer zu konfigurieren. Die Aufgabe kann also über einen Controller konfiguriert und dann delegiert werden. Ähnlich, aber in Kubernetes selbst betreibbar, ist Ingress. Ein Reverse-Proxy, der auf der Granularität der URIs eine externe Adresse mit einem Kubernetes-Service verbindet. Implementie-rungen durch F5 Loadbalancer oder HA-Proxy bzw. durch NGinx, Haproxy oder Varnish stehen zur Verfügung.

Planetary Scale

Ein weiteres Problem, das für größere Cluster gelöst werden muss, ist die Integration von entfernten Clustern. Ohne Aussicht auf eine zeitnahe Synchronisation von Daten bleibt nur eine Inte-gration über die Loadbalancer und eine asynchrone Replikation im Hintergrund. Diese Aufgabe wird von Kubernetes-Federation übernommen, allerdings ist dazu die Unterstützung durch ein globales DNS unerlässlich, dass das günstigste Routing im Sinne von kurzer Latenzzeit zum nächsten Kubernetes-Cluster erlaubt.

Anwendungsarten

Als Plattform hat es keine Vorgaben für Programmiersprachen, Bibliotheken oder bestimmte Versionen. Alles was sich in Images verpacken lässt, kann als Anwendung in Pods ausgeliefert werden. Pods sind Container, die sich die gleichen Linux-Namespaces teilen. Sie haben ein gemeinsames Schicksal, werden zusammen erzeugt und gelöscht, laufen auf demselben Hardware-Node und teilen sich die Netzwerkadresse sowie den gesamten Name-space. Sie können gemeinsam, aber auch einzeln angesprochen werden. Damit lassen sich alle Applikationen verwenden, die in Docker- oder Rkt-Containern laufen und die APPC10-kon-form gemäß Standard der OCI (Open Container Initiative) sind.

Konfigurationen in YAML-Files können als ConfigMaps und Tokens, Passwörter oder Keys als Secrets in jeder Stage unab-hängig zugesteuert werden. Pods können so schon in mehreren Sprachen implementiert werden. Das ist insofern wichtig, als neben der JVM-Plattform in agilen Projekten alle Programmier-sprachen verwendet werden. Wir haben schon NodeJS und Ruby für Frontends, Python für Machine-Learning, Go für systemnahe Anwendungen und .Net für Legacy Applikationen in Kubernetes verwendet. Auch Hypervisor mit vollständigen Images lassen sich erfolgreich in Containern betreiben.

Multitenancy, Networks, Staging, Namespaces, RBAC

Durch die gerade in Kubernetes von Alpha zu Beta gereifte Role-based Access-Control lassen sich verschiedene Konzepte auf einem Cluster realisieren. zum einen können Entwicklung, Test und Produktion im selben Cluster ebenso wie verschiedene Kunden im gleichen Hardware-Cluster laufen, zum anderen kann über eine sehr feingranulare Rollenverteilung der zugriff durch Policies geregelt werden. Eine wichtige Rolle spielt hier die Möglichkeit, Policies zum Starten der Container zu vergeben und nur bestimmten Accounts zu erlauben, privilegierte Container zu starten. Der Standard, nur eingeschränkte Rechte zu gewähren, reicht für die meisten Anwendungen völlig aus. Eine besondere Stärke von Kubernetes wird die Einführung von Netzwerkimple-mentierungen mit NetworkPolicies werden. Hier lassen sich Con- tainer alleine durch Label und Namespaces trennen. Der Grad der Isolierung entspricht einem Paketfilter. Die Konfiguration erlaubt zum Beispiel einen Namespace per Default zu isolieren

Listing (4)

kind: NamespaceapiVersion: v1metadata: annotations: net.beta.kubernetes.io/network-policy: | { „ingress“: { „isolation“: „DefaultDeny“ } }

und per Label einzelne Verbindungen zwischen gelabelten Pods freizugeben.

Listing (5)

apiVersion: extensions/v1beta1kind: NetworkPolicymetadata:name: test-network-policynamespace: defaultspec:podSelector: matchLabels: role: db

CLOUD & CONTAINER

Links:

ingress: - from: - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: tcp

port:6379

Java

In Java-Umgebungen, wie auch in anderen Programmierspra-chen, geht der Trend dazu, auch Aufgaben, die über die eigent-liche Programmierung hinausgehen, in das Framework hinein-zuziehen. Je weiter vom Kern der Programmierung, also von der Entwicklung entfernt, desto schwächer ist die Ausführung. Während Webserver meistens noch gut implementiert werden, ist Application-Lifecycle-Management schlecht ausgeführt. Wir müssen hier nicht auf IoT (Internet-of-Things) zeigen, um Beispiele für wirklich verheerende Sicherheitsprobleme zu finden, wie das Project Rosehub11 zeigt. Dieser Philosophie von Sepa- ration-of-Concerns folgend sind Service Broker, Updates und Lifecycle-Management nicht Aufgabe von Java-Tools sondern des Container-Managements. Sobald die JVM-only-Welt verlassen wird, weil zum Beispiel neue Herausforderungen für Machine-Learning angegangen werden sollen, stellt sich diese Frage ernsthaft neu. Spring Boot12 erlaubt die Verbindungen zwischen diesen Welten, weil direkt auf der Kommandozeile der Java-Applikation auch tief in Archiven vergrabene Parameter auf einfache Weise überschrieben werden können. Aus

Listing (6)

java -jar $ARTEFACT $JAVA_RUNTIME_OPTIONS“

wird durch Konfiguration der Environment Variablen

Listing (7)

java -jar myApplication.jar --rabbitmq.server-host=172.17.0.100--spring.data.mongodb.host=172.17.0.99

eine laufende, fertig konfigurierte Applikation.

Deployment Pipelines mit Fabric8

Fabric813 ist eine Microservice-Plattform, die Docker, Kubernetes und Jenkins zu einem Continuous-Deployment-System integ-riert. Es enthält eine Web-Developer-Console, die den gesamten Lebenszyklus eines Microservice abdeckt. Neben Create, Edit, Build auch Deploy und Test, Logging, Metrics, ChatOps und selbst einen Chaos-Monkey. Hawtio und Jolokia erlauben eine tiefe Analyse von Java in Containern. Eine Integration von

Messaging-Services wie ActiveMQ und Camel, ein Maven-Plugin zum direkten Deployment in Kubernetes und Test-Integration in Arquillian runden das Build-System ab.

Die Verbindungen zwischen Java und Kubernetes werden Java-konform über Annotationen gestiftet. Es gibt bereits Anno-tationen für Delivery und Management sowie für Secrets, sodass bereits im Java-Code Hinweise auf die Deployment-Pipeline, der Anschluss an das Monitoring und die zu verbindenden Secrets designt werden können. Damit kann bereits bei der Architektur einer Applikation der Anschluss an Operations gelegt und die DevOps-Kultur in Kubernetes gelebt werden.

Listing (8)

@Producespublic BuildSignallerService createBuildSignallerService(@Protocol(„http“)@ServiceName(„fabric8“)StringconsoleLink,@ConfigProperty(name=„BUILD_NAMESPACE“,defaultValue=„“)String namespace, KieSession ksession) { BuildSignallerService service = new BuildSignallerService(ksession, namespace); service.setConsoleLink(consoleLink); service.start(); return service;}

Pakete und Charts

Helm als Kubernetes-Projekt erlaubt die Definition von Paketen, also Pods die in Abhängigkeit zueinanderstehen, und die Defi-nitionen von Anwendungen über Pattern. Client-Server ist in diesem Sinne auch ein Pattern, genau wie Replikationsmuster in Datenbanken.

Fazit:

Das die zukunft containerisiert wird, steht nicht mehr in Frage. Die Frage die nunmehr besteht ist, wie schnell die Koffer für den Umzug gepackt werden können.

1 https://docker.io2https://kubernetes.io3http://mesos.apache.org 4 https://dcos.io 5 RancherOS: http://rancher.com/rancher-os6https://12factor.net/de/7https://developer.ibm.com/linuxonpower/2017/04/21/tensorflow-training-kubernetes-openpower-servers-using-powerai/

8https://pdos.csail.mit.edu/6.824/papers/borg.pdf 9 https://commons.wikimedia.org/wiki/File:Kubernetes.png, Lizenz: https://creativecommons.org/licenses/by-sa/4.0/deed.en 10 https://github.com/appc/spec11https://opensource.googleblog.com/2017/03/ operation-rosehub.html12http://blog.christianposta.com/microservices/spring-boot -microservice-development-on-kubernetes-the-easy-way/13https://fabric8.io/guide/develop/createMicroservice.html

CLOUD & CONTAINER


#JAVAPRO #Container #CloudNative

Per Anhalter durch denCloud Native Stack Cloud-Größen wie Google, Twitter und Netflix haben die Kern-Bausteine ihrer

Infrastruktur quelloffen verfügbar gemacht. Das Resultat aus vielen Jahren

Cloud-Erfahrung ist nun frei zugänglich, jeder kann selbst Cloud-Native-Anwen-

dungen entwickeln – anwendungen, die in der Cloud zuverlässig laufen und fast

beliebig skalieren. Die Bausteine wachsen zu einem großen Ganzen zusammen:

dem Cloud-Native-stack. Dieser Artikel stellt wichtige Konzepte und schlüssel-

Technologien vor, und beschreibt wie eine Cloud-Native-Anwendung schrittweise

auf diesem stack zur Ausführung gebracht wird.

Autor:

Mario-Leander Reimer ist Cheftechnologe bei der QAware. Er ist Spezialist für den Entwurf und die Umsetzung von komplexen System- und Softwarear-chitekturen auf Basis von Open-Source-Technologien. Er beschäftigt sich intensiv mit Technologien rund um den Cloud Native Stack und deren Einsatzmöglich-keiten im Unternehmensumfeld.

Anzahl an Usern, Endgeräten, Verbindungen, Traffic und Daten die von heutigen Systemen verarbeitet werden wollen. Man spricht von Hyperscale. Damit diese Geschäftsmodelle nicht von Fehlern und Systemabstürzen gefährdet werden, ist die Anti- fragilität solcher Systeme essentiell. Und auch die Konkurrenz schläft nicht. So müssen die neuen Ideen und Features in immer kürzeren zyklen entwickelt und in Betrieb gebracht werden. Continuous-Delivery und DevOps spielen in diesem zusammen-hang eine wichtige Rolle.

Klassische Betriebsmodelle und Applikationen scheinen wenig geeignet zu sein diesen hohen Anforderungen gerecht zu werden. Der Trend geht klar in Richtung Cloud-nativer Applika-tionen, also Anwendungen, die in der Cloud zuverlässig laufen und fast beliebig skalieren. Doch wie werden solche Systeme gebaut und mit was werden sie betrieben? Diesen Fragen geht dieser Artikel im Folgenden nach.

Einführung und Motivation

Moderne Geschäftsmodelle verlassen sich heutzutage immer mehr auf leistungsstarke und zuverlässige IT-Systeme oder würden ohne diese erst gar nicht mehr funktionieren. Mit immer neuen, innovativen Ideen und Dienstleitungen wird versucht Kunden an sich zu binden. Das Resultat sind eine stetig steigende

CLOUD & CONTAINER

Die sieben Design Prinzipien Cloud-nativer Anwendungen

Cloud-Native-Anwendungen müssen zwingend anders entworfen und gebaut werden als bisherige Web-Ap-plikationen. Denn „Everything fails, all the time“ (Werner Vogels, Amazon CTO). Entwickler und Architekten sollten diesen zustand in der Cloud als Normalfall akzeptieren und nicht als Ausnahmefall behandelt. Auch die „Acht Irrtümer der verteilten Daten-verarbeitung“1 sind plötzlich aktueller denn je. Die folgenden sieben Design-Prinzipien sollten drin-gend von Beginn an berücksichtigt werden, damit die eigene Cloud-native Anwendung am Ende auch das hält was sie verspricht.

• Design for Distribution: Die Anwendung ist API-getrieben mit Microservices entwickelt und kann in einem Container betrieben werden.

• Design for Performance: Die Anwendung ist responsive,arbeitet in weiten Teilen asynchron und geht schonend mit den Ressourcen um.

• Design for Resiliency: Die Anwendung ist tolerantgegenüber Fehlern und selbstheilend.

• Design for Elasticity: Die Anwendung ist zustandslosund skaliert dynamisch in beiden Richtungen.

• Design for Automation: Typische Dev- und Ops-Aufgabenlassen sich über geeignete Schnittstellen automatisieren.

• Design for Delivery: Kurze Roundtrips während der Entwicklung und die automatisierte Provisionierung der Anwendung sind Pflicht.

• Design for Diagnosability: Cluster-weite Logs, Metrikenund Traces können zu Diagnosezwecken gesammelt und ausgewertet werden.

Die Anatomie des Cloud Native Stack

Cloud-Native-Anwendungen bringen also zusätzliche Komple-xität beim Entwurf, der Umsetzung und beim Betrieb mit sich. Es braucht geeignete Abstraktionen um diese Komplexität leichter beherrschbar zu machen: den Cloud-Native-Stack. Der schema-tische Aufbau dieses Stacks ist in (Abb. 1) dargestellt. Auf der untersten Ebene befindet sich die Cluster-Virtualization. Diese Ebene entkoppelt von der physischen Hardware. Die Technolo-gien auf dieser Ebene befassen sich mit der Bereitstellung virtu-eller Ressourcen, wie etwa Memory, Storage oder Netzwerk. Darüber sitzt der Cluster-Scheduler. Dieser kennt und verwaltet die virtuellen Ressourcen im Cluster. Der Scheduler führt einzelne Container aus, weist diesen die benötigten Ressourcen zu und kümmert sich dabei um deren faire und gleichmäßige Verteilung innerhalb des Clusters. Der Cluster-Orchestrator führt ganze

Applikationen auf dem Cluster aus. Er arbeitet dabei eng mit dem Scheduler zusammen. Der Orchestrator ist für den kompletten Lebenszyklus einer Cloud-nativen Anwendung verantwortlich. Er überwacht den zustand und stellt sicher, dass der gewünschte Systemzustand jederzeit gegeben ist. Die Application-Platform stellt die Ablaufumgebung, Infrastrukturbausteine sowie APIs bereit gegen die eine Cloud-Native-Application programmiert wird.

Nun gibt es nicht nur diesen einen Cloud-Native-Stack. Der in (Abb. 1) dargestellte Stack ist lediglich einer von vielen mögli-chen Ausprägungen. Bei der konkreten Technologieauswahl helfen die Cloud-Native-Landkarten2 der Cloud Native Compu-ting Foundation (CNCF) oder der QAware GmbH. Vorkonfektio-nierte Stacks wie OpenShift oder Cloud Foundry erfreuen sich zunehmender Beliebtheit, speziell im Enterprise Umfeld.

In vier Schritten zur cloud-nativen Anwendung

Die Entwicklung von Anwendungen auf dem Cloud-Native-Stack folgt einem einfachen Muster. Es müssen die folgenden vier Schritte durchlaufen werden:

Cloud Native Stack mit Docker, Kubernetes und Spring Boot. (Abb. 1)

4-steps (Abb. 2)

CLOUD & CONTAINER


1. Microservices: Die funktionalen Teile der Applikationwerden als Microservices entworfen und entwickelt.

2. Containerisierung: Die einzelnen Microservices werdenin Containern verpackt und verteilt.

3. Komposition: Die Anwendungsbausteine werden durchzusätzliche Infrastrukturbausteine verbunden und erweitert.

4. Orchestrierung: Die Anwendungs- und Infrastrukturbau-steine werden auf einem Cluster-Betriebssystem gesamthaft zur Ausführung gebracht.

Die folgenden Abschnitte gehen nun auf jeden dieser Schritte detailliert ein.

Von Entwicklung-Komponenten zu Betriebs-Kom-ponenten

Microservices und Self-Contained-Systems (SCS) sind essenti-elle Architekturmuster mit denen Cloud-native Anwendungen und Systeme umgesetzt werden. Nüchtern betrachtet sind diese Muster aber nur alter Wein in neuen Schläuchen, denn die Konzepte von Softwarekomponenten und Schnittstellen sind nicht neu. Microservices sind lediglich das Resultat einer konse-quenten Anwendung der komponentenbasierten Softwareent-wicklung vom Design bis hin zum Betrieb.

Bereits in der Entwurfsphase eines Systems denken wir in Kompo-nenten. Diese sind fachlich anhand von Use-Cases geschnitten. Sie bilden kohäsive Funktionseinheiten, sorgen selbst für ihre Datenintegrität und sind lose miteinander gekoppelt. Während der Entwicklung werden die Komponenten dann zu Einheiten der Planung, Arbeitsteilung, Umsetzung und Integration. Wirklich neu ist nun die Abbildung der Entwicklungs- auf Betriebskom-ponenten. Eine Komponente wird hier zur Einheit für Release, Deployment und Skalierung. Bei diesem Übergang gibt es

Freiheitsgrade, die bewusst und mit Augenmaß eingegangen werden sollten (Abb. 3).

Werden alle Komponenten eines gesamten Systems auf genau eine einzelne Betriebskomponente abgebildet, entsteht ein Betriebsmonolith. Dieser hat die bekannten Nachteile aber auch gewisse Vorteile. Fehlersuche und Debugging sind einfach, die Infrastrukturkomplexität ist niedrig und es gibt keine Latenz bei Aufrufen zwischen den Komponenten.

Microservices entstehen, wenn einzelne Komponenten auf eigene Betriebskomponenten abgebildet werden. Diese Dekom-position bringt Vorteile mit sich. So sind nun unabhängige Releases und Deployments der funktionalen Teile eines Systems einfach möglich. Diese können wesentlich flexibler skaliert werden, die Ressourcen werden effizienter genutzt. Durch die höhere Laufzeitisolation der einzelnen Teile sind nun auch nicht mehr die Stabilität und die Verfügbarkeit des Gesamtsystems gefährdet. Doch die Dekomposition bringt auch Nachteile und Pflichten mit sich. Durch die Verteilung müssen plötzlich Dinge wie Latenz, Bandbreite und Verfügbarkeit beachtet werden. Ein gutes Schnittstellendesign ist nun essentiell für ein effizientes Kommunikationsverhalten der Microservices. Die Suche nach Fehlern gestaltet sich schwieriger und die höhere Infrastruktur-komplexität erfordert zwingend eine automatische Bereitstellung und Konfiguration aller Teile.

Docker, Docker, Docker

Docker ist sicherlich eine der Schlüsseltechnologien durch die Cloud-Native-Anwendungen wie wir sie heute kennen erst möglich geworden sind. Docker ist eine leichtgewichtige Form der Virtualisierung die erst ab der Ebene des Betriebssystems aufsetzt. Verglichen mit der klassischen Virtualisierung sind hier die Image-Größen deutlich kleiner und es gibt auch keinen Over-

head beim Start eines Containers. Trotzdem laufen die Anwendungen in einem Container isoliert und beeinträchtigen sich nicht gegenseitig.Am Anfang der Contain- erisierung steht immer ein Docker-File (Listing 1). Es beschreibt wie, aufset-zend auf einem Basis-Image (zeile 1), die eigene Anwendung in das Datei-system des Docker-Image gebracht (zeilen 4-6) und mit welchem Befehl die Anwendung gestartet (zeile 10) wird.

Von Entwicklungs-Komponenten zu Betriebs-Komponenten. (Abb. 3)

CLOUD & CONTAINER

(Listing 1)

1FROMqaware/alpine-k8s-ibmjava8:8.0-3.102MAINTAINERQAwareGmbH<[email protected]>3 4 RUN mkdir -p /app 5 COPY build/libs/zwitscher-service-1.0.1.jar 67/app/zwitscher-service.jar8COPYsrc/main/docker/zwitscher-service.conf/app/ 910EXPOSE8080 CMD /app/zwitscher-service.jar

In (Listing 2) sind die nötigsten Docker-Befehle aufgelistet um aus einem Docker-File ein Docker-Image zu erzeugen, dieses lokal zur Ausführung zu bringen, zu kontrollieren und es am Ende in einer Remote-Docker-Registry zu veröffentlichen. Diese Befehle (und noch ein paar mehr) gehören zum Grundwissen und Handwerkszeug eines Cloud-nativen Entwicklers.

(Listing 2)

1 $ docker build -t zwitscher-service:1.0.1 .23$dockerrun--namezwitscher-service--rm-d\4-e„PORT=8080“-p8080:8080zwitscher-5 service:1.0.167$dockerlogs-fzwitscher-service8$dockerstopzwitscher-service910 $ docker tag zwitscher-service:1.0.111 hitchhikersguide/zwitscher-service:1.0.1

12$ docker login -u hitchhikersguide -p <password>$ docker push hitchhikersguide/zwitscher-service

Komposition einer cloud-nativen Anwendung

Ein einzelner Microservice allein macht natürlich noch keine Cloud-Native Applikation. Erst im zusammenspiel aller Teile entsteht ein vollwertiges System. Für ein reibungsloses zusam-menspiel braucht es zusätzliche Infrastrukturbausteine und Dienste, wie in (Abb. 4) exemplarisch dargestellt. Bei der konkreten Auswahl der benötigten Dienste und Bausteine lohnt erneut ein Blick auf die Cloud-Native-Landkarten. Das Microservice-Chassis dient als Laufzeitumgebung für die Service Endpoints. Doch welche Technologie ist hier nun die Richtige? Die Antwort liegt auf der Hand: Jeder nach seiner Fasson! Denn sowohl mit Java EE, als auch mit Spring Boot oder dem Lagom-Framework lassen sich Microservice-basierte Systeme mit mehr oder weniger vergleichbarem Aufwand sehr gut umsetzen.

Die Service-Discovery dient der Registrierung und Suche von Service Endpoints. Alle Services registrieren sich an einer zent-ralen Registry um später über ihren Namen von Clients gefunden zu werden. Im einfachsten Fall wird DNS für den Lookup verwendet. Für etwas mehr Komfort bieten Bausteine, wie etwa Consul, erweiterte Funktionen wie Health-Checks, Load-Balan-cing und Hochverfügbarkeit.

Über Infrastrukturbausteine zur Configuration-and-Coordination werden den Endpoints und Microservices-Cluster-weite Konfi-gurationswerte bereitgestellt, wie etwa Secrets oder anderweitig umgebungsabhängige Werte.

Das Thema Monitoring und Diagnostizierbarkeit ist für Cloud-Na-tive-Anwendungen von enormer Bedeutung. Durch die hohe

Cloud-native Infrastruktur-Bausteine und Dienste. (Abb. 4)

CLOUD & CONTAINER


Links:

Verteilung ist es in Fehlersituation nicht mehr so einfach, den genauen Verlauf einer Anfrage durch das System nachzuvoll-ziehen. Auch ein Debugging des Gesamtsystems ist nicht mehr möglich. Es braucht also weitere Infrastrukturbausteine für die Bereiche Logging, Monitoring und Tracing.

Ein API-Gateway regelt den externen zugriff auf die Service-End-points des Systems. Über Routendefinition wird geregelt, welche eingehenden Requests an welchen Service-Endpoint weiter-geleitet werden. Häufig steht das API-Gateway hierfür mit der Service-Discovery in Verbindung und es bietet zusätzliche Funk-tionen zur Authentifizierung, Autorisierung, Monitoring und Traf-fic-Management an.

Orchestrierung mit einem Cluster Betriebssystem

Die Anwendungs- und Infrastrukturbausteine werden nun auf einem Cluster-Betriebssystem wie Kubernetes gesamthaft zur Ausführung gebracht. In (Abb. 5 [k8sconcepts]) sind die wich-tigsten Konzepte und Begriffe dargestellt die häufig verwendet werden. Für eine detaillierte Beschreibung der Architektur sowie aller unterstützten Konzepte wird auf die ausführliche Online-Do-kumentation3 verwiesen.

Im zentrum stehen die Pods. Diese beinhalten einen oder mehrere Container und bilden die kleinste Deployment- und Laufzeiteinheit in Kubernetes. Das Replica-Set überwacht den zustand der Pods und stellt sicher, dass immer genug Pods im Cluster laufen. Das Deployment bietet die Möglichkeit für dekla-rative Updates der Pods und Replica-Sets. Der Service dient als logische Abstraktion für den zugriff auf eine Menge an Pods, die über Labels ausgewählt werden.Die Definition der benötigten Pods, Deployments und Services erfolgt über eine einfache YAML- oder JSON-Datei. Mit dieser Datei wird anschließend die Anwendung per Kubernetes-CLI (Listing 3 [k8scmds]) auf dem Cluster angelegt und ausge-führt (zeile 1). Die Skalierung der Anwendung wird ebenfalls

per einfachem Kommando erledigt (zeile 3), genauso wie ein Rolling-Update (zeile 5) der Anwendung auf eine neue Version. Im Fall eines Fehlers kann der Rollout-Prozess mit einem Kommando auch wieder rückgängig gemacht werden.

(Listing 3)

1 $ kubectl apply -f zwitscher-service.yaml23$kubectlscaledeployment/zwitscher-service--replicas=845 $ kubectl set image deployment/zwitscher-service \6 zwitscher-service=hitchhikersguide/zwitscher-7service:1.2.389 $ kubectl rollout status deployment/zwitscher-service $ Kubectl rollout undo deployment/zwitscher-service

Keine Magie, aber komplexe Technologie

„Building distributed systems is hard!“ Diese Erkenntnis ist sicher nicht neu. Auch schon in zeiten von CORBA und Client-Ser-ver-Systemen war das so. Die Verteilung bringt schlicht eine Menge an zusätzlicher Komplexität mit sich, die beim Entwurf, der Umsetzung und dem Betrieb eines verteilten Systems mitbe-rücksichtigt werden muss.

Eines hat sich jedoch drastisch weiterentwickelt: die Technik, die heute zur Verfügung steht. Der Cloud-Native-Stack mit seinen verschiedenen Technologien macht die inhärente Komplexität hoch verteilter Systeme nun endlich beherrschbar.

Doch die hohe Abstraktion des Cloud-Native-Stacks ist Segen und Fluch zugleich. Denn sobald Dinge nicht mehr funktionieren wie erwartet, muss man in die Untiefen der jeweiligen Techno-logie abtauchen. Entwickler und Architekten von Cloud-nativen Systemen brauchen somit zusätzliche Skills und Know-how in etlichen neuen Technologien, um sich in dieser schönen neuen Welt sicher zu bewegen.

1 [fodc] Fallacies of Distributed Computing [https://de. wikipedia.org/wiki/Fallacies_of_Distributed_Computing]2[repo]Quellcode[https://github.com/qaware/ hitchhikers-guide-cloudnative]3[k8sd]KubernetesConceptsDokumentation

[https://kubernetes.io/docs/concepts/]

[cnls]QAwareCloudNativeLandscape[https://goo.gl/xrVg3J][cncf] Cloud Native Computing Foundation Landscape [https:// github.com/cncf/landscape] [jm01] Der Cloud Stack: Mesos, Kubernetes und Spring Cloud [https://goo.gl/U5cJAU][jm02]SpringCloudundNetflixOSS:Cloud-nativeAnwendungenbauen [https://goo.gl/edNlUK][jm03]Cloud-nativeAnwendungenmitKubernetes[https://goo.gl/dVkoyR] [jm04] Eine Einführung in Apache Mesos: Das Betriebsystem der Cloud[https://goo.gl/7SnMZA]

Wichtige Kubernetes Konzepte und Begriffe. (Abb. 5)

CLOUD & CONTAINER

www.java-pro.de/seminare

Normalpreis 1199,- €

Earlybird bis 10. Aug. 2017:

899 €,-


Powered by

ROAVAPower-Seminar

Web-Anwendungen jetztmit JavaFX entwickeln

EXKLUSIV - ERSTE JPRO SCHULUNG !

ROAVA

• Einführung und Architektur-Overview

Web-Anwendungen mit JavaFX•

Web-Portale mit JavaFX•

Bestehende FX-Anwendungen fürs Web optimieren•

JavaFX-Anwendungen in der Cloud betreiben•

Frontend-Sharing direkt mit JavaFX•

Monitoring Heat-Maps• &

Hands-on-Workshop Best-Practice• &

Fragen Antworten• &

12. - 13. September 2017in München

Endlich, Java ist zurück im Browser! Mit jpro lassen

sich beliebige JavaFX-Anwendungen im Web-

Browser ausführen. Dazu führt jpro die FX-

Anwendung auf einem Server aus und bildet den FX-

Scenegraph, der die Oberfläche beschreibt, mittels

SVG im Web-Browser ab. Es wird weder JavaScript,

noch ein Browser-Plugin benötigt. Sogar bestehende

FX-Desktop-Applikationen werden mit jpro zur Web-

Anwendung. Die Vorteile sind enorm: Gesamte

Entwicklung erfolgt in Java, es können die bekannten

Tools und Prozesse genutzt werden, keine

aufwändigen Browser-Anpassungen mehr, nur noch

ein solide UI-Technologie (FX) anstatt vieler JS-Library-

Abhängigkeiten, Browser-Inkompatibilitäten und -

Änderungen haben keine negativen folgen mehr, auf

Jahre hinaus wartungsfreies Frontend u.V.m.

In diesem JAVAPRO-Power-Seminar erfahren Sie, wie

jpro funktioniert, was Sie bei der Entwicklung von

Multi-User-Anwendungen berücksichtigen müssen,

wie Sie Ihre Anwendung deployen und erhalten

wertvolles Know-how für den Einsatz in der Praxis.

*

*zzgl. 19% ges.MwSt.!

www.xdevcon.deXDEVCON#

Earlybird

bis 10. August 2017

Visual & Cross-Platform-Development mit Java & Eclipse

Tag 1: Grundlagen Know-how - Java, Eclipse, Hibernate, Vaadin, Projektstart

Tag 2: Best Practice Day - Hibernate, Vaadin, Reporting, Webservices, Migration

Tag 3: Workshop Day - Deep-dive, Live-Coding, Häufigste Anforderungen, Diskussionen


7Jahre XDEVCON

3Power-Tage

20+Haupt-Sessions

80+Parallele Java-Sessions

200+Teilnehmer

ROAVApowered by

CON2017

JCON2017 & XDEVCON 2017 Sponsoren:

Freie Java Community Konferenz

FÜR ALLE JAVA USER GROUPMITGLIEDER KOSTENLOS !

650 JUG-Tickets verfügbar!

Java & eclipseStarterconference

XDEVCON 2017

Achtung - Neuer Termin!

24. - 26. Oktober 2017

Düsseldorf - UFA Palast, Multiplex-Kino

www.xdevcon.de

TICKETS

Haben Sie Fragen zur JCON 2017 ? Wir beraten Sie gerne!

Fon: +49 (0)6196 – 204801 – 0 | E-Mail: [email protected]

Für die Buchung eines JUG-Tickets benötigen Sie einen Buchungs-Code, den Sie von Ihrer JUG erhalten.

JUG-Tickets

Die XDEVCON ist seit 7 Jahren die Top-Konferenz für Rapid-Cross-

Platform- Development mit Java und Eclipse. Die XDEVCON ist die

einzige Java-Konferenz, die sich nicht an Java-Gurus, sondern

gezielt an Anwendungsentwickler richtet. Alles dreht sich darum, wie

Sie professionelle Business-Applikationen mit Java und Eclipse sehr

viel einfacher, schneller und kostengünstiger entwickeln können,

Features schneller realisieren und komplizierte, zeitraubende Low-

Level-Programmierung vermeiden können. In drei Tagen lernen Sie

von den führenden Experten, mit den neuesten Eclipse-Tools für

visuelle Java-Entwicklung HTML5 Web-Anwendungen und Mobile-

Apps für Android und iOS zu entwickeln und wie Sie bei der

Projektentwicklung und Migrationsprojekten vorgehen sollten.

Die XDEVCON 2017 ist Teil der JCON

2017 und eine echte Java-Community-

Konferenz. Die Teilnahme ist für alle

Mitglieder einer Java-User-Group

völlig kostenlos.

Die XDEVCON 2017 und JCON 2017

Organisiert wird von JAVAPRO,

zusammen mit der XDEV Software

Corp. und Mitgliedern des JAVAPRO-

Partner-Network organisiert.

DIE XDEVCON 2017 KOSTENLOSE JAVACOMMUNITY KONFERENZ

XDEVCON#

1-TAGES-PASS

TAG 1

24. Oktober

Java & EclipseStarter Day

Inklusive alleJCON 2017 Sessions

Normalpreis249 €


199 €

JUG-Mitglieder

FREI !

1-TAGES-PASS

TAG 2

25. Oktober

Best-Practice Day


Normalpreis249 €


199 €

JUG-Mitglieder

FREI !

1-TAGES-PASS

TAG 1

26. Oktober

Workshop Day

JCON 2017Agile Day

Architecture Day

Normalpreis249 €


199 €

2-TAGES-PASS

TAG 1 - 2

24. - 25. Oktober

Java & EclipseStarter Day

Best-Practice Day


Normalpreis449 €


349 €

JUG-Mitglieder

FREI !

3-TAGES-PASS

TAG 1 - 3

24. - 26. Oktober

Alle Sessions derXDEVCON 2017

JCON 2017

Normalpreis499 €


399 €

JUG-Mitglieder

199 €

Alle Preise verstehen sich zzgl. der gesetzl. MwSt.

33JAVA-PRO.DE 2-2017

#JAVAPRO #Container #Mesos

Container Orchestrierungmit Apache Mesos Cluster-Infrastrukturen sind heute sehr viel komplexer als noch vor 10 Jahren.

Microservices, Container und Big-Data-anwendungen stellen hohe anforderungen

an die Infrastruktur. Container allein reichen jedoch nicht aus. Mit Container-Or-

chestrierungs-systemen wie DC/Os auf Basis von Mesos lassen sich Container

managen, überwachen, warten, Prozesse automatisieren und ganze Cluster

ausfallsicher betreiben.

Autor:

Dr. Jörg Schad ist Distributed Systems Engineer bei Mesosphere in Hamburg und arbeitet an Apache Mesos und DC/OS. In seinem früheren Leben entwickelte er und verteilte In-Memory-Datenbanken bzw. forschte im Hadoop- und Cloud-Umfeld.

Johannes Unterstein organisiert die Java User Group in Kassel, lehrt an der DHBW Stuttgart und arbeitet als Distributed Applications Engineer bei Mesosphere. Früher hat er in Projekten für DAX30-Unter-nehmen gearbeitet und die Welt der Online-Wahlen modernisiert.

eue Microservices-Architekturen, Container und Big-Da-ta-Anwendungen haben auch die Anforderungen und

den Umgang mit der Cluster-Infrastruktur verändert. Die Anzahl und oft dynamische Skalierung dieser Services macht eine stati-sche und manuelle zuweisung auf einzelne Rechner im Cluster nicht praktikabel. Daher rücken Cluster- und Container-Manage-ment-Systeme in den Fokus von Entwicklern und Administra-toren. ziele hierbei sind häufig automatisches Deployment, Skalierung von Anwendungen, ein schnelleres Feedback für Entwickler sowie außerdem eine bessere Ressourcen-Auslastung im Cluster. Weiterhin ist eine höhere Fehlertoleranz und Flexibi-lität gegenüber Lastspitzen zu beobachten, da Container dyna-misch auf Servern verteilt werden können (Abb. 1).

N

CLOUD & CONTAINER

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates.

cloud.oracle.com/database

or call 1.800.ORACLE.1

…or Back to Your Data Center

Push a ButtonMove Your Database

to the Oracle Cloud

Same Database

Same Standards

Same Architecture

Fonts: Univers LT Std. 75 Black, 65 Bold, 55 Roman, 45 Light,

67 Bold Condensed, 57 Condensed

PRODUCTION NOTES

VENDOR NOTE: Please use center marks to align page.

Please examine these publication materials carefully.

Any questions regarding the materials, please

contact Darci Terlizzi (650) 506-9775

READER

01LASER% RELEASED

7/28

2015

Resize

210mm x 297mmPrint

Job #:

Headline:

Live:

Trim:

Bleed:

M_415M_CLD00282_PushButton_DB

Push a Button - Move Your DB to the O Cld

10mm around

210mm x 297mm

216mm x 303mm


Cluster-Infrastrukturen sind heute viel komplexer

Die Welt vor 10 Jahren war, zumindest aus der Sicht der meisten Cluster-Infrastrukturen, noch einfach: Es gab häufig nur wenige verteilte Anwendungen. Daher war es zum Beispiel nicht unüb-lich einen dedizierten Hadoop-Cluster zu betreiben sowie einen dedizierten Cluster für eigene Web-Anwendung. Die heutige Welt sieht da schon etwas komplexer aus. Wir haben eine wach-sende Anzahl an Big-Data-Anwendungen, wie zum Beispiel Apache Spark, Apache Cassandra, Apache Flink, die alle gerne eine große Anzahl an Cluster-Ressourcen für sich beanspruchen würden. Außerdem ist da noch der Trend zu Microservices, die es kleinen Teams erlauben ihren Teil des Systems als unabhän-gigen Service zu entwickeln. Dies führt häufig zu einer höheren Entwicklungsgeschwindigkeit, da Teams unabhängig vonein-ander entwickeln, testen und releasen können. Es bedeutet aber auch, dass jetzt viele kleine Microservices in der Infrastruktur deployt, skaliert und verwaltet werden müssen. Auch verstärkt dieser Trend das Problem der Abhängigkeitsverwaltung, denn häufig haben die verschiedenen Microservices unterschiedliche Abhängigkeiten, zum Beispiel unterschiedliche JRE-Versionen oder verschiedene Python-Bibliotheken.

Container allein reichen nicht aus

Um diesem Problem Herr zu werden, haben sich Container durchgesetzt, die es erlauben Anwendungen samt ihren Abhän-gigkeiten in ein Paket zu verpacken - dem Container. Dieser kann schnell, unabhängig und effizient deployt werden. Cont-ainer Runtimes, wie zum Beispiel Docker, erlauben daher eine Anwendung auf dem eigenen Laptop zu entwickeln, diese dann in einen Container zu verpacken und den Container dann auf einer völlig anderen Test- oder Produktivumgebung zu starten. Insbesondere Java-Entwickler sollten hier den einen oder anderen Fallstrick bei der Kombination von Java und Containern beachten. Es ist zum Beispiel so, dass der maximale Speicherver-brauch vom Kernel hart begrenzt wird. Wenn ein Container zu viel Speicher verbraucht, wird er einfach vom Kernel gestoppt und nicht, wie man es als Java-Entwickler gewohnt ist, mit einem

java.lang.OutOfMemoryError beendet. Da die JRE außer-halb des Heap-Memory noch weiteren Speicher benötigt, zum Beispiel für kompilieren, Thread-Verwaltung oder NIO, empfiehlt es sich die Speicher-begrenzung des Containers auf mindestens das einein-halbfache der maximalen Heap-Größe zu setzen. Eine weitere Herausforderung besteht darin, dass die JRE viele Standardwerte wie zum Beispiel die Anzahl der Garba-

ge-Collection-Threads abhängig von der Anzahl der Prozessoren setzt und je nach JRE-Version nicht die Umstände des Containers beachtet. Daher kann es passieren, dass eine Java-Anwendung, die einwandfrei auf einem Entwicklungs- oder Testsystem läuft, plötzlich auf einem 32-Core-Produktivsystem nur noch mit Umschalten zwischen verschiedenen Threads beschäftigt ist, weil unter falschen Annahmen operiert wird.

Die Anforderungen an einen Container sind vielseitig

Von einem einzelnen Container, der auf einem beliebigen System gestartet werden kann, ist es noch ein weiter Weg bis zu einem Produktivsystem, in dem viele Microservices produktiv betrieben und skaliert werden können. So hätten wir in Produktionssze-narien zum Beispiel gerne, dass unser Container automatisch nach Fehlern oder sogar dem gesamten Ausfall eines Rechners neu gestartet wird. zudem müssen unsere verschiedenen Micro-services, die ja jetzt in Containern auf verschiedenen Servern laufen, irgendwie miteinander kommunizieren können. Die großen Herausforderungen in diesen hochdynamischen Umge-bungen sind die Platzierung von Containern, die Verwaltung von Ressourcen-Limitierung und die Verwaltung der Container. Eine Übersicht über die verschiedenen Herausforderungen gibt Tabelle 1.

Scheduling Ressourcen-Verwaltung

Container-Verwaltung

•PlatzierungderContaineraufServer

•SkalierungderAnzahlderContainer

•AutomatischesNeustartenimFallvonFehlern

•Upgrades/Downgrades(ohnedenNutzerzubeeinflussen)

•Memory•CPU•GPU•Volumes•Ports•IPs

•Labels•Gruppen•Abhängigkeiten•Load-Balancing•Service-Discovery

•Health-Checks

Anforderungen an Container und an die Container-Orchestrie-rung. (Tabelle 1)

Verbesserung der Ressourcen-Auslastung durch Multiplexing. (Abb. 1)

CLOUD & CONTAINER

Container-Orchestrierungs-Systeme lösen das Problem

Hierzu kommt jetzt ein Container-Orchestrierungs-System wie zum Beispiel DC/OS ins Spiel. DC/OS steht für Datacenter Operating System und ist ein Open Source Projekt, welches um den Cluster-Manager Apache Mesos und das Container-Orche-strierungs-Tool Marathon gebaut ist. DC/OS ermöglicht das Verwalten von Containern und Anwendungen. zudem erlaubt es DC/OS dem Benutzer, einfach Container zu starten und bietet zahlreiche Konfigurationsoptionen, wie beispielsweise Ressour-cen-Limitierung, Anzahl der laufenden Instanzen, Health-Checks oder Upgrade-Strategien. Weiterhin ist es möglich zu definieren, wie die Container im Cluster verteilt werden sollten, dass Cont-ainer Abhängigkeiten zueinander besitzen oder, dass Container bestimmte Netzwerkkonfigurationen beinhalten sollen. Man kann aber auch definieren, dass pro Agent z.B. nur ein Cont-ainer laufen darf oder, dass alle Container auf einem Agenten mit einem bestimmten Kriterium laufen müssen.

Container-Überwachung durch Health-Checks

Weiterhin ist es möglich Health-Checks zu definieren. Ein Health-Check kann als HTTP-Endpunkt, TCP-Check oder in Form von Shell-Skripts innerhalb des Containers definiert sein. Diese Health-Checks werden periodisch ausgeführt. Sollte ein Health-Check öfter als erlaubt nicht bestanden werden, wird Marathon die Instanz erneut starten.

DC/OS besteht aus über 30 Projekten

DC/OS ist allerdings mehr als Mesos und Marathon. DC/OS ist eine Bündelung von mehr als 30 Open-Source-Projekten zu einer Distribution mit gemeinsamer Roadmap, Dokumentation, Security-Konzept, Benutzeroberfläche, Tutorials und Design. Die enthaltenen Komponenten sind aufeinander abgestimmt und stellen eine Sammlung von Best-Practices vieler Installationen dar. DC/OS wird als vorgefertigte Distribution für CentOS, RHEL und CoreOS sowie als lokale Variante und für diverse Cloud Provider bereitgestellt. Unter https://dcos.io/install/ kann eine vollstän-dige Liste der Installationsmöglichkeiten eingesehen werden. Mittels AWS (Amazon Webservices) Cloudformation-Templates ist es möglich, ein vollwertiges DC/OS-Cluster mit wenigen Klicks zu installieren und in Betrieb zu nehmen.

Im Dashboard laufen alle Informationen zusammen

Der Einstiegspunkt nach dem Login ist das DC/OS-Dashboard. (Abb. 2) zeigt das Dashboard und es wird eine aggregierte Ansicht des Clusters dargestellt. Es werden alle Informationen bereitgestellt um eine qualifizierte Aussage über den zustand des Clusters zu treffen, nämlich die aggregierte Ressourcenaus-lastung (CPU, Arbeitsspeicher und Festplattenplatz), wie viele Anwendungen laufen und ob alle laufenden Anwendungen die konfigurierten Health-Checks bestehen. Die Information, wie viele physische oder virtuelle Server in diesem Cluster vorhanden sind, ist nur ein Detail und eigentlich auch nur interessant, wenn einer der anderen Parameter nah an der maximalen Auslastung ist.

Container per Skript erzeugen und deployen

Unter dem Services-Bereich verbirgt sich Marathon. Mara-thon ermöglicht es, einen einzelnen Container oder eine Gruppe von Containern mittels JSON (JavaScript Object Nota-tion) zu beschreiben und zu deployen. (Listing 1) zeigt eine gekürzte Konfiguration, welche eine Serviceland-schaft beschreibt, die aus drei Java-Anwendungen, einer JavaScript-Anwendung und einem internen Proxy besteht. Der vollständige Code ist auf GitHub veröffentlicht. Diese Konfiguration beschreibt viele der bisher vorge-stellten Konzepte. So ist zum Beispiel eine Abhängigkeit Im DC/OS-Dashboard laufen alle Informationen zusammen. (Abb. 2)

CLOUD & CONTAINER


vom Checkout-Service auf den Basket-Service definiert und alle beschriebenen Container haben Ressourcen-Limitierung in Bezug auf CPU, Arbeitsspeicher, Festplatte und Ports. Service-Discovery wird am Beispiel einer Virtuellen IP (VIP) gezeigt. Die Definition einer VIP hat die Publizierung eines DNS-Eintrags zur Folge, welcher über einem Load-Balancer verfügbar gemacht wird. Sollte eine Anwendung also skaliert werden, beispielhaft in (Abb. 3) gezeigt, dann werden alle Requests mittels des Load-Balan-cers an die laufenden Anwendungen verteilt. Weiterhin werden Health-Checks und verfügbare Umgebungsvariablen definiert, so wie das Verhalten im Falle eines Upgrades, welches hier ein Rolling-Upgrade ist. Ein klassisches Blau/Grün-Upgrade wäre ebenfalls möglich. Für Anwendungen die in verschiedenen Umgebungen laufen, zum Beispiel lokal und produktiv, ist es sehr wichtig umliegende Anwendungen und sonstige Parameter extern konfigurieren zu können, damit Container auch wirklich portabel sind. In diesem Beispiel werden die Host-Namen der anderen Anwendungen per Umgebungsvariablen konfiguriert.

Listing (1) - Konfiguration

{ „id“:“brewery“, „apps“:[ { „id“:“articleservice“, „cpus“:0.5,„mem“:256, „instances“:1, „container“:{ „type“:“DOCKER“, „docker“:{ „image“:“unterstein/dcos-microservices-article“, „network“:“BRIDGE“, „portMappings“:[ { „hostPort“:0,„containerPort“:8081, „protocol“:“tcp“, „labels“:{„VIP_0“:“articleservice:8081“ } } ] }

}, „upgradeStrategy“:{„minimumHealthCapacity“:0.85, „maximumOverCapacity“:0.15 }, „healthChecks“:[ { „protocol“:“HTTP“, „path“:“/articles/“, „portIndex“:0, „timeoutSeconds“:10, „gracePeriodSeconds“:10,„intervalSeconds“:2, „maxConsecutiveFailures“:10 } ] }, { „id“:“basketservice“, „cpus“:0.5,„mem“:256, „instances“:1, „container“:{ „type“:“DOCKER“, „docker“:{ „image“:“unterstein/dcos-microservices-basket“, „network“:“BRIDGE“, „portMappings“:[ { „hostPort“:0,„containerPort“:8082, „protocol“:“tcp“, „labels“:{„VIP_0“:“basketservice:8082“ } } ] } }, ... }, { „id“:“checkoutservice“, „dependencies“:[ „/brewery/articleservice“, „/brewery/basketservice“ ], „cpus“:1,„mem“:256, „instances“:1, „container“:{

Skalierung. (Abb. 3)

CLOUD & CONTAINER

Links:

„type“:“DOCKER“, „docker“:{ „image“:“unterstein/dcos-microservices-checkout“, „network“:“BRIDGE“, „portMappings“:[ { „hostPort“:0,„containerPort“:8083, „protocol“:“tcp“, „labels“:{„VIP_0“:“checkoutservice:8083“ } } ] } }, ... „env“:{ „HOST_ARTICLESERVICE“: „articleservice.marathon.l4lb.thisdcos.directory“, „HOST_BASKETSERVICE“: „basketservice.marathon.l4lb.thisdcos.directory“ } }, { „id“:“webservice“, „cpus“:0.1,„mem“:256, „instances“:1, „container“:{ „type“:“DOCKER“, „docker“:{ „image“:“unterstein/dcos-microservices-web“, „network“:“BRIDGE“, „portMappings“:[ { „hostPort“:0,„containerPort“:80, „protocol“:“tcp“, „labels“:{„VIP_0“:“webservice:80“ } } ] } }, ... }, { „id“:“proxy“, „dependencies“:[ „/brewery/articleservice“, „/brewery/basketservice“, „/brewery/checkoutservice“, „/brewery/webservice“ ], „cpus“:0.1,„mem“:256, „instances“:1, „container“:{ „type“:“DOCKER“, „docker“:{ „image“:“unterstein/dcos-microservices-proxy“, „network“:“BRIDGE“, „portMappings“:[ { „hostPort“:0,„containerPort“:80,

„protocol“:“tcp“ } ] } }, „env“:{ „HOST_ARTICLESERVICE“: „articleservice.marathon.l4lb.thisdcos.directory“, „HOST_BASKETSERVICE“: „basketservice.marathon.l4lb.thisdcos.directory“, „HOST_CHECKOUTSERVICE“: „checkoutservice.marathon.l4lb.thisdcos.directory“, „HOST_WEBSERVICE“: „webservice.marathon.l4lb.thisdcos.directory“ }, ... } ]}

Ausfallsicherheit erfordert die Berücksichtigung zahlreicher Konzepte

Nachdem wir unsere Applikation erfolgreich gestartet haben, kommt in Produktions-Szenarien aber noch ein zentraler und wichtiger Punkt hinzu: Wie können wir den Service ohne Unter-brechung verfügbar halten und das trotz Cluster-Upgrades (inklusive DC/OS-Upgrades), neuen Anwendungs-Updates und Server-Ausfällen in unserem Cluster? Die Aufgaben, auch manchmal als Day2-Operations bezeichnet, lassen sich grob in die Kategorien Maintenance, Debugging, Metriken und Logging einteilen. Maintenance umfasst Themen die mit der Wartung der Applikationen und des eigentlichen Clusters zusammen-hängen. zum Beispiel das Deployment von neuen Versionen der Applikation oder auch ganzen Cluster Upgrades, während die Anwendung selbst für die Nutzer verfügbar bleibt. Debugging beschäftigt sich mit der Identifikation und Lösung von Prob-lemen. Da jetzt Container auf beliebigen Servern laufen, brau-chen Nutzer einen einfachen Weg diese Container unabhängig von ihrem Ausführungsort inspizieren zu können. Metriken sind wichtig um sowohl die Auslastung des Clusters zu messen, als auch um potentielle Probleme frühzeitig zu erkennen. Quellen für Metriken umfassen das System (zum Beispiel DC/OS), die Container und natürlich auch die Applikation selbst. Logging ist sowohl für das Debuggen von Problemen wichtig, als auch um später bei einem Audit feststellen zu können, wer welche Ände-rungen vorgenommen hat. Bei all diesen Themen ist wichtig, dass diese schon bei der Konzeption eines Systems berücksich-tigt werden sollten, anstatt diese erste später hinzuzufügen.

http://dcos.iohttp://mesos.apache.org/https://mesosphere.github.io/marathon/https://github.com/unterstein/dcos-microservices

CLOUD & CONTAINER


#JAVAPRO #Serverless #AWSLambda

Serverless – Funktionen ohne Server mit AWS Lambda Nicht nur die softwareentwicklung, sondern auch der IT-Betrieb ist einer ständigen

weiterentwicklung unterworfen. Ohne eine Virtualisierung geht nicht nur in Java

heute gar nichts. Mit Aws-Lambda gibt es jetzt die Möglichkeit der serverlosen

Datenverarbeitung um sich bei der Umsetzung auf die Umsetzung der Anforde-

rungen und nicht um den Betrieb von Infrastrukturen zu kümmern.

Autor:

Frank Pientka arbeitet als Principal Software Architect bei der MATERNA GmbH in Dortmund und sorgt für mehr Qualität in der Software. Als Gründungsmitglied des iSAQB sorgt er für eine verbesserte Ausbildung und zertifizierung von Architekten. Seit mehr als zwei Jahrzehnten unterstützt er Firmen bei der Umsetzung tragfähiger Software-Architekturen und begleitet sie auf ihrem Weg in die Cloud.http://blog.materna.de/author/frank-pientka/[email protected]://mobile.twitter.com/fpientka

Diese Variante verspricht in der Kombination mit den anderen AWS-Diensten, dass man sich als Entwickler rein auf die Umset-zung von ereignisgesteuerten Funktionen konzentrieren kann und sich nicht mit der Wartung der Infrastruktur beschäftigen muss. Für den Einstieg in die Entwicklung einer Lambda-Funk-tion mit Node.js reicht ein einfacher Browser und ein AWS-Konto. Die ersten eine Million Anforderungen und 400.000 GB/s verar-beiteten Daten sind in jedem Monat kostenlos. zusätzliche Gebühren können anfallen, wenn Ihre Lambda-Funktion andere AWS-Services nutzt, Daten übertragen oder die jährliche kosten-lose Testphase abgelaufen ist. Für bestimmte Kontingente bleiben zum Beispiel für AWS-Lambda, Step-Functions und X-Ray auch danach kostenlos, jedoch nicht für das API oder IoT-Gateway.

Die Evolution der Cloud mit FaaS

Seit vor über einem Jahrzehnt das Cloud-Angebot Amazon Web Services (AWS) erschienen ist, hat sich die Anzahl und die Art der von AWS angebotenen Services verhundertfacht. War man am Anfang schon zufrieden, dass man sich nicht mehr um Rechner- und Speicherressourcen kümmern musste, sondern direkt in seine dort installierten virtuellen Maschinen loslegen konnte, stieg mit der Nutzung auch der Bedarf nach höherwertigen Diensten. Als neue Variante nach IaaS, PaaS und CaaS gibt es jetzt seit 2014 AWS-Lambda¹, das allgemein als FaaS (Function as a Service) bezeichnet wird (Abb. 1).

CLOUD & CONTAINER

FaaS als neuer Clouddienst Abbildung. (Abb. 1)

Was ist eine serverlose Datenverarbeitung?

Mit dieser rein verbrauchsabhängigen Abrechnung wird man in vielen Fällen weniger bezahlen, als für eine nur schwach ausgelastete virtuelle Maschine, bei der man je nach Bereitstel-lung zusätzliche verbrauchsabhängige Kosten hat. Wenn kein Code ausgeführt wird, fallen bei Lambda also keine Kosten an.

Ein weiterer Vorteil ist, wenn man AWS-Plattformdienste nutzt, dass man sich auch nicht um die Wartung, Aktuali-sierung oder Skalierung dieser Dienste kümmern muss. Denn, wie sich AWS CTO Werner Vogels ausdrücke: „Kein Server ist so einfach zu verwalten, wie überhaupt kein Server“. Auch ThougtWorks hat das Thema serverlos in seinem neuesten Technology-Radar² aufgenommen und auch in einem Grundlagenartikel von Mike Roberts beschrieben.

Der typische Aufbau einer serverlosen Architektur sieht wie folgt aus: Es gibt eine Funktion, die aufgrund eines Ereignisses in einem bestimmten Kontext gestartet wird und Geschäftslogik oder andere Backend-Dienste aufruft. Dessen Ergebnis wird dann asynchron zurückgeliefert. Es kann jedoch auch nur der Start eines Batch-Programmes sein.Eine Lambdafunktion darf selbst keine zustände verwalten. zum Abspeichern von Ergebnissen werden weitere AWS-Dienste, wie das Dateisystem S3 oder eine Datenbank wie DynamoDB benö-tigt (Abb. 2).

AWS-Lambda Funktionen können in Node.js (JavaScript), Python, Java und C# (.NET Core) umgesetzt werden. Für Java bzw. C# gibt es mit AWS-Toolkit-for-Eclipse bzw. AWS-Toolkit-for-Visual Studio auch eine Integration in deren beliebteste IDE.

Von vielen AWS-Diensten können Ereignisse verarbeitet und selbst wieder veröffentlicht werden. zu den aktuell unterstützten AWS-Diensten gehören Amazon-Simple-Storage-Service (S3), DynamoDB, API-Gateway, Kinesis-Streams, Amazon-Simple-No-tification-Service, Simple-Email-Service, Cognito, CloudForma-tion, CloudWatch , CodeCommit, Config, Echo und Lex (Abb. 3).

Funktionen einer serverlosen Plattform

Da die Ausführung einer Lambda-Funktion selbst nicht immer garantiert werden kann und weil die Log-Ausgaben und API-Auf-rufe mit CloudTrail protokolliert werden, wird für eine größere AWS-Anwendung mit mehreren Funktionen und Services eine Überwachungs- und Tracing-Lösung, wie AWS-CloudWatch und AWS-X-Ray benötigt. Obwohl sich jede Änderung an der Lambda-Version automatisch pensioniert gestaltet, wird zum reinen API-Management das Amazon-API-Gateway benötigt. Das API-Proxy hilft beim Erstellen, Veröffentlichen, Warten,

Überwachen und Absichern der angebotenen REST-Ser-vices. zusätzlich kann es auch die Autorisierung, zugriffs-steuerung, ebenso wie das Monitoring und Versionsma-nagement der Services über-nehmen. Gerade bei verteilten Diensten ist es wichtig einen Gesamtüberblick zu behalten und im Fehlerfall nachvoll-ziehen zu können, wo der Engpass oder Fehler ursäch-

lich aufgetreten ist, um nicht nur die Symptome zu behandeln, sondern das Problem an der Quelle lösen zu können. Mit X-Ray kann man seine eigene Anwendung um spezielle Trace-Aus-gaben mit einer eindeutigen Korrelations-ID versehen.

CLOUD & CONTAINER

Elemente einer Lambda-Funktion. (Abb. 2)

Lambda in Aktion mit weiteren AWS-Diensten. (Abb. 3)


Durch diese Gasse muss alles

Doch was sind typische Anwendungsfälle für serverlose Archi-tekturen? Da sind die für mobile Apps oder IoT-Clients bereitge-stellten Backend-for-Frontend-Dienste. Damit können entweder bestehende Backend-Dienste mit neuen geeigneten Schnitt-stellen und Protokolle angeboten werden, ohne die bisherigen Dienste anpassen zu müssen oder auch davon entkoppelt weiter-entwickelt werden. Ein beliebtes Muster ist hier das Gateway. Dieses wird von Amazon sowohl zum Management der API, als auch für IoT-Geräte angeboten. Unterstützt das API-Gateway nur REST-Endpunkte, werden vom Device-Gateway zusätzlich die Protokolle MQTT und WebSockets unterstützt. Vor allem kann das Device-Gateway mit einer sehr hohen Anzahl von Geräten umgehen und kümmert sich um dessen Verwaltung. Gerade das API-Gateway ist für die meisten Lambda-Funktionen gesetzt, da es die Entwicklung und den Betrieb von Lambda-Funktionen erleichtert. Neben einer Versionierung, kann auch die Dienstgüte und die Sicherheit der Lambda-Funktionen an einer Stelle einfa-cher realisiert werden. Das API-Gateway unterstützt Mock-Inte-gration für API-Methoden. Damit ist es möglich, Testdaten für API-Antworten im API-Gateway zu hinterlegen, ohne dass die entsprechende Backendlogik bereits implementiert ist. Damit können Entwicklungsteams voneinander entkoppelt arbeiten.

Das Amazon-API-Gateway unterstützt den Import und Export von Swagger-Definitionen. Als Quasi-REST-Standard (die darauf basierende Open API Spezifikation³ 3.0 ist gerade in Arbeit) gibt es für Swagger in über 40 Sprachen Client-Bibliotheken. So lassen sich aus der API-Beschreibungen die Client-Rümpfe gene-rieren oder in der Swagger-Oberfläche schon mal testen.

Anwendungsfälle für serverlose Referenzarchi-tekturen

Neben Mobile-Back-Ends und IoT-Back-Ends, die eh schon oft nachrichtenbasierten Informationsaustausch haben, sind sicher

auch Teilfunktionen von Web-Anwendungen typische Einsatz-gebiete von Lambda-Funktionen. So können Lambda-Funkti-onen über AWS-SNS-Push-Benachrichtigungen, E-Mails und SMS-Nachrichten asynchron versenden. Da gerade der Ressour-cenbedarf für solche Nachrichten stark schwanken kann, profi-tieren diese Dienste von der dynamischen Skalierbarkeit und den verbrauchsabhängigen Kosten von Lambda.

Mit den durch Amazon-Alexa (die sprechende Lautsprecherbox) bzw. Lex (T2S, S2T-Konversationsdienste) beliebt gewor-dene Sprachsteuerung werden Chatbots immer populärer. Da diese bereits Cloud-Dienste nutzen und letztendlich wiederum einen Cloud-Dienst aufrufen, sind diese quasi prädestiniert für die Verwendung von Lambda. Da AWS mit Recognition einen eigenen Dienst für eine Bildanalyse anbietet, kann auch diese von Lambda genutzt werden (Abb. 4).

Für die Verarbeitung oder Umwandlung von großen Daten-mengen bietet sich Lambda in Kombination mit anderen AWS-Data-Diensten an. Neben einer einfachen Dateiverarbei-tung mit S3, kann Lambda auch Dienste von AWS-Kinesis zum Laden und Analysieren von Streaming-Daten nutzen.

Da Lambda-Funktionen selbst zustandslos sind und damit keine eigene Datenhaltung haben, müssen diese ihre Ergeb-nisse in Backend-Systemen speichern, wenn diese von anderen, darauf aufbauenden Funktionen genutzt werden sollen. Mit AWS-Step-Functions können einfache Arbeitsschritte von einzelnen Lambda-Funktionen grafisch modelliert und orchest-riert werden. Je nach definiertem zustand werden dann Folge-funktionen aufgerufen.

Anwendungsfälle mit einem Architekturdiagramm und Beispiel-Code finden sich auf der jeweiligen AWS-Github-Seite, wo diese aktualisiert und weiterentwickelt werden. Für den tieferen Einstieg gibt es eine ausführliche und mit Beispielen vorbildlich erstellte Dokumentation von Amazon zu Lambda. Abgerundet

Hochgeladene Bilder analysieren, verschlagworten oder kontrollieren mit AWS-Lambda und Rekognition (Quelle AWS). (Abb. 4)

CLOUD & CONTAINER

Links:

wird das durch vertiefende Whitepaper4, aktuellen Blogbeiträgen oder Präsentationen, die neue Verwendungsmöglichkeiten beschreiben.

Serverlose Entwicklung und Deployment

Da man bei komplexeren serverlosen Anwendungen mit vielen genutzten Diensten schnell den Überblick verlieren kann und auch die regelmäßigen Deployment-Schritte nur automatisiert sinnvoll sind, gibt es auch hier hilfreiche Erweiterungen. Eine Deployment-Vorlage lässt sich mit dem AWS-Serverless-Appli-cation-Model (AWS-SAM) in einem Designer grafisch erstellen und mit CloudFormation automatisiert ausführen. Damit ist man nicht mehr, wie bei den ersten Schritten mit AWS-Lambda, darauf angewiesen die Konfiguration über die AWS-Web-Kon-sole vorzunehmen.

(Listing 1)

AWSTemplateFormatVersion:‚2010-09-09‘Transform:‚AWS::Serverless-2016-10-31‘Resources: MyFunction: Type: ‚AWS::Serverless::Function‘ Properties: Handler: index.handler Runtime:nodejs4.3 CodeUri:‚s3://my-bucket/function.zip‘

AWS SAM Beispielvorlage.

CodeBuild und CodePipeline ergänzen CloudFormation, um die einzelnen Schritte zum Bauen, Testen und Paketieren von server-losen AWS-Anwendungen zu automatisieren. Bis auf die lokale Entwicklungsumgebung und eine gute Netzanbindung, braucht man keine eigene Infrastruktur um serverlose Anwendungen zu entwickeln, da Amazon diese kostengünstig zur Verfügung stellt.

Mit dem Open-Source-Projekt Serverless-Framework, kann das Deployment und das Testen von serverlosen Anwendungen nicht nur von AWS-Lambda, sondern auch mit seinen Konkurrenten MS-Azure und IBM-OpenWhisk, vereinfacht werden. Dadurch, dass dieses Deployment-Framework produktunabhängig ist, lässt es sich durch eigene oder fremde Plugins auch an die eigenen Bedürfnisse anpassen und so den eigenen Deployment-Prozess optimieren. Beim Bau von serverlosen Architekturen können die fünf im Buch „Serverless Architectures on AWS“ von Peter Sbarski beschriebenen Muster für Command, Messaging, Priori-ty-Queue, Fan-out, Pipes-and-Filter hilfreich sein.

Besonders spannend, gerade für den IoT-Bereich, ist die Verknüpfung zwischen lokaler Vorverarbeitung auf dem Gerät und der Nutzung serverlosen Funktionen. Mit AWS-Green-grass kann AWS-Lambda-Code lokal ausgeführt werden. Dazu muss auf einem Linux-Gerät, wie zum Beispiel der Raspberry Pi, Greengrass-Core installiert werden. Die Programmierung

erfolgt mit dem Greengrass-Device-SDK, welches das beste-hende AWS-IoT-Device-SDK erweitert. Durch die lokale Daten-vorverarbeitung wird für die Datenübertragung weniger Band-breite benötigt und die gesamte Übertragungszeit reduziert sich. Damit ist es auch einfach möglich auf zeitweise Netzausfälle reagieren zu können. Auch höhere Sicherheitsanforderungen können damit umgesetzt werden, da zum Beispiel nicht mehr individualisierte Daten, sondern nur deren berechneten Ergeb-nisse weitergegeben werden.

Ausblick

Gewiss sind serverlose Architekturen nicht für jede Anwendung geeignet. Je mehr die Leistungsfähigkeit von Cloud-Diensten erkannt wird und damit deren Nutzung voranschreitet, sind serverlose Dienste aber eine gute Ergänzung zu bestehenden Ansätzen. Die Vielzahl und Reife der bereits unterstützten Dienste ist beeindruckend. Gerade bei neuen oder spezialisierten Anwendungsfällen in den Bereichen Mobile, IoT, Big-Data oder kognitive Dienste können diese recht schnell umgesetzt und produktiv evaluiert werden. Serverlose Architekturen machen andere Ansätze, wie zum Beispiel containerbasierte Microser-vices, nicht überflüssig sondern ergänzen diese hervorragend. Als einziger Schwachpunkt bleibt, dass man sich mit der inten-siven Nutzung, der von einem Cloud-Anbieter angebotenen Dienste mit serverlosen Anwendungen, stark abhängig von diesem macht. Wie bei jeder Architekturentscheidung sollte man sich deren Wechselwirkung bewusst sein, und sich nach einer Kosten-/Nutzen-/Riskobetrachtung entscheiden. Auf jeden Fall ist es sinnvoll, mit der serverlosen Architekturalternative erste Erfahrungen zu sammeln.

1 https://aws.amazon.com/de/lambda/2https://www.thoughtworks.com/de/radar/techniques/ serverless-architecture3https://github.com/OAI/OpenAPI-Specification4 http://d0.awsstatic.com/whitepapers/ AWS_Serverless_Multi-Tier_Architectures.pdf

AWS Lambda Developer Guidehttp://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-dg.pdfWhitepaperMehrstufigeAWS-ArchitekturenohneServermitAmazonAPIGatewayundAWSLambda,November2015http://d0.awsstatic.com/whitepapers/AWS_Serverless_Multi-Tier_Architectures.pdfReferenzarchitekturen und Beispiel-Codehttps://github.com/awslabs?utf8=%E2%9C%93&q=lambda-refarch&ty-pe=&language=AWS Serverless Application Model (SAM)https://github.com/awslabs/serverless-application-model Server-less Framework https://serverless.com/Kostenloses AWS-Nutzungskontingent (nicht auslaufende Angebote) https://aws.amazon.com/de/free/AWS Lambda Grenzen http://docs.aws.amazon.com/lambda/latest/dg/limits.htmlAWS Step Functions Grenzenhttp://docs.aws.amazon.com/step-functions/latest/dg/limits.html

CLOUD & CONTAINER

Donnerstag, 06. Jul i 2017

K u l t u r - u n d K o n g r e s s z e n t r u m L i e d e r h a l l e S t u t t g a r t

ca. 40 Aussteller

Mittwoch, 05. Juli 2017Workshop „Java für Entscheider“Eintägige Überblicksveranstaltung für Entscheider aus der IT oder IT- nahen Einsatzfeldern wie Abteilungs- oder Teamleiter, deren Mitarbeiter im Java Umfeld tätig sind oder sein sollen.

Donnerstag, 06. Juli 2017 JFS - Java Forum Stuttgart

Mit nun 20 Jahren Tradition ist das JFS zur festen Institution ge-worden. Das Forum bietet den Teil-nehmern die Möglichkeit, sich um-fassend über Themen zu Java bzw.

im JVM-Umfeld zu informieren. Die Breite wird erreicht durch Grund-lagenvorträge, Erfahrungsberichte und Informationen über konkrete Projekte. Produkte werden sowohl in Form von Vorträgen als auch als Demonstrationen an den Ausstel-lungsständen präsentiert.

Eine Veranstaltung der Java User Group Stuttgart e.V.

Besucheranmeldung

ab 19. April 2017

www.java-forum-stuttgart.de

max. 48 Fachvorträge

& zusätzlich einige

Pecha Kucha Kurz-Vorträge


#JAVAPRO #Mobile #MADP

Sichere Mobile-App-Bereitstel-lung erfordert PlattformansatzBei der Kommunikation mit Kunden und Geschäftspartnern führt kein weg an

mobilen Applikationen vorbei. Die Entwicklung und Integration der Anwendungen

in die Backend-systeme ist jedoch oft mit großem Aufwand verbunden. Traditi-

onelle, siloartige ansätze sind wenig hilfreich, vor allem neue Plattformlösungen

zeigen hier ihre stärken.

Autor:

Thomas Mitzka arbeitet seit 1995 als Datenbankadmi-nistrator, Entwickler und Systemadministrator. Mit der wachsenden Popularität von Java, hat er sich in der Entwicklung von Datenbank-Applikationen ganz auf die Kombination Java und SQL-Datenbanken fokus-siert. Der Einsatz der Java Persistence API ist hierbei ein Schwerpunkt und in der Praxis von ganz beson-derem Interesse.

geschaffen. Grund hierfür ist auch, dass sie meistens kein eigenes Mobile-Entwicklungsteam aufgebaut, sondern auf externe Dienstleister zurückgegriffen haben. Bei deren Entwicklungen standen in vielen Fällen aber weder IT-Standards noch Verfahren im Vordergrund, mit denen die Applikationen wirklich sicher im Unternehmen verankert werden können. Die fehlende Standar-disierung der bei der App-Entwicklung eingesetzten Technolo-gien hat dazu geführt, dass die Umsetzung von Sicherheitsricht-linien äußerst schwierig ist. Und aus IT-Architektur-Sicht muss klar gesagt werden: Eine solche Vorgehensweise ist nicht mehr zeitgemäß.

Ein Umdenken setzt ein

Es zeichnet sich aber eine Trendwende ab - und zwar hin zu einer zentralisierung, Standardisierung und Nutzung von Mobile-Ap-plication-Platforms. Eine ähnliche Entwicklung ist beispielsweise auch aus der Java-Welt bekannt. Früher konnte hier hinsichtlich der Software-Entwicklung mit einer gewissen Berechtigung von einem Wildwuchs gesprochen werden. Geändert hat sich dieser zustand erst mit dem Aufkommen von Java-EE-Application-Ser-vern, mit denen ein Rahmenwerk für die standardisierte Entwick-lung von Web-Anwendungen zur Verfügung stand.

Bei fast allen Mobile-Entwicklungen sind mehrere Herausfor-derungen zu berücksichtigen. Im Wesentlichen sind dabei zu nennen:• Backend-Integration• Heterogenität von Geräten und Betriebssystemen• Fragmentierung der Frontend-Technologien

obile-Apps haben das Potenzial, viele Unterneh-mens-Workflows effizienter und einfacher zu gestalten

und neue Geschäftsprozesse zu ermöglichen. Allerdings erweist sich die Erstellung mobiler Apps und die sichere Integration in die existierende IT-Infrastruktur in der Regel als erhebliche Herausforderung, da die meisten unternehmenskritischen ERP-, CRM-, BPM- oder Datenbank-Systeme in der Vergangenheit als monolithische Applikationen entwickelt wurden – Mobile Computing war zu dieser zeit noch kein Thema. Eine Erweiterung solcher Anwendungen zur Nutzung durch mobile Endgeräte erfordert deshalb eine kosten- und zeitaufwändige Überarbei-tung, umfangreiche Tests und eine Neuimplementierung des Programm-Codes zur Einbindung der mobilen App. Deutlich minimiert werden kann der Aufwand nur durch die Nutzung einer Plattformlösung.Vor allem große Unternehmen befassen sich schon seit Jahren mit Mobile-Computing und nutzen den mobilen Vertriebs-kanal. Vielfach haben sie mit unterschiedlichen Technologien und Ansätzen ein umfangreiches Spektrum von Applikationen

M

MOBILE APP DEVELOPMENT

• Sicherheit• Time-to-Market• Kontinuierliche Entwicklung und Bereitstellung

Leistungsspektrum einer Mobile-Application- Plattform

Um die wichtigsten Anforderungen im Hinblick auf eine reibungslose Einbindung mobiler Applikationen in die Unter-nehmensinfrastruktur zu erfüllen, sollte eine zukunftsweisende Mobile-Application-Plattform im Wesentlichen über vier grund-legende Funktionen verfügen: Unterstützung verbreiteter Platt-formen und Tools, effiziente Integration in unterschiedliche Backend-Systeme, integrierte Sicherheit und durchgängiges Lifecycle-Management.

Unterstützung gängiger Geräte und Tools

Durch die Heterogenität mobiler Geräte und genutzter Tools beziehungsweise Frameworks muss die Mobile-Application- Plattform ein breites Anwendungsspektrum bieten, das für Unter-nehmen sowohl lokal als auch in der Cloud nutzbar sein sollte. zunächst muss die Plattform Entwicklern die Möglichkeit bieten, die Frontend-Technologie ihrer Wahl zu verwenden. Im Hinblick auf JavaScript wären hier etwa Angular, Backbone, Ionic, Ember oder React zu nennen. Darüber hinaus sollte die Lösung zum Beispiel native SDKs für iOS, Android und Windows 10 Mobile sowie hybrides Apache-Cordova, HTML5, Titanium-Appcele-rator und Microsoft Xamarin unterstützen. Auch ein Support für integrierte Entwicklungsumgebungen (IDEs) wie Red Hat JBoss Developer Studio, WebStorm, Sublime Text, Komodo oder Micro-soft Visual Studio sollte gegeben sein.

Wichtig ist zudem, dass vorhandene mobile Anwendungen einfach und schnell importiert und zentral verwaltet werden können - unabhängig davon, ob es native, HTML5- oder hybride Applikationen sind. Auch Builds für mehrere Geräte sollten

unter-stützt werden, zum Beispiel für native und hybride Anwen-dun-gen im iOS-, Android- oder Windows-10-Mobile-Umfeld. Dadurch entfällt auch die Notwendigkeit zum Aufbau geräte-spe-zifischer Hardware- und Software-Umgebungen für die Entwick-lung neuer Anwendungen.

Nicht zuletzt ist es von Vorteil, wenn die Plattform auch Mög-lich-keiten für eine codelose Entwicklung bietet, zum Beispiel mit Drag-and-Drop-Entwicklungs-Tools, sowie Vorlagen zum schnellen Erstellen von Prototypen und mobilen Apps.

Backend-Integration

Im Hinblick auf die effiziente und sichere Integration mobiler Apps in die Unternehmensinfrastruktur haben sich in den letzten

Jahren vor allem Lösungen in Form eines Mobile-Backend-as-a-Ser-vice (MBaaS) bewährt. Eine Mobi-le-Application-Platform bietet deshalb idealerweise auch eine solche MBaaS-Funktionalität. Dabei handelt es sich um eine Cloud-basierte Middle-ware-Schicht, die Backend-Systeme und Frontend-Systeme entkoppelt, damit sich die Geräte nicht direkt mit den Backend-Systemen verbinden. Durch die Entkopplung der mobilen Endgeräte und der darauf laufenden Apps von den Backend-Systemen in den Rechenzentren ist die Basis für eine hohe Sicherheit geschaffen. zur Integration der mobilen Apps in die Backend-Systeme, beispielsweise in

Salesforce, SharePoint oder Oracle, stellt ein MBaaS RESTful-APIs zur Verfügung.

Darüber hinaus steuert der MBaaS Dienste wie Datenspeiche-rung und -verwaltung, Push-Benachrichtigungen, Analysen der Kommunikation zwischen Geräten und Backend-Systemen sowie die Benutzerverwaltung und stellt diese über einen Service-Ka-talog bereit. Dieses Modell hat zwei Vorteile: Erstens lässt sich die Wiederverwendbarkeit verbessern und zweitens können die mobilen Dienste einfacher verwaltet werden.

Ein derartiger Middleware-Schicht-Ansatz ist allein schon deshalb sinnvoll, da bei Legacy-Systemen oft noch Batch-Prozesse zu berücksichtigen sind, bei denen ein direkter Frontend-zugriff auf das Backend nicht möglich ist.

Integrierte Sicherheit

Eine sichere Verwendung von mobilen Geräten und ein hoher Schutz der Daten gehören zu den wichtigen Anforderungen an mobile Lösungen. Eine Mobile-Application-Plattform muss

MOBILE APP DEVELOPMENT

Das Leistungsspektrum der Red Hat Mobile Application Platform im Überblick.

47JAVA-PRO.DE 2-201746 JAVA-PRO.DE 2-2017

deshalb eine zentralisierte Steue-rung und Kontrolle der Sicherheit bieten, mit Features wie Verschlüs-selung, Schutz des zugriffs auf Backend-Systeme oder Benutzer-authentifizierung und -autorisie-rung. Auf dem Gerät sollten sich die in lokalen Caches befindlichen Daten verschlüsseln lassen. Die Übertragung von der Anwen-dung bis zum MBaaS erfolgt nach Möglichkeit über HTTPS. zudem sollte es möglich sein, bei Bedarf pro Anwendung einen API-Schlüssel hinzuzufügen. Authentifizierungs-APIs, Benutzer-berechtigungen oder ein X.500-, LDAP- oder Active-Directo-ry-System sorgen für die Verwaltung und sichere Authentifizie-rung der Benutzer. Der zugriff vom MBaaS auf Backend-Systeme muss im Einklang mit den Sicherheitsrichtlinien des Unterneh-mens realisierbar sein, zum Beispiel mit vollständig konfigu-rierten Standort-zu-Standort-VPNs, starken Firewalls oder DMzs.

Teamübergreifende Kooperation und Lifecycle Management

Nicht zuletzt sollte eine Mobile-Application-Platform auch eine team- und rollenbasierte zusammenarbeit unterstützen und ein durchgängiges Lifecycle-Management für mobile Anwendungen bieten. So sollte es möglich sein, dass Entwicklungs-Teams, die aus Mitarbeitern mit unterschiedlichen Kompetenzbereichen – User-Interface-Design, Frontend-Codierung, Backend-Ser-vice-Entwicklung oder Administration – bestehen, gleichzeitig an Anwendungsprojekten arbeiten, ohne dass die Agilität des einzelnen Entwicklers beeinträchtigt wird. Die Konfiguration detaillierter Kontrollen auf allen Ebenen eines jeden Mobile-Pro-jekts kann dabei für einen sicheren zugriff auf wichtige Projekt- und Produktkomponenten sorgen.

Mit einem integrierten Lifecycle-Management ist es möglich, mehrere Projektumgebungen wie Entwicklung, Text, Vorproduk-tion oder Produktion mit integrierter zugangskontrolle zu konfi-gurieren und zu verwalten.

Doch wann sollte ein Unternehmen eine solche Plattformlö-sung einsetzen? Man könnte hier auf Gartners „Rule of Three“ zurückgreifen, in der die Marktforscher Unternehmen empfehlen, die Nutzung einer Mobile-Enterprise-Application-Platform in Betracht zu ziehen, wenn• drei oder mehr mobile Applikationen unterstützt werden

müssen,• drei oder mehr mobile Betriebssysteme zu berücksichtigen

sind oder• eine Integration mit mindestens drei Backend-Datenquellen

erfolgen muss.

Allerdings zeigt der Plattformansatz bereits bei einer einzigen App seine Vorteile, zum Beispiel hinsichtlich Sicherheit oder der Unterstützung unterschiedlicher Push-Notifications. Und allein schon dieses Leistungsmerkmal ist von erheblichem Nutzen, da Microsoft, Apple und Google jeweils eigene Push-Netzwerke nutzen.

Im Hinblick auf die IT-zentralisierung und Standardisierung sollte somit auch im Umfeld der Entwicklung und Verwaltung mobiler Apps auf Plattformlösungen zurückgegriffen werden, die inzwischen mit hohem Funktionsumfang auf dem Markt verfügbar sind. Red Hat etwa bietet mit Red Hat Mobile Application Platform eine ganzheitliche Lösung für das Thema Enterprise-Mobility an. Sie unterstützt sowohl eine effiziente, Team-basierte Entwicklung von Apps, bei der Entwickler nicht auf eine bestimmte Fron-tend-Technologie eingeschränkt sind, als auch den Betrieb der notwendigen App-Dienste. Dazu zählen beispielsweise Caching, Data-Sync, Authentication, ein Rollenkonzept und ein MBaaS. Die Lösung bietet in Form von Node.js-basierten Services ein schlankes, ereignisgesteuertes I/O-Modell, das sich vor allem für mobile Apps hervorragend eignet. Red Hat Mobile Applica-tion Platform ist als gehostete Cloud- und auch als On-Premise- Lösung verfügbar. Damit können sowohl die Bedürfnisse von großen Unternehmen, die ihre Infrastruktur im eigene Rechen-zentrum betreiben möchten, als auch von kleinen und mittel-ständischen Firmen abgedeckt werden, die schnell und ohne großen Implementierungsaufwand eine Plattform nutzen wollen.

Insgesamt ist der Mobile-Markt von einer großen Heterogenität geprägt. Den damit verbundenen Herausforderungen hinsicht-lich Integration in die Unternehmensinfrastruktur mit isolierten Ansätzen zu begegnen, ist wenig zielführend. Deshalb sollten Unternehmen vor allem im Kontext der Anwendungsarchitektur auf offene Standards setzen und eine zentrale Mobile-Plattform etablieren. So können wiederverwendbare Dienste angeboten und ein zentrales Management der Apps umgesetzt werden. Damit steht einer sicheren und effizienten Mobile-Nutzung nichts mehr im Wege.

Screenshot Red Hat Mobile Application Platform. (Abb. 2)

#JAVAPRO #Agile

Agilität gestern und heute – Neue Herausforderungenerfordern neues DenkenDie Einführung agiler Methoden wie scrum geht immer mit Veränderungen einher.

Diese betreffen heute nicht mehr nur die Teamebene oder die Produktentwick-

lung, sondern sie beeinflussen die Mitarbeiter, das Management, Beurteilungssys-

teme und stellenbeschreibungen, sprich die gesamte Firmenstruktur und -kultur.

Autor:

Marion Eickmann ist Mitgründerin und Mitglied der Geschäftsführung von agile42. Seit über 15 Jahren ist sie im Bereich Softwareentwicklung und Projekt-management tätig. Aufgrund dieser Erfahrung ist es Marion Eickmann und ihrem internationalen Team möglich, seit 2007 erfolgreich agile Projekte lokal und global umzusetzen.

[email protected]: @agile42https://de.linkedin.com/in/marioneickmann/dehttps://www.xing.com/profile/ Marion_Eickmann

ynamische Marktveränderungen, wirtschaftliche Unsicher-heiten und technologische Umbrüche stellen Unter-

nehmen vor die Herausforderung schnell zu handeln. So wie sich Produktlebenszyklen insbesondere in der Technologiebranche verkürzen, verringern sich auch die Phasen, in denen mit neuen Produkten hohe Gewinne erzielt werden können. Die Verluste durch zu späten Markteintritt wiegen schwerer als höhere Kosten während der Entwicklung. Immer mehr Unternehmen wird bewusst, dass sie mit den bestehenden Prozessen zu langsam sind und agiler werden müssen. Agile Projektmanagement-Me-thoden wie Scrum setzen vor allem auf Flexibilität und Selbstbestimmung.

Scrum erobert neues Terrain

Als wohl bekannteste agile Methode kann Scrum inzwischen auf eine 20-jährige Erfolgsgeschichte zurückblicken. Ursprünglich angewendet in der Softwareentwicklung, wächst das Verfahren mehr und mehr über die IT hinaus und erobert auch andere Unternehmensbereiche, denn: Von der „strukturierten Selbstbe-stimmung“ profitiert nicht nur die Software-, sondern auch die Organisationsentwicklung. Scrum ist ein iterativer, inkremen-teller Prozess für die Produktentwicklung und die Organisation von Teams, der Mitte der 90er Jahre von Ken Schwaber und Jeff Sutherland entworfen wurde. Im Kern steht das Setzen auf eine hohe Eigenmotivation: Mit Scrum legt ein Team selbst fest, welche Aufgaben es wie erledigen kann. Kundenanforderungen werden iterativ priorisiert und sukzessive realisiert. ziel ist, Trans-parenz zu erreichen durch die frühzeitige und umfassende Einbeziehung des Kunden und die regelmäßige Kommunikation aller Beteiligten.

D Sportinteressierte dürften das Wort Scrum übri-gens aus einem ganz anderen Zusammenhang kennen: Es ist im Rugby die Bezeichnung für das „geord-nete Gedränge“ zum Wiederbeginn des Spiels nach einem Regelverstoß.

Die drei Scrum-Rollen

Im Gegensatz zu klassischen Projektmanagement-Methoden kennt Scrum weder Projektmanager noch Projekt- oder Team-leiter. Jedenfalls nicht dem Namen nach. Stattdessen arbeitet es mit drei wichtigen Rollen: Product-Owner, Scrum-Master und Team. Alle drei sind gleichgestellte Management-Rollen und haben bestimmte Verantwortlichkeiten:

AGILEMOBILE APP DEVELOPMENT


• Der Product-Owner ist verantwortlich für die Produktvision,die umfassende Vorstellung vom Endergebnis, die Erhebung und Priorisierung der Anforderungen, die Budget-Kontrolle und den Return-on-Investment.

• Der Scrum-Master räumt Probleme aus dem Weg, sorgt für die Einhaltung der Scrum-Regeln und schafft die nötigen Rahmenbedingungen für das Team.

Das Team ist in Scrum eine selbstorganisierte Einheit, die für die Erstellung und die Qualität des Produkts verantwortlich ist. Scrum-Projekte werden in Iterationen, sogenannte Sprints, aufgeteilt und haben in der Regel eine Länge von zwei oder vier Wochen. zunächst nimmt der Product-Owner die Anforde-rungen des Kunden und der Stakeholder auf. Diese werden in einem Plan, dem Backlog, erfasst und anschließend priorisiert. Im Sprint-Planning stellt der Product-Owner dem Team die Liste aller Anforderungen samt dazugehörigen Akzeptanzkriterien vor. Das Team findet durch gezielte Fragen heraus, was sich genau hinter den fachlichen Anforderungen verbirgt und schätzt grob den Aufwand. Anders als in klassischen Projektmanagement-verfahren schreibt man dem Scrum-Team nicht vor, wie viele Features es in einer bestimmten zeit realisieren soll. Stattdessen wählt das Team selbst aus, welche Funktionen es in einem Sprint für umsetzbar hält. Alle Anforderungen werden schließlich in einzelne Aufgaben heruntergebrochen und schriftlich festge-halten. Diese Aufzeichnungen werden täglich mit der Angabe über den jeweiligen Restaufwand versehen, so dass immer eine aktuelle grafische Übersicht vorhanden ist.

Am Ende eines Sprints präsentiert das Team dem Product-Owner und gegebenenfalls den Stakeholdern die implementierten Funktionen. Dieser entscheidet dann, ob alle Akzeptanzkriterien erfüllt sind und er die Lieferung abnimmt. Der Scrum-Master sorgt während des gesamten Prozesses für die Einhaltung der Regeln und wehrt Störungen von außen ab.

Von der Team- zur Organisationsebene

Methoden wie Scrum sind erprobt und zeichnen sich durch Transparenz und einfache Regeln aus. Allerdings wurden sie ursprünglich für kleinere Teams entwickelt, sie lassen sich nicht ohne weiteres skalieren. Dabei sind agile Pilotprojekte durchaus auch in großen Unternehmen erfolgreich. Häufig abgekoppelt von den übergreifenden Unternehmensstrukturen wird für diese Piloten der nötige Freiraum geschaffen, um sich auf die eigent-liche Produktwertschöpfung zu konzentrieren und so erreichen viele Piloten die gewünschten Ergebnisse. Der Einbruch kommt beim Versuch, die Ergebnisse aus den Piloten auf das Gesamt-unternehmen zu übertragen. Agiles Verständnis kollidiert dann mit bestehenden Strukturen und mit klassischem Unterneh-mensdenken. Ängste beim Management führen oft zu Wider-ständen, denn der Schritt vom Manager hin zum Agile Leader ist nicht trivial und erfordert ein ganzheitliches Umdenken im Unternehmen.

Grundsätze des Agilen Handelns verstehen

Deshalb ist der erste und entscheidende Schritt zur Agilität – noch vor dem Erlernen bestimmter Methoden – das Verständnis für die Prinzipien und Überzeugungen, die diesen Methoden zugrunde liegen. Dazu lässt sich ein Meta-Framework wie z. B. das Enterprise-Transition-Framework (ETF) von agile42 nutzen. Hier werden neue Methoden unter Berücksichtigung der Unter-nehmenskultur und der agilen Prinzipien eingeführt.

Agiles Arbeiten fußt auf Einstellungen und Handlungsweisen, die eine ständige Verbesserung ermöglichen. Es ist ein Wachs-tums- und Lernprozess, den jedes Team und jede Organisation durchlaufen muss, um ihren agilen Weg zu finden. Das Bild der Agile-Reading-Glasses beschreibt, wie sich im Vergleich zu herkömmlichen Ansätzen die Schwerpunkte verschieben: von der definierten zur empirischen Prozesskontrolle, von Push zu Pull. Lean-Thinking, iterative und inkrementelle Verbesserungen sind weitere Grundsätze.

Empirische versus definierte Prozesskontrolle

Bei der herkömmlichen, definierten Prozesskontrolle wird ein Gesamtprozess in Teilaufgaben untergliedert und anschließend die für jede Teilaufgabe benötigte zeit geplant. Kontrolliert wird die tatsächlich benötigte Arbeitszeit im Vergleich zur geplanten Arbeitszeit. Diese kostengünstigste Form der Kontrolle ist erfolg-versprechend bei einfachen wie komplizierten Prozessen. Sie setzt allerdings voraus, dass die notwendigen Arbeitsschritte in ihrer Abfolge schon genau bekannt und festgelegt sind, die zeit kann dann daraus abgeleitet werden. Bei neuen Entwicklungen muss aber zunächst herausgefunden werden, was genau zu tun ist. Es wird getestet, Erfolgsfaktoren und Wechselwirkungen sind noch gar nicht verstanden, Überflüssiges muss erst erkannt und eliminiert werden. Hier greift man auf die empirische Prozess-kontrolle zurück. Das ist die aufwendigste, aber auch einzig erfolgversprechende Form der Kontrolle unter komplexen Bedin-gungen. Aufwendig deshalb, weil es nicht um einen einfachen zahlenvergleich geht, sondern jedes Mal das zwischenprodukt geprüft und beurteilt werden muss. In agilen Projekten werden dazu zeiträume von zwei bis vier Wochen festgelegt. Danach erfolgt dann regelmäßig ein Abgleich des Ergebnisses mit den Kundenanforderungen. Ein agiler Coach wird diesem entschei-denden Punkt besondere Aufmerksamkeit widmen: Das Team lernt, die effektiven Prozesse zu identifizieren und in der weiteren Arbeit anzuwenden. Sind diese Arbeitsschritte herausgefil-tert, werden auch statistisch gestützte Aussagen zur Prozess-geschwindigkeit möglich. Nur in dem Maße, wie die nötigen Prozesse verstanden und etabliert sind, kann auch der Übergang zur definierten Prozesskontrolle erfolgen.

Pull versus Push

Das Team, als sich selbst organisierende Einheit, entwickelt die

AGILE

nötige Kompetenz, die Kundenanforderungen in Aufgaben zu übersetzen und richtig zu verteilen. Die Erfahrungen sind kumu-liert zu kollektiver „Weisheit“, die ein einzelner übergeordneter Manager so nicht haben kann. Das Team agiert also innerhalb der gesetzten Rahmen und ziele eigenverantwortlich. Lean-Thinking stellt sicher, dass stets der Kundennutzen im Fokus des agilen Handelns bleibt: Agile Methoden zielen darauf ab, dem Kunden genau das zu liefern, was er braucht – schnell und in bester Qualität. Was nicht wertschaffend ist, entfällt. Überflüs-sige Variationen ebenso wie unnötige Tätigkeiten.

Der Idealzustand im gewohnten Prozessansatz sieht so aus: Der Kunde liefert zu Beginn des Projekts eine klare und umfassende Beschreibung des benötigten Produktes mit allen Eigenschaften. Daran ändert sich während des gesamten Projektzeitraums nichts. Wie jeder Projektarbeiter weiß, sieht die Realität anders aus: Der Kunde sagt was er wünscht (was er eigentlich braucht, kann etwas ganz anderes sein), doch dann ändern sich plötzlich die Rahmenbedingungen. In solch einem Fall starr am ursprüng-lich Vereinbarten festzuhalten, wäre mit dem Kundennutzen nicht vereinbar. Der agile Ansatz akzeptiert diese Änderungen und arbeitet iterativ und mit inkrementellen Verbesserungen. Ergebnis jedes Durchlaufs (Sprint) ist ein marktfähiges Produkt. Durch den Abgleich der Ergebnisse mit den Kundenanforde-rungen können Fehler und Abweichungen schnell erkannt und

behoben werden. Parallel wird auch auf unnötige Synchronisa-tion von Abläufen verzichtet. Das verkürzt die Time-to-Market. Das Produkt sollte so früh wie möglich bereits auf dem Markt verfügbar sein und wird dann fortlaufend verbessert.

Das passende Tempo finden

Die genannten Prinzipien sollten vor dem Übergang zum agilen Arbeiten durchdacht werden. Das fällt Unternehmen leichter oder schwerer, je nachdem, wie stark eine Kultur der Eigenver-antwortung und des ständigen Lernens bereits ausgeprägt ist. Auf diesem Weg verändert sich das Unternehmen schrittweise in einem selbstbestimmten Tempo und so wie es dem Bedarf entspricht. Änderungen werden nicht vorgeschrieben oder auf einem Blatt Papier entwickelt, sondern erwachsen aus den echten Arbeitsbedingungen heraus. Schritt für Schritt werden so immer mehr Teams und Abteilungen in die agile Arbeit einbezogen. Die parallel zum Projekt laufende Ausbildung von internen Coaches hilft, das agile Denken nachhaltig im Unternehmen zu verankern.

Agile Transition erfordert Geduld, denn kaum ein Tool oder eine Erfahrung kann eins zu eins auf ein anderes Projekt übertragen werden. Jedes Unternehmen muss seinen eigenen agilen Weg finden.

AGILE

Ihre E-Mail Bewerbung bitte an: [email protected]

XDEV Software Corp.Deutschland GmbHSedanstraße 2-492637 Weiden

XDEV Software Corp.One Embarcadero CenterSan Francisco, CA 94111, US

JAVA ENTWICKLER (m/w)

bei XDEV Software Corp. in 92637 Weiden

www.xdev-software.de

51JAVA-PRO.DE 2-2017

#JAVAPRO #Agile #Scrum

Faktor Mensch! - Wiederholbare Projekterfolge mit Scrum Zu der Erkenntnis, dass Menschen Projekte machen, gelangt man nicht erst durch

die Lektüre von Tom De Marcos¹ Büchern. Aber was hat sich in den letzten Jahr-

zehnten tatsächlich in der professionellen software Entwicklung getan? Trotz der

vielen neuen innovationen und Methodiken hat sich augenscheinlich nur wenig

bewegt. Die Klagelieder aus den Unternehmen summen nach wie vor die gleiche

Melodie.

ausgetauscht werden. Stellen wir die klassischen Modelle in einen Vergleich mit agilen Techniken, können wir nur wenige essenti-elle Unterschiede ausmachen. Die einzelnen Stufen wie Planung, Implementierung, Testen und Ausliefern sind wenig variabel. Ob man nun den Projektleiter als Scrum-Master bezeichnet oder Releases lieber als Sprints definiert, ist Geschmackssache. Allein ein neues Vokabular genügt allerdings nicht, um von tatsächlicher Innovation zu sprechen. Ein neues Vokabular hilft aber durchaus,

tellen wir uns bei all dem Wandel einmal eine essentielle Frage: Kann ein Softwareprojekt heute noch erfolgreich

sein, wenn es nicht auf Methoden wie Scrum2 setzt oder die neuesten Innovationen verwendet? Anwendungen werden Dank leistungsfähigerer Maschinen zunehmend komplexer, so dass diese nicht mehr von einzelnen Personen in ihrer Gänze über-blickt werden können. Das gute Teamarbeit ein wichtiger Bestandteil erfolgreicher Projekte ist, ist seit langem auch bei den Unternehmen angekommen. Daher zählen bei Bewerbungsge-sprächen mittlerweile nicht allein harte technische Fähigkeiten. Auch ausgewogene Softskills und Kommunikationsfähigkeit sind wichtige Anforderungen bei der Auswahl von neuem Personal. Daher die provokante Behauptung, dass andere Faktoren für Projekterfolge wesentlich essentieller sind als technologische Details.

Alter Wein in neuen Schläuchen?

Ganz so einfach ist es dann doch nicht. Und nicht alles Neue macht der Mai. Aus persönlicher Erfahrung wiederholt sich die Geschichte kontinuierlich, lediglich die Protagonisten können

S

Autor:

Marco Schulz studierte an der HS Merseburg Diplo-minformatik. Sein persönlicher Schwerpunkt liegt in Software Architekturen, der Automatisierung des Softwareentwicklungs-Prozess und dem Soft-warekonfigurationsmanagement. Seit über fünfzehn Jahren entwickelt er für nahmenhafte Unternehmen auf unterschiedlichen Plattformen umfangreiche Webapplikationen. Derzeit arbeitet er als freier Consultant und ist Autor verschiedener Fachartikel.E-Mail: [email protected]

AGILE


sich leichter von alten und möglicherweise schlechten Gewohn-heiten zu lösen. Der Ansatz von Scrum ist es, das Kommunika-tionsproblem in Teams zu adressieren und durch Techniken aus der Rhetorik, die gemeinsamen ziele zu visualisieren. Kurze Entwicklungszyklen ermöglichen ein schnelles Feedback um mögliche Probleme bereits zu Beginn zu erkennen und berich-tigen zu können. Auf tatsächliche Bedürfnisse zügig zu reagieren sind Kernkompetenzen eines Managers. Analysiert man in einer Retrospektive was zu Fehleinschätzungen beim Manage-ment geführt hat, ist es nicht selten die mangelnde Bereitschaft sich mit technischen zusammenhängen auseinandersetzen zu wollen. Dies ist aber essentiell, für ein Gelingen der anvisierten ziele. Klare Anweisungen lassen sich nur dann formulieren, wenn man deren Inhalt auch versteht. Ein sehr empfehlenswerter Titel für IT Management ist von Johanna Rothman und Esther Derby „Behind closed Doors“3 welches hervorragend Motivierung, Teamentwicklung und Kommunikation bespricht.

Werfen wir einmal ein Blick in ein typisches Auftaktmeeting, wenn ein neues Projekt initiiert wird. Oft ist an dieser Stelle noch keine klare Vision vorhanden. Das wiederum hat zur Folge das schwammige Anforderungen formuliert werden. Sehr klassisch ist bei nicht funktionalen Anforderungen, dass sich alle Betei-ligten einig sind, dass beispielsweise eine hohe Qualität einge-halten werden muss. Es wir schnell vergessen zu definieren, was man unter Qualität versteht und wie man dies erreichen will. Lenkt man in diesen Meetings alle Beteiligten auf die Details, fehlt oft die Bereitschaft sich diesen mit der notwendigen Sorg-falt zuzuwenden. Euphorisch benennt man fix einen Qualitätsver-antwortlichen, ohne ihm die notwendige Entscheidungsgewalt zuzusprechen. zum Thema Qualität hat sich sehr ausführlich bereits im Jahre 1976 B. W. Boehm auf knapp 14 Seiten4 geäußert. Eine Lösung für dieses Problem wäre es, sich zu entschließen einen hohen Wert auf Coding-Standarts zu legen. Diese Konven-tion ermöglicht es den einzelnen Entwicklern sich schnell in die Lösungen der Kollegen einzufinden. Es gewährleistet nicht, das die Applikation robust gegen Änderungen ist und diese über einen langen zeitraum auch wartungsfähig bleibt. Eine Entschei-dung alle diese Aspekte zu bedienen hat die Konsequenz, dass damit auch die bereitzustellenden Aufwände erhöht werden müssen. Von daher gilt es, bewusst abzuwägen was tatsäch-lich notwendig ist. Aber verweilen wir nicht allzu lange beim Management. Es gibt viele weitere Dinge die es lohnt ein wenig stärker auszuleuchten.

Im Gleichschritt Marsch!

Nicht alle Arbeiten zählen zu den begehrtesten Beschäftigungen, dennoch müssen sie erledigt werden. Eine gute Unterstützung findet man für solche Tätigkeiten in Automatisierungsmecha-nismen. Dazu muss man sich auch bewusst sein, dass eine auto-matisierte Lösung bei komplexen Problemen sehr aufwendig gestaltet werden kann. Die damit verbundenen Kosten können sich erst dadurch amortisieren, dass die gefundene Lösung sehr häufig eingesetzt wird oder die Anfälligkeiten für Fehler während

der Ausführung massiv reduziert werden. Ein hervorragendes Beispiel für diese Thematik sind Build- und Testprozesse. Nicht das Werkzeug bestimmt das Ergebnis, sondern der Prozess defi-niert das zu verwendende Werkzeug. Auch an dieser Stelle über-schätzt sich der Mensch hin und wieder, in dem er hochkomplexe Prozesse nicht in ihre Bestandteile zerlegt, um diese dann nach-einander abzuarbeiten. Schlägt dann ein Schritt fehl ist nur dieser Teilprozess zu wiederholen. Hierzu gab es, in unterschiedlichen persönlich erlebten Situationen des Autors, ähnliche Begeben-heiten. Es war notwendig die Aussage zu entkräften, weswegen es sich bei der Wahl explizit gegen Maven5 und bewusst für Gradle6 entschieden werden sollte. Das Argument für Gradle war die Möglichkeit eines frei choreographierbaren Buil-Pro-zesses und die damit verbundene Flexibilität. Die Notwendigkeit einer Build-Choreographie kann ein wichtiger Indikator für eine mangelhafte Architektur sein. Fehlende Kapselung und dadurch implizierte Abhängigkeiten sind die üblichen Verdächtigen. Die strikten Konventionen von Maven reduzieren hingegen das Aufkommen von unlesbaren Build-Skripten, die kaum oder nur mit erheblichem Aufwand gewartet werden können. Es ist nicht immer förderlich, volles Vertrauen an die Verantwortlichen zu delegieren, in der Absicht, dass diese optimale Ergebnisse produ-zieren. zuviel Freiheit führt auch schnell zu Anarchie. In diesem zusammenhang wäre das Argument für die Verwendung von Gradle, bereits einen Experten für diese Technologie im Hause zu haben, so schwergewichtig, dass wenig Spielräume für eine andere Wahl offen stünden.

Auch die Erstellung von Testfällen ist ein Kapitel für sich. Es grenzt schon an ein Wunder, wenn überhaupt Testfälle exis-tieren. Wenn diese dann auch noch eine hohe Testabdeckung erzielen, könnte man meinen einen Großteil möglicher Risiken minimiert zu haben. Dass Testen nicht gleich Testen ist, skizziert die folgende Überlegung: Sehr wichtig ist zu wissen, dass das Bestehen der Testfälle keine Fehlerfreiheit garantiert. Es wird lediglich garantiert, dass die Anwendung sich entsprechend den Vorgaben der Testfälle verhält. Hierzu ist es interessant zu wissen, dass für IT-Projekte der NASA sämtliche Compiler-Mel-dungen für selbst entwickelte Software, die sich in Produktion befindet, behoben sein müssen. Aber auch die Aussagekraft von Testfällen lässt sich etwas ausführlicher betrachten. Die zykloma-tische Komplexität nach McCabe7 gibt einen guten Hinweis, wie viele Testfälle für eine Methode benötigt werden. Veranschau-lichen wir die zusammenhänge an einem kleinen Beispiel. Ein Validator prüft anhand eines regulären Ausdrucks (Regex) mit der Methode validate(), ob es sich bei der Benutzereingabe um ein korrektes 24-Stunden-Format der Uhrzeit handelt. Dabei werden ausschließlich die Stunden und Minuten in zweistelliger Notation (hh:mm) angenommen. Es besteht nun die Möglichkeit einen einzigen Testfall für den regulären Ausdruck der Uhrzeit zu schreiben. Schlägt dieser Test fehl, muss der Entwickler den vorhandenen Testfall analysieren um das Problem zu identifi-zieren. Genauso wenig sagt die Methode testUhrzeit24hFormat() über die tatsächlichen durchgeführten Tests etwas aus. So hat man möglicherweise nicht immer im Fokus, dass Werte wie 24:00

AGILE

Links & Literatur:

oder 00:60 unzulässig sind, hingegen 00:00 und 23:59 gültige Einträge darstellen. Splittet man den Testfall beispielsweise in die Teile testMinuten und testStunden, so erkennt man schnell die tatsächlichen Schranken. Dieser Formalismus gestattet es zudem fehlgeschlagene Testfälle schneller bewerten zu können. Die Kombination mit dem Framework jGiven8 ermöglicht es deskrip-tive Testszenarien zu formulieren, sodass nachgelagerte manu-elle Akzeptanztest weniger aufwendig gestaltet werden müssen.

Wir messen, weil wir können

Die Vermessung der Welt ist nicht allein den rein physikalischen Größen vorbehalten. Auch für Softwareprojekte bilden Metriken eine nützliche Informationsquelle. Wie bereits erläutert ist die zyklomatische Komplexität ein guter Anhaltspunkt für die Bewer-tung von Testfällen. Auch die klassischen Lines-of-Code (LoC) sagen einiges über die Größe eines Projektes aus. Was bei all dem zahlenwerk oft wenig beachtet wird, sind die tatsächlichen Points-of-Intrests (PoI). Sicher kann man Äpfel mit Birnen verglei-chen. Aber der Nutzen bleibt etwas fragwürdig wenn man keinen geeigneten Kontext definiert. Auch an dieser Stelle ist es wichtig sich nicht mit einer Informationsflut an Daten zu überfordern. So ist es hilfreich, die Projektentwicklung der einzelnen Release Milestones zu dokumentieren und dann zu vergleichen. Auch die Vergleichbarkeit unterschiedlicher Projekte führt zu neuen Erkenntnissen. Dabei ist es aber nicht förderlich ein Projekt, welches bereits 10 Jahre Entwicklung beschritten hat, mit einer kleinen Hilfsbibliothek zu vergleichen. Auch die Repräsentation der ermittelten Informationen ist ein nicht zu vernachlässigendes Detail. Eine grafische Darstellung lässt die zusammenhänge leichter fassen. So ist die reine Darstellung der LoC als nackte zahl nett zu wissen, aber eine Bewertung gestaltet sich auf diese Weise eher schwer. Ein kumulierter Chart über die Entwicklung der LoC zu den einzelnen Releases vermittelt dagegen ein recht deutliches Bild. Dies lässt sich weiter befüllen mit der Anzahl der Klassen, Interfaces, Packages und JavaDocs und all dies in Rela-tion zur Speichergröße des fertigen Artefaktes zu setzen. Der Einsatz hochkomplexer Werkzeuge kann durch ein geeignetes Tabellenkalkulationsprogramm und Methoden des Projekt-Cont-rollings ohne weiteres ersetzt werden. Ein Skript, das die notwen-digen Rohdaten einsammelt, kann von der Entwicklungsabteilung schnell bereitgestellt werden ohne, dass ein überfrachteter Werk-zeugkasten den man mit sich herum tragen muss, zu „schweren Rückenproblemen“ führt.

Informationsdschungel

Ein weiterer Blick in den Werkzeugkasten bringt nicht selten verstaubte Infrastruktur zutage, die den Anschein erweckt als reiner Selbstzweck zu fungieren. Das Unternehmens-Wiki, bei dem die meisten Einträge aus weniger als 100 zeichen bestehen sowie eine Navigation nur vermutet werden kann, ist leider die traurige die Regel. Aussagen zum Daily-Meeting wie „Ich bin Heiko und kümmere mich auch heute wieder um die Suchfunktion“ erinnern

eher an eine Selbsthilfegruppe. Das Ganze wird dann noch durch SCM-Logeinträge (SCM ist ein Tool zur Kommentierung von Issues) wie „JIRA-KM-100 update Build-Skripte“ dekoriert. Gute Kommunikation ist mehr als sich seinen Mitmenschen mitzu-teilen. Reflektierte Aussagen unterstützen uns bei der Bewälti-gung unserer täglichen Aufgaben. Sie strukturieren zugleich unser Denken. Wenn wir beim morgendlichen Treffen mit den Kollegen hingegen sagen „Für das Erzeugen des Suchindexes implementiere ich heute die Abfragen über die Keywords in den Content-Tabellen, sodass ich morgen bereits einige Testfälle formulieren kann“, kurz und auf den Punkt gebracht, dann sind die Kollegen informiert. Ein präziser Kommentar im SCM „JIRA-KM-100 Hinzufügen der Lucene-Abhängigkeiten für die Suche“ gibt schnell Aufschluss über die vorgenommenen Arbeiten ohne, dass man erst den entsprechenden Task im Issue-Managment öffnen muss, um zu sehen welche Änderungen vorgenommen wurden. Bereits diese kleinen Aufmerksamkeiten in unserer Kommunikation bewirken einen enormen Anschub in die Moti-vation des gesamten Teams. Jeder einzelne empfindet sich so wesentlich mehr wertgeschätzt. Funktionierende und aktuelle Anleitungen über das Einrichten des Arbeitsplatzes, Hinweise mit Beispielen zum Schreiben von Kommentaren für SCM-Com-mits regen die Kollegen zum Mitmachen an. Der Mehrwert einer solchen Unternehmenskultur beschränkt sich nicht einzig auf einen funktionierenden Informationsaustausch. Das höhere ziel dieser Bestrebungen ist auf eine angenehme Weise, die Produk-tivität zu steigern, ohne stetig Druck ausüben zu müssen.

Lessons Learned

Wie wir sehen konnten, genügt es nicht sich allein auf eine gute Methodik wie Scrum zu verlassen, um sich von den notwen-digen Vorbereitungen befreien zu können. Der Wille allein, etwas Hervorragendes zu erschaffen, ist nicht ausschlaggebend für beste Resultate. Vor den Erfolg ist stets Fleiß zu setzen. Bevor man sich in Details verliert ist es unerlässlich, das große Ganze sehen zu können. Erst wenn alle Beteiligten die gleiche Vision teilen, können sie gemeinsam in die Mission starten. Anhand der beschriebenen Beispiele kann man gut nachvollziehen, dass die vielen neuen Techniken erhebliche Möglichkeiten bieten. Diese Chancen lassen sich allerdings nur dann nutzen, wenn man zuerst die notwendigen Grundlagen tief verinnerlicht hat.

1TomDeMarco,Peopleware,1987,ISBN0-932633-43-92Scrum,https://www.scrum.org3J.Rothman&E.Derby,BehindClosedDooors,2005,ISBN0-9766940-2-64Boehm,QuantitativeEvaluationofSoftwareQuality,1976,2ndInternationalConferenceonSoftwareEngineering5 Maven, https://maven.apache.org6 Gradle, https://gradle.org7McCabe,AComplexityMeasure,1976, IEEE Transactions on Software Engineering8jGiven,http://jgiven.org

AGILE


#JAVAPRO #Agile #Coaching

Buchvorstellung: Agile Teams lösungsfokussiert coachen Das Buch „Agile Teams lösungsfokussiert coachen“ agile Arbeitsweisen aus der

sicht eines Coaches und geht weit über das hinausgeht, was man üblicherweise zu

diesem Themengebiet erwartet.

Buchvorstellung:

Titel Agile Teams lösungsfokussiert coachenAutoren: Ralph Miarka, Veronika Kotrba Verlag: dpunkt-Verlag, 2015 ISBN: 386491776X, 9783864917769 Länge: 252 Seiten

Obwohl der Inhalt des Buches schon sehr interessant ist, finden sich zwölf Seiten mit Verweisen auf andere Quellen, die die angesprochenen Themen weiter ausführen, bzw. wissenschaft-lich belegen.Alleine diese Quellensammlung weckt schon Spaß, sich weiter mit diesen Themen zu beschäftigen und das erlernte in der Praxis auszuprobieren. zusätzlich aber untermauern diese Verweise, dass es sich auch bei der Erforschung von Soft-Skills um wissen-schaftliches Arbeiten handelt – einer Erkenntnis die so manchem technikverliebten Nerd neu ist.

Alles in allem handelt es sich bei diesem Buch um ein leicht zu lesendes und leicht zu verstehendes Buch. Dabei sind die 250 Seiten keineswegs oberflächlich. Das Gegenteil ist der Fall. Grund ist der oben besprochene Teil mit Verweisen zu anderen Quellen. Werden diese beim Durcharbeiten mit bearbeitet, so entsteht deutlich mehr als nur ein kurzer Überblick über das Thema.

Einziges Manko ist: Die angesprochenen Themen sind deutlich leichter zu lesen und zu begreifen, als wirklich umzusetzen. Dies liegt aber nicht an den Autoren, sondern daran, dass Sie mit Menschen arbeiten – und Menschen reagieren nie gleich. Sie wissen vielleicht wie schwer es ist sich selbst zu ändern? Können Sie sich vielleicht vorstellen wie schwer es ist ein Team zu Ände-rungen zu bewegen?

Mein Rat: Lesen Sie das Buch Stück für Stück und versuchen Sie mit der Strategie der „kleinen Schritte“ die für Sie relevanten Themen auch umzusetzen, denn erst nach und nach wird dem Leser die ganze Tiefe dieses Buches wirk-lich bewusst, da das Buch „Agile Teams lösungsfokussiert coachen“ weit über das hinausgeht, was man üblicherweise von einem 250 Seiten Buch zu diesem Themenge-biet erwartet.

Thomas Ronzon:

Das hier beschriebene Buch behandelt agile Arbeitsweisen aus der Sicht eines Coaches. Dies beginnt mit der Beschreibung der „Sechs grundlegenden Coaching-Haltungen“, die die Basis für das ganze Buch darstellen. Diese sind „Die Haltung des Nicht-Wis-sens“, „Jeder ist Experte für sich selbst“, „Geduld und zuversicht“, “Ressourcenfokus“, “Allparteilichkeit“ und „Vertraulichkeit“.

Aus diesen, eigentlich Selbstverständlichkeiten, entwickeln die Autoren im Laufe des Buches verschiedene Methoden bzw. Ansätze um Teams zu coachen. Interessant ist meiner Meinung nach, dass hierbei nicht nur, wie in vielen Büchern dieser Art, das Team als eine Einheit betrachtet wird, sondern sich ein ganzes Kapitel mit dem Thema „Das Team und seine Indivi-duen“ beschäftigt. Dabei wechseln sich theoretische Themen mit Praxistipps und Grafiken bzw. Bildern ab.

Schnell erkennt man den eigenen Stil aus Sympathie für die Person (Leser) und Empathie für die Probleme dieser wieder. Aber gerade durch diesen Stil lässt sich das Buch sehr flüssig lesen.

Dies spiegelt sich auch den in kleinen Anekdoten wieder, die an allen möglichen Stellen in das Buch eingeflossen sind. Sie dienen dabei nicht nur als Auflockerung nach theoretische Teilen, sondern vermitteln dem Leser direkt den Bezug zur Praxis. Gerade an diesen Anekdoten wird aber auch klar, dass die Autoren hier nicht nur eine Aneinanderreihung von Soft-Skills präsentieren, sondern dass sie selbst mit beiden Beinen in der Praxis stehen.

REZEssIONEN

ROAVA

www.java-pro.de

GRUNDLAGEN •PRAXIS •ARCHITEKTUR •AGILE •AINNOVATION

www.java-pro.deMagazin für professionelle JavaEntwicklung in der Praxis

ww

w.java

-pro

.de

... auch als eBook App&

kostenlos verfügbar !

Das kostenlose

Magazin für Java

NEU!Kostenl

os anfordern un

ter:

www.java-pro.de

KeineKosten.KeineVerpflichtungen.KeineAbo-Falle.

Ausgabe 3 - 15. August 2017

Ausgabe 4 - 15. Oktober 2017

Ausgabe 2 - 15. Juni 2017

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates.

oracle.com/javaor call 1.800.ORACLE.1

13 BillionDevices Run Java

ATMs, Smartcards, POS Terminals, Blu-ray Players,

Set Top Boxes, Multifunction Printers, PCs, Servers,

Routers, Switches, Parking Meters, Smart Meters,

Lottery Systems, Airplane Systems, IoT Gateways,

Programmable Logic Controllers, Optical Sensors,

Wireless M2M Modules, Access Control Systems,

Medical Devices, Building Controls, Automobiles…

#1 Development Platform

M_117M_JAV00008_13BDevicesRunJava_8x10.5

JCON2017-ERSTEKOSTENLOSE 6 KONFERENZFÜRDIEJAVA … · e e!...

Documents

Transcript of JCON2017-ERSTEKOSTENLOSE 6 KONFERENZFÜRDIEJAVA … · e e!...