COMLINE Cloud ServicesGuidelines zur Software-Entwicklung auf der CSP

Christian GüntherHannover, 09.12.2016

Die COMLINE AG präsentiert

Entwicklungs-Guidelines der Open Platform

1. Obey CQRS2. Codebasis3. Abhängigkeiten4. Konfiguration5. Build, Release, Run6. Backend-Dienste7. Prozesse8. Laufzeitcontainer9. Interfacing10. Port Binding11. Concurrency & Skalierung12. Elastizität & Verfügbarkeit13. Dev-/Prod-Parität14. Logs15. 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 abgebildetSiehe 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-Interaktion2. 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üntherPrincipal Solution Architect

Mobile: +49 1511 22 40 942E-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.