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)