SlideShare ist ein Scribd-Unternehmen logo
COMLINE Cloud Services
Guidelines zur Software-Entwicklung auf der CSP
Christian Günther
Hannover, 09.12.2016
Die COMLINE AG präsentiert
Entwicklungs-Guidelines der Open Platform
1. Obey CQRS
2. Codebasis
3. Abhängigkeiten
4. Konfiguration
5. Build, Release, Run
6. Backend-Dienste
7. Prozesse
8. Laufzeitcontainer
9. Interfacing
10. Port Binding
11. Concurrency & Skalierung
12. Elastizität & Verfügbarkeit
13. Dev-/Prod-Parität
14. Logs
15. Administration und One-off Tasks
Entwicklungs-Guidelines
Architektur-Guidelines stellen, sprach-
und laufzeitunabhängige Regeln,
sowohl für die Entwicklung (Dev), als
auch für das Operation (Ops) der
Services und Applikationen dar.
 CQRS Command Query Responsibility
Segregation
 Trennung der Verantwortung von Software-
Komponenten, je nachdem, ob sie für
schreibende oder lesende Operationen genutzt
werden.
 Gegenentwurf zum klassischen CRUD – Create,
Read, Update Delete.
 Commands sollen, möglichst kleine, Teile von
Daten schreiben.
 Queries sollen möglichst große Mengen an
Daten auf einmal lesen.
 CQRS kann in unterschiedlichen
Architekturmustern eingesetzt werden, eignet
sich aber insbesondere mit der Nutzung einer
Document Database, wie MongoDB.
CQRS setzt auf einem Domain-
Modell auf und verteilt die Workload
für lesende und schreibende
Arbeiten auf zwei getrennte
Arbeitsbereiche in der Software
Obey CQRS
Codebasis
Eine Codebasis mehrere Deploys
 Jeder Service wird in einem Versions-Control
System verwaltet.
 Eine Codebasis ist ein einzelnes Repository.
 Repository und Service haben eine 1:1
Beziehung.
 Wenn ein Service mehrere Repositories hat, ist
es keine App, sondern ein verteiltes System.
 Jede Komponente in einem verteilten System ist
ein Service/ eine App und muss den Guidelines
entsprechen.
 Pro Service gibt es nur eine Codebasis, aber es
kann verschiedene Versionen geben.
 Ein Deploy ist eine lauffähige Instanz des
Service – typischerweise eine produktive und
eine oder mehrere Staging-Instanzen.
 Zusätzlich hat jeder Entwickler eine lauffähige
Instanz als lokale Kopie.
Abhängigkeiten
Dependencies werden während
des Builds aufgelöst und in das
Deployment Package injiziert.
Explizites deklarieren und isolieren von
Abhängigkeiten
 Ein Service darf keine systemweit verfügbaren
Pakete oder Tools implizit annehmen / voraussetzen.
 Abhängigkeiten zu Libraries, Paketen oder externen
Tools (Beispielsweise ImageMagick oder Tomcat)
müssen explizit in einem Manifest deklariert werden.
 Die Auflösung von Abhängigkeiten zur Laufzeit wird
über ein Dependency Isolation Tool (wie etwa Maven
für Java) sichergestellt.
 Aufgabe des DIT ist die korrekte und Vollständige
Bereitstellung aller Abhängigkeiten des Service, im
Rahmen des Build- und Deploy-prozesses.
 Um dies sicherzustellen, muss das DIT als global
verfügbares Repository aufgesetzt und als einzige
Quelle für Abhängigkeiten in allen
Entwicklungsumgebungen deklariert werden.
Strikte Trennung von Code und Konfiguration
 Das Laufzeitverhalten eines Service, zum Beispiel hinsichtlich anzubindender
Backend-Dienste oder spezifischer Laufzeitumgebungen oder Zielplattform, wird
durch seine Konfiguration gesteuert.
 Die Konfiguration eines Service kann bei verschiedenen Instanzen (Dev, Prod, ...)
oder Zielplattformen (Release oder etwa Migration) unterschiedlich sein, ohne dass
sich der Code hierdurch ändert.
 Beispiele hierfür sind:
– Credentials zur Anmeldung an Datenbanken
– Cache- und Objektgrößen, Textbegrenzer etc.
 Die Konfiguration eines Service wird zum Deploy dynamisch, entsprechend der Ziel-
Stage, aus einem eigenen Repository hinzugefügt.
Konfiguration
 Speziell für Variablen oder Konstanten welche das Laufzeitverhalten einer
Anwendung beeinflussen gilt die folgende Regel als Constraint:
 Es darf keine Konstanten im Code geben, die nicht über eine Konfigurationsoption
übersteuert werden können.
 Mögliche Werte zur Übersteuerung einer Option (etwa maximale Zeichenlängen etc.)
müssen in der Konfigurationsumgebung ersichtlich sein. Dies gilt explizit auch für
solche Optionen, die zum Release-Zeitpunkt Standardwerte haben. In diesem Fall
können sie etwa auskommentiert und mit einem Vermerk "Standardwert" versehen
sein.
 Konfigurationen können entweder als Umgebungsvariablen, oder als config-file (etwa
cloud-config File für docker) deklariert werden.
 Werden Konfigurationen in config-files angelegt, ist sicherzustellen, dass diese nicht
im Repository der Codebasis mit abgelegt werden, sondern als Dependency in einem
eigenen Repo liegen.
 Werden Konfigurationen über Umgebungsvariablen deklariert, so muss die
Betriebssystem-Umgebung die gemanagte Deklaration pro Instanz ermöglichen.
Konfiguration
Build, release, run
Das Ergebnis eines Build-Prozesses
wird mit einer Konfiguration zu einer
lauffähigen Instanz verbunden.
Strikte Trennung zwischen Build und Run Stages
 Aus einer Codebasis wird durch 3 Stages eine
produktive Instanz:
1. Im Build wird aus der Codebasis eine ausführbares
Programm; hierbei werden alle Dependencies
aufgelöst
2. Im Release-Stage wird zu der laufähigen Instanz die
notwendige Konfiguration hinzugefügt, wie sie für
den jeweiligen Fall (Produktion, Test etc.) notwendig
ist.
3. Im Run-Stage wird die Instanz auf der Plattform
ausgeführt.
 Die Codebasis einer App kann nicht in der
Runtime-Umgebung geändert werden.
 Jedes Deployment bekommt eine eigene
Versionsnummer.
 Jeder Release kann über eine Rollback-Funktion
auf mindestens einen vorherigen Stand
zurückgeführt werden.
Dieser Prozess wird über ein CI-System abgebildet
Siehe hierzu 08_Software_Delivery_...
Alle Backend Dienste als angeschlossene Ressourcen behandeln
 Ein Backend-Service ist jede Art von Dienst, den ein Service über ein Netzwerk nutzt.
 Backend-Services können sowohl lokale Dienste (z.B. Datenbanken oder Message-
Queue-Systeme), externe Drittsysteme (etwa ein Wetterdienst, Twitter oder externe
Mailgateways) oder andere Anwendungs-Services sein.
 Für einen Service ist jeder Backend-Dienst eine eigene Ressource. Das heißt, eine
SQL-Datenbank ist eine Ressource; eine zweite SQL-Datenbank (auch auf dem
selben Server) ist eine zweite, von der ersten getrennte, Ressource.
 Services sind so zu entwickeln, dass die Lokalität (sowohl geografisch, als auch im
Sinne der Administration) eines Backend-Dienstes für diesen unerheblich ist.
 Insbesondere dürfen Services keine impliziten Annahmen hinsichtlich der
Verfügbarkeit und internen Strukturen angeschlossener Dienste machen.
 Ist ein Service von einem (Backend)-Dienst abhängig, so muss er ein Fall-Back
Szenario, für den Fall dass der Service nicht erreichbar ist, vorhalten.
(Backend)-Dienste
Services sind stateless und haben keine gemeinsam genutzten Ressourcen
 Ein Service kann auf einer Laufzeitumgebung mehrmals ausgeführt werden.
 Jeder ausgeführte Prozess eines Service ist dabei von allen anderen Prozessen
abgeschirmt.
 Müssen Services miteinander kommunizieren, so geschieht dies über ein
Nachrichten-System oder offene Protokolle und Schnittstellen (etwa REST) und nicht
über Interprozesskommunikation wie RPC oder RMI – siehe auch Interfacing.
 Services teilen keinen globalen Kontext, wie etwa Variablen, oder Shared Memory
Segmente*.
 Alle zu sichernde Daten müssen in einem persistenten Datastore (typischerweise
eine Datenbank) abgelegt werden.
 Diese Persistenz ist nicht Teil des Service sondern ein Backend Dienst.
 Services können RAM oder Dateisystem-Speicher als temporären Cache nutzen, der
bei einem Neustart oder Abbruch gelöscht wird.
 Die Verfügbarkeit und Konsistenz dieses temporären Speichers darf nicht über den
Kontext der Ausführung eines Service hinweg vorausgesetzt werden – dieses
Constraint betrifft sowohl die parallele Ausführung des gleichen Service, als auch die
wiederholte Ausführung derselben Instanz.
Prozesse und Daten
* Dies könnten sie auch gar nicht, da das Container-System die einzelnen Instanzen voneinander abschirmt.
Ein Service ist in sich vollständig abgeschlossen und alleine lauffähig
 Services sind so zu konfigurieren, dass sie alle zur Laufzeit benötigten Komponenten
(siehe auch Abhängigkeiten) in einem Container bereitstellen. Durch dieses Vorgehen
ist es möglich, Services mit allen Bestandteilen gekapselt zu deployen.
 Im Container wird also eine komplette Laufzeitumgebung, mit allen notwendigen
Dependencies, für den Service bereitgestellt.
Beispiel
 Web-Apps werden häufig im Kontext eines Webservers ausgeführt – etwa PHP als
Modul im Apache, ASP.NET als Seiten im IIS oder JAVA mit Tomcat oder Jetty.
 Braucht ein Service solch einen Applikationsserver, so ist dieser als Dependency zu
deklarieren, und mit dem Service zu deployen.
 Der notwendige Applikationsserver muss also als Teil des Service ausgeliefert und im
selben Kontext (also im User-Space) ausgeführt werden, um die Nutzung von Shared
Memory Segmenten und (nicht durch eine API geschützte) Datennutzung zu
verhindern.
Laufzeitcontainer
Für weitere Informationen zu den Containern, siehe 05_Komponenten_und_OS-Plattform_...
Ein Service exponiert seine Funktionalität immer über eine API basierend auf
einem offenen Protokoll und Schnittstelle
 Anwendungen bestehen gemäß der Microservices Architektur aus sind in sich
gekapselten Services.
 Jeder Service exponiert seine Funktionalität über eine HTTP-API, wobei die
angebotene Version der API im Aufruf erkennbar sein muss (siehe auch Präsentation
zu RESTful API Design).
 Als Übertragungsprotokoll sollte HTTP und als Schnittstelle REST zum Einsatz
kommen. REST ist dem SOAP Ansatz und JSON einer XML-Kodierung vorzuziehen,
es sein denn ein anzubindender Dienst versteht kein JSON, oder bietet keine REST-
Schnittstelle.
 Klassische Methoden, wie Remote Procedure Calls (RPC), Remote Function Call
(RFC) oder Remote Method Invocation (RMI) dürfen nur nach expliziter Freigabe
durch das Architektur-Board eingesetzt werden.
 Diese Methoden widersprechen dem Microservices Ansatz und führen zu einem
hohen Abhängigkeitsgrad zwischen einzelnen Diensten, was zu erhöhten Kosten- und
Wartungseffekten führt.
Interfacing
Eine App exponiert ihren Funktionalität über exakt einen Port
 Soll die Funktionalität einer App von außen erreichbar sein, so ist der Service an
einen entsprechenden Port zu binden – siehe vorherige Slide.
 Werden externe (HTTP)-Ports deklariert, so sind diese immer in einem Port-Bereich,
der vom User-Kontext aus erreichbar ist, zu binden. Typischerweise sind dies alle
Ports über 1024 (bei UNIX).
 Ports im niedrigen Bereich (etwa 1025-9000) sind ebenfalls zu vermeiden, da diese
zwar nicht offiziell zugewiesen sind, aber es häufig eine stillschweigendes
Einverständnis zum Betrieb bestimmter Anwendungen auf diesen Ports gibt – etwa
Port 8000 für Tomcat oder andere J2EE Applikationsserver.
 Der öffentliche Zugriff auf den Port der App muss über ein Routing Layer (etwa
Firewall oder Reverse Proxy) vom offiziellen Port des Transportprotokolls (etwa
HTTP) zum privaten Port der App gemappt werden.
 Benötigt eine App mehr als einen Port, so ist zu prüfen, ob es sich im Sinne der
Microservices Architektur noch um eine App mit einem Service handelt, oder die App
zu splitten ist.
 Die Ausnahme, zu dieser Guideline, sind etwaige Administrations-Interfaces, welche
ebenfalls über einen expliziten und dann weiteren Port zu exponieren sind.
Port Binding
Concurrency & Skalierung
Skalierung und gleichzeitige
Ausführung über ein Servicemodell
Skalierung durch Service Modell
 Anwendungen stellen typischerweise zwei
verschiedene Arten von Prozesstypen bereit:
1. kurzlebige Benutzer- oder System-Interaktion
2. langlaufende, batchartige Jobs
 Werden diese unterschiedlichen Funktionsarten,
durch dedizierte Prozesstypen differenziert,
können Concurrency und Skalierung leicht über
das Service-Modell erreicht werden.
 Beispielsweise kann eine Web-App in den Part
der Userinteraktion über die Webseite und einen
asynchronen Part zur Datenbeschaffung oder -
analyse getrennt werden. Um die gleichzeitige
Ausführung und hohe Last bei der Analyse
optimal zu skalieren, können nun mehrere Web-
Server und/oder Worker (für die Analyse)
instanziiert werden.
Minimale Startup und Shutdown-Zeiten sorgen für Elastizität und Agilität
 Services und Anwendungen müssen in kürzester Zeit nach dem Start "betriebsbereit"
sein; ihre Startup- und Shutdown-Dauer sollte im einstelligen Sekunden-Bereich
liegen.
 Durch extrem schnelle Startup- und Shutdown-Zeiten wird eine hohe Elastizität der
Gesamtarchitektur erreicht.
 Neuer Code/Konfiguration kann einfach und schnell deployd werden, ohne dass es
zu nennenswerten Unterbrechungen in der Service-Bereitstellung kommt.
 Erreicht wird dies durch die Microservice-Architektur (in der eine App immer nur einen
kleinen Funktionsumfang hat) und die asynchrone Anbindung (potentiell komplexer)
Backend-Dienste, wie Persistenz oder einer Message-Queue.
 Ist ein Service von vielen weiteren Diensten Abhängig, so ist zumindest darauf zu
achten, dass der Service starten kann, ohne das diese Komponenten bereits
verfügbar sind, in diesem Fall muss der Service seine eingeschränkte
Dienstbereitschaft signalisieren, oder Caching-Methoden bieten, um Anfragen bis zur
vollständigen Verfügbarkeit, zu speichern.
 Andernfalls kann es zum berüchtigten Dependency-Lock kommen, bei der eine
Anwendung nicht startet, da sie auf eine weitere Komponente wartet, welche
wiederum auf eine weitere Komponente wartet und so weiter.
Startup & Shutdown
Verfügbarkeit und Skalierung durch verteilte
Systeme erreichen
 Früher wurde Verfügbarkeit vor allem durch
Redundanzen, also das Vorhalten von
Backupsystemen, erreicht.
 Die Backupsysteme liefen in einem Stand-By-
Betrieb mit und waren so konzipiert, dass sie,
wenn das Hauptsystem ausfiel, dessen Arbeit
übernehmen konnten.
 Die von diesen Systemen bereitgestellte
Rechenleistung konnte aber im produktiven
Betrieb nicht genutzt werden.
 Verfügbarkeit durch redundantes Bereitstellen
von Infrastruktur mit vorgehaltenen Installationen
der Anwendungen ist entsprechend teuer und
unflexibel.
Elastizität & Verfügbarkeit
Cloud-Service Anwendungen müssen bei Bedarf auf vielen Computingplattformen
gleichzeitig gestartet werden können, ohne sich gegenseitig zu blockieren.
 Werden Anwendungen als Microservices betrachtet und sind sie darüberhinaus als
Agentensystem im Rahmen einer verteilten Architektur konzipiert und entwickelt,
werden, können sie dynamisch an Kapazitätsanforderungen angepasst betrieben
werden.
 Eine Anwendung auf Basis eines verteilten Agentensystems kann auf eine große Zahl
kostengünstiger virtueller Knoten installiert werden. Fällt einer dieser Knoten aus, so
übernehmen andere dessen Last, oder es können weitere Knoten schnell angefahren
werden.
 Außerdem können in einer verteilten, elastischen Architektur die Dienste problemlos
über die Grenzen eines Rechenzentrums hinweg installiert werden, da die
Partitionierung der Daten und Funktionen keine nachträglich einzubringende, sondern
inhärente Eigenschaft des Systems ist.
 Hierzu ist es notwendig, dass auch Backend-Dienste (wie eine Datenbank) als
partitioniertes System konzipiert wurde.
Elastizität statt Redundanz
Die Development, Staging und
Produktionsumgebungen sollten so ähnlich wie
möglich sein und die Entwicklungs- und
Operations-Teams eng zusammenarbeiten.
 Es gibt drei Bereiche in denen Diskrepanzen
negative Auswirkungen auf die Agilität der
Entwicklung und Stabilität des Produktes haben:
 Zeitlich: Ein Entwickler arbeitet über Tage,
Wochen oder sogar Monate bevor dieser Code
in die Produktion überführt wird.
 Personell: Entwickler schrieben den Code und
Operations deployen diesen.
 Umgebung/Tools: Entwickler verwenden in der
Entwicklung komplett andere oder sogar
inkompatible Umgebungen, als die, in der das
fertige Produkt nachher genutzt wird.
Beispiel für eine Dev/Prod-
Diskrepanz: Die Entwicklung
verwendet Jetty und SQLite auf OS
X, während in der Produktion
Glassfish und Oracle auf Linux
genutzt werden.
Dev-/Prod-Parität
Jetty
OS X
SQLLite
Glassfish
Linux
Oracle
Entwicklung Produktion
 Um die zeitliche Diskrepanz zu reduzieren, sollte Code innerhalb kurzer Zeit
(optimaler weise innerhalb von Stunden) in die Produktion überführt werden können.
Hierfür sind Microservices geeignet, da sie typischerweise eine kleine Codebasis
besitzen und damit schnell entwickelt und getestet werden können.
 Zur Reduktion negativer Konsequenzen durch personelle Diskrepanzen sollten
Entwickler und Operations-Verantwortliche das Deployment gemeinsam durchführen,
so dass die Entwickler das Verhalten Ihrer Anwendung in der Produktivumgebung
direkt miterleben.
 Um Diskrepanzen in der Umgebung (Tools) zu reduzieren, sollten Entwicklungs- und
Produktivumgebung möglichst ähnlich sein; etwa indem die Entwickler auf einer
virtuellen Maschine mit allen Komponenten aus der Produktionsumgebung
entwickeln.
Dev-/Prod-Parität
Gerade bei Backend Diensten, wie Datenbanken, Messaging Systemen oder
Caching-Komponenten, ist besonderes Augenmerk auf die Dev-/Prod-Parität zu
legen.
 Entwickler bevorzugen bei diesen Systemen oft leichtgewichtige Anwendungen, da
sie sich dann mehr auf ihren Code konzentrieren können.
 In der Produktionsumgebung werden aber evtl. komplexere Systeme eingesetzt, zum
Beispiel könnte ein Entwickler auf seinem lokalen System eine MySQL Datenbank
nutzen, in der Produktion setzt man aber evtl. auf Oracle.
 Folgt man den vorliegenden Guidelines (siehe auch Backend Dienste) werden
Backend Komponenten über einheitliche Interfaces angesprochen und eine gewisse
Diskrepanz ist zu verschmerzen.
 Trotzdem sollte auch in diesem Fall auf möglichst große Nähe zwischen Entwicklung,
Staging und Produktion geachtet werden, um Seiten- oder Skalierungseffekte
frühzeitig zu erkennen. Selbst kleine Unterschiede, etwa im Locking-Mechanismus
oder in der Caching-Engine, können sich schnell zu großen Problemfeldern
entwickeln.
Dev-/Prod-Parität – Backend Services
Logs als Event-Stream betrachten
 Logs zeigen das Laufzeitverhalten einer Anwendung auf, indem sie zeitlich geordnet
die Events im Gesamtsystem wiederspiegeln.
 Traditionell wurden Logs von den Anwendungen generiert und dann in eine Datei
(Logfile) geschrieben.
 In einer monolithischen Anwendung, bei der alles in einem System geschieht, ist
dieser Ansatz nützlich.
 In einem verteilten System, mit vielen kleinen Diensten, führt dies im Fehlerfall zu
hohen Aufwänden und erschwert die Ursachenforschung.
 Eine verteilte Anwendung innerhalb einer Microservices-Architektur sollte Logs nicht
selbst in eine Datei, sondern unbuffered in den Standardkanal stdout schreiben.
 In der Entwicklungsumgebung kann der Programmierer diesen Kanal direkt
überwachen, in Staging und Produktion wird stdout von einer Event-Stream
Komponente aufgenommen weiter verarbeitet.
Logs
 Jeder Service schreibt seine Logs mit
Informationen zu seinem eigenen Prozess und
der Umgebung nach stdout.
 Der Log-Event-Stream aus stdout wird, evtl.
zusammen mit anderen Log-Events auf dem
gleichen System, von einem Event-Stream
Processor aufgenommen und an ein zentrales
System zum Monitoring und Archivieren
überführt.
 Mögliche Komponenten hierfür sind Logplex
oder Fluent.
 Über diese können die Logs an weitere
Systeme, etwa Splunk zur Echtzeitanalyse,
weitergeleitet werden und ermöglichen somit
nicht nur einen Blick auf den lokalen
Anwendungszustand, sondern die Analyse des
Gesamtsystems.
Beispiel für ein Log-Event Stream
System
Log-Event Stream System
Die Administration einer Anwendung sollte nicht zwischen Routine- und speziellen
Einzelaufgaben unterscheiden.
 Tägliche administrative Aufgaben zum Betrieb einer App, etwa die Überprüfung von
Logs oder das Leeren/Synchronisieren eines Caches, fallen üblicherweise im
Rahmen der Produktivumgebung an und werden zumeist durch, zur Anwendung
gehörenden, Tools unterstützt.
 Daneben gibt es spezielle Aufgaben, wie die Migration von Daten (etwa in einer
Datenbank), welche Entwickler häufig in der Dev- oder Staging-Umgebung proben
und die sie häufig als Sonderfall mit einer speziellen Umgebung ansehen.
 Um die Komplexität dieser Aufgaben für alle Beteiligten (seien es nun Entwickler oder
Administratoren) zu minimieren, sollten diese One-Off Tasks genauso als Teil der
Administrationsumgebung einer Anwendung behandelt werden, wie Tools für
Routineaufgaben.
Administration und One-off Tasks
One-off Tasks sind üblicherweise kein Tagesgeschäft, weshalb einige
Besonderheiten zu beachten und teilweise auch spezielle Verfahren notwendig
sind.
 Ein One-off Task ist in einer, zur Zielumgebung, identischen Plattform durchzuführen.
 Jeder One-off Task stellt einen speziellen Release (etwa einen Migrationsrelease) mit
spezifischer Konfiguration und Zielplattform dar.
 Für den Task notendige Tools müssen in das Dependency-Manifest (siehe
Abhängigkeiten) des Releases mit aufgenommen werden.
 Quell- und Zielsystem, also der Zustand der Systemumgebung mit Daten, Code und
Konfiguration, sollte vor und nach der Durchführung eingefroren oder gesichert
werden.
Administration und One-off Tasks
Christian Günther
Principal Solution Architect
Mobile: +49 1511 22 40 942
E-Mail: christian.guenther@comlineag.de
COMLINE Computer und Softwarelösungen AG
Leverkusenstr. 54
DE - 22761 Hamburg
www.comlineag.de
Vielen Dank für Ihre Aufmerksamkeit.

Weitere ähnliche Inhalte

Andere mochten auch

InformeFinal
InformeFinalInformeFinal
InformeFinal
Anastasia Belikow
 
Evaluation de la qualité des processus informatiques en petites et moyennes e...
Evaluation de la qualité des processus informatiques en petites et moyennes e...Evaluation de la qualité des processus informatiques en petites et moyennes e...
Evaluation de la qualité des processus informatiques en petites et moyennes e...
christophefeltus
 
Gracia silvia-fábula la grenouille et la huître
Gracia silvia-fábula la grenouille et la huîtreGracia silvia-fábula la grenouille et la huître
Gracia silvia-fábula la grenouille et la huître
hadibujo
 
lineas de tiempo de tecnologia
lineas de tiempo de tecnologialineas de tiempo de tecnologia
lineas de tiempo de tecnologia
jhonatan wilson
 
PARTENARIAT MIW CREA IUT
PARTENARIAT MIW CREA IUTPARTENARIAT MIW CREA IUT
PARTENARIAT MIW CREA IUT
Pascal Boscher
 
Beloisia Belzheimer 1
Beloisia Belzheimer 1Beloisia Belzheimer 1
Beloisia Belzheimer 1
trbecker
 
4 Notas sobre Emprendimiento
4 Notas sobre Emprendimiento4 Notas sobre Emprendimiento
4 Notas sobre Emprendimiento
Eduardo Reyes
 
Speranze
SperanzeSperanze
Actividad integradora
Actividad integradoraActividad integradora
Actividad integradora
Antonio Lopez
 
Les cellules
Les cellulesLes cellules
Les cellules
Rana Habchy
 
AEM Projet de décret 2.15.257 ( Version en Arabe )
AEM Projet de décret 2.15.257 ( Version en Arabe )AEM Projet de décret 2.15.257 ( Version en Arabe )
AEM Projet de décret 2.15.257 ( Version en Arabe )
Auto-Entrepreneurs MAROC
 
Cr délib 14 1307-siae
Cr délib 14 1307-siaeCr délib 14 1307-siae
Cr délib 14 1307-siae
Martine Promess
 
Appel à projet permanent cr2015 ateliers et aci
Appel à projet permanent cr2015 ateliers et aciAppel à projet permanent cr2015 ateliers et aci
Appel à projet permanent cr2015 ateliers et aci
Martine Promess
 
Guide to Bill 28 French
Guide to Bill 28 FrenchGuide to Bill 28 French
Guide to Bill 28 French
Medavie Blue Cross
 
Cv créatif Cécile Désiré
Cv créatif Cécile DésiréCv créatif Cécile Désiré
Cv créatif Cécile Désiré
Désiré Cécile
 
Extrait jardins solidaires 84 solid'agri 2015
Extrait jardins solidaires 84 solid'agri 2015Extrait jardins solidaires 84 solid'agri 2015
Extrait jardins solidaires 84 solid'agri 2015
Martine Promess
 

Andere mochten auch (18)

InformeFinal
InformeFinalInformeFinal
InformeFinal
 
Evaluation de la qualité des processus informatiques en petites et moyennes e...
Evaluation de la qualité des processus informatiques en petites et moyennes e...Evaluation de la qualité des processus informatiques en petites et moyennes e...
Evaluation de la qualité des processus informatiques en petites et moyennes e...
 
Gracia silvia-fábula la grenouille et la huître
Gracia silvia-fábula la grenouille et la huîtreGracia silvia-fábula la grenouille et la huître
Gracia silvia-fábula la grenouille et la huître
 
lineas de tiempo de tecnologia
lineas de tiempo de tecnologialineas de tiempo de tecnologia
lineas de tiempo de tecnologia
 
PARTENARIAT MIW CREA IUT
PARTENARIAT MIW CREA IUTPARTENARIAT MIW CREA IUT
PARTENARIAT MIW CREA IUT
 
Beloisia Belzheimer 1
Beloisia Belzheimer 1Beloisia Belzheimer 1
Beloisia Belzheimer 1
 
4 Notas sobre Emprendimiento
4 Notas sobre Emprendimiento4 Notas sobre Emprendimiento
4 Notas sobre Emprendimiento
 
Speranze
SperanzeSperanze
Speranze
 
Lectura digitales2
Lectura digitales2Lectura digitales2
Lectura digitales2
 
Actividad integradora
Actividad integradoraActividad integradora
Actividad integradora
 
Les cellules
Les cellulesLes cellules
Les cellules
 
AEM Projet de décret 2.15.257 ( Version en Arabe )
AEM Projet de décret 2.15.257 ( Version en Arabe )AEM Projet de décret 2.15.257 ( Version en Arabe )
AEM Projet de décret 2.15.257 ( Version en Arabe )
 
Cr délib 14 1307-siae
Cr délib 14 1307-siaeCr délib 14 1307-siae
Cr délib 14 1307-siae
 
Appel à projet permanent cr2015 ateliers et aci
Appel à projet permanent cr2015 ateliers et aciAppel à projet permanent cr2015 ateliers et aci
Appel à projet permanent cr2015 ateliers et aci
 
Guide to Bill 28 French
Guide to Bill 28 FrenchGuide to Bill 28 French
Guide to Bill 28 French
 
Cv créatif Cécile Désiré
Cv créatif Cécile DésiréCv créatif Cécile Désiré
Cv créatif Cécile Désiré
 
Extrait jardins solidaires 84 solid'agri 2015
Extrait jardins solidaires 84 solid'agri 2015Extrait jardins solidaires 84 solid'agri 2015
Extrait jardins solidaires 84 solid'agri 2015
 
Nos vacances à la mer
Nos vacances à la merNos vacances à la mer
Nos vacances à la mer
 

Ähnlich wie 06 Software Development Guidelines der COMLINE Cloud Service Platform - CSP

Server Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerServer Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerSandro Sonntag
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Christian Guenther
 
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
Gregor Biswanger
 
JBoss AS / EAP Clustering
JBoss AS / EAP  ClusteringJBoss AS / EAP  Clustering
JBoss AS / EAP Clustering
hwilming
 
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Bernd Zuther
 
B3 Lotus Expeditor Und Composite Applications
B3 Lotus Expeditor Und Composite ApplicationsB3 Lotus Expeditor Und Composite Applications
B3 Lotus Expeditor Und Composite Applications
Andreas Schulte
 
Lotus Notes SAP Integration Wünsch AG
Lotus Notes SAP Integration Wünsch AGLotus Notes SAP Integration Wünsch AG
Lotus Notes SAP Integration Wünsch AG
Wünsch AG
 
Dateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud ComputingDateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud Computing
Lothar Wieske
 
Introduction to JEE
Introduction to JEEIntroduction to JEE
Introduction to JEEguestc44b7b
 
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
 
Automatischer Build mit Maven - OPITZ CONSULTING - Stefan Scheidt
Automatischer Build mit Maven - OPITZ CONSULTING - Stefan ScheidtAutomatischer Build mit Maven - OPITZ CONSULTING - Stefan Scheidt
Automatischer Build mit Maven - OPITZ CONSULTING - Stefan Scheidt
OPITZ CONSULTING Deutschland
 
Sql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint AdministratorenSql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint Administratoren
Communardo GmbH
 
Sql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point AdminsSql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point Admins
SharepointUGDD
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
matfsw
 
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
adesso AG
 
Automatischer Build mit Maven
Automatischer Build mit MavenAutomatischer Build mit Maven
Automatischer Build mit Maven
Stefan Scheidt
 
Vagrant, Puppet, Docker für Entwickler und Architekten
Vagrant, Puppet, Docker für Entwickler und ArchitektenVagrant, Puppet, Docker für Entwickler und Architekten
Vagrant, Puppet, Docker für Entwickler und Architekten
OPITZ CONSULTING Deutschland
 
react-de.pdf
react-de.pdfreact-de.pdf
react-de.pdf
ssuser65180a
 
Something for the Cloud
Something for the CloudSomething for the Cloud
Something for the Cloud
ESUG
 

Ähnlich wie 06 Software Development Guidelines der COMLINE Cloud Service Platform - CSP (20)

Server Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM ServerServer Revolutions- Der Spring Source DM Server
Server Revolutions- Der Spring Source DM Server
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
 
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
 
JBoss AS / EAP Clustering
JBoss AS / EAP  ClusteringJBoss AS / EAP  Clustering
JBoss AS / EAP Clustering
 
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
 
B3 Lotus Expeditor Und Composite Applications
B3 Lotus Expeditor Und Composite ApplicationsB3 Lotus Expeditor Und Composite Applications
B3 Lotus Expeditor Und Composite Applications
 
Lotus Notes SAP Integration Wünsch AG
Lotus Notes SAP Integration Wünsch AGLotus Notes SAP Integration Wünsch AG
Lotus Notes SAP Integration Wünsch AG
 
Dateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud ComputingDateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud Computing
 
Integration camel
Integration camelIntegration camel
Integration camel
 
Introduction to JEE
Introduction to JEEIntroduction to JEE
Introduction to JEE
 
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.
 
Automatischer Build mit Maven - OPITZ CONSULTING - Stefan Scheidt
Automatischer Build mit Maven - OPITZ CONSULTING - Stefan ScheidtAutomatischer Build mit Maven - OPITZ CONSULTING - Stefan Scheidt
Automatischer Build mit Maven - OPITZ CONSULTING - Stefan Scheidt
 
Sql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint AdministratorenSql Server Grundlagen für Sharepoint Administratoren
Sql Server Grundlagen für Sharepoint Administratoren
 
Sql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point AdminsSql Server GrundlagenfüR Share Point Admins
Sql Server GrundlagenfüR Share Point Admins
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
 
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
 
Automatischer Build mit Maven
Automatischer Build mit MavenAutomatischer Build mit Maven
Automatischer Build mit Maven
 
Vagrant, Puppet, Docker für Entwickler und Architekten
Vagrant, Puppet, Docker für Entwickler und ArchitektenVagrant, Puppet, Docker für Entwickler und Architekten
Vagrant, Puppet, Docker für Entwickler und Architekten
 
react-de.pdf
react-de.pdfreact-de.pdf
react-de.pdf
 
Something for the Cloud
Something for the CloudSomething for the Cloud
Something for the Cloud
 

06 Software Development Guidelines der COMLINE Cloud Service Platform - CSP

  • 1. COMLINE Cloud Services Guidelines zur Software-Entwicklung auf der CSP Christian Günther Hannover, 09.12.2016 Die COMLINE AG präsentiert
  • 3. 1. Obey CQRS 2. Codebasis 3. Abhängigkeiten 4. Konfiguration 5. Build, Release, Run 6. Backend-Dienste 7. Prozesse 8. Laufzeitcontainer 9. Interfacing 10. Port Binding 11. Concurrency & Skalierung 12. Elastizität & Verfügbarkeit 13. Dev-/Prod-Parität 14. Logs 15. Administration und One-off Tasks Entwicklungs-Guidelines Architektur-Guidelines stellen, sprach- und laufzeitunabhängige Regeln, sowohl für die Entwicklung (Dev), als auch für das Operation (Ops) der Services und Applikationen dar.
  • 4.  CQRS Command Query Responsibility Segregation  Trennung der Verantwortung von Software- Komponenten, je nachdem, ob sie für schreibende oder lesende Operationen genutzt werden.  Gegenentwurf zum klassischen CRUD – Create, Read, Update Delete.  Commands sollen, möglichst kleine, Teile von Daten schreiben.  Queries sollen möglichst große Mengen an Daten auf einmal lesen.  CQRS kann in unterschiedlichen Architekturmustern eingesetzt werden, eignet sich aber insbesondere mit der Nutzung einer Document Database, wie MongoDB. CQRS setzt auf einem Domain- Modell auf und verteilt die Workload für lesende und schreibende Arbeiten auf zwei getrennte Arbeitsbereiche in der Software Obey CQRS
  • 5. Codebasis Eine Codebasis mehrere Deploys  Jeder Service wird in einem Versions-Control System verwaltet.  Eine Codebasis ist ein einzelnes Repository.  Repository und Service haben eine 1:1 Beziehung.  Wenn ein Service mehrere Repositories hat, ist es keine App, sondern ein verteiltes System.  Jede Komponente in einem verteilten System ist ein Service/ eine App und muss den Guidelines entsprechen.  Pro Service gibt es nur eine Codebasis, aber es kann verschiedene Versionen geben.  Ein Deploy ist eine lauffähige Instanz des Service – typischerweise eine produktive und eine oder mehrere Staging-Instanzen.  Zusätzlich hat jeder Entwickler eine lauffähige Instanz als lokale Kopie.
  • 6. Abhängigkeiten Dependencies werden während des Builds aufgelöst und in das Deployment Package injiziert. Explizites deklarieren und isolieren von Abhängigkeiten  Ein Service darf keine systemweit verfügbaren Pakete oder Tools implizit annehmen / voraussetzen.  Abhängigkeiten zu Libraries, Paketen oder externen Tools (Beispielsweise ImageMagick oder Tomcat) müssen explizit in einem Manifest deklariert werden.  Die Auflösung von Abhängigkeiten zur Laufzeit wird über ein Dependency Isolation Tool (wie etwa Maven für Java) sichergestellt.  Aufgabe des DIT ist die korrekte und Vollständige Bereitstellung aller Abhängigkeiten des Service, im Rahmen des Build- und Deploy-prozesses.  Um dies sicherzustellen, muss das DIT als global verfügbares Repository aufgesetzt und als einzige Quelle für Abhängigkeiten in allen Entwicklungsumgebungen deklariert werden.
  • 7. Strikte Trennung von Code und Konfiguration  Das Laufzeitverhalten eines Service, zum Beispiel hinsichtlich anzubindender Backend-Dienste oder spezifischer Laufzeitumgebungen oder Zielplattform, wird durch seine Konfiguration gesteuert.  Die Konfiguration eines Service kann bei verschiedenen Instanzen (Dev, Prod, ...) oder Zielplattformen (Release oder etwa Migration) unterschiedlich sein, ohne dass sich der Code hierdurch ändert.  Beispiele hierfür sind: – Credentials zur Anmeldung an Datenbanken – Cache- und Objektgrößen, Textbegrenzer etc.  Die Konfiguration eines Service wird zum Deploy dynamisch, entsprechend der Ziel- Stage, aus einem eigenen Repository hinzugefügt. Konfiguration
  • 8.  Speziell für Variablen oder Konstanten welche das Laufzeitverhalten einer Anwendung beeinflussen gilt die folgende Regel als Constraint:  Es darf keine Konstanten im Code geben, die nicht über eine Konfigurationsoption übersteuert werden können.  Mögliche Werte zur Übersteuerung einer Option (etwa maximale Zeichenlängen etc.) müssen in der Konfigurationsumgebung ersichtlich sein. Dies gilt explizit auch für solche Optionen, die zum Release-Zeitpunkt Standardwerte haben. In diesem Fall können sie etwa auskommentiert und mit einem Vermerk "Standardwert" versehen sein.  Konfigurationen können entweder als Umgebungsvariablen, oder als config-file (etwa cloud-config File für docker) deklariert werden.  Werden Konfigurationen in config-files angelegt, ist sicherzustellen, dass diese nicht im Repository der Codebasis mit abgelegt werden, sondern als Dependency in einem eigenen Repo liegen.  Werden Konfigurationen über Umgebungsvariablen deklariert, so muss die Betriebssystem-Umgebung die gemanagte Deklaration pro Instanz ermöglichen. Konfiguration
  • 9. Build, release, run Das Ergebnis eines Build-Prozesses wird mit einer Konfiguration zu einer lauffähigen Instanz verbunden. Strikte Trennung zwischen Build und Run Stages  Aus einer Codebasis wird durch 3 Stages eine produktive Instanz: 1. Im Build wird aus der Codebasis eine ausführbares Programm; hierbei werden alle Dependencies aufgelöst 2. Im Release-Stage wird zu der laufähigen Instanz die notwendige Konfiguration hinzugefügt, wie sie für den jeweiligen Fall (Produktion, Test etc.) notwendig ist. 3. Im Run-Stage wird die Instanz auf der Plattform ausgeführt.  Die Codebasis einer App kann nicht in der Runtime-Umgebung geändert werden.  Jedes Deployment bekommt eine eigene Versionsnummer.  Jeder Release kann über eine Rollback-Funktion auf mindestens einen vorherigen Stand zurückgeführt werden. Dieser Prozess wird über ein CI-System abgebildet Siehe hierzu 08_Software_Delivery_...
  • 10. Alle Backend Dienste als angeschlossene Ressourcen behandeln  Ein Backend-Service ist jede Art von Dienst, den ein Service über ein Netzwerk nutzt.  Backend-Services können sowohl lokale Dienste (z.B. Datenbanken oder Message- Queue-Systeme), externe Drittsysteme (etwa ein Wetterdienst, Twitter oder externe Mailgateways) oder andere Anwendungs-Services sein.  Für einen Service ist jeder Backend-Dienst eine eigene Ressource. Das heißt, eine SQL-Datenbank ist eine Ressource; eine zweite SQL-Datenbank (auch auf dem selben Server) ist eine zweite, von der ersten getrennte, Ressource.  Services sind so zu entwickeln, dass die Lokalität (sowohl geografisch, als auch im Sinne der Administration) eines Backend-Dienstes für diesen unerheblich ist.  Insbesondere dürfen Services keine impliziten Annahmen hinsichtlich der Verfügbarkeit und internen Strukturen angeschlossener Dienste machen.  Ist ein Service von einem (Backend)-Dienst abhängig, so muss er ein Fall-Back Szenario, für den Fall dass der Service nicht erreichbar ist, vorhalten. (Backend)-Dienste
  • 11. Services sind stateless und haben keine gemeinsam genutzten Ressourcen  Ein Service kann auf einer Laufzeitumgebung mehrmals ausgeführt werden.  Jeder ausgeführte Prozess eines Service ist dabei von allen anderen Prozessen abgeschirmt.  Müssen Services miteinander kommunizieren, so geschieht dies über ein Nachrichten-System oder offene Protokolle und Schnittstellen (etwa REST) und nicht über Interprozesskommunikation wie RPC oder RMI – siehe auch Interfacing.  Services teilen keinen globalen Kontext, wie etwa Variablen, oder Shared Memory Segmente*.  Alle zu sichernde Daten müssen in einem persistenten Datastore (typischerweise eine Datenbank) abgelegt werden.  Diese Persistenz ist nicht Teil des Service sondern ein Backend Dienst.  Services können RAM oder Dateisystem-Speicher als temporären Cache nutzen, der bei einem Neustart oder Abbruch gelöscht wird.  Die Verfügbarkeit und Konsistenz dieses temporären Speichers darf nicht über den Kontext der Ausführung eines Service hinweg vorausgesetzt werden – dieses Constraint betrifft sowohl die parallele Ausführung des gleichen Service, als auch die wiederholte Ausführung derselben Instanz. Prozesse und Daten * Dies könnten sie auch gar nicht, da das Container-System die einzelnen Instanzen voneinander abschirmt.
  • 12. Ein Service ist in sich vollständig abgeschlossen und alleine lauffähig  Services sind so zu konfigurieren, dass sie alle zur Laufzeit benötigten Komponenten (siehe auch Abhängigkeiten) in einem Container bereitstellen. Durch dieses Vorgehen ist es möglich, Services mit allen Bestandteilen gekapselt zu deployen.  Im Container wird also eine komplette Laufzeitumgebung, mit allen notwendigen Dependencies, für den Service bereitgestellt. Beispiel  Web-Apps werden häufig im Kontext eines Webservers ausgeführt – etwa PHP als Modul im Apache, ASP.NET als Seiten im IIS oder JAVA mit Tomcat oder Jetty.  Braucht ein Service solch einen Applikationsserver, so ist dieser als Dependency zu deklarieren, und mit dem Service zu deployen.  Der notwendige Applikationsserver muss also als Teil des Service ausgeliefert und im selben Kontext (also im User-Space) ausgeführt werden, um die Nutzung von Shared Memory Segmenten und (nicht durch eine API geschützte) Datennutzung zu verhindern. Laufzeitcontainer Für weitere Informationen zu den Containern, siehe 05_Komponenten_und_OS-Plattform_...
  • 13. Ein Service exponiert seine Funktionalität immer über eine API basierend auf einem offenen Protokoll und Schnittstelle  Anwendungen bestehen gemäß der Microservices Architektur aus sind in sich gekapselten Services.  Jeder Service exponiert seine Funktionalität über eine HTTP-API, wobei die angebotene Version der API im Aufruf erkennbar sein muss (siehe auch Präsentation zu RESTful API Design).  Als Übertragungsprotokoll sollte HTTP und als Schnittstelle REST zum Einsatz kommen. REST ist dem SOAP Ansatz und JSON einer XML-Kodierung vorzuziehen, es sein denn ein anzubindender Dienst versteht kein JSON, oder bietet keine REST- Schnittstelle.  Klassische Methoden, wie Remote Procedure Calls (RPC), Remote Function Call (RFC) oder Remote Method Invocation (RMI) dürfen nur nach expliziter Freigabe durch das Architektur-Board eingesetzt werden.  Diese Methoden widersprechen dem Microservices Ansatz und führen zu einem hohen Abhängigkeitsgrad zwischen einzelnen Diensten, was zu erhöhten Kosten- und Wartungseffekten führt. Interfacing
  • 14. Eine App exponiert ihren Funktionalität über exakt einen Port  Soll die Funktionalität einer App von außen erreichbar sein, so ist der Service an einen entsprechenden Port zu binden – siehe vorherige Slide.  Werden externe (HTTP)-Ports deklariert, so sind diese immer in einem Port-Bereich, der vom User-Kontext aus erreichbar ist, zu binden. Typischerweise sind dies alle Ports über 1024 (bei UNIX).  Ports im niedrigen Bereich (etwa 1025-9000) sind ebenfalls zu vermeiden, da diese zwar nicht offiziell zugewiesen sind, aber es häufig eine stillschweigendes Einverständnis zum Betrieb bestimmter Anwendungen auf diesen Ports gibt – etwa Port 8000 für Tomcat oder andere J2EE Applikationsserver.  Der öffentliche Zugriff auf den Port der App muss über ein Routing Layer (etwa Firewall oder Reverse Proxy) vom offiziellen Port des Transportprotokolls (etwa HTTP) zum privaten Port der App gemappt werden.  Benötigt eine App mehr als einen Port, so ist zu prüfen, ob es sich im Sinne der Microservices Architektur noch um eine App mit einem Service handelt, oder die App zu splitten ist.  Die Ausnahme, zu dieser Guideline, sind etwaige Administrations-Interfaces, welche ebenfalls über einen expliziten und dann weiteren Port zu exponieren sind. Port Binding
  • 15. Concurrency & Skalierung Skalierung und gleichzeitige Ausführung über ein Servicemodell Skalierung durch Service Modell  Anwendungen stellen typischerweise zwei verschiedene Arten von Prozesstypen bereit: 1. kurzlebige Benutzer- oder System-Interaktion 2. langlaufende, batchartige Jobs  Werden diese unterschiedlichen Funktionsarten, durch dedizierte Prozesstypen differenziert, können Concurrency und Skalierung leicht über das Service-Modell erreicht werden.  Beispielsweise kann eine Web-App in den Part der Userinteraktion über die Webseite und einen asynchronen Part zur Datenbeschaffung oder - analyse getrennt werden. Um die gleichzeitige Ausführung und hohe Last bei der Analyse optimal zu skalieren, können nun mehrere Web- Server und/oder Worker (für die Analyse) instanziiert werden.
  • 16. Minimale Startup und Shutdown-Zeiten sorgen für Elastizität und Agilität  Services und Anwendungen müssen in kürzester Zeit nach dem Start "betriebsbereit" sein; ihre Startup- und Shutdown-Dauer sollte im einstelligen Sekunden-Bereich liegen.  Durch extrem schnelle Startup- und Shutdown-Zeiten wird eine hohe Elastizität der Gesamtarchitektur erreicht.  Neuer Code/Konfiguration kann einfach und schnell deployd werden, ohne dass es zu nennenswerten Unterbrechungen in der Service-Bereitstellung kommt.  Erreicht wird dies durch die Microservice-Architektur (in der eine App immer nur einen kleinen Funktionsumfang hat) und die asynchrone Anbindung (potentiell komplexer) Backend-Dienste, wie Persistenz oder einer Message-Queue.  Ist ein Service von vielen weiteren Diensten Abhängig, so ist zumindest darauf zu achten, dass der Service starten kann, ohne das diese Komponenten bereits verfügbar sind, in diesem Fall muss der Service seine eingeschränkte Dienstbereitschaft signalisieren, oder Caching-Methoden bieten, um Anfragen bis zur vollständigen Verfügbarkeit, zu speichern.  Andernfalls kann es zum berüchtigten Dependency-Lock kommen, bei der eine Anwendung nicht startet, da sie auf eine weitere Komponente wartet, welche wiederum auf eine weitere Komponente wartet und so weiter. Startup & Shutdown
  • 17. Verfügbarkeit und Skalierung durch verteilte Systeme erreichen  Früher wurde Verfügbarkeit vor allem durch Redundanzen, also das Vorhalten von Backupsystemen, erreicht.  Die Backupsysteme liefen in einem Stand-By- Betrieb mit und waren so konzipiert, dass sie, wenn das Hauptsystem ausfiel, dessen Arbeit übernehmen konnten.  Die von diesen Systemen bereitgestellte Rechenleistung konnte aber im produktiven Betrieb nicht genutzt werden.  Verfügbarkeit durch redundantes Bereitstellen von Infrastruktur mit vorgehaltenen Installationen der Anwendungen ist entsprechend teuer und unflexibel. Elastizität & Verfügbarkeit
  • 18. Cloud-Service Anwendungen müssen bei Bedarf auf vielen Computingplattformen gleichzeitig gestartet werden können, ohne sich gegenseitig zu blockieren.  Werden Anwendungen als Microservices betrachtet und sind sie darüberhinaus als Agentensystem im Rahmen einer verteilten Architektur konzipiert und entwickelt, werden, können sie dynamisch an Kapazitätsanforderungen angepasst betrieben werden.  Eine Anwendung auf Basis eines verteilten Agentensystems kann auf eine große Zahl kostengünstiger virtueller Knoten installiert werden. Fällt einer dieser Knoten aus, so übernehmen andere dessen Last, oder es können weitere Knoten schnell angefahren werden.  Außerdem können in einer verteilten, elastischen Architektur die Dienste problemlos über die Grenzen eines Rechenzentrums hinweg installiert werden, da die Partitionierung der Daten und Funktionen keine nachträglich einzubringende, sondern inhärente Eigenschaft des Systems ist.  Hierzu ist es notwendig, dass auch Backend-Dienste (wie eine Datenbank) als partitioniertes System konzipiert wurde. Elastizität statt Redundanz
  • 19. Die Development, Staging und Produktionsumgebungen sollten so ähnlich wie möglich sein und die Entwicklungs- und Operations-Teams eng zusammenarbeiten.  Es gibt drei Bereiche in denen Diskrepanzen negative Auswirkungen auf die Agilität der Entwicklung und Stabilität des Produktes haben:  Zeitlich: Ein Entwickler arbeitet über Tage, Wochen oder sogar Monate bevor dieser Code in die Produktion überführt wird.  Personell: Entwickler schrieben den Code und Operations deployen diesen.  Umgebung/Tools: Entwickler verwenden in der Entwicklung komplett andere oder sogar inkompatible Umgebungen, als die, in der das fertige Produkt nachher genutzt wird. Beispiel für eine Dev/Prod- Diskrepanz: Die Entwicklung verwendet Jetty und SQLite auf OS X, während in der Produktion Glassfish und Oracle auf Linux genutzt werden. Dev-/Prod-Parität Jetty OS X SQLLite Glassfish Linux Oracle Entwicklung Produktion
  • 20.  Um die zeitliche Diskrepanz zu reduzieren, sollte Code innerhalb kurzer Zeit (optimaler weise innerhalb von Stunden) in die Produktion überführt werden können. Hierfür sind Microservices geeignet, da sie typischerweise eine kleine Codebasis besitzen und damit schnell entwickelt und getestet werden können.  Zur Reduktion negativer Konsequenzen durch personelle Diskrepanzen sollten Entwickler und Operations-Verantwortliche das Deployment gemeinsam durchführen, so dass die Entwickler das Verhalten Ihrer Anwendung in der Produktivumgebung direkt miterleben.  Um Diskrepanzen in der Umgebung (Tools) zu reduzieren, sollten Entwicklungs- und Produktivumgebung möglichst ähnlich sein; etwa indem die Entwickler auf einer virtuellen Maschine mit allen Komponenten aus der Produktionsumgebung entwickeln. Dev-/Prod-Parität
  • 21. Gerade bei Backend Diensten, wie Datenbanken, Messaging Systemen oder Caching-Komponenten, ist besonderes Augenmerk auf die Dev-/Prod-Parität zu legen.  Entwickler bevorzugen bei diesen Systemen oft leichtgewichtige Anwendungen, da sie sich dann mehr auf ihren Code konzentrieren können.  In der Produktionsumgebung werden aber evtl. komplexere Systeme eingesetzt, zum Beispiel könnte ein Entwickler auf seinem lokalen System eine MySQL Datenbank nutzen, in der Produktion setzt man aber evtl. auf Oracle.  Folgt man den vorliegenden Guidelines (siehe auch Backend Dienste) werden Backend Komponenten über einheitliche Interfaces angesprochen und eine gewisse Diskrepanz ist zu verschmerzen.  Trotzdem sollte auch in diesem Fall auf möglichst große Nähe zwischen Entwicklung, Staging und Produktion geachtet werden, um Seiten- oder Skalierungseffekte frühzeitig zu erkennen. Selbst kleine Unterschiede, etwa im Locking-Mechanismus oder in der Caching-Engine, können sich schnell zu großen Problemfeldern entwickeln. Dev-/Prod-Parität – Backend Services
  • 22. Logs als Event-Stream betrachten  Logs zeigen das Laufzeitverhalten einer Anwendung auf, indem sie zeitlich geordnet die Events im Gesamtsystem wiederspiegeln.  Traditionell wurden Logs von den Anwendungen generiert und dann in eine Datei (Logfile) geschrieben.  In einer monolithischen Anwendung, bei der alles in einem System geschieht, ist dieser Ansatz nützlich.  In einem verteilten System, mit vielen kleinen Diensten, führt dies im Fehlerfall zu hohen Aufwänden und erschwert die Ursachenforschung.  Eine verteilte Anwendung innerhalb einer Microservices-Architektur sollte Logs nicht selbst in eine Datei, sondern unbuffered in den Standardkanal stdout schreiben.  In der Entwicklungsumgebung kann der Programmierer diesen Kanal direkt überwachen, in Staging und Produktion wird stdout von einer Event-Stream Komponente aufgenommen weiter verarbeitet. Logs
  • 23.  Jeder Service schreibt seine Logs mit Informationen zu seinem eigenen Prozess und der Umgebung nach stdout.  Der Log-Event-Stream aus stdout wird, evtl. zusammen mit anderen Log-Events auf dem gleichen System, von einem Event-Stream Processor aufgenommen und an ein zentrales System zum Monitoring und Archivieren überführt.  Mögliche Komponenten hierfür sind Logplex oder Fluent.  Über diese können die Logs an weitere Systeme, etwa Splunk zur Echtzeitanalyse, weitergeleitet werden und ermöglichen somit nicht nur einen Blick auf den lokalen Anwendungszustand, sondern die Analyse des Gesamtsystems. Beispiel für ein Log-Event Stream System Log-Event Stream System
  • 24. Die Administration einer Anwendung sollte nicht zwischen Routine- und speziellen Einzelaufgaben unterscheiden.  Tägliche administrative Aufgaben zum Betrieb einer App, etwa die Überprüfung von Logs oder das Leeren/Synchronisieren eines Caches, fallen üblicherweise im Rahmen der Produktivumgebung an und werden zumeist durch, zur Anwendung gehörenden, Tools unterstützt.  Daneben gibt es spezielle Aufgaben, wie die Migration von Daten (etwa in einer Datenbank), welche Entwickler häufig in der Dev- oder Staging-Umgebung proben und die sie häufig als Sonderfall mit einer speziellen Umgebung ansehen.  Um die Komplexität dieser Aufgaben für alle Beteiligten (seien es nun Entwickler oder Administratoren) zu minimieren, sollten diese One-Off Tasks genauso als Teil der Administrationsumgebung einer Anwendung behandelt werden, wie Tools für Routineaufgaben. Administration und One-off Tasks
  • 25. One-off Tasks sind üblicherweise kein Tagesgeschäft, weshalb einige Besonderheiten zu beachten und teilweise auch spezielle Verfahren notwendig sind.  Ein One-off Task ist in einer, zur Zielumgebung, identischen Plattform durchzuführen.  Jeder One-off Task stellt einen speziellen Release (etwa einen Migrationsrelease) mit spezifischer Konfiguration und Zielplattform dar.  Für den Task notendige Tools müssen in das Dependency-Manifest (siehe Abhängigkeiten) des Releases mit aufgenommen werden.  Quell- und Zielsystem, also der Zustand der Systemumgebung mit Daten, Code und Konfiguration, sollte vor und nach der Durchführung eingefroren oder gesichert werden. Administration und One-off Tasks
  • 26. Christian Günther Principal Solution Architect Mobile: +49 1511 22 40 942 E-Mail: christian.guenther@comlineag.de COMLINE Computer und Softwarelösungen AG Leverkusenstr. 54 DE - 22761 Hamburg www.comlineag.de Vielen Dank für Ihre Aufmerksamkeit.