COMLINE Cloud Services
Guidelines zur Software-Entwicklung auf der CSP
Christian Günther
Hannover, 09.12.2016
Die COMLINE ...
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. Lauf...
 CQRS Command Query Responsibility
Segregation
 Trennung der Verantwortung von Software-
Komponenten, je nachdem, ob sie...
Codebasis
Eine Codebasis mehrere Deploys
 Jeder Service wird in einem Versions-Control
System verwaltet.
 Eine Codebasis...
Abhängigkeiten
Dependencies werden während
des Builds aufgelöst und in das
Deployment Package injiziert.
Explizites deklar...
Strikte Trennung von Code und Konfiguration
 Das Laufzeitverhalten eines Service, zum Beispiel hinsichtlich anzubindender...
 Speziell für Variablen oder Konstanten welche das Laufzeitverhalten einer
Anwendung beeinflussen gilt die folgende Regel...
Build, release, run
Das Ergebnis eines Build-Prozesses
wird mit einer Konfiguration zu einer
lauffähigen Instanz verbunden...
Alle Backend Dienste als angeschlossene Ressourcen behandeln
 Ein Backend-Service ist jede Art von Dienst, den ein Servic...
Services sind stateless und haben keine gemeinsam genutzten Ressourcen
 Ein Service kann auf einer Laufzeitumgebung mehrm...
Ein Service ist in sich vollständig abgeschlossen und alleine lauffähig
 Services sind so zu konfigurieren, dass sie alle...
Ein Service exponiert seine Funktionalität immer über eine API basierend auf
einem offenen Protokoll und Schnittstelle
 A...
Eine App exponiert ihren Funktionalität über exakt einen Port
 Soll die Funktionalität einer App von außen erreichbar sei...
Concurrency & Skalierung
Skalierung und gleichzeitige
Ausführung über ein Servicemodell
Skalierung durch Service Modell
 ...
Minimale Startup und Shutdown-Zeiten sorgen für Elastizität und Agilität
 Services und Anwendungen müssen in kürzester Ze...
Verfügbarkeit und Skalierung durch verteilte
Systeme erreichen
 Früher wurde Verfügbarkeit vor allem durch
Redundanzen, a...
Cloud-Service Anwendungen müssen bei Bedarf auf vielen Computingplattformen
gleichzeitig gestartet werden können, ohne sic...
Die Development, Staging und
Produktionsumgebungen sollten so ähnlich wie
möglich sein und die Entwicklungs- und
Operation...
 Um die zeitliche Diskrepanz zu reduzieren, sollte Code innerhalb kurzer Zeit
(optimaler weise innerhalb von Stunden) in ...
Gerade bei Backend Diensten, wie Datenbanken, Messaging Systemen oder
Caching-Komponenten, ist besonderes Augenmerk auf di...
Logs als Event-Stream betrachten
 Logs zeigen das Laufzeitverhalten einer Anwendung auf, indem sie zeitlich geordnet
die ...
 Jeder Service schreibt seine Logs mit
Informationen zu seinem eigenen Prozess und
der Umgebung nach stdout.
 Der Log-Ev...
Die Administration einer Anwendung sollte nicht zwischen Routine- und speziellen
Einzelaufgaben unterscheiden.
 Tägliche ...
One-off Tasks sind üblicherweise kein Tagesgeschäft, weshalb einige
Besonderheiten zu beachten und teilweise auch speziell...
Christian Günther
Principal Solution Architect
Mobile: +49 1511 22 40 942
E-Mail: christian.guenther@comlineag.de
COMLINE ...
Nächste SlideShare
Wird geladen in …5
×

06 Software Development Guidelines der COMLINE Cloud Service Platform - CSP

121 Aufrufe

Veröffentlicht am

Software Entwicklung Guidelines für Cloud Anwendungen

Domain Principles für Cloud Services und Cloud Anwendungsentwicklung

In den letzten zehn bis fünfzehn Jahren haben sich eine Reihe von Architekturparadigmen etabliert, die heute die Grundlage für Unternehmensanwendungen definieren und in vielfältigen Standards, Frameworks und Best Practices so fest verankert sind, dass man kaum noch darüber nachdenkt.

Wendet man diese Paradigmen unreflektiert auf Cloud-Anwendungen an, führt das in der Regel zu ernüchternden Resultaten. Insbesondere die für Cloud Computing wichtigen Eigenschaften Skalierbarkeit, Elastizität und Robustheit sind auf diese Weise nicht erreichbar.

Ein Umdenken ist also notwendig, um die Potenziale der Cloud freizusetzen.

Die COMLINE Cloud Computing Platform (CSP) ist die Antwort hierauf, sie ist eine moderne Plattform für Cloud-Computing und wurde als reaktives System konzipiert.

Reaktive Systeme müssen stets antwortbereit, widerstandsfähig, elastisch und nachrichtenorientiert sein. Systeme und Plattformen, die nach diesen Anforderungen entwickelt werden, erweisen sich als anpassungsfähiger, mit weniger starr gekoppelten Komponenten und in jeder Hinsicht skalierbarer. Sie sind einfacher weiterzuentwickeln und zu verändern. Sie reagieren zuverlässiger und eleganter auf Fehler und vermeiden so desaströse Ausfälle. Reaktive Systeme bereiten dem Anwender durch ihre fortwährende Antwortfreudigkeit eine interaktive und höchst befriedigende Erfahrung.

All diese Anforderungen erfüllt die COMLINE Cloud Service Plattform.

Aus Sicht der COMLINE eine PaaS (Platform as a Service) dar, auf der COMLINE Cloud-Dienste entwickelt.
Betrieben wird die CSP auf einem IaaS Modell in COMLINE-eigenen Rechenzentren in Berlin
Die Cloud-Dienste werden zu Anwendungen zusammengefasst, die von Kunden der COMLINE im Sinne eines SaaS (Software as a Service) Modells gemietet und genutzt werden können.

Sowohl die Plattform selber, als auch die Services und Anwendungen werden entlang einer Reihe von Guidelines entwickelt und betrieben. Diese Guidelines bilden die Grundlage aller Aktivitäten (von Design, über Konzeption bis hin zu Entwicklung und Betrieb) auf der CSP

Die Folien auf Slideshare zeigen die Prinzipien, Paradigmen und Design Patterns auf, nach denen wir sowohl die CSP selber betreiben, als auch die Anwendungen auf ihr entwickeln und betreiben.

Die CSP wurde massgeblich von Christian Günther konzipiert und stellt heute die DeFacto Entwicklungsplattform für COMLINE dar.

Veröffentlicht in: Software
1 Kommentar
0 Gefällt mir
Statistik
Notizen
  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
121
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
0
Aktionen
Geteilt
0
Downloads
0
Kommentare
1
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

06 Software Development Guidelines der COMLINE Cloud Service Platform - CSP

  1. 1. COMLINE Cloud Services Guidelines zur Software-Entwicklung auf der CSP Christian Günther Hannover, 09.12.2016 Die COMLINE AG präsentiert
  2. 2. Entwicklungs-Guidelines der Open Platform
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

×