Managed Public Clouds
Mit der Eröffnung der deutschen Amazon Web Services (AWS) Region im vergangenen Oktober in Frankfurt ist die Public Cloud auch in Deutschland angekommen. Unterstrichen wird deren Bedeutung von zahlreichen Kundenreferenzen und zum Teil innovativen Use Cases. Aber nicht nur AWS wird im kommenden Jahr weiter für Furore sorgen. Auch von IBM Softlayer, Salesforce, ProfitBricks und insbesondere Microsoft, die nun auch mit eigenen Rechenzentren in den deutschen Markt einsteigen, dürfen wir im Jahr 2016 einige Überraschungen erwarten. Der Kampf um die Public Cloud ist auch in Deutschland entbrannt und das kürzlich gefallene Safe Harbor Urteil wird seinen Teil dazu beitragen!
Zu einer spannenden Geschichte gehören allerdings mehrere Protagonisten. Die Hauptrolle in der Public Cloud nehmen einmal mehr die IT-Anwender ein. Eine hohe Komplexität in der Nutzbarkeit - Stichwort: Cloud-Wissen - und eine bislang unklare Kommunikation der Verantwortlichkeiten - Stichwort: Self-Service / Shared-Responsibility - sorgen für Verwirrung und beeinträchtigen die Public Cloud Adaption.
Die weißen Ritter, die sowohl die Situation für die Anbieter als auch die Anwender entschärfen werden, sind die Managed Public Cloud Provider (MPCP). MPCPs entwickeln und betreiben die Systeme, Applikationen und virtuellen Umgebungen ihrer Kunden auf den Public Cloud-Infrastrukturen. Sie gleichen damit das fehlende Cloud-Wissen der Unternehmen aus und lösen das Problem der Shared-Responsibility.
Hybrid-Cloud und Multi-Cloud-Integration
Im Rahmen der digitalen Transformation ihres Unternehmens stehen CIOs vor der Herausforderung, neben der Einführung neuartiger Infrastruktur- und IT-Umgebungen, zur Unterstützung moderner Workloads, ihre Legacy- und Compliant-kritischen Systeme nicht zu vernachlässigen. In der jüngsten Vergangenheit hat sich daher gezeigt, dass zu einer modernen IT-Umgebung zwei Welten gehören: die Dynamic IT und die Static IT.
Was sich bereits abzeichnet: Dynamic IT-Umgebungen, vorwiegend auf Basis von Public Cloud-Umgebungen implementiert, nicht nur bei einem einzigen Anbieter aufgebaut werden. Stattdessen ist Vielfalt gefragt. Denn der One-Stop-Shop mit dem idealen Cloud-Portfolio existiert nicht. Hinzu kommt, dass sich Innovationen nur von verschiedenen Anbietern einkaufen lassen und per se nicht alle Eier in ein einziges Nest gehören.
CIOs sollten daher zwei Ansätze verfolgen. Hierzu gehören das Multi-Cloud-Management, bei dem Anwendungen und Systeme die auf IaaS-, PaaS-, und SaaS-Umgebungen betrieben werden, nicht zwangsläufig miteinander integriert werden müssen. Dennoch besteht die große Herausforderung darin, den Überblick über alle verwendeten Cloud-Services und -Angebote zu behalten. Anhand der hybriden Integration gehen CIOs einen ernst zunehmenden Schritt. Schließlich entsteht der eigentliche Mehrwert von Cloud-Systemen erst dann, wenn diese miteinander verzahnt sind, auf einer gemeinsamen Datenbasis arbeiten können beziehungsweise gegenseitig Daten austauschen. So sollte es zum Beispiel eigentlich eine Selbstverständlichkeit sein, dass ein Cloud-basierter CRM-Service auf Daten eines ERP-Systems zugreifen kann.
Die Multi-Cloud-Integration bildet die Königsklasse. Hierbei nutzen Unternehmen einen bunten Mix unterschiedlicher Cloud-Arten - Infrastrukturen, Plattformen und Software-Services - die sie Teils autark verwenden, zum Großteil jedoch auf eine einheitliche Basis miteinander integrieren. Über diesen Cloud-Bebauungsplan (Digital Platform Fabric) gilt es einerseits das bedingungslose Zusammenspiel sicherzustellen, andererseits den Durchblick zu behalten.
Platform-Services
Architekturen auf Basis von Microservices sind der Trend, wenn es um die Entwicklung moderner System- und Applikationslandschaften geht. Durch das Aufbrechen von Applikationen auf die atomare Ebene einzelner Prozesse und Funktionen ("Microservices"), beziehen sich Updates oder Patches nur auf einzelne Teile des Systems und niemals auf die gesamte Applikation. So können einzelne Microservices leicht durch neue ersetzt sowie Innovationen mit kurzem "Time to Market" realisiert werden.
Während der Entwicklung einer Microservice-Architektur geht es in erster Linie darum, den Fokus auf die eigene Applikationsarchitektur zu richten und eigene Microservices zu entwickeln. Dafür die notwendigen Kompetenzen aufzubauen bzw. das richtige Personal zu finden ist heute aber weiterhin keine leichte Aufgabe. Mit den Platform-Services hat sich in den letzten Jahren ein Trend gefestigt, mit denen CIOs und CTOs ihre Entwicklermannschaften mit bereits fertigen Microservices unterstützen können. Public Cloud IaaS-Anbieter wie Amazon Web Services oder Microsoft Azure treiben den Trend maßgeblich voran.
Ein Platform-Service kapselt eine abgeschlossene Funktionalität und wird unabhängig entwickelt und betrieben. Es handelt sich dabei also um eine kleine eigenständige Softwarekomponente (Service), die eine Teil-Funktion innerhalb einer großen, verteilten Softwareapplikation bereitstellt. Mit diesen verwendbaren Services lassen sich Applikationen schneller entwickeln, da die Bausteine nicht mehr selbst entwickelt werden müssen und sich stattdessen direkt als Bausteine im eigenen Quellcode verwenden lassen.
Damit können sich Entwickler und IT-Abteilungen ganz auf die Entwicklung der eigentlichen Kernfunktionalität ihrer Anwendung konzentrieren und können mit diesen Enablement-Services besser auf die Anforderungen aus den Fachabteilungen reagieren und damit für ein schnelleres Time-to-Market sorgen.
Server-Landschaft im Wandel oder Infrastructure as Code
Der herkömmliche Administrator klickt - der zukünftige Administrator programmiert! So lässt sich der Wandel im Rechenzentrum beschreiben, der angetrieben durch Cloud Computing und die Automatisierung der Bestell-, Konfigurations-, Deployment- und Administrationsprozesse in vollem Gange ist. "Infrastructure as Code" ist für IT-Infrastrukturentscheider der kommende Evolutionsschritt auf dem Weg zu einer dynamischen, und autonomen Infrastrukturbasis. Er ist die logische Folge von "Infrastructure-as-a-Service", sprich Cloud-Infrastrukturdiensten, die via API auf Cloud-Plattformen zur Verfügung gestellt und über Befehle auf der Kommandozeile konfiguriert werden. Scripten statt Schrauben heißt es für Administratoren zukünftig. Denn die IT-Infrastruktur der Zukunft, die "Digital Infrastructure Platform", stellt nicht mehr Hardware sondern Infrastruktur als Dienstleistung zur Verfügung. Unternehmen, die sich diesem Trend nicht mit eigenen Personalressourcen stellen wollen oder können, werden in den nächsten Jahren für eine enorme Nachfrage nach sogenannten "Managed Public Cloud Services" sorgen.
Microservices Architectures
Microservices-Architekturen werden zum Blueprint zur Entwicklung digitaler Workloads und zukünftiger Systemlandschaften. Durch das Zusammentreffen von Container-Technologien wie zum Beispiel Docker, APIs und skalierbaren Cloud-Infrastrukturen lassen sich erstmals Software- und Systemarchitekturen entwerfen, entwickeln und betreiben, die ein Höchstmaß an Agilität bei gleichzeitiger Robustheit versprechen. Durch das Aufbrechen von Applikationen auf die unterste Ebene einzelner Prozesse und Funktionen ("Microservices"), beziehen sich Updates oder Patches nur auf einzelne Teile des Systems und niemals auf die gesamte Applikation. So können einzelne Microservices leicht durch neue ersetzt sowie Innovationen mit kurzem "Time to Market" realisiert werden.
Ebenso lassen sich Fehler und Integrationsaufwand erheblich reduzieren. Da einzelne Microservices unabhängig voneinander existieren können und sich gut horizontal skalieren lassen, sind Microservices-Architekturen ebenfalls ausfallsicher und robust. Um den Nachteil höherer Komplexität zu kompensieren, sollten CIOs und CDOs beginnen, eigene Kompetenzen aufzubauen bzw. sich frühzeitig die richtigen Dienstleistungspartner auszuwählen, um sich so im DevOps-Modell und der agilen Entwicklung auf Basis von Microservices zu üben.
Storage mit NoSQL-Databases
Wenn es um große Datenmengen und gute horizontale Skalierbarkeit geht, kommt man an NoSQL-Datenbanken nicht vorbei. Klassische relationale Datenbanken haben oft das Problem, dass man sie nur begrenzt und mit viel Aufwand horizontal skalieren kann, was bei NoSQL-Datenbanken anders ist. Das liegt zum einen an der Datenstruktur, zum anderen am Konsistenzmodell. Man kann NoSQL-Datenbanken in vier Kategorieren einteilen, die jeweils unterschiedliche Konzepte zur Datenspeicherung und somit auch für ganz unterschiedliche Einsatzzwecke gedacht sind.
Beim Key-Value-Storage werden die Daten mit einem eindeutigen Schlüssel verknüpft und können auch nur über diesen referenziert werden und es eignet sich sehr gut als performanter Cache-, Session-, Queue- oder einfacher Daten-Speicher.
Beim Document-Storage werden zusammenhängende Daten, zum Beispiel alle Daten die einen User betreffen, in einem Dokument abgelegt. Ein übergeordnetes Schema existiert nicht, allerdings sind die Daten innerhalb der Dokumente wohl strukturiert und auch das Referenzieren über bestimmte Attribute ist möglich. Das Einfügen und Abfragen einzelner Dokumente geht somit sehr einfach, Konsistenz und Schemaüberprüfung müssen allerdings in der Applikation implementiert werden.
Der Column-Storage ähnelt am ehesten einer relationalen Datenbank, nur werden hier die Daten spaltenorientiert abgespeichert. Das verringert die IO-Zugriffe deutlich, wenn man Operationen über viele Reihen hinweg auf einer bestimmten Spalte ausführt. Operation die auf viele Spalten innerhalb einer Reihe angewandt werden sind entsprechend teuer. Sie eignet sich also gut für Analyse-Zwecke oder Data-Mining.
In die letzte Kategorie fällt der Graph-Storage, bei dem die Daten als Graphen abgespeichert werden. Diesen eignen sich somit hervorragend zur Darstellung von Beziehungen unter Objekten.
Die Derivate der NoSQL-Familie lassen sich nicht immer ganz eindeutig in diese Konzepte einteilen, sie vermischen diese teilweise und letztendlich muss man sich entscheiden, welche Datenbank für das bestehende Problem die Richtige ist. (hal)