Einleitung und Übersicht zur COMLINE Cloud Service Plattform 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.

1. COMLINE Cloud Services
Einleitung
Christian Günther
Hannover, 09.12.2016
Die COMLINE AG präsentiert

2. COMLINE CSP – Einleitung

4.  On-demand self-service
Nutzer bestellen gewünschte Dienste über einen Self-Service
(aka Shop), wobei die Bereitstellung vollständig automatisiert
(also ohne manuelle Tätigkeit) geschieht.
 Broad network access
Der Zugang zu den angebotenen Diensten wird über ein
Netzwerk (meist das Internet) realisiert und setzt (in aller Regel)
einen breitbandigen Anschluss voraus.
 Resource pooling
Infrastruktur-Komponenten werden in Ressourcen-Pools
zusammengefasst und als Einheit betrachtet.
 Rapid elasticity
Steigenden Anforderungen an die Dienste (etwa Zugriffszahlen
oder Datenvolumen) kann mittels einer elastischen Infrastruktur
extrem schnell und möglichst automatisiert begegnet werden.
 Measured service
Dienste liefern Daten zur Nutzung an eine Management-Einheit
und lassen sich hinsichtlich Kosten (üblicherweise definiert über
ihre Leistung) in Klassen einteilen.
Kerndefinition (nach NIST) für Cloud-Dienste

5. 3 Arten von Diensten in der Cloud

6.  Die COMLINE Cloud Computing Platform (CSP)
ist eine Umgebung zur Entwicklung und Betrieb
von Cloud Diensten.
 Die CSP stellt 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.
Die COMLINE CSP, best of all
Worlds
Die COMLINE CSP

7. Key Technical Figures der CSP
Virtualization Layer and Cloud Service Automation
Configuration
and Service
Discovery
UI Runtime / User-Mgmt / SSO
Services Registry
Container Mgmt
Service Control
Open Platform
Any App
Ubuntu LTS-Cluster
Runs in Docker Container
CSP Open Platform = Micro services Architecture / Design + Runtime-Platform
Consumer
Camunda
BPM Service
Generic AKKA
Services
Node.js
Services
Developer
DevOps
A reactive, fully scalable and partition tolerant platform offers highest availability and performance
Designed with the most innovative technologies and framework for cloud computing and analytics
Able to support agile Software Development concepts to quickly and reliable fulfill customer requirements
Standardized Software Development methodology based on DevOps and Continuous Integration
Analytics / ML
Services
Operations
Jenkins CI

8. Grundlagen und Konzepte der COMLINE CSP

9.  Die COMLINE CSP ist als reaktives System konzipiert.
 Sowohl die Plattform selber, als auch die Services und Anwendungen
werden entlang einer Reihe von Guidelines entwickelt und betrieben.
 Die folgenden Slides geben eine Übersicht über
– Reactive Systems
– Domain Principles
– Computing Concepts
– Infrastructure Design Patterns
– Architecture Design Patterns
– Software Development Guidelines
 Sie bilden die Grundlage aller Aktivitäten (von Design, über Konzeption bis
hin zu Entwicklung und Betrieb) auf der CSP
Die COMLINE Cloud Services Platform

10. 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.
Cloud Services – Umdenken im Kopf

11. Reactive Systems

12. The Reactive Manifesto
Die Lösung – reaktive Systeme

13.  Eine moderne Plattform für Cloud-Computing muss als reaktives System
konzipiert sein. Diese 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.
Was sind reaktive Systeme?

14. Das System antwortet unter allen Umständen
zeitgerecht, solange dies überhaupt möglich ist.
Antwortbereitschaft ist die Grundlage für Funktion
und Benutzbarkeit eines Systems, aber noch
wichtiger ist, dass Fehler in verteilten
Systemen nur durch die Abwesenheit einer
Antwort sicher festgestellt werden können.
Ohne vereinbarte Antwortzeit-grenzen ist die
Erkennung und Behandlung von Fehlern nicht
möglich. Eine weitere Facette ist, dass konsistente
Antwortzeiten als Zeichen von Qualität Vertrauen
stiften und so weitere Interaktion fördern.
Antwortbereit – Responsive

15. Das System bleibt selbst bei Ausfällen von Hard-
oder Soft-ware antwortbereit. Jedes System,
welches nicht widerstandsfähig ist, verliert durch
einen Ausfall seine Antwortbereitschaft und damit
seine Funktion. Widerstandsfähigkeit ist
nur erreichbar durch Replizieren der
Funktionalität, Eindämmung von Fehlern,
Isolation von Komponenten sowie Delegation von
Verantwortung. So bleibt der Ausfall eines
Teilsystems auf dieses begrenzt, andere
Teilsysteme sind geschützt und in ihrer Funktion
nicht behindert.
Die Wiederherstellung des Normalzustandes wird
einer übergeordneten Komponente übertragen, die
durch die gesteuerte Replizierung der ihr
untergeordneten Komponenten die geforderte
Verfügbarkeit sicherstellt. All dies bedeutet, dass
Nutzer eines auf diese Weise widerstands-fähigen
Systems von der Last befreit sind, sich mit dessen
Ausfällen auseinandersetzen zu müssen.
Widerstandsfähig – Resilient

16. Das System bleibt auch unter sich ändernden
Lastbedingungen antwortbereit. Auch hier bildet die
Verteilung und Replizierung von Funktionalität die
Grundlage, auf der das System auf Veränderungen
reagiert. Bei Verminderung oder
Erhöhung der Last werden automatisch die
Replizierungsfaktoren und damit die
genutzten Ressourcen angepasst. Um dies zu
ermöglichen, darf das System keine Engpässe
aufweisen, die den Gesamtdurchsatz vor Erreichen
der geplanten Maximalauslegung einschränken.
Ideal ist eine Architektur, die keine fixen Engpässe
aufweist. In diesem Fall kann das bearbeitete
Aufgabengebiet in unabhängige Teile zerlegt und
auf beliebig viele Ressourcen verteilt werden.
Reaktive Systeme unterstützen die Erfassung ihrer
Auslastung zur Laufzeit, um automatisch regelnd
eingreifen zu können. Dank ihrer Elastizität können
sie auf Speziallösungen verzichten und mit
handels-üblichen Komponenten implementiert
werden.
Elastisch – Elastic

17. Das System verwendet asynchrone
Nachrichtenübermittlung zwischen seinen
Komponenten zur Sicherstellung von deren
Entkopplung und Isolation sowie zwecks Übermittlung
von Fehlern an übergeordnete Komponenten.
Die explizite Verwendungen von
Nachrichtenübermittlung führt zu einer
ortsunabhängigen Formulierung des Programms und
erlaubt die transparente Skalierung von Komponenten.
Die Überwachung von Nachrichtenpuffern ermöglicht
kontinuierlichen Einblick in das Laufzeitverhalten des
Systems (sowohl zur Diagnose als auch zur
automatischen Ressourcensteuerung) sowie
Priorisierung und Kontrolle der Nachrichtenflüsse.
Ortsunabhängigkeit bedeutet, dass Code und
Semantik des Programms nicht davon abhängen, ob
dessen Teile auf demselben Computer oder verteilt
über ein Netzwerk ausgeführt werden. Nicht-
blockierende nachrichtenorientierte Systeme erlauben
eine effiziente Verwendung von Ressourcen, da
Komponenten beim Ausbleiben von Nachrichten
vollständig inaktiv bleiben können.
Nachrichtenbasiert – Message Driven

18. Grundlagen, Konzepte und Guidelines

19. 1. Business Value durch maßvolle,
kontinuierliche Verbesserung
2. Erwartung nach unendlicher Kapazität
3. 100%ige Service-Verfügbarkeit
4. Agieren wie ein Public Cloud-Service
Provider
5. Optimierte Ressourcen-Nutzung
6. Verfügbarkeit als ganzheitlicher Ansatz
7. Minimieren personeller Unterstützung
8. Vorhersagbarkeit
9. Gewünschtes Verhalten belohnen
10. Einheitliche User-Experience
Prinzipien für die Anwendungs-
domäne Cloud-Services
Domain Principles
Weiterführende Informationen zu den Domain Principles finden sich in
01_Domain_Principles...

20. 1. Elastizität statt Redundanz
2. Elastische Infrastruktur
3. Homogenität der physischen Plattform
4. Ressourcen-Pools
5. Virtualisierte Infrastruktur
6. Fabric Management
7. Partitionierung der Shared Ressourcen
8. Ressource Decay
9. Service Klassifizierung
10.Sicherheit und Identitäts-Management
11.Multitenancy
Computing Concepts
Weiterführende Informationen zu den Computing Concepts finden sich in
02_Computing_Concepts...

21. Die Infrastruktur unter der Cloud Service
Plattform wird entlang der folgenden
Entwurfsmuster konzipiert:
1. Ressource Pooling
2. Physikalische Fault Domain
3. Upgrade Domain
4. Reserve Capacity
5. Skalierende Einheiten (Units)
6. Kapazitätsplanung
7. Health Model
Entwurfsmuster sind bewährte
Lösungsschablonen für
wiederkehrende Entwurfsprobleme.
Infrastructure Design Patterns
Weiterführende Informationen zu den Infrastructure Design Patterns finden sich in
02_Computing_Concepts...

22. Die Anwendungen auf einer Cloud Service
Plattform werden entlang der folgenden
Entwurfsmuster konzipiert:
1. Domain Driven Design
2. Microservices Architektur
3. Hexagonale Architektur
4. Peer-to-Peer Architektur
5. Nachrichtenbasiertes SystemEntwurfsmuster sind bewährte
Lösungsschablonen für
wiederkehrende Entwurfsprobleme.
Software Architecture Design Patterns
Weiterführende Informationen zu den Design Patterns finden sich in
03_SW-Architecture_Design_Patterns...

23. 1. Codebasis
2. Abhängigkeiten
3. Konfiguration
4. Build, Release, Run
5. Backend-Dienste
6. Prozesse
7. Laufzeitcontainer
8. Interfacing
9. Port Binding
10. Concurrency & Skalierung
11. Elastizität & Verfügbarkeit
12. Dev-/Prod-Parität
13. Logs
14. Administration und One-off Tasks
Software-Development Guidelines
Entwicklungs-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.
Weiterführende Informationen zu den Design Patterns finden sich in
04_SW-Development_Guidelines...

24. Komponentenmodell der CSP
Weiterführende Informationen zum Komponenten-Modell finden sich in
11_Komponenten_und_OS-Plattform...
BI 4 Server
Open Platform ANALYTICS-Plattform
Cloud Service
Automation
MS SQL
Instanz
SAP HANA-Instanz
Analytics
UI Runtime / OpenID Logon / SSO
Cloud
Automation
CLOUD-Service Plattform
Camunda
BPM
Service
Swarm / Registrator / Consult
Docker
Container
Docker
Container
Docker
Container
Windows
Server
Nginx
AKKA
Services
Node.js
Services
.Net /
SharePoint
Ubuntu LTS
Neo4J
Graph DB
Cassandra
-
ClusterMySQL
Instanz
Konfiguration und
Service Discovery
Any App

25. COMLINE Cloud Service Automation
Service-Automation
Portal
Benutzerschnittstelle
 Benutzer kann mit minimalen
Informationen im Service Portal
den Dienst beauftragen
 Die Anforderung wird im Rahmen
von 7x24 Stunden sofort
umgesetzt
Service-Automation
Engine
Durchführung
 Neue Benutzer anlegen
 Drucker einrichten, ändern
 Berechtigungen für Dateisysteme
einrichten
 Smartphone bestellen, einrichten
 Endgeräte wie Laptop bestellen
und einrichten
Umgesetzte Prozesse
Ergebnis
 Neuer Mitarbeiter kann sich an
dem bereitgestellten Notebook
anmelden, Drucken, E-Mails
versenden und mit dem
SmartPhone telefonieren. Er ist
sofort arbeitsfähig.
komplexe Prozesse vereinfachen
Weiterführende Informationen zur Infrastruktur finden sich in
12_Cloud_Service_Automation...

26. Dev/Ops
Weiterführende Informationen zum Dev/Ops-Ansatz finden sich in
08_DevOps...

27. Software Delivery
Weiterführende Informationen zur Software Delivery finden sich in
09_Software_Delivery...

28. 1. Hardware Layer
2. Virtualization Layer
3. Automation Layer
4. Management Layer
5. Orchestration Layer
6. PaaS and SaaS Layer
7. Tenant / Self-Services und Admin-UI
Plattform Infrastruktur
Weiterführende Informationen zur Plattform-Infrastruktur finden sich in
13_Plattform_Infrastruktur...
Storage Network Compute Facility
Hardware Layer
Virtualization Layer
Automation Layer
Management Layer
Orchestration Layer
PaaS Workloads
SaaS Workloads
Tenant Self-Service / Admin Interfaces

29. Software Architektur
Weiterführende Informationen zur Software-Architektur finden sich in
14_SW-Architektur-Overview..., 15_SW-Architektur_Process-and-Workflow... Und
16_SW-Architektur_BigData-Analytics
Node.js
Cluster
Job Manager
Cluster Manager
View Service
BI 4 Server
Application
Service
PROCESS-Plattform ANALYTICS-Plattform
HANA
Connector
Cloud Service
Automation
Cassandra-
Cluster
MSSQLI
nstanz
Service-
Execution &
Workflows
SAP HANA-Instanz
Analytics
MySQL
Instanz
Portal Runtime
Cloud
Automation
CLOUD-Service Plattform
BPM Service
KAFKA
Messaging IO
SPARK
Analytics
SPARK
Cluster-
Manager
Job-Manager
SPARK
Streaming
Consumer
SPARK Driver
SPARK
ML
InStream Analytics
InStream
Analytics &
Machine
Learning
Neo4J
Graph DB

30. 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.