Aufrufe
vor 1 Jahr

01 | 2017 public

  • Text
  • Digitale
  • Microservices
  • Verwaltung
  • Hypervisor
  • Umgebungen
  • Informationstechnologie
  • Digitalen
  • Nutzung
  • Projekt
  • Zeit
Gesellschaft und digitale Transformation

Abbildung 1:

Abbildung 1: Microservice-Topologie bei Netflix (Quelle: A. Tseitlin, „Resiliency through failure“, QCon NY, 2013). Abhängigkeiten von Services werden mit zunehmender Anzahl schnell unüberschaubar. In SOA versucht man, diesem Effekt durch Einsatz eines Enterprise Service Bus entgegenzuwirken. AUSRICHTUNG AUF ENTWICKLUNGSEFFIZIENZ SOA verfolgt primär die Ziele Agilität und Kosteneffizienz 5. Microservices sind alleine auf Agilität ausgerichtet. Das klingt gar nicht so unterschiedlich. Tatsächlich hat die unterschiedliche Gewichtung jedoch zu grundsätzlich unterschiedlichen Herangehensweisen geführt. dass bereits eine große Zahl an Services existiert, die wiederverwendet werden können – zumindest in der Theorie. In der Praxis hat sich das jedoch kaum bewahrheitet. Der sehr fundamentale Ansatz „Agilität durch Wiederverwendung bestehender Services“ kann heute als gescheitert angesehen werden. SIND MICROSERVICES DIE BESSERE SOA? Microservices setzen konsequent auf Dezentralisierung und Deregulierung. Sie erreichen ihr Ziel – die Agilität –, indem sie es ermöglichen, neue Services sehr schnell zu entwickeln und in Betrieb zu nehmen. Offenbar unterscheiden sich Microservices gar nicht so sehr von modernen SOA, sind ihnen aber in einigen Aspekten überlegen. Allerdings zeigen sie Schwächen in Bereichen, die in der SOA- Welt längst gelöst sind: SOA verfolgt einen zentralistischen Ansatz: Services werden zentral angeboten, überwacht und gesteuert. Der einzusetzende Technologiestack und die Architektur werden durch Architektenboards explizit gesteuert und somit möglichst einheitlich und stabil gehalten. Neue Services können hier nur langsam in Betrieb genommen werden. Die Agilität entsteht vor allem dadurch, Um eine größere Servicelandschaft dauerhaft zu beherrschen, bedarf es einer gewissen Steuerung (Governance). Dazu gehört auch eine übergreifende Service-Registratur, die eine Wiederverwendung von Services in einer Behörde mit zahlreichen Fachfunktionen erst möglich macht. Microservices bieten hierfür bisher keine entsprechenden Konzepte oder vorgefertigten Werkzeuge. 5 http://soa-manifest.de/praeambel.html 36 | .public 01-17 | Informationstechnologie

Immerhin wurde mittlerweile erkannt, dass ein dezentraler Ansatz ohne irgendeine Art zentraler Steuerung nicht beherrschbar ist. Hier entsteht eine Reihe proprietärer Werkzeuge für Monitoring, Service Discovery oder Configuration Management. Wie robust diese sind und wie weit darauf basierende Microservice-Landschaften skalieren, ist derzeit kaum abzuschätzen (siehe auch Grafik Service-Topologie bei Netflix). Auch der Einsatz moderner Technologien in Microservices hat seine Schattenseiten. So berichtet Matt Ranney, Chief Systems Architect bei Uber, dass der Einsatz von JSON für die Datenübertragung 6 einer der größten frühen Designfehler war, da eine syntaktische Nachrichtenvalidierung dadurch faktisch unmöglich wurde. 7 • die Reduzierung des Scopes auf einen beherrschbaren Umfang – sowohl funktional als auch (entwicklungs-)organisatorisch, • die Konzentration auf pragmatische Ansätze mit unmittelbar messbarer Wirkung, • der sparsamen Einsatz zentraler Infrastruktur. Microservices entwickeln sich derzeit rasant weiter. Mit Eureka, Ribbon und Hystrix gibt es derzeit OSS-Bausteine für Service Discovery, Client-side Loadbalancing und Fault Tolerance, die in der SOA-Welt bisher in die Domäne der zentralen Infrastruktur gehörten. Schließlich ist der große Themenkomplex der Service-Integration weitgehend offen. Eine Anwendung in viele kleine Services zu zerlegen, mag für den Entwickler attraktiv klingen, für den Anwender ist es das aber sicher nicht. Er erwartet weiterhin eine einheitliche Benutzeroberfläche. Hier finden sich zwei Ansätze: • Die Benutzeroberfläche wird als eigener Client implementiert. Dieser ist hoch integriert, aber über sehr viele Schnittstellen mit allen anderen Microservices verknüpft. Der Ansatz skaliert nur für kleinere Anwendungslandschaften. • Jeder Microservice bringt seine eigene Oberfläche mit. Die Integration erfolgt, wie beispielsweise bei OTTO.de, über krude und proprietäre Technologien wie Server Side Includes 8 . Die beiden Ansätze münden in die konkrete Frage, ob ein Microservice nun eine Webanwendung mit Benutzeroberfläche ist, oder wirklich nur ein Webservice, der auf anderem Wege integriert werden muss. In der Microservices-Community besteht darüber keine Einigkeit. Ähnlich verhält es sich bei der Backend-Integration. Microservices akzeptieren ein gewisses Maß an Redundanz zwischen Services. Dazu, wie die Verteilung und der Abgleich der Daten erfolgen, machen Microservices jedoch keine Aussagen. In der Praxis findet man auch hier proprietäre Lösungen anstatt der von den SOA-Suiten implementierten EAI-Patterns. DevOps und Containerization DevOps und Containerization sollen Software-Entwicklungsteams in die Lage versetzen, Software schneller in Betrieb zu nehmen. DevOps bezeichnet dabei das Vorgehen, Containerization bietet Werkzeuge dazu. Unterschätzt wird dabei häufig der Paradigmenwechsel, den dieser Ansatz mit sich bringt. Versteht sich die klassische Behörden-IT bisher als Betreiber von Anwendungen, um die herum ITIL-Prozesse umgesetzt werden, wird sie nun zum Betreiber von Infrastruktur „degradiert“. Dieser Ansatz passt durchaus zu den Cloud-Anbietern wie Amazon und Strato, die sich ohnehin nie als etwas anderes gesehen haben als Infrastrukturbetreiber. In einem IT-DLZ wirft das jedoch einige Fragen auf: • Verantwortlichkeiten wie IT-Sicherheit und Datenschutz gehen teilweise an die Entwicklung über und müssen neu geregelt werden. • Große Teile des Incident-Managements verlagern sich in die Entwicklung. Die Schnittstelle zwischen Entwicklung und Betrieb muss neu gestaltet werden. • Wer betreibt Software-Produkte, die nicht im Hause entwickelt werden? Wer betreibt querschnittliche Infrastrukturprodukte wie zum Beispiel LDAP-Server? Diese Beispiele zeigen: Microservices sind zwar pragmatischer als SOA, haben aber nicht denselben Reifegrad erreicht. Insbesondere gibt es für viele Herausforderungen keine Standardlösungen. Anwender müssen daher proprietäre Lösungen für Probleme finden, die in der SOA-Welt längst gelöst sind. Derzeit ist es also sicher zu früh, SOA zu begraben. Allerdings kann man von den Microservices so einiges lernen: Nachdem sich die IT-DLZs mit der Anwendung von ITIL in den vergangenen Jahren in diesen Bereichen erheblich weiterentwickelt haben, ist nicht abzusehen, dass diese Kompetenzen nun an die Software-Entwicklung abgegeben werden. 6 Siehe Artikel über RESTful URL, .public 03-2016 7 https://www.infoq.com/articles/podcast-matt-ranney 8 Server Side Includes (SSI) sind in (meist HTML-)Dokumente eingebettete, einfach zu nutzende Skript-Befehle, die auf dem Webserver ausgeführt werden, bevor das Dokument an den Client ausgeliefert wird; siehe https://dev.otto.de/2015/09/30/on-monoliths-and-microservices Informationstechnologie | .public 01-17 | 37

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2016 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum