SlideShare ist ein Scribd-Unternehmen logo
1 von 5
Downloaden Sie, um offline zu lesen
D:4,90EUR A:5,60EUR CH:9,80CHF Benelux:5,80EUR ISSN2191-6977
Javaaktuell
Javaaktuell
03-2016 | Herbst | www. ijug.eu
Praxis. Wissen. Networking. Das Magazin für Entwickler
Aus der Community — für die Community
419197830490303
iJUG
Verbund
Container-Architektur
Verteilte Java-Anwen­
dungen mit Docker
Microservices
Schnell und einfach
implementieren
Java-Web-Anwendungen
Fallstricke bei der
sicheren Entwicklung
4 |
Inhalt
Sich schnell einen Überblick über bestehende Strukturen und deren Beziehungen verschaffen
34
3	Editorial
5	 Das Java-Tagebuch
Andreas Badelt
8	 Verteilte Java-Anwendungen
mit Docker
Dr. Ralph Guderlei und Benjamin Schmid
12	 JavaLand 2016: Java-Community-
Konferenz mit neuem Besucherrekord
Marina Fischer
14	 Groovy und Grails – quo vadis?
Falk Sippach
20	 PL/SQL2Java – was funktioniert
und was nicht
Stephan La Rocca
25	 Canary-Releases mit der Very
Awesome Micro­services Platform
Bernd Zuther
28	 Weiterführende Themen zum Batch
Processing mit Java EE 7
Philipp Buchholz
34	 Exploration und Visualisierung von
Software-Architekturen mit
jQAssistant
Dirk Mahler
38	 Fallstricke bei der sicheren Entwicklung­
von Java-Web-­Anwendungen
Dominik Schadow
43	 Java ist auch eine Insel −
Einführung, Ausbildung, Praxis
gelesen von Daniel Grycman
44	 Microservices – live und in Farbe
Dr. Thomas Schuster und Dominik Galler
49	Open-Source-Performance-
Monitoring mit stagemonitor
Felix Barnsteiner und Fabian Trampusch
53	 Profiles for Eclipse – Eclipse im
Enterprise-Umfeld nutzen
und verwalten
Frederic Ebelshäuser und
Sophie Hollmann
57	 JAXB und Oracle XDB
Wolfgang Nast
61	Java-Enterprise-Anwendungen
effizient und schnell entwickeln
Anett Hübner
66	Impressum
66	Inserentenverzeichnis
Neues von den letzten Releases
Daten in unterschiedlichen Formaten in der Datenbank ablegen
57
14
| 25
www.ijug.eu
iii
iiiiii
iii
Java aktuell 3-2016
Canary-Releases mit der
Very Awesome Micro­services
Platform
Bernd Zuther, codecentric AG
ImmermehrUnternehmenzerschlagenihreSoftware-SystemeinkleineMicroservices.
Wenn das passiert, entstehen mehrere Deployment-Artefakte, was nicht nur das
DeploymentdesGesamtsystemskomplexermacht.UmdieseKomplexitätbeherrschen
zukönnenunddieAuslieferungsmöglichkeiteneinerSoftwarezuverbessern,istder
Einsatz von Werkzeugen zur Infrastruktur-Automatisierung unumgänglich.
sich „Canary-Release“ nennt. Dabei werden
Änderungen erst einmal nur einem Teil der
Benutzer zu Verfügung gestellt und es wird
gemessen, wie dieser Teil auf die Änderun-
gen reagiert, bevor man die neue Software
auf der kompletten Infrastruktur ausrollt.
Durch dieses Vorgehen wird eine Möglich-
keit geschaffen, Software schrittweise aus
fachlicher Sicht zu verbessern [2].
Abbildung 1 stellt den Aufbau eines Cana-
ry-Release dar. Es ähnelt in der Ausführung
einem Blue-Green-Deployment [3], das aber
das Ziel verfolgt, die Downtime einer Applika-
tion zu minimieren. Bei beiden Verfahren wer-
den zwei Infrastruktur-Stränge benötigt, auf
die zwei unterschiedliche Software-Versionen
geliefert werden. Dabei handelt es sich jeweils
um die neue und die alte Version der Software.
Über einen Router werden die Benutzer auf
die entsprechende Version umgeleitet.
Bei einem Blue-Green-Deployment macht
man einen harten Wechsel auf die neue Ver-
sion der Software. Beim Canary-Release wer-
den dagegen beispielsweise nur fünf Prozent
des Traffics auf die neue Version umgeleitet.
Damit soll herausgefunden werden, ob eine
neue Funktionalität wirklich eine signifikante
Veränderung im Verhalten der Benutzer aus-
löst. Diese Release-Form kann auch benutzt
werden, um A/B-Testing zu implementieren.
Das Durchführen von Canary-Releases ist bei
einer Microservice-Architektur eine nicht trivi-
ale Aufgabe.
Microservice-Architektur
Abbildung 2 zeigt ein Verteilungsdiagramm
einer Microservice-Architektur, das die Kom-
plexität dieser Architektur-Form verdeutli-
chen soll. Hier sind unterschiedlichste Arte-
fakte zu sehen, die entstehen können, wenn
NurUnternehmen,dieesschaffen,sichschnell
genug an die sich ändernden Ansprüche und
Anforderungen ihrer Kunden anpassen zu
können, werden auf lange oder kurze Sicht
überlebensfähig bleiben. Die Absatzmärk-
te der meisten Firmen erfahren seit einigen
Jahren einen drastischen Wandel. Durch Glo-
balisierung, Marktsättigung und das Internet
haben sich stark konkurrierende und dynami-
sche Märkte entwickelt, die bedarfsgesteuert
sind. Daher sollten sich Unternehmen an die
veränderten Bedürfnisse ihrer Kunden schnell
anpassen: An dieser Stelle sollte von „kosten-
effizienter Skalierung“ zu „Reaktionsfähigkeit“
gewechselt werden [1].
Canary-Release
Um das Risiko beim Ausrollen einer neuen
Software-Version zu vermindern, benut-
zen viele Unternehmen eine Technik, die
Abbildung 1: Canary-Release
26 |
Micro­services
man eine monolithische Anwendung in eine
Microservice-Architektur zerteilt. Auf dem
linken Server ist eine Shop-Anwendung zu
sehen, die über eine WAR-Datei ausgeliefert
wird und über einen Service mit dem rech-
ten Server kommuniziert. Auf diesem Server
sind drei verschiedene Anwendungen ins-
talliert. Eine Anwendung implementiert eine
Katalog-Ansicht, die von einem Nginx aus-
geliefert wird. Außerdem sind ein Produkt-
und ein Warenkorb-Service dargestellt, die
jeweils über eine JAR-Datei gestartet wer-
den. Damit die Anwendung vollständig läuft,
sind also vier Artefakt-Arten erforderlich,
die unterschiedlich betrieben werden [4].
Docker
Docker eignet sich, um diese unterschied-
lichen Artefakt-Arten aus Betriebssicht zu
standardisieren. Es bietet Funktionen zum
Erstellen und Pflegen von Images, die man
über eine sogenannte „Registry“ sehr einfach
und schnell auf andere Rechner verteilen
kann. Betreibt man den Docker-Daemon auf
einem Rechner, kann man aus einem solchen
Image einen Container erzeugen, der einen
laufenden Linux-Prozess beinhaltet. Der Do-
cker-Daemon nutzt zum Ausführen solcher
Prozesse spezielle Kernel-Funktionalitäten,
um einzelne Prozesse in den Containern von-
einander abzugrenzen. Container enthalten
kein Betriebssystem, sondern nur die jeweils
erforderlichen Linux-Anwendungen und de-
ren benötigte Bibliotheken [5].
Listing 1 verdeutlicht einen Workflow,
der mit Docker abgebildet werden kann, um
Anwendungen auf beliebigen anderen Rech-
nern auszuführen. Zuerst wird mithilfe eines
Docker-Files und des Build-Kommandos ein
Image gebaut. Dann übermittelt man das
Image mit dem Push-Kommando in eine pri-
vate oder öffentliche Registry. Auf dem Ziel-
rechner wird ein Image mit dem Pull-Kom-
mando aus der Registry heruntergeladen und
mit dem Run-Kommando gestartet. Danach
läuft auf diesem Rechner ein neuer Prozess.
Docker im verteilten System
Um zwei Container miteinander per Netz-
werk kommunizieren zu lassen, bietet Docker
das Link-Konzept an. Beim Verlinken werden
IP und exportierte Ports des Zielcontainers
als Umgebungsvariable im nutzenden Con-
tainer bereitgestellt. Der Container, der den
Link erzeugt, kann in der Konfiguration der
Anwendung auf diese Umgebungsvariablen
zugreifen und muss nicht IP und Port direkt
verwenden. Listing 2 zeigt, wie diese Umge-
bungsvariablen aussehen.
Die Verlinkung funktioniert allerdings nur,
wenn sich die Docker-Container auf dem
gleichen Server befinden. Wenn Container
über mehrere Server verteilt und mitein-
ander verbunden werden sollen, kann das
direkt über IP und Port passieren. Möchte
man dies per Hand machen, muss man sich
auf den unterschiedlichen Rechnern an-
melden, die Container in einer bestimmten
Reihenfolge starten und die entsprechen-
den Umgebungsvariablen setzen. Sollten
sich IP oder Port der Zielcontainer ändern,
müsste der zugreifende Container angepasst
und neu gestartet werden. Dieses Vorge-
hen würde zu einer statischen Umgebung
führen und man könnte nicht einfach neue
Rechner hinzufügen oder wegnehmen [6].
Very Awesome Microservices
Platform
Die Very Awesome Microservices Platform
(VAMP, [7]) ist ein Werkzeug, das an dieser
Stelle ansetzt. Es verwendet aktuell Mesos
und Marathon als Container-Manager. Die
Plattform wird von der niederländischen Fir-
ma magnetic.io [8] entwickelt. Mesos [9] sorgt
für die Ressourcen-Verwaltung im Cluster
und ist verantwortlich für das Starten von Do-
cker-Containern in einem verteilten Rechner-
Cluster. Marathon [10] ist ein Werkzeug, das
auf Mesos aufbaut. Mit Marathon kann das
Deployment von Microservice-Anwendungen
durchgeführt werden. Marathon stellt einen
Scheduler dar, der die Verteilung und Ausfüh-
rung von Docker-Containern steuert (siehe Ab-
bildung 3).
Vamp ist ein Dienst, der sich oberhalb eines
Container-Managers wie Marathon ansiedelt
und aus mehreren Komponenten besteht.
bz@cc1 $ docker build -t zutherb/product-service .
bz@cc1 $ docker push zutherb/product-service
bz@cc2 $ docker pull zutherb/product-service
bz@cc2 $ docker run zutherb/product-service
bz@cc2 $ docker ps
CONTAINER ID IMAGE					COMMAND
87bb5524067d zutherb/product-service:latest ”/product-0.6/bin/
bz@cc $ docker exec 254e40d85a33 env
MONGODB_PORT_27017_TCP=tcp://172.17.0.2:27017
MONGODB_PORT_27017_TCP_ADDR=172.17.0.2
MONGODB_PORT_27017_TCP_PORT=27017
Listing 1
Listing 2
Abbildung 2: Verteilungsdiagramm einer Microservice-Architektur
| 27
www.ijug.eu
iii
iiiiii
iii
Java aktuell 3-2016
Vamp-Core bietet eine Plattform-agnostische
DSL und ein REST-API. Die DSL kann ähnlich
wie Giant Swarm [11] und Docker-Compose
[12] benutzt werden, um eine Microservice-
Anwendung mit all ihren Abhängigkeiten zu
beschreiben und auszuführen.
Listing 3 zeigt einen Ausschnitt aus einer
solchen Beschreibung [13]. Diese DSL wird
von Vamp-Core benutzt, um mit Marathon die
Microservices im Mesos-Cluster auszuliefern.
Außerdem beinhaltet die DSL Elemente zum
Beschreiben von A/B-Tests und Canary-Re-
leases sowie zum Beschreiben von SLAs. Die-
se SLAs sorgen dafür, dass, wenn bestimmte
Antwortzeiten unterschritten werden und
noch Ressourcen im Cluster verfügbar sind,
automatisch neue Docker-Container im Clus-
ter gestartet werden.
Zum Sammeln der Metriken, die für die
SLAs und A/B-Tests benötigt werden, gibt es
den Metriken- und Event-Store Vamp-Pulse,
in dem Daten von Core und Router in Elas-
ticsearch gespeichert werden. Der Vamp-
Router ist eine Komponente, die einen HA-
Proxy steuert, der die Verbindung zwischen
den laufenden Docker-Containern und den
eigentlichen Benutzern realisiert [14].
Fazit
Um die Reaktionsfähigkeit durch Canary-Re-
leases und A/B-Testing für die Produkt-Ent-
wicklung zu verringern, die Effizienz bei der
Auslieferung von Microservice-Architekturen
zu verbessern und eine größere Geschwin-
digkeit in die Auslieferung von Software zu
bekommen, ist Vamp eine Plattform, die sich
sehr gut für folgende Aufgaben eignet:
•	 Jeden einzelnen Service in einer Microser-
vice-Architektur erst mal nur im Rahmen
eines Canary-Release mit einem klei-
nen Teil seiner Benutzer testen und fest-
stellen, ob eine Änderung wirklich einen
Mehrwert für seine Kunden bringt
•	 Software schneller und ohne Ausfallzei-
ten mithilfe eines Blue-Green-Deploy-
ment in Produktion bringen
•	 Testumgebungen einfachen bereitstel-
len, da auf unterschiedlichen Endpunkten
unterschiedliche Anwendungskonfigura-
tionen ausgeliefert werden können
•	 Bei Lastspitzen sein eigenes Datencenter
um Cloud-Infrastrukturen erweitern und
automatisch bei bestimmen Antwortzei-
ten herauf und herunter skalieren
•	 Daten im Metrik- und Event-System sam-
meln, um nachhaltige Entscheidungen
über Veränderungen treffen zu können.
Diese kommen aus dem Live-Betrieb und
können vom Anfang bis zum Ende der
Wertschöpfungskette vollständig auto-
matisiert betrieben werden.
Quellen
[1]	 https://blog.codecentric.de/2015/08/the-need-for-
speed-eine-geschichte-ueber-devops-microservic-
es-continuous-delivery-und-cloud-computing/
[2]	 http://martinfowler.com/bliki/CanaryRelease.html
[3]	 http://martinfowler.com/bliki/BlueGreenDeploy-
ment.html
[4]	 Zuther, Bernd: Microservices und die Jagd nach
mehr Konversion., in: Java aktuell (2015), Nr. 2, S.
35 – 40.
[5]	 https://public.centerdevice.de/00d60e2d-5490-
4df6-afe0-c70824ffb14b
[6]	 https://blog.codecentric.de/2015/08/variation-
des-ambassador-pattern-von-coreos/
[7]	 http://vamp.io/
[8]	 http://magnetic.io/
[9]	 http://mesos.apache.org/
[10] https://mesosphere.github.io/marathon/
[11] https://blog.codecentric.de/2015/05/microservice-
deployment-ganz-einfach-mit-giant-swarm/
[12] https://blog.codecentric.de/2015/05/microservice-
deployment-ganz-einfach-mit-docker-compose/
[13] https://github.com/zutherb/AppStash/blob/mas-
ter/vamp/shop-ab-test.yml
[14] https://blog.codecentric.de/2015/10/canary-release-
mit-der-awesome-microservices-platform-vamp/
Abbildung 3: Vamp-Architektur
Bernd Zuther ist seit mehreren Jahren als Software-
Entwickler tätig. Derzeit ist er bei der codecentric AG
als Berater im Bereich Agile Software Factory be-
schäftigt, wo er vor allem Themen in den Bereichen
„Big Data“, „Continuous Delivery“ und „Agile Software-
Architekturen“ bearbeitet. Bernd verfügt über langjäh-
rige Erfahrung im Bereich E-Commerce und beschäf-
tigt sich seit mehreren Jahren mit der Entwicklung von
hochverfügbaren, individuellen Online-Systemen.
Bernd Zuther
bernd.zuther@codecentric.de
Hinweis: Das Listing 3 finden sie online un-
ter: www.ijug.eu/go/javaaktuell/zuther/listing

Weitere ähnliche Inhalte

Andere mochten auch

Do Realtors Earn Their Commission?
Do Realtors Earn Their Commission? Do Realtors Earn Their Commission?
Do Realtors Earn Their Commission? Chris Smith
 
2016 share the three headed beast v4
2016 share the three headed beast v42016 share the three headed beast v4
2016 share the three headed beast v4bigendiansmalls
 
creatorstand for SBIO '13
creatorstand for SBIO '13creatorstand for SBIO '13
creatorstand for SBIO '13Creatorbase
 
Splunk Conf 2014 - Splunking the Java Virtual Machine
Splunk Conf 2014 - Splunking the Java Virtual MachineSplunk Conf 2014 - Splunking the Java Virtual Machine
Splunk Conf 2014 - Splunking the Java Virtual MachineDamien Dallimore
 
HockeyApp: A plataforma para seus apps
HockeyApp: A plataforma para seus appsHockeyApp: A plataforma para seus apps
HockeyApp: A plataforma para seus appsWennder Santos
 
Nordic APIs - Building a Secure API
Nordic APIs - Building a Secure APINordic APIs - Building a Secure API
Nordic APIs - Building a Secure APITwobo Technologies
 
App Dev in the Cloud: Not my circus, not my monkeys...
App Dev in the Cloud: Not my circus, not my monkeys...App Dev in the Cloud: Not my circus, not my monkeys...
App Dev in the Cloud: Not my circus, not my monkeys...Eric D. Schabell
 
How to Adopt Infrastructure as Code
How to Adopt Infrastructure as CodeHow to Adopt Infrastructure as Code
How to Adopt Infrastructure as CodeNGINX, Inc.
 
DOBRÁ ZNAČKA PRO VEŘEJNOU SLUŽBU
DOBRÁ ZNAČKA PRO VEŘEJNOU SLUŽBUDOBRÁ ZNAČKA PRO VEŘEJNOU SLUŽBU
DOBRÁ ZNAČKA PRO VEŘEJNOU SLUŽBUOndřej Rudolf
 
Spark Kernel Talk - Apache Spark Meetup San Francisco (July 2015)
Spark Kernel Talk - Apache Spark Meetup San Francisco (July 2015)Spark Kernel Talk - Apache Spark Meetup San Francisco (July 2015)
Spark Kernel Talk - Apache Spark Meetup San Francisco (July 2015)Robert "Chip" Senkbeil
 
Reactive dashboard’s using apache spark
Reactive dashboard’s using apache sparkReactive dashboard’s using apache spark
Reactive dashboard’s using apache sparkRahul Kumar
 
ZNetLive- A Quick Overview
ZNetLive- A Quick OverviewZNetLive- A Quick Overview
ZNetLive- A Quick OverviewZNetLive
 
Using Spark, Kafka, Cassandra and Akka on Mesos for Real-Time Personalization
Using Spark, Kafka, Cassandra and Akka on Mesos for Real-Time PersonalizationUsing Spark, Kafka, Cassandra and Akka on Mesos for Real-Time Personalization
Using Spark, Kafka, Cassandra and Akka on Mesos for Real-Time PersonalizationPatrick Di Loreto
 
FinTech Industry Report 2016
FinTech Industry Report 2016FinTech Industry Report 2016
FinTech Industry Report 2016Bernard Moon
 

Andere mochten auch (16)

Do Realtors Earn Their Commission?
Do Realtors Earn Their Commission? Do Realtors Earn Their Commission?
Do Realtors Earn Their Commission?
 
Splunk Java Agent
Splunk Java AgentSplunk Java Agent
Splunk Java Agent
 
Splunk for JMX
Splunk for JMXSplunk for JMX
Splunk for JMX
 
2016 share the three headed beast v4
2016 share the three headed beast v42016 share the three headed beast v4
2016 share the three headed beast v4
 
creatorstand for SBIO '13
creatorstand for SBIO '13creatorstand for SBIO '13
creatorstand for SBIO '13
 
Splunk Conf 2014 - Splunking the Java Virtual Machine
Splunk Conf 2014 - Splunking the Java Virtual MachineSplunk Conf 2014 - Splunking the Java Virtual Machine
Splunk Conf 2014 - Splunking the Java Virtual Machine
 
HockeyApp: A plataforma para seus apps
HockeyApp: A plataforma para seus appsHockeyApp: A plataforma para seus apps
HockeyApp: A plataforma para seus apps
 
Nordic APIs - Building a Secure API
Nordic APIs - Building a Secure APINordic APIs - Building a Secure API
Nordic APIs - Building a Secure API
 
App Dev in the Cloud: Not my circus, not my monkeys...
App Dev in the Cloud: Not my circus, not my monkeys...App Dev in the Cloud: Not my circus, not my monkeys...
App Dev in the Cloud: Not my circus, not my monkeys...
 
How to Adopt Infrastructure as Code
How to Adopt Infrastructure as CodeHow to Adopt Infrastructure as Code
How to Adopt Infrastructure as Code
 
DOBRÁ ZNAČKA PRO VEŘEJNOU SLUŽBU
DOBRÁ ZNAČKA PRO VEŘEJNOU SLUŽBUDOBRÁ ZNAČKA PRO VEŘEJNOU SLUŽBU
DOBRÁ ZNAČKA PRO VEŘEJNOU SLUŽBU
 
Spark Kernel Talk - Apache Spark Meetup San Francisco (July 2015)
Spark Kernel Talk - Apache Spark Meetup San Francisco (July 2015)Spark Kernel Talk - Apache Spark Meetup San Francisco (July 2015)
Spark Kernel Talk - Apache Spark Meetup San Francisco (July 2015)
 
Reactive dashboard’s using apache spark
Reactive dashboard’s using apache sparkReactive dashboard’s using apache spark
Reactive dashboard’s using apache spark
 
ZNetLive- A Quick Overview
ZNetLive- A Quick OverviewZNetLive- A Quick Overview
ZNetLive- A Quick Overview
 
Using Spark, Kafka, Cassandra and Akka on Mesos for Real-Time Personalization
Using Spark, Kafka, Cassandra and Akka on Mesos for Real-Time PersonalizationUsing Spark, Kafka, Cassandra and Akka on Mesos for Real-Time Personalization
Using Spark, Kafka, Cassandra and Akka on Mesos for Real-Time Personalization
 
FinTech Industry Report 2016
FinTech Industry Report 2016FinTech Industry Report 2016
FinTech Industry Report 2016
 

Ähnlich wie Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices Platform

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionQAware GmbH
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturContinuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturQAware GmbH
 
Java magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollJava magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollWolfgang Weigend
 
Verteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und KubernetesVerteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und KubernetesGregor Biswanger
 
Cloud Native Computing & DevOps
Cloud Native Computing & DevOpsCloud Native Computing & DevOps
Cloud Native Computing & DevOpsAarno Aukia
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
 
Boost your APEX Deployment and Provisioning with Docker
Boost your APEX Deployment and Provisioning with DockerBoost your APEX Deployment and Provisioning with Docker
Boost your APEX Deployment and Provisioning with DockerSteven Grzbielok
 
BATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern
 
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaCloud Observability mit Loki, Prometheus, Tempo und Grafana
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaQAware GmbH
 
Docker for Python Development
Docker for Python DevelopmentDocker for Python Development
Docker for Python DevelopmentMartin Christen
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringQAware GmbH
 
Windows Server 8 - eine Vorschau
Windows Server 8 - eine VorschauWindows Server 8 - eine Vorschau
Windows Server 8 - eine VorschauDigicomp Academy AG
 
A Hitchhiker's Guide to the Cloud Native Stack
A Hitchhiker's Guide to the Cloud Native StackA Hitchhiker's Guide to the Cloud Native Stack
A Hitchhiker's Guide to the Cloud Native StackQAware GmbH
 
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConfA Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConfMario-Leander Reimer
 
Was gibt es Neues im Docker-Universum
Was gibt es Neues im Docker-UniversumWas gibt es Neues im Docker-Universum
Was gibt es Neues im Docker-UniversumNicholas Dille
 

Ähnlich wie Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices Platform (20)

Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Openshift
OpenshiftOpenshift
Openshift
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
Vagrant
VagrantVagrant
Vagrant
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer InfrastrukturContinuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
Continuous Delivery für Cloud-native Anwendungen auf Cloud-nativer Infrastruktur
 
Java magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_vollJava magazin9 2012_wls 12c_das_dutzend_ist_voll
Java magazin9 2012_wls 12c_das_dutzend_ist_voll
 
Verteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und KubernetesVerteilte Anwendungen bei Azure mit Docker und Kubernetes
Verteilte Anwendungen bei Azure mit Docker und Kubernetes
 
Cloud Native Computing & DevOps
Cloud Native Computing & DevOpsCloud Native Computing & DevOps
Cloud Native Computing & DevOps
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Boost your APEX Deployment and Provisioning with Docker
Boost your APEX Deployment and Provisioning with DockerBoost your APEX Deployment and Provisioning with Docker
Boost your APEX Deployment and Provisioning with Docker
 
Cloud-Native ohne Vendor Lock-in mit Kubernetes
Cloud-Native ohne Vendor Lock-in mit KubernetesCloud-Native ohne Vendor Lock-in mit Kubernetes
Cloud-Native ohne Vendor Lock-in mit Kubernetes
 
BATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu MicroservicesBATbern41 Die Evolution zu Microservices
BATbern41 Die Evolution zu Microservices
 
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
Cloud Observability mit Loki, Prometheus, Tempo und GrafanaCloud Observability mit Loki, Prometheus, Tempo und Grafana
Cloud Observability mit Loki, Prometheus, Tempo und Grafana
 
Docker for Python Development
Docker for Python DevelopmentDocker for Python Development
Docker for Python Development
 
Make Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform EngineeringMake Developers Fly: Principles for Platform Engineering
Make Developers Fly: Principles for Platform Engineering
 
Windows Server 8 - eine Vorschau
Windows Server 8 - eine VorschauWindows Server 8 - eine Vorschau
Windows Server 8 - eine Vorschau
 
A Hitchhiker's Guide to the Cloud Native Stack
A Hitchhiker's Guide to the Cloud Native StackA Hitchhiker's Guide to the Cloud Native Stack
A Hitchhiker's Guide to the Cloud Native Stack
 
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConfA Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
A Hitchhiker’s Guide to the Cloud Native Stack. #ContainerConf
 
Was gibt es Neues im Docker-Universum
Was gibt es Neues im Docker-UniversumWas gibt es Neues im Docker-Universum
Was gibt es Neues im Docker-Universum
 

Mehr von Bernd Zuther

Von Null auf Hundert mit Microservices
Von Null auf Hundert mit Microservices Von Null auf Hundert mit Microservices
Von Null auf Hundert mit Microservices Bernd Zuther
 
code.talks 2015 - Microservices und die Jagd nach mehr Konversion
code.talks 2015 - Microservices und die Jagd nach mehr Konversioncode.talks 2015 - Microservices und die Jagd nach mehr Konversion
code.talks 2015 - Microservices und die Jagd nach mehr KonversionBernd Zuther
 
Confess - Microservices and Conversion Hunting - Build architectures for chan...
Confess - Microservices and Conversion Hunting - Build architectures for chan...Confess - Microservices and Conversion Hunting - Build architectures for chan...
Confess - Microservices and Conversion Hunting - Build architectures for chan...Bernd Zuther
 
Javaland 2015 - Bernd Zuther - Die Jagd nach mehr Konversion - Fluch oder Seg...
Javaland 2015 - Bernd Zuther - Die Jagd nach mehr Konversion - Fluch oder Seg...Javaland 2015 - Bernd Zuther - Die Jagd nach mehr Konversion - Fluch oder Seg...
Javaland 2015 - Bernd Zuther - Die Jagd nach mehr Konversion - Fluch oder Seg...Bernd Zuther
 
Memory leak analyse
Memory leak analyseMemory leak analyse
Memory leak analyseBernd Zuther
 
Building an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBuilding an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBernd Zuther
 
Building an-online-recommendation-engine-with-mongodb-cebit-hannover
Building an-online-recommendation-engine-with-mongodb-cebit-hannoverBuilding an-online-recommendation-engine-with-mongodb-cebit-hannover
Building an-online-recommendation-engine-with-mongodb-cebit-hannoverBernd Zuther
 
Building an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBuilding an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBernd Zuther
 
Building an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBuilding an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBernd Zuther
 
Mongodb + Hadoop Big Data Solyanka
Mongodb + Hadoop Big Data SolyankaMongodb + Hadoop Big Data Solyanka
Mongodb + Hadoop Big Data SolyankaBernd Zuther
 
Real time Analytics with MongoDB
Real time Analytics with MongoDBReal time Analytics with MongoDB
Real time Analytics with MongoDBBernd Zuther
 

Mehr von Bernd Zuther (11)

Von Null auf Hundert mit Microservices
Von Null auf Hundert mit Microservices Von Null auf Hundert mit Microservices
Von Null auf Hundert mit Microservices
 
code.talks 2015 - Microservices und die Jagd nach mehr Konversion
code.talks 2015 - Microservices und die Jagd nach mehr Konversioncode.talks 2015 - Microservices und die Jagd nach mehr Konversion
code.talks 2015 - Microservices und die Jagd nach mehr Konversion
 
Confess - Microservices and Conversion Hunting - Build architectures for chan...
Confess - Microservices and Conversion Hunting - Build architectures for chan...Confess - Microservices and Conversion Hunting - Build architectures for chan...
Confess - Microservices and Conversion Hunting - Build architectures for chan...
 
Javaland 2015 - Bernd Zuther - Die Jagd nach mehr Konversion - Fluch oder Seg...
Javaland 2015 - Bernd Zuther - Die Jagd nach mehr Konversion - Fluch oder Seg...Javaland 2015 - Bernd Zuther - Die Jagd nach mehr Konversion - Fluch oder Seg...
Javaland 2015 - Bernd Zuther - Die Jagd nach mehr Konversion - Fluch oder Seg...
 
Memory leak analyse
Memory leak analyseMemory leak analyse
Memory leak analyse
 
Building an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBuilding an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDB
 
Building an-online-recommendation-engine-with-mongodb-cebit-hannover
Building an-online-recommendation-engine-with-mongodb-cebit-hannoverBuilding an-online-recommendation-engine-with-mongodb-cebit-hannover
Building an-online-recommendation-engine-with-mongodb-cebit-hannover
 
Building an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBuilding an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDB
 
Building an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDBBuilding an Online-Recommendation Engine with MongoDB
Building an Online-Recommendation Engine with MongoDB
 
Mongodb + Hadoop Big Data Solyanka
Mongodb + Hadoop Big Data SolyankaMongodb + Hadoop Big Data Solyanka
Mongodb + Hadoop Big Data Solyanka
 
Real time Analytics with MongoDB
Real time Analytics with MongoDBReal time Analytics with MongoDB
Real time Analytics with MongoDB
 

Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices Platform

  • 1. D:4,90EUR A:5,60EUR CH:9,80CHF Benelux:5,80EUR ISSN2191-6977 Javaaktuell Javaaktuell 03-2016 | Herbst | www. ijug.eu Praxis. Wissen. Networking. Das Magazin für Entwickler Aus der Community — für die Community 419197830490303 iJUG Verbund Container-Architektur Verteilte Java-Anwen­ dungen mit Docker Microservices Schnell und einfach implementieren Java-Web-Anwendungen Fallstricke bei der sicheren Entwicklung
  • 2. 4 | Inhalt Sich schnell einen Überblick über bestehende Strukturen und deren Beziehungen verschaffen 34 3 Editorial 5 Das Java-Tagebuch Andreas Badelt 8 Verteilte Java-Anwendungen mit Docker Dr. Ralph Guderlei und Benjamin Schmid 12 JavaLand 2016: Java-Community- Konferenz mit neuem Besucherrekord Marina Fischer 14 Groovy und Grails – quo vadis? Falk Sippach 20 PL/SQL2Java – was funktioniert und was nicht Stephan La Rocca 25 Canary-Releases mit der Very Awesome Micro­services Platform Bernd Zuther 28 Weiterführende Themen zum Batch Processing mit Java EE 7 Philipp Buchholz 34 Exploration und Visualisierung von Software-Architekturen mit jQAssistant Dirk Mahler 38 Fallstricke bei der sicheren Entwicklung­ von Java-Web-­Anwendungen Dominik Schadow 43 Java ist auch eine Insel − Einführung, Ausbildung, Praxis gelesen von Daniel Grycman 44 Microservices – live und in Farbe Dr. Thomas Schuster und Dominik Galler 49 Open-Source-Performance- Monitoring mit stagemonitor Felix Barnsteiner und Fabian Trampusch 53 Profiles for Eclipse – Eclipse im Enterprise-Umfeld nutzen und verwalten Frederic Ebelshäuser und Sophie Hollmann 57 JAXB und Oracle XDB Wolfgang Nast 61 Java-Enterprise-Anwendungen effizient und schnell entwickeln Anett Hübner 66 Impressum 66 Inserentenverzeichnis Neues von den letzten Releases Daten in unterschiedlichen Formaten in der Datenbank ablegen 57 14
  • 3. | 25 www.ijug.eu iii iiiiii iii Java aktuell 3-2016 Canary-Releases mit der Very Awesome Micro­services Platform Bernd Zuther, codecentric AG ImmermehrUnternehmenzerschlagenihreSoftware-SystemeinkleineMicroservices. Wenn das passiert, entstehen mehrere Deployment-Artefakte, was nicht nur das DeploymentdesGesamtsystemskomplexermacht.UmdieseKomplexitätbeherrschen zukönnenunddieAuslieferungsmöglichkeiteneinerSoftwarezuverbessern,istder Einsatz von Werkzeugen zur Infrastruktur-Automatisierung unumgänglich. sich „Canary-Release“ nennt. Dabei werden Änderungen erst einmal nur einem Teil der Benutzer zu Verfügung gestellt und es wird gemessen, wie dieser Teil auf die Änderun- gen reagiert, bevor man die neue Software auf der kompletten Infrastruktur ausrollt. Durch dieses Vorgehen wird eine Möglich- keit geschaffen, Software schrittweise aus fachlicher Sicht zu verbessern [2]. Abbildung 1 stellt den Aufbau eines Cana- ry-Release dar. Es ähnelt in der Ausführung einem Blue-Green-Deployment [3], das aber das Ziel verfolgt, die Downtime einer Applika- tion zu minimieren. Bei beiden Verfahren wer- den zwei Infrastruktur-Stränge benötigt, auf die zwei unterschiedliche Software-Versionen geliefert werden. Dabei handelt es sich jeweils um die neue und die alte Version der Software. Über einen Router werden die Benutzer auf die entsprechende Version umgeleitet. Bei einem Blue-Green-Deployment macht man einen harten Wechsel auf die neue Ver- sion der Software. Beim Canary-Release wer- den dagegen beispielsweise nur fünf Prozent des Traffics auf die neue Version umgeleitet. Damit soll herausgefunden werden, ob eine neue Funktionalität wirklich eine signifikante Veränderung im Verhalten der Benutzer aus- löst. Diese Release-Form kann auch benutzt werden, um A/B-Testing zu implementieren. Das Durchführen von Canary-Releases ist bei einer Microservice-Architektur eine nicht trivi- ale Aufgabe. Microservice-Architektur Abbildung 2 zeigt ein Verteilungsdiagramm einer Microservice-Architektur, das die Kom- plexität dieser Architektur-Form verdeutli- chen soll. Hier sind unterschiedlichste Arte- fakte zu sehen, die entstehen können, wenn NurUnternehmen,dieesschaffen,sichschnell genug an die sich ändernden Ansprüche und Anforderungen ihrer Kunden anpassen zu können, werden auf lange oder kurze Sicht überlebensfähig bleiben. Die Absatzmärk- te der meisten Firmen erfahren seit einigen Jahren einen drastischen Wandel. Durch Glo- balisierung, Marktsättigung und das Internet haben sich stark konkurrierende und dynami- sche Märkte entwickelt, die bedarfsgesteuert sind. Daher sollten sich Unternehmen an die veränderten Bedürfnisse ihrer Kunden schnell anpassen: An dieser Stelle sollte von „kosten- effizienter Skalierung“ zu „Reaktionsfähigkeit“ gewechselt werden [1]. Canary-Release Um das Risiko beim Ausrollen einer neuen Software-Version zu vermindern, benut- zen viele Unternehmen eine Technik, die Abbildung 1: Canary-Release
  • 4. 26 | Micro­services man eine monolithische Anwendung in eine Microservice-Architektur zerteilt. Auf dem linken Server ist eine Shop-Anwendung zu sehen, die über eine WAR-Datei ausgeliefert wird und über einen Service mit dem rech- ten Server kommuniziert. Auf diesem Server sind drei verschiedene Anwendungen ins- talliert. Eine Anwendung implementiert eine Katalog-Ansicht, die von einem Nginx aus- geliefert wird. Außerdem sind ein Produkt- und ein Warenkorb-Service dargestellt, die jeweils über eine JAR-Datei gestartet wer- den. Damit die Anwendung vollständig läuft, sind also vier Artefakt-Arten erforderlich, die unterschiedlich betrieben werden [4]. Docker Docker eignet sich, um diese unterschied- lichen Artefakt-Arten aus Betriebssicht zu standardisieren. Es bietet Funktionen zum Erstellen und Pflegen von Images, die man über eine sogenannte „Registry“ sehr einfach und schnell auf andere Rechner verteilen kann. Betreibt man den Docker-Daemon auf einem Rechner, kann man aus einem solchen Image einen Container erzeugen, der einen laufenden Linux-Prozess beinhaltet. Der Do- cker-Daemon nutzt zum Ausführen solcher Prozesse spezielle Kernel-Funktionalitäten, um einzelne Prozesse in den Containern von- einander abzugrenzen. Container enthalten kein Betriebssystem, sondern nur die jeweils erforderlichen Linux-Anwendungen und de- ren benötigte Bibliotheken [5]. Listing 1 verdeutlicht einen Workflow, der mit Docker abgebildet werden kann, um Anwendungen auf beliebigen anderen Rech- nern auszuführen. Zuerst wird mithilfe eines Docker-Files und des Build-Kommandos ein Image gebaut. Dann übermittelt man das Image mit dem Push-Kommando in eine pri- vate oder öffentliche Registry. Auf dem Ziel- rechner wird ein Image mit dem Pull-Kom- mando aus der Registry heruntergeladen und mit dem Run-Kommando gestartet. Danach läuft auf diesem Rechner ein neuer Prozess. Docker im verteilten System Um zwei Container miteinander per Netz- werk kommunizieren zu lassen, bietet Docker das Link-Konzept an. Beim Verlinken werden IP und exportierte Ports des Zielcontainers als Umgebungsvariable im nutzenden Con- tainer bereitgestellt. Der Container, der den Link erzeugt, kann in der Konfiguration der Anwendung auf diese Umgebungsvariablen zugreifen und muss nicht IP und Port direkt verwenden. Listing 2 zeigt, wie diese Umge- bungsvariablen aussehen. Die Verlinkung funktioniert allerdings nur, wenn sich die Docker-Container auf dem gleichen Server befinden. Wenn Container über mehrere Server verteilt und mitein- ander verbunden werden sollen, kann das direkt über IP und Port passieren. Möchte man dies per Hand machen, muss man sich auf den unterschiedlichen Rechnern an- melden, die Container in einer bestimmten Reihenfolge starten und die entsprechen- den Umgebungsvariablen setzen. Sollten sich IP oder Port der Zielcontainer ändern, müsste der zugreifende Container angepasst und neu gestartet werden. Dieses Vorge- hen würde zu einer statischen Umgebung führen und man könnte nicht einfach neue Rechner hinzufügen oder wegnehmen [6]. Very Awesome Microservices Platform Die Very Awesome Microservices Platform (VAMP, [7]) ist ein Werkzeug, das an dieser Stelle ansetzt. Es verwendet aktuell Mesos und Marathon als Container-Manager. Die Plattform wird von der niederländischen Fir- ma magnetic.io [8] entwickelt. Mesos [9] sorgt für die Ressourcen-Verwaltung im Cluster und ist verantwortlich für das Starten von Do- cker-Containern in einem verteilten Rechner- Cluster. Marathon [10] ist ein Werkzeug, das auf Mesos aufbaut. Mit Marathon kann das Deployment von Microservice-Anwendungen durchgeführt werden. Marathon stellt einen Scheduler dar, der die Verteilung und Ausfüh- rung von Docker-Containern steuert (siehe Ab- bildung 3). Vamp ist ein Dienst, der sich oberhalb eines Container-Managers wie Marathon ansiedelt und aus mehreren Komponenten besteht. bz@cc1 $ docker build -t zutherb/product-service . bz@cc1 $ docker push zutherb/product-service bz@cc2 $ docker pull zutherb/product-service bz@cc2 $ docker run zutherb/product-service bz@cc2 $ docker ps CONTAINER ID IMAGE COMMAND 87bb5524067d zutherb/product-service:latest ”/product-0.6/bin/ bz@cc $ docker exec 254e40d85a33 env MONGODB_PORT_27017_TCP=tcp://172.17.0.2:27017 MONGODB_PORT_27017_TCP_ADDR=172.17.0.2 MONGODB_PORT_27017_TCP_PORT=27017 Listing 1 Listing 2 Abbildung 2: Verteilungsdiagramm einer Microservice-Architektur
  • 5. | 27 www.ijug.eu iii iiiiii iii Java aktuell 3-2016 Vamp-Core bietet eine Plattform-agnostische DSL und ein REST-API. Die DSL kann ähnlich wie Giant Swarm [11] und Docker-Compose [12] benutzt werden, um eine Microservice- Anwendung mit all ihren Abhängigkeiten zu beschreiben und auszuführen. Listing 3 zeigt einen Ausschnitt aus einer solchen Beschreibung [13]. Diese DSL wird von Vamp-Core benutzt, um mit Marathon die Microservices im Mesos-Cluster auszuliefern. Außerdem beinhaltet die DSL Elemente zum Beschreiben von A/B-Tests und Canary-Re- leases sowie zum Beschreiben von SLAs. Die- se SLAs sorgen dafür, dass, wenn bestimmte Antwortzeiten unterschritten werden und noch Ressourcen im Cluster verfügbar sind, automatisch neue Docker-Container im Clus- ter gestartet werden. Zum Sammeln der Metriken, die für die SLAs und A/B-Tests benötigt werden, gibt es den Metriken- und Event-Store Vamp-Pulse, in dem Daten von Core und Router in Elas- ticsearch gespeichert werden. Der Vamp- Router ist eine Komponente, die einen HA- Proxy steuert, der die Verbindung zwischen den laufenden Docker-Containern und den eigentlichen Benutzern realisiert [14]. Fazit Um die Reaktionsfähigkeit durch Canary-Re- leases und A/B-Testing für die Produkt-Ent- wicklung zu verringern, die Effizienz bei der Auslieferung von Microservice-Architekturen zu verbessern und eine größere Geschwin- digkeit in die Auslieferung von Software zu bekommen, ist Vamp eine Plattform, die sich sehr gut für folgende Aufgaben eignet: • Jeden einzelnen Service in einer Microser- vice-Architektur erst mal nur im Rahmen eines Canary-Release mit einem klei- nen Teil seiner Benutzer testen und fest- stellen, ob eine Änderung wirklich einen Mehrwert für seine Kunden bringt • Software schneller und ohne Ausfallzei- ten mithilfe eines Blue-Green-Deploy- ment in Produktion bringen • Testumgebungen einfachen bereitstel- len, da auf unterschiedlichen Endpunkten unterschiedliche Anwendungskonfigura- tionen ausgeliefert werden können • Bei Lastspitzen sein eigenes Datencenter um Cloud-Infrastrukturen erweitern und automatisch bei bestimmen Antwortzei- ten herauf und herunter skalieren • Daten im Metrik- und Event-System sam- meln, um nachhaltige Entscheidungen über Veränderungen treffen zu können. Diese kommen aus dem Live-Betrieb und können vom Anfang bis zum Ende der Wertschöpfungskette vollständig auto- matisiert betrieben werden. Quellen [1] https://blog.codecentric.de/2015/08/the-need-for- speed-eine-geschichte-ueber-devops-microservic- es-continuous-delivery-und-cloud-computing/ [2] http://martinfowler.com/bliki/CanaryRelease.html [3] http://martinfowler.com/bliki/BlueGreenDeploy- ment.html [4] Zuther, Bernd: Microservices und die Jagd nach mehr Konversion., in: Java aktuell (2015), Nr. 2, S. 35 – 40. [5] https://public.centerdevice.de/00d60e2d-5490- 4df6-afe0-c70824ffb14b [6] https://blog.codecentric.de/2015/08/variation- des-ambassador-pattern-von-coreos/ [7] http://vamp.io/ [8] http://magnetic.io/ [9] http://mesos.apache.org/ [10] https://mesosphere.github.io/marathon/ [11] https://blog.codecentric.de/2015/05/microservice- deployment-ganz-einfach-mit-giant-swarm/ [12] https://blog.codecentric.de/2015/05/microservice- deployment-ganz-einfach-mit-docker-compose/ [13] https://github.com/zutherb/AppStash/blob/mas- ter/vamp/shop-ab-test.yml [14] https://blog.codecentric.de/2015/10/canary-release- mit-der-awesome-microservices-platform-vamp/ Abbildung 3: Vamp-Architektur Bernd Zuther ist seit mehreren Jahren als Software- Entwickler tätig. Derzeit ist er bei der codecentric AG als Berater im Bereich Agile Software Factory be- schäftigt, wo er vor allem Themen in den Bereichen „Big Data“, „Continuous Delivery“ und „Agile Software- Architekturen“ bearbeitet. Bernd verfügt über langjäh- rige Erfahrung im Bereich E-Commerce und beschäf- tigt sich seit mehreren Jahren mit der Entwicklung von hochverfügbaren, individuellen Online-Systemen. Bernd Zuther bernd.zuther@codecentric.de Hinweis: Das Listing 3 finden sie online un- ter: www.ijug.eu/go/javaaktuell/zuther/listing