Download(PDF 213 kb)

Reaching the Cloud
Moderne Integrationsinfrastrukturen für die Cloud
NTT DATA
Inhalt
Management Summary
4
Reaching the Cloud
6
Vorgehen bei der Cloud-Migration
6
Cloud-Service-Modelle
7
Schlüsseltechnologien von klassischen Integrationsinfrastrukturen
Der Enterprise Service Bus als Fundament der Integrationsinfrastruktur
Automatisierte Steuerung von Geschäftsprozessen
Case Management (CM)
9
10
11
12
Microservices13
Fazit15
2
NTT DATA
3
Management Summary
Die Themen, die das Management von Unternehmen aktuell beschäftigen, sind die
digitale Transformation mit ihren vielfältigen Auswirkungen auf die Geschäftsfelder und
die IT-Landschaft sowie die Notwendigkeit, Teile der Funktionalitäten und Daten in die
Cloud auszulagern, um bei planbaren Kosten flexibel auf Veränderungen im Geschäftsfeld
reagieren zu können.
Die daraus resultierenden Cloud-Computing-Modelle müssen so flexibel sein, dass sie
einfach und bedarfsgerecht bei festen Kosten skaliert und nach Verbrauch abgerechnet
werden können. Aus Sicht der IT-Manager sind diese Modelle im Idealfall dynamisch am
zu erwartenden Lastverhalten ausgerichtet. Dabei soll sich die Skalierung zum Beispiel
an mehrfach täglich gestarteten Verkaufsaktionen ausrichten können, was zur Folge hat,
dass auch die IT-Funktionalität von monolithischen Anwendungen in separat einsetzbare
Features aufgebrochen werden müssen. Hierzu sind sowohl neue Architekturen in
Form von Microservices und Container-based Virtualization, als auch organisatorische
Änderungen erforderlich.
Bei den organisatorischen Änderungen geht es Cloud-Computing-Modelle:
um die Verlagerung von Verantwortlichkeiten. • Einfache und bedarfsgerechte
Die Verantwortung für die Anforderungen, EntSkalierung
wicklung, Qualitätssicherung und der Betrieb • Feste Kosten pro Einheit
der entsprechenden Features der fachlichen • Abrechnung nach Verbrauch
Anwendung liegt bei den DevOps. Der Infrastrukturbetrieb inklusive der Betrieb der container-based virtualization ist separat geregelt und kann ausgelagert werden. Die Kommunikation zwischen diesen Einheiten erfolgt nicht über einen langwierigen Ticket-Prozess,
sondern über standardisierte Schnittstellen.
Durch die Zerschlagung der monolithischen Applikation in Features kann man auch
von wenigen starren Release-Zyklen im Jahr hin zur Continuous Delivery kommen. Erst
dadurch kann man den Wunsch der Fachbereiche, neue Funktionalität schnell produktiv
zu setzen, verwirklichen.
Sowohl die digitale Transformation, mit der Integration von immer mehr unterschiedlichen
Informationsquellen und Endgeräten sowie Prozesspartnern, als auch die Auslagerung
von Teilen der Geschäftsprozesse in die Cloud, bedürfen einer passenden Serviceorientierten Integrationsarchitektur.
In diesem White Paper werden die prinzipielle Vorgehensweise für eine erfolgreiche
Cloud-Integration beschrieben sowie die aktuellen Integrationsarchitekturen erläutert.
Die Erfahrungen, die wir im Laufe vieler Jahre mit Integrationslösungen von großen
Produktherstellern und von Open-Source-Lösungen, sowie bei der Integration von
Standardprodukten aus dem CRM-Bereichen gesammelt haben, sind in eine Extension
Platform Architecture (EPA) geflossen. Mit OLIA steht eine auf Open Source Software
basierende „integrated Platform-as-a-Service“ (iPaaS)-Lösung zur Verfügung.
Aktuelle Trends wie „Digital Transformation“ mit ihrer industrieübergreifenden
Wertschöpfungskette und „Cloud-Computing“ werfen ein neues Licht auf das Thema
Integrationsarchitekturen.
4
1.Digitale Transformation
Digital transformierte Unternehmen erreichen nachhaltige Wettbewerbsvorteile durch
Agilität, Elastizität und Reaktionsfähigkeit. Sie haben eine definierte und etablierte
Unternehmensarchitektur, die ihnen den Bau effizienter und zuverlässiger BackendSysteme ermöglicht. Ihre Wertschöpfungskette koppelt die eigenen Fähigkeiten lose mit
denen verschiedener Partner – die Lieferung erfolgt über verschiedene Leistungserbringer
hinweg.
Die Erweiterung der Wertschöpfungskette auf Partner-Dienstleistungen sowie der
zunehmende Einsatz mobiler Endgeräte erfordert die nahtlose Einbindung verschiedener
Transaktionen in einen größeren Kontext. Kalenderdienste, Plattformen für „social rating“,
GPS und Restaurant-Reservierungen sind Beispiele für Dienste, deren Zusammenspiel
vom Nutzer erwartet wird.
2.Cloud-Computing
Cloud-Computing verspricht durch seine standardisierten und weitgehend automatisierten
Prozesse eine außergewöhnliche Kostenersparnis in Betrieb und Wartung der
Anwendungen. Die wachsende Anzahl mobiler Endgeräte sorgt dafür, dass der Zugriff
auf Unternehmensressourcen extrem skalierbar sein muss.
Im Bereich B2C muss sichergestellt werden, dass Lastspitzen, wie sie z.B. bei
Rabattaktionen auftreten können, ohne Ressourcenengpässe zur Zufriedenheit der
Endanwender abgefangen werden können. Allerdings soll den Rest des Jahres nicht 80%
der IT-Infrastruktur brach liegen.
Um den Anforderungen der Kunden hinsichtlich der Flexibilisierung ihrer IT-Systeme zu
genügen, gibt es unterschiedliche Ausprägungen von Cloud-Computing. Die Schlagworte
hierbei sind „Infrastructure as a Service“ (IaaS), „Platform as a Service“ (PaaS) und
„Software as a Service” (SaaS).
Der Mehrwert von Integrationsinfrastruktur wird in Anbetracht der anhaltenden
Transformation von Unternehmens-IT hin zu ‚PaaS‘ und ‚SaaS‘ nicht mehr vorrangig
über Kosteneffizienz erbracht – die Cloud ist der neue Weg, Kosteneffizienz zu erreichen.
Für die Transformation in die Cloud sowie für die Integration in Legacy-Systeme ist
Integrationsarchitektur im eigenen Haus jedoch nach wie vor unverzichtbar. Zusätzlich
spielt sie innerhalb der Cloud eine Rolle – das Stichwort hierzu heißt „iPaaS“ (integrated
Platform-as-a-Service).
3.Industrieübergreifende Wertschöpfungskette
Die digitale Transformation wurde eingeläutet durch die ständige Verfügbarkeit von internetbasierenden Diensten auf immer leistungsfähigeren Mobilgeräten wie Smartphones
und Tablets. Durch die weite Verbreitung dieser Geräte ergeben sich immer mehr
Möglichkeiten, den Kunden in die Geschäftsprozesse zu integrieren. Im Gegenzug dazu
wächst aber auch die Erwartungshaltung des Kunden, immer individueller und nahtloser
in die Geschäftsprozesse integriert zu werden. Das führt dazu, dass immer mehr Daten
und Informationen des Kunden vernetzt werden müssen, um dem Kunden mehr Komfort
zu bieten.
NTT DATA
5
Reaching the Cloud
Die Frage ist nicht, ob Unternehmen „in die Cloud gehen“, sondern wann. Daher ist
es Zeit, sich mit dem Vorgehen für die Wege in die Cloud, den unterschiedlichen
Service-Modellen und den aktuellen Integrationsarchitekturen zu beschäftigen.
Vorgehen bei der Cloud-Migration
Cloud-Service-Modelle
Der Begriff „Cloud Computing“ hat viele Facetten. Für eine genauere Betrachtung der
Angebote, die sich hinter dem Begriff „Cloud Computing“ verbergen, muss man sich die
unterschiedlichen Cloud-Service-Modelle ansehen.
Ausgangspunkt für die Migration in die Cloud ist die Frage, welche Daten und
Funktionalitäten in die Cloud ausgelagert werden sollen. Es reicht hierzu nicht allein der
Blick auf die aktuelle Systemlandschaft – zudem müssen die Fachbereiche befragt werden,
um die angebotenen Produkte und Dienstleistungen zukunftssicher im Hinblick auf die
Unternehmensstrategie auszuprägen.
Ausgehend von der Zukunftsvision des Unternehmens muss die dafür notwendige,
langfristig tragfähige Integrationsstrategie festgelegt werden. Wenn klar ist, welche Daten
und welche Dienstleistungen in eine Cloud-Lösung ausgelagert werden können, muss
geklärt werden, wie die notwendige Integration mit den Daten und Prozessen erfolgen
kann, die weiterhin in den eigenen Rechenzentren vorgehalten werden müssen.
Einflussfaktoren auf die
Cloud-Strategie
CRM
ERP
FiBU
On Premise
Wichtige Einflussfaktoren auf diese Strategie sind:
Datenschutz und Datensicherheit
SaaS
Verfügbarkeit und Antwortzeitverhalten (Latency) der Cloud-Lösung
Preismodell der Integrationslösung mit der Überlegung, auf eine produktbasierte
Integration zu setzen, oder auf eine Realisierung mit Open-Source-Komponenten
iPaaS
Die Flexibilität der Integrationslösung in Hinblick auf die Integration unterschiedlicher
Cloud-Service-Provider bis hin zur Flexibilität bezüglich event-gesteuerter Ressourcenund damit Kostenoptimierung
PaaS
Wichtig in diesem Zusammenhang ist, dass man
mit der gewählten Integrationsarchitektur einen
technologischen Durchstich im Rahmen eines
Proof of Concept (PoC) durchführt und dabei
prüft, ob die Lösung sowohl technologisch und
architektonisch, als auch längerfristig strategisch
den Unternehmensanforderungen standhalten
kann.
IaaS
CRM
DB
ERP
BI
Rechenkapazität
FiBU
API
IDE
Storage
Unsere Empfehlung:
• Proof of Concept für technologischen Durchstich
• Produktivsetzung verteilt
über mehrere Releases
Abb. 1: Die Cloud-Service-Modelle
Die Produktivsetzung sollte, wenn möglich, nicht in einem Big Bang erfolgen, sondern
verteilt über mehrere Releases. Mit den Erfahrungen, die man aus den ersten Releases
bezüglich der funktionalen und nicht funktionalen Anforderungen gewinnt, können die
Architektur- und Integrationsentscheidungen validiert und nötigenfalls optimiert oder gar
revidiert werden.
6
NTT DATA
7
Im Bereich Cloud-Services haben sich folgende Modelle herauskristallisiert:
Software-as-a-Service (SaaS) definiert Standardsoftwaresysteme, die in einer CloudUmgebung gehostet sind. Das können beispielsweise CRM- oder ERP-Systeme sein.
Einer der Keyplayer im Cloud-CRM-Bereich ist Salesforce.
Cloud-Service-Modelle
Integration-Platform-as-a-Service (iPaaS) bezeichnet Integrationsplattformen, die
als Service in einer Cloud zur Verfügung gestellt werden. Der Fokus liegt hier auf der
Bereitstellung von Orchestrierungslösungen in der Cloud. Aber auch die Integration von
weiteren Cloud-Services oder von lokalen Systemen in den Gesamtprozess wird damit
adressiert.
Mit Platform-as-a-Service (PaaS) sind Basisfunktionalitäten gemeint, die von
unterschiedlichen Anwendungen gleichartig genutzt werden. Beispiele hierfür
sind Datenbanken (DB) und Reporting (BI), aber auch Programmiermodelle (API)
und Entwicklungswerkzeuge (IDE) wie Microsoft Windows Azure oder force.com von
Salesforce fallen in diese Kategorie.
Infrastructure-as-a-Service (IaaS) ist die Bereitstellung von IT-Ressourcen in Form
Rechenleistung, Festplattenkapazität (Storage) und Netzwerkressourcen. Weitere
Funktionalitäten, die als IaaS angeboten werden, sind z.B. Identity Management,
Messaging und Caching. Das Zusammenstellen der IT-Infrastruktur aus den CloudRessourcen obliegt dem Kunden. Bekannte Service-Provider sind hier Amazon mit der
Service Elastic Compute Cloud (EC2) (http://aws.amazon.com/de/ec2/) und die Google
Cloud Platform (https://cloud.google.com/compute/) sowie die NTT Enterprise Cloud
(http://www.eu.ntt.com/en/services/cloud/enterprise-cloud.html).
Gemeinsam ist diesen Service-Modellen, dass sich die Cloud-Services nicht innerhalb der
Unternehmens-IT befinden, sondern von Cloud-Service-Providern in unterschiedlicher
Ausprägung zur Verfügung gestellt werden.
Schlüsseltechnologien von klassischen Integrationsinfrastrukturen
Viele Unternehmen suchen eine sanfte Migration in die Cloud. Daher stehen in diesem
White Paper die Architekturkomponenten der klassischen SOA (noch) am Beginn dieses
Kapitels. Aber neue Architekturpatterns machen in Form von Microservices (siehe Kap.
2.4) die Runde.
Eine aktuelle Integrationsinfrastruktur erreicht man klassischerweise durch eine auf
mehrere Schichten verteilte Komponentenhierarchie, wie sie exemplarisch in Abbildung 2
dargestellt ist.
Anwedungsund
Interaktions­schicht
Spezifische
Benutzeroberflächen für
unterschiedliche
Zielgruppen
Prozess
Schicht / BPM
Ablauffähige
Geschäftsprozesse
Service
Schicht / ESB
Lose Kopplung
durch wiederverwendbare
Services
SAP Service
ORACLE DB
Service
Backend
Systeme
Siebel Service
Host Service
Standardanwendungen und
Datenbanken
Abb. 2: Komponenten einer Integrationsinfrastruktur
Die Basiskomponenten dieser Integrationsinfrastruktur sind der Enterprise Service Bus
(ESB) und ein System zur Steuerung und Automatisierung von Business-Prozessen (BPM
Engine). Sollen in der Infrastruktur nur fachliche Services für unterschiedliche Anwendungen
und Eingangskanäle zur Verfügung gestellt werden, ist eine BPM Engine nicht notwendig.
Enterprise Service Bus
und BPM Engine als
Basis einer klassischen
Infrastruktur
Eine relativ neues BPM-Trendthema ist das Case Management (CM). Beim Case
Management geht es darum, einen Fall (engl. Case) zu bearbeiten. Da nicht jeder Fall exakt
dem gleichen Muster folgt, ist eine statische Modellierung der einzelnen Bearbeitungsschritte
nicht sinnvoll, oder gar unmöglich.
8
NTT DATA
9
Der Enterprise Service Bus als Fundament der Integrationsinfrastruktur
In der klassischen SOA ist der ESB das Fundament der Kommunikations­infrastruktur.
Er bietet die Basis für automatisierte Business-Prozesse und den Zugriff auf aktuelle
Unternehmensdaten aus unterschiedlichen Kontexten.
In der Microservice Community wird hier der alternative Ansatz „smart endpoints and
dumb pipes“ verfolgt (http://martinfowler.com/articles/microservices.html). Im Gegensatz
zu einem ESB mit seinen ausgeklügelten Mechanismen zum Message Routing, zur
Transformation und Nachrichtenanreicherung sind die „dumb pipes“ nur für die sichere
Datenübertragung zuständig. Die Intelligenz liegt in den Endpunkten, d.h. in den
Microservices selbst.
Die wichtigsten Funktionalitätsbereiche des ESBs sind:
Bereitstellung einer auf Standards basierenden Kommunikationsplattform für ServiceAnbieter und Service-Nutzer
Bereitstellung von Adaptoren zur nahtlosen Integration unterschiedlicher Ressourcen
und Systeme über unterschiedliche Technologien hinweg
Transformation und Anreicherung (enrichment) von Daten beim Datenaustausch
zwischen Service-Anbieter und Service-Nutzer
V
on Nachrichteninhalten abhängige Weiterleitung von Daten (content based routing).
Ein Enterprise Service Bus stellt in erster Linie eine Plattform zum Datenaustausch
zwischen einem Service-Anbieter und Service-Nutzer zur Verfügung. Der Service-Nutzer
muss hierbei den Service-Anbieter nicht direkt adressieren. Die Systeme sind also mit
Hilfe des ESB nur lose gekoppelt. Diese lose Kopplung ist für die weitere IT-Strategie ein
wichtiger Aspekt. Hierdurch wird der Austausch des Service-Anbieters ermöglicht, ohne
die Service-Nutzer anzupassen.
Setzt man den ESB als eine eigenständige, Unsere Empfehlung:
zentrale Komponente für den Service-Aufruf Den ESB auch zur betriebaus
unterschiedlichen
Anwendungen
und lichen Überwachung, zum
Eingangskanälen ein, wie das in der SOA Policy-Enforcement und als
Architektur Community seit Jahren propagiert wird, Datenlieferant für SLAs zu
dann können hier auch die für den Betrieb und die nutzen.
Überwachung des Systems notwendigen Daten
für das Monitoring des Systems zentral ermittelt
werden. Aus den hier ermittelten Daten lassen sich aggregierte Zahlen ermitteln, um die
Einhaltung von SLAs zu überwachen. Weitere zentrale Dienste wie das Policy Management
können ebenfalls am ESB ansetzen.
Ein zentraler Enterprise
Service Bus birgt auch
Risiken
Einen unternehmensweiten, zentralen ESB einzusetzen birgt auch Risiken, die dazu
führen können, dass sich die erhofften Optimierungspotenziale nicht ergeben, oder dass
Änderungen erschwert oder gar verhindert werden. Wird ein ESB, sei es als Produkt, oder
in Form von Integration Patterns eingesetzt, dann sollte das vor allem geschehen, um die
Komplexität unterschiedlicher Integrationstechnologien zu kapseln und den Anwendungen
eine einheitliche, auf Standards basierende fachliche Schnittstelle zur Verfügung zu stellen.
Wenn es um die Cloud-Integration geht, gibt es zusätzliche technologiespezifische
Herausforderungen an die Integration von Daten und Funktionalität in der Cloud und den
lokalen „On Premise“-IT-Systemen. Das sind insbesondere das Antwortzeitverhalten, die
Verfügbarkeit sowie die Skalierbarkeit.
10
Automatisierte Steuerung von Geschäftsprozessen
Viele Studien belegen das ungenutzte Potenzial bei der Service-Orchestrierung und der
Automatisierung von Geschäftsprozessen. In den SOA-Reifegradmodellen (SOA Maturity
Models, zum Beispiel in http://soablueprint.com/maturity_models) steht die automatisierte
Steuerung von Geschäftsprozessen an oberster Stelle. Das bedeutet, dass erst durch
automatisierte Geschäftsprozesse der Nutzen einer Service-orientierten Architektur voll
ausgeschöpft wird und damit das Unternehmen einen hohen SOA-Reifegrad erreicht.
Automatisierte Geschäftsprozesse leisten ihren Beitrag zu effizienteren Unternehmen in
vielfacher Weise:
Nutzen automatisierter
Geschäftsprozesse
Geschäftsregeln und Prozesse werden direkt in ausführbare Software abgebildet.
Dadurch ist sichergestellt, dass alle Fälle gleichartig in optimaler Geschwindigkeit und
Qualität ausgeführt werden.
Durch eine Teilautomatisierung und eine zielgerichtete Prozesssteuerung kann
die Auslastung der Mitarbeiter optimiert werden. Das steigert die Qualität des
Gesamtprozesses in mehrfacher Weise. Die Mitarbeiter werden von einfachen manuellen
Tätigkeiten entlastet und können sich damit auf anspruchsvollere, nicht automatisierbare
Tätigkeiten und Sonderfälle konzentrieren.
Durch Fristüberwachung und Eskalationsmechanismen ist sichergestellt, dass
vereinbarte Qualitäts- und Durchsatzziele erreicht werden. Engpässe werden frühzeitig
erkannt und es kann den zugrunde liegenden Ursachen schnell gegengesteuert
werden. Außerdem können rechtzeitig Maßnahmen zur Kompensation der Verzögerung
eingeleitet werden.
Die Automatisierung von Geschäftsprozessen ist auch die Grundlage für Business
Activity Monitoring (BAM). Die KPIs können an geeigneter Stelle direkt ermittelt werden.
Die Auswertung der Prozessdurchlaufzeiten und der ermittelten Kennzahlen bieten die
Grundlage für eine Geschäftsprozessoptimierung.
Ein automatisierter Geschäftsprozess baut auf Services auf, die von einem ESB
bereitgestellt werden. Da die einzelnen Prozessinstanzen, und damit die Aufrufketten
der Service-Aufrufe, anhand von fachlichen Schlüsseln ermittelt werden können, wird
der fachliche Support in einer komplexen Systemlandschaft vereinfacht.
Um den Zugriff auf Service-Instanzen über den fachlichen Schlüssel und technische
IDs zu ermöglichen, muss diese Anforderung schon bei der Modellierung der Services
berücksichtigt werden. Mit Hilfe von Modellierungskonventionen wird dafür gesorgt,
dass alle Services ein standardisiertes Format bezüglich der Schnittstellen und
Protokollierung haben.
NTT DATA
11
Case-ManagementHerausforderungen
Case-ManagementZiele
12
Case Management (CM)
Microservices
Eine relativ neues BPM-Trendthema ist das Case Management (CM). Beim Case
Management geht es darum, einen Fall zu bearbeiten. Da nicht jeder Fall exakt dem
gleichen Muster folgt, ist eine statische Modellierung der einzelnen Bearbeitungsschritte
nicht sinnvoll, oder gar unmöglich.
Microservices sind die logische Konsequenz aus einem Service-orientierten Ansatz.
Monolithische Applikationen werden aufgebrochen in Teilfunktionalitäten. In der klassischen
Service-orientierten Architektur stehen die fachlichen Services auf einem Cluster von
Application Servern zur Verfügung.
Beim Case Management stehen die Daten im Vordergrund, wohingegen beim Business
Process Management (BPM) die Prozesse im Vordergrund stehen.
Bei Microservices geht man einen Schritt weiter.
Die Microservices laufen vollkommen eigenständig
innerhalb eines eigenen Containers. Das bedeutet,
ein Microservice ist eine eigenständige Deployment–Einheit, die unabhängig von allen anderen
laufenden Services produktiv gesetzt wird. Dieser
Ansatz ebnet den Weg „in die Cloud“, da es bei
Microservices unerheblich ist, ob diese fachliche Funktionalität im eigenen Rechenzentrum
oder extern gehostet ausgeführt wird.
Die Herausforderungen beim Case Management sind, dass
eine Modellierung aller möglichen Fallverläufe zu einem nicht mehr handhabbaren
Prozess­modell führen würde,
nicht jeder Fall immer alle vorgesehenen Arbeitsschritte in einer vorbestimmten
Reihenfolge durchlaufen muss,
oft mehrere Bearbeitungssysteme erforderlich sind,
viele unterschiedliche Kommunikationskanäle (Telefon, E-Mail, Einbindung weiterer
Abteilungen oder externer Dienstleister…) beteiligt sind,
kein System übergreifendes Reporting möglich ist und somit die Nachvollziehbarkeit
des Falls und die analytische Auswertung aller bearbeiteten Fälle eingeschränkt ist,
es oft kein dokumentiertes Expertenwissen gibt.
Mit Case-Management-Systemen will man erreichen, dass
Experten große Freiheiten bei der Wahl der Folgeaktivitäten haben, da diese nur
vorgeschlagen und nicht vorgeschrieben sind, Sachbearbeiter aber besser geführt
werden,
die Entscheidungen der Experten durch geeignete Vorschläge von Folgeaktionen
verbessert werden,
Bearbeitungsvorschläge (nächste mögliche Schritte) vom System, basierend auf
ähnlichen Fällen, gemacht werden, der Experte aber die freie Wahl einer Folgeaktion für
den konkreten Fall hat,
die Einstiegshürde für neue Mitarbeiter niedriger wird,
es nur wenige Medienbrüche gibt,
es nur eine Benutzeroberfläche für die Bearbeitung eines Falls gibt,
die Einbindung von weiteren Bearbeitern oder externen Dienstleistern in den Fall einfach
möglich ist,
die Nachvollziehbarkeit des Falls über Systemgrenzen hinweg gegeben ist,
und umfangreiche Daten zur statistischen Auswertung zur Prozessoptimierung und der
Definition neuer Geschäftsfelder vorliegen.
Unsere Empfehlung:
Auf Microservices setzen – für
die größtmögliche Flexibilität
bei Cloud-Architekturen
Microservices als Wegbereiter in die Cloud
Unterstützt wird dieses Architekturpattern durch Infrastrukturen, die einen Containeransatz
implementieren, wie zum Beispiel Docker (siehe https://www.ibm.com/developerworks/
community/blogs/1ba56fe3-efad-432f-a1ab-58ba3910b073/entry/microsevices_
architecture_containers_and_docker).
Klassischerweise werden heute viele Anwendungen auf virtuellen Servern ausgeführt.
Diese virtuellen Maschinen haben den Vorteil, dass sie bei Bedarf generiert und schnell
gestartet werden können. Sie haben aber auch einen großen Nachteil, da sie neben der
eigentlichen Anwendung auch immer das komplette Betriebssystem virtualisieren, was zu
sehr großen Images führt.
Bei einem Containeransatz erfolgt die Virtualisierung auf Serviceebene. Jeder Service
stellt einen eigenen, versionierten Container dar. Dabei werden viele Container in
einem Betriebssystem ausgeführt und nutzen sowohl dieses als auch die Bibliotheken
gemeinsam. Die Images der Container sind somit sehr viel kleiner, als bei klassischen
Virtualisierungslösungen.
NTT DATA
13
Unsere Integrationsarchitekturen für eine
Zukunft in der Cloud
Die Grafik veranschaulicht den unterschiedlichen Ansatz einer Virtualisierung auf Ebene
einer virtuellen Maschine (VM) und auf Applikationsebene (Container) am Beispiel der
Container-Plattform Docker.
VM
Guest
OS
Guest
OS
Guest
OS
Die in vielen großen Integrationsprojekten gewonnen Erfahrungen („Best Practices“) hat
NTT DATA in ihren Produkten und Frameworks umgesetzt, die für unsere Kunden im
Rahmen von Projekten zur Verfügung stehen.
Container
Hypervisor
Binaries /
Libraries 1
Binaries / Libraries 2
Host OS
Host OS
Server
Server
Container
Engine
Binaries /
Libraries 2
APP 2‘
Binaries /
Libraries 1
APP 2‘
Binaries /
Libraries 1
APP 2
APP 2
APP 1‘
APP 1
Die Cloud-Integration muss vom Geschäftsmodell und der Zukunftsvision des Unternehmens
geprägt sein. Sie muss eine geschäfts- und industrieübergreifende Erweiterung der
Wertschöpfungskette nahtlos unterstützen. Dabei müssen Kunden- und Geschäftsdaten
sowie Geschäftsprozesse gegen unberechtigte Zugriffe geschützt werden.
APP 1
APP 1
Bei Bedarf, zum Beispiel bei Vertriebsaktionen)
können sehr schnell weitere Container bei einem
Cloud-Provider gestartet werden, um Lastspitzen
abzufangen. Ebenso schnell sind die Microservices
aber auch wieder abzuschalten, um Kosten in der
Cloud zu sparen. Durch die Standardisierung der
Container ist das innerhalb von Sekunden möglich.
Die Standardisierung der Container erlaubt auch
einen schnellen Umzug von einem Cloud-Provider
Basisinfrastruktur des Cloud-Providers genutzt wird.
Die NTT Data EP (Extension Platform) ist eine seit Jahren bewährte Integrationsarchitektur,
die ihre Stärken bei Integrationsszenarien mit Standardprodukten insbesondere aus dem
CRM-Bereich ausspielt.
Die NTT DATA OLIA (Open Lean Integration Architecture) folgt dem Gedanken,
eine
leichtgewichtige,
aus
Open-Source-Komponenten
zusammengesetzte
Integrationsinfrastruktur für die Entwicklung von Anwendungen anzubieten, die in eine
Unternehmenslandschaft eingebettet werden müssen.
NTT DATA bietet Fach- und IT-Experten mit langjähriger Integrationserfahrung und
Erfahrungen bei der Etablierung von strategischen Cloud-Lösungen in weltweit tätigen
Konzernen. Sie arbeiten industrieübergreifend, unterstützen mit dem Best-PractiseGedanken unseren Kunden, den Trend der digitalen Transformation und die Erweiterung
der Wertschöpfungsketten optimal umzusetzen.
Abb. 3: Virtual Machines vs. Container based virtualization
Microservices in hoch
skalierbaren
Umgebungen
Die digitale Transformation mit ihren vielfältigen Auswirkungen auf die Geschäftsfelder und
die IT-Landschaft ist ein Haupttreiber dafür, Teile der Business-Prozesse und -Daten in eine
Cloud auszulagern.
Unsere Empfehlung:
Microservices ermöglichen
eine flexible Skalierbarkeit in
der Cloud.
zu einem anderen, da lediglich die
Große Internetfirmen wie Google, Netflix, ebay und Spotify, die auf Microservices
setzen, verwenden den Open Source Container Docker (https://www.docker.com/) als
leichtgewichtigen Container-Ansatz. Google startet zum Beispiel 2 Milliarden Container in
der Woche.
Die ING-Bank, bekannt für ihre innovative IT, setzte Docker schon vor der offiziellen Version
1.0 für ihre „continuous delivery“-Pipeline in ihrer Private Cloud Platform im Rahmen einer
Microservice-Architektur ein.
Auch NTT DATA Deutschland hat zusammen mit einem großen Kunden aus der
Automobilbranche Microservices erfolgreich in den produktiven Einsatz gebracht.
14
NTT DATA
15
Autoren
Stefan Kohlmann steht für Service-orientierte
Architektur
(SOA)
und
Integrationsinfrastruktur.
Derzeit beschäftigt er sich intensiv mit dem Thema
„container-based virtualization“, das großes Potenzial
hat, die aktuell vorherrschende IT-Architektur und
die Organisationsstruktur und Rollenverteilung in ITProjekten grundlegend zu revolutionieren.
Sein IT-Fokus liegt auf der system- und
abteilungsübergreifenden Integration von Systemen
und Geschäftsprozessen. Er ist als Architekt bei
erfolgreichen SOA-Einführungsprojekten, zum Beispiel
in der Telekommunikationsindustrie, tätig.
[email protected]
Auf LinkedIn
Andreas Hilbig bezeichnet sich selbst gern als
„Open- Source-Enthusiasten”. Er hat im Jahr 2007
erstmals den Versuch unternommen, eine komplett
auf Open-Source-Komponenten beruhende Alternative
zum IBM SOA Technologie-Stack gemäß damaligem
IBM SOA Blueprint zu entwickeln, und dazu eine
Referenzimplementierung vorgelegt, die auch das bis
dahin noch nicht im Blueprint enthalte Complex Event
Processing auf Basis der Open-Source-Engine „esper“
einschloss.
ndreas ist Team Lead für das Team “Open Source
A
Integration bei NTT DATA und Product Owner der “NTT
DATA OLIA Plattform”.
Über NTT DATA
NTT DATA
Hans-Döllgast-Straße 26
80807 München
Deutschland
Telefon +49 89 9936 -0
www.nttdata.com/de
NTT DATA ist ein führender Anbieter von Business- und IT-Lösungen und globaler
Innovationspartner seiner Kunden. Der japanische Konzern mit Hauptsitz in Tokio ist in über
40 Ländern weltweit vertreten. Der Schwerpunkt liegt auf langfristigen Kundenbeziehungen:
Dazu kombiniert NTT DATA globale Präsenz mit lokaler Marktkenntnis und bietet erstklassige,
professionelle Dienstleistungen von der Beratung und Systementwicklung bis hin zum
Outsourcing. Weitere Informationen finden Sie auf www.nttdata.com/de
Copyright © 2015 NTT DATA Deutschland GmbH
[email protected]
Auf LinkedIn