Von Nixdorf nach Kubernetien – Digitalisierung im Wander der Zeit

Die Politik entdeckt die Digitalisierung als Zukunftsthema und gibt den Rat: „Die Digitalisierung ist auch für Mittelständler eine Pflichtaufgabe“. Dabei ist die Digitalisierung im Mittelstand schon lange angekommen, wie ein Ausflug in das Optica Abrechnungszentrum, einem Unternehmen der Dr. Güldner Firmengruppe, zeigt – lange bevor das Internet zum Neuland in der Politik deklariert wurde.

Digitalisierung 1.0

Mit der mittleren Datentechnik, die in den 70er Jahren des vorherigen Jahrhunderts vor allem durch Nixdorf in Deutschland und Europa geprägt wurde, wurden Computer auch für mittelständische Unternehmen erschwinglich. So hat das Optica Abrechnungszentrum bereits früh auf Unterstützung durch die elektronische Datenverarbeitung (EDV), wie IT früher hieß, gesetzt. Damit sich die teure Investition rechnete, waren die Prozesse auf den Computer ausgerichtet, um Leerlauf zu vermeiden. In mehreren großen Schreibbüros mit 40 bis 50 vorwiegend weiblichen Mitarbeitern wurden Abrechnungsdaten an Datensammelsystemen erfasst und gespeichert, anfangs auf Lochkarten, später auf Magnetbändern. Zum Abrechnungslauf wurden die Bänder auf ein Nixdorf 8850 eingespielt und anschließend archiviert. Benutzerschnittstellen waren in der EDV-Bronzezeit kein Thema – der Benutzer hatte sich nach dem Rechner zu richten. Vorherrschend waren Batch-Betrieb und das EVA-Prinzip: Eingabe – Verarbeitung – Ausgabe (Abb. 1). Hierbei gab es einfache, meist grüne Masken, die über die Tastatur und Enter-Taste bedient wurden. Und gute Datentypisten/-innen konnten die Masken blind und in hoher Geschwindigkeit bedienen.

Das EVA-Prinzip (Abb. 1)

Digitalisierung 2.0

In den 80er Jahren kamen dann relationale Datenbanken auf. Diese dienten nicht nur der standardisierten Ablage von Daten, sondern erlaubten es auch, Beziehungen (mathemaisch: Relationen) auszudrücken. Als 1985 das Gigabyte RAM noch etwa 100.000 DM kostete, stand vor allem die effiziente Speicherung von Daten im Vordergrund. Gleichzeitig fand mit dem Aufkommen des Personal-Computer eine Dezentralisierung statt. Im Mittelpunkt stand eine relationale Datenbank, während die Eingabe und (Vor-)Verarbeitung bereits auf PCs stattfand. Zusammen mit der aufkommenden Vernetzung war dies die Geburtsstunde vieler Client-Server-Architekturen, die teilweise auch heute noch im Einsatz sind. Und auch hier gab es bereits die ersten digitalen Transformationen. Es galt die Records und Datenbänder aus der Nixdorf Ära in die neue, relationale Welt zu übersetzen – und umgekehrt (Abb. 2). Schließlich liefen auf dem alten System lebenswichtige Prozesse, mit denen Geld erwirtschaftet wurde. Und diese Prozesse wollen mit Daten bzw. Magnetbändern versorgt werden.

Datenaustausch zwischen alter und neuer Welt (Abb. 2)

In einigen Bereichen wie Banken und Versicherungen sind diese Transformationen auch heute noch im Einsatz. Wer schonmal mit einer COBOL-Copy-Strecke zu kämpfen hatte, weiß wovon die Rede ist.

World-Wide-Web

Waren es anfangs noch lokale Netze, die den Datenaustausch durch Disketten oder andere Datenträger ablösten, wurde vor allem nach der Geburtsstunde des World-Wide-Webs 1989 am CERN der elektronische Austausch mit externen Partnern immer wichtiger. War es bis dahin noch üblich, Bestellungen, Rechnungen und andere Unterlagen in Papierform auszutauschen, entwickelte sich ein wilder B2B- und B2C-Schnittstellen-Zoo mit dem Ziel, diesen Medienbruch zu reduzieren (Abb. 3). Mit dem Austausch von Daten ist immer auch die Frage des Formats von Bedeutung. Waren es anfangs meist binäre Protokolle, wurde ab 1998 immer häufiger XML für die Definition von Austauschformaten eingesetzt. XML spielt auch für die Idee von Service-Oriented-Architecture (SOA) eine zentrale Rolle, die ihre Hypephase Anfang der 2000er Jahre hatte.

Datenaustausch mit Business-Partnern (Abb. 3)

Auch wenn um 2000 die ersten NoSQL-Datenbanken aufkamen, änderte sich datenbanktechnisch nicht viel: im Mittelpunkt vieler Anwendungen und Architekturen steht nach wie vor eine relationale Datenbank, die aber langsam zum Flaschenhals zu werden droht. Nun kann man zwar Datenbanken clustern, aber dies bedeutet nicht zwangsläufig einen Performancegewinn, sondern hängt stark davon ab, ob sich die Daten anhand der Zugriffe aufteilen lassen. Dies kann beim Datenbankdesign berücksichtigt werden, aber die Realität sieht oft so aus, dass neue Anforderungen meist mit einer Anreicherung von Datenbanktabellen um neue Spalten einhergehen. Und auch wenn es sinnvoller wäre eine Tabelle aufzuteilen, so scheitert das oft daran, dass sich um die Datenbank eine ganze Menge von Anwendungen gruppiert haben, die eine grundlegende Änderung des Datenbankdesigns unmöglich machen. Was also tun, wenn sich die Datenbank nicht clustern lässt? Und wie lassen sich neue Anforderungen schneller umsetzen als mit der aktuellen Architektur?

Microservices

Ein Resultat dieser Überlegungen war die Aufteilung der Datenbank und der Anwendungslandschaft nach Domain-Driven-Design in verschiedene Bereiche (Stammdaten, Rechnungen, Rezepte etc.). Darin sollte jede Domain ihr eigenes Datenbankschema bekommen. Architektonisch sollte der Zugriff dann nur über Microservices erfolgen. Damit wird die Datenbank zum Implementierungsdetail und kann später auch durch eine NoSQL-Datenbank ausgetauscht werden (Abb. 4).

Aufteilung und Kapselung der Datenbank über Microservices (Abb. 4)

Warum Microservices? Bei Microservices geht es immer um die Performance der Softwareentwickler, nicht um die der Software. Natürlich gibt es auch andere Vorteile wie bessere Skalierbarkeit und Unabhängigkeit von der Programmiersprache, aber man erkauft sich diese Vorteile durch eine höhere Komplexität der Anwendungslandschaft. Und Microservices allein lösen nicht das Problem der Aufteilung unserer zentralen Datenbank. Prinzipiell gibt es dafür zwei Strategien:

1. Beibehaltung der zentralen Datenbank und Kapselung durch Microservices.
2. Microservices mit eigener Datenbank + Synchronisierung mit zentraler Datenbank.

Strategie 1 bringt die Gefahr, dass viele Anwendungen die Kapselung umgehen können und neue Anforderungen zu einem weiteren Aufblähen der Datenbank führen. Langfristig hat daher die 2. Strategie das größere Potential. Allerdings birgt es auch größere Risiken: man muss die zentrale Datenbank mit ihren Redundanzen und potenziellen Inkonsistenzen mit den internen Datenbanken der einzelnen Services synchronisieren. Das ist ein nicht ganz triviales Problem. Technisch gelöst wird das über Events, die bei Datenänderungen erzeugt werden (z.B. per Datenbank-Trigger oder über den Microservices selbst). Ob man jetzt hier RabbitMQ, Kafka oder andere Lösungen einsetzt, hängt von verschiedene Randbedingungen ab. Das Prinzip ist aber das gleiche – Events werden zusammen mit den Daten in Messages verpackt und an die Abonnenten verschickt, die so über Datenänderungen informiert werden (Abb. 5).

Rabbit MQ (Abb. 5)

Wolkige Aussichten

Gab es früher nun einen oder einige wenige physikalische Server im Rechenzentrum, so sind es heute viele virtuelle Server. Damit stellt sich die Frage, auf welche Server verteilen wir am besten unsere Microservices. Und wie skalieren wir, wenn wir Lastspitzen abfangen wollen oder müssen.
Eine weitere Frage ist die Frage des Testens. Microservices kommen selten allein, sondern sind oft von anderen Seiten abhängig. Wie kann ich das testen, wenn dann auch noch weitere Abhängigkeiten wie eine Datenbank mit Testdaten und ein Elastic-Search-Server dazukommen?

Früher oder später stößt man bei der Suche nach der Antwort auf Docker, einer leichtgewichtigen Virtualisierungslösung mit vielen vorgefertigten Containern. Es gibt Container für Java, für Datenbanken, für Webserver, kurzum – für alles Mögliche. Darauf aufbauend kann man eigene Container bauen und sich damit sein eigenes kleines virtuelles Rechenzentrum auf seinem Rechner aufbauen – ideal für den kleinen Integrationstest zwischendurch oder auch einfach nur zum Ausprobieren, ob für ein bestimmtes Problem vielleicht eine NoSQL-Datenbank die bessere Alternative wäre. Endlich ist man auch nicht mehr vom Admin abhängig, wenn bestimmte Dienste oder Rechenkapazitäten gebraucht werden. Man sucht sich einfach den passenden Container aus und packt ihn in die Cloud. Und zum Deployment in Produktion ist es dann nur noch ein kleiner Schritt, oder? (Abb. 6).

Microservice-Landschaft (Abb. 6)

Stop! Spätestens ab hier wird es jetzt kritisch. In Produktion ist das Gewässer rauer und hier herrschen andere Gesetze. Auch wir mussten erst lernen, den Admin frühzeitig mit einzubinden und ein DevOps-Team aufzubauen, das für unsere Basis-Container verantwortlich ist und sie für die Gefahren auf rauer See härtet, das dafür sorgt, dass man im Falle von Sturmschäden rechtzeitig vom Ausfall einzelner Systeme benachrichtigt wird und das Fehleranalysen betreiben kann. Aus Sicherheitsüberlegungen werden bei uns die Rechnerkapazitäten intern bereitgestellt. Wer das nicht kann, für den ist die Frage nach einem vertrauensvollen Cloud-Provider überlebenswichtig. Neben der Frage der Datensicherheit ist vor allem die Frage zu klären, wie man im Fehlerfalle an wichtige Daten und Protokolle herankommt, um eine Analyse erfolgsversprechend durchführen zu können.

Die Reise nach Kubernetien

Mit der steigenden Anzahl von containern wird die effektive Zuteilung der Ressourcen immer wichtiger. Welcher Container bekommt wieviel Speicher oder CPUs? Welchen Container starte ich lieber mehrfach? Wie skaliere ich und wie überwinde ich das Ganze? Für die Antwort auf diese Fragen setzen wir auf Kubernetes, um unsere Container-Landschaft zu orchestrieren. Der Orchestrierung sollte aber immer eine gute Planung vorausgehen. Welche Microservices gehören zusammen und sollten am besten in ein eigenes Self-Contained-System (SCS) untergebracht werden? Welche gemeinsamen Dienste müssen bereitgestellt werden? Wer darf mit wem kommunizieren? Wie wird Autorisierung und Authentisierung gehandhabt? Wie soll Load-Balancing gesteuert werden? Wo soll das ganze laufen – in einer internen, externen oder hybriden Cloud? Für die Beantwortung dieser Fragen braucht es neben den verantwortlichen Architekten ein DevOps-Team mit entsprechender Kubernetes-Kompetenz. Und damit schließt sich der Kreis zu den Anfängen. Auch im Nixdorf- und Mainframe-Zeitalter war die zentrale Administration Voraussetzung für einen effektiven und störungsfreien Betrieb. Eine schöne Oberfläche allein reicht nicht, um auf Dauer erfolgreich zu sein (Abb. 7)

.

Orchestrierung über Kubernetes (Abb. 7)

Fazit:

Im Gegensatz zur Politik ist die Digitalisierung im Mittelstand schon längst angekommen. Musste man sich zu Beginn der Digitalisierung noch fragen, ob sich die teure Hardware lohnt und wie man sie am besten auslastet, setzt man heute auf Virtualisierung und Verlagerung der Ressourcen in die Cloud, um die Kosten in den Griff zu bekommen – unerheblich, ob die Cloud bei Amazon, Azure oder selbst betrieben wird. Eine selbstbetriebene Cloud muss dabei nicht unbedingt teurer sein, wenn man auf unendliche Skalierung verzichten kann. Und sie bietet Vorteile bei der Sicherheit:

– Daten können nicht abgegriffen werden,
– Daten können nicht verloren gehen,
– beim Ausfall der Cloud ist man nicht von anderen abhängig (auch Public-Clouds können ausfallen 4 5 ).

Auch wenn der Datenschutz oft als hinderlich angesehen wird, so kann er auch ein Wettbewerbsvorteil sein. Gerade im Gesundheitsbereich, wo man mit hochsensiblen Daten umgehen muss, ist Datenschutz unabdingbar und es gilt das Risiko von Datenlecks zu minimieren, auch in Zeiten von Corona und Home-Office. Neben dem schleppenden Breitbandausbau seit mehr als 10 Jahren ist die Rekrutierung von IT-Fachkräften eines der größeren Probleme bei der weiteren Entwicklung. Auch wenn sich Studienabgänger oft von großen Firmen und Globalisierung verleiten lassen, hat der Mittelstand den Vorteil, dass für ihn Entwickler keine Human-Resources sind, sondern Mitarbeiter, die Spaß an der Arbeit haben sollen. Hinderlich an der Digitalisierung sind analoge Schnittstellen, wie sie sowohl im Gesundheitsbereich, aber auch bei manchen Verwaltungsämtern zu finden sind. Aber wenn die Politik wie anfangs in der Corona-Krise mehr auf Experten, als auf Interessenverbände und Lobbyisten hört, dann klappt das auch dort mit der Digitalisierung. Im Mittelstand jedenfalls ist die Digitalisierung schon seit Jahrzehnten angekommen.

Quellen / Links:

[1] Zitat Peter Altmeier: https://bit.ly/altmeier-p1

[2] Zitat Hanna Prinz: https://bit.ly/prinz-h2

[3] https://bit.ly/heise-h3

[4] https://bit.ly/heise-h4

[5] https://bit.ly/heise-h5

 

Bildquellen:

Uher-Tonband: https://bit.ly/uher-t2

 

Oliver Böhm

Oliver Böhm ist derzeit beim Optica Abrechnungszentrum für Fragen rund um die Java-Entwicklung verantwortlich – nicht nur für aktuelle Themen, sondern auch für Legacy-Systeme. Passend dazu hat er im letzten Jahrhundert Informatik an der Uni Stuttgart studiert. Seit 1999 entwickelt er mit Java. Neben seiner hauptberuflichen Tätigkeit als Java-Archäologe und -Architekt ist er Board-Mitglied der JUG Stuttgart und organisiert dort neben den Stuttgarter Testtagen Code Retreats zusammen mit der Softwerkskammer Stuttgart.

Twitter | E-Mail | Xing | Blog 

Redaktion


Leave a Reply