Re: Befreiung der Haushalte, der Behörden, ... von Microsoft-Software (ein Beispiel)

[Kristian Rink]

Hi Theo;

danke für die Erklärung. Ich kenne ähnliche Situationen, habe meine 
eigene Geschichte und sehe andere Problempunkte - eben einige der schon 
beschriebenen: Ehemals "Admin", dann IT-Leiter in einem KMU, das einen 
datenintensiven, sehr branchenspezifischen Nischendienst anbietet. Wir 
waren auf den Servern immer Linux, auf den Clients immer Windows, weil 
viele der Fachanwendungen in der Nische (CAD, Planungssoftware) nicht 
unter Linux verwend- oder ersetzbar sind.

Wir haben im Grunde "full stack" alles in der Hand vom Blech bis hin zu 
den Fachanwendungen, die die Dienste für Nutzer intern und extern 
bereitstellen. Mehrwert schaft die Entwicklung (Programmierung) 
spezifischer Lösungen innerhalb der Nische mit relativ schmalen Margen. 
Betrieb der darunterliegenden Infrastruktur war und ist schon immer 
"nur" Kostenpunkt gewesen, etwas, was eben einfach notwendig, aber 
schlecht optimierbar war. Über lange Zeit haben wir das mit 
PC-Infrastruktur bewältigt, bis das schlicht aus Stabilitätsgründen 
nicht mehr funktioniert hat - die PCs, Laufwerke, irgendwann auch 
Netzteile sind unter der 24x7-Last schlicht ausgestiegen. Wir haben 
mehrfach pro Monat Backups zurückgesichert und immer mal wieder Daten 
verloren, weil Dinge kaputtgegangen sind.

Irgendwann haben wir "richtige" Server gekauft, Blech und Storage von 
IBM. Mit Support, dafür aber eben auch mit "anderen" 
Linux-Distributionen. Wenn man next-business-day - Hardwaresupport vor 
Ort will, will die IBM kein Debian, sondern RedHat oder SuSE. Also 
Wechsel der Distribution, mit hinreichend komplexem Umbau von Backup, 
Hosting der Anwendungsserver, ... . Das hat immer mehr und immer 
massiver Zeit gefressen, und die Software-Entwicklung für 
Kundenprojekte, die *eigentlich* unser Geschäft sind, wurde zunehmend 
Nebenbeschäftigung hinter der Betriebssicherung der Infrastruktur 
darunter. Erste Virtualisierungs-Versuche mit VMWare sind grandios 
gescheitert, weil die VMWare-Infrastruktur damals (erste oder zweite 
Version von ESXi Server) viel zu inperformant für unsere Anforderungen 
war. Irgendwann zwischendrin ist uns die CentOS/IBM-Infrastruktur 
zusammengebrochen und wir hatten mehrere Tage Downtime, weil ein Ausfall 
des RAID-Controllers und zweier Platten gleichzeitig das RAID-System 
mitgenommen hat. An diesem Punkt bin ich aus dem Urlaub zurückgefahren 
in der Erkenntnis: Das Linux-System ist sehr effizient und 
leistungsfähig - aber es gab damais in unserem Umfeld (außer mir) 
niemanden, der wirklich imstande war, das in seiner Gänze zu überblicken.

Irgendwann gab es einen zweiten Versuch mit VMWare und HP-Servern, der 
dann gut funktioniert hat und lang gelaufen ist. Dann ist uns in einem 
Jahr vor Weihnachten unter der Endjahreslast (Abgaben vorm 
Jahreswechsel) die Netzwerk-Infrastruktur zusammengebrochen.

Momentane Lösung, seit einigen Jahren: Wir besitzen keine eigene 
Hardware mehr, sondern "mieten Ressourcen" auf Abstraktionsebene von VMs 
mit CPUs, RAM und Storage in verschiedenen Güteklassen (schnell/langsam, 
mit/ohne Backup) im RZ eines lokalen Partners. Dort haben wir eine 
gegenseitige Abhängigkeit (ohne den können wir unser Geschäft nicht mehr 
tun, ohne uns fällt dem ein substantieller Teil des monatlichen Umsatzes 
weg), aber es funktioniert stabil.

Viel wichtiger aber: Dieses Modell ist möglicherweise teurer, als 
Hardware und Software selbst vorzuhalten. Aber es ist *deutlich* 
billiger, als Hardware und Software *und* Personal, Prozesse, Wissen, 
Qualifikation ... für deren Betrieb immer selbst vorzuhalten. Aus dieser 
Brille ist die Entwicklung für mich sogar konsequent, nahtlos, 
folgerichtig: Irgendwann gab es einzelne Rechner, für die Software 
individuell entwickelt wurde durch die Leute, die die Maschine kannten. 
Irgendwann gab es Betriebssysteme für eine Klasse von Maschinen - die 
Betriebssystem-API war "Schnittstelle", und die Anwendungsentwickler 
obendrüber mussten nicht zwingend die Maschinen kennen (und die 
Betriebssystementwickler "darunter" nicht mehr zwingend die 
Anwendungs-Use-Cases). Irgendwann gab es Virtualisierung auf 
Maschinenebene, und plötzlich mussten Betriebssysteme nicht mehr auf 
spezifischem Blech laufen, konnten Betriebssysteminstallationen mit 
Anwendungen darauf zwischen Maschinen verschoben, portiert, ... werden. 
Irgendwann gab es VMs in der "Cloud", bei der man zwar wusste, das 
natürlich Hardware untendrunterliegt, sich darum aber gar keine Gedanken 
mehr machen musste. Die Schnittstelle zwischen "Anwendung" und 
"Infrastruktur", zwischen "eigener Arbeit" und "Einkaufbarem" rutscht 
stückweise höher - was erwartungskonform ist, weil es überall anders in 
einer arbeitsteiligen, sich immer mehr spezialisierenden Gesellschaft 
genau so läuft.

Und ich denke durchaus, dass das auch für Nachhaltigkeit gut ist. Etwa: 
Stand heute bräuchten wir aus Redundanzgründen eigentlich mindestens 
vier Leute um Systems Engineering - von denen sich aber mindestens zwei 
immer langweilen. Nur um auf Stand der Technik zu sein, müssten wir die 
immer halbwegs "qualifiziert" halten - dafür, dass sie in einem 
letztlich doch kleinen Rahmen unser Geschäft tragen. Unser lokaler 
Dienstleister ist genau darauf spezialisiert, der kann das viel besser, 
der tut nix anderes - also warum sollten wir das selbst tun wollen? Wir 
können uns auf unsere Dinge konzentrieren und dort "besser" sein, er auf 
seine. Der Spezialist erledigt die Arbeit meist deutlich effizienter als 
jemand, der Dinge "nebenbei" tut.

Gleichsam: Durch den Betrieb unserer Infrastruktur (die auf Peaks 
dimensioniert sein muss, aber äußerst selten an diesen Limits läuft) in 
einem Rechenzentrum auf Blech zusammen mit anderen Kunden (für die 
dasselbe gilt) läuft in summa weniger Hardware, und die Hardware, die 
läuft, wird besser ausgelastet. Klimatisierung, Energieversorgung etc. 
sind in einem "richtigen" Rechenzentrum eh um einiges besser abbildbar 
als in einem pragmatischen KMU-Serverstandort. Netzwerk-Infrastruktur 
brauch ich in beiden Fällen, dort sehe ich insofern keine Verbesserung 
oder Verschlechterung.

Azure und Co. treiben das jetzt einen Schritt weiter, indem sie genau 
diesen Dienst anbieten und damit unserem lokalen Partner Konkurrenz 
machen - mit den zwei Faktoren, die der noch nicht kann, nämlich (a) 
Downscaling (ich bezahle nur das, was ich brauche - was zumindest unser 
Dienstleister im Blick auf Block-Storage derzeit nicht kann) und 
wichtiger (b) das Hosting dedizierter Dienste, die die schon benannte 
Schnittstelle noch eine Ebene höher schieben (nicht mehr Mieten von VMs, 
sondern Mieten eines Datenbank-, Block-Storage- oder 
Application-Services). Und dort wird es für mich merkwürdig und perfide, 
dort beginne ich mir zunehmend die Frage zu stellen, wo sich FLOSS in 
Zukunft hin entwickelt: In Microsoft Azure kann ich mir performante und 
hochverfügbare FLOSS-Umgebungen bauen, kann mir Linux-VMs, 
Apache-Server, postgresql-Datenbanken, all den Kram mieten, den ich für 
meine "FLOSS-basierten" Applikationen so brauche. Ich kann mir über 
kubernetes oder OpenStack virtuelle Infrastrukturen bauen. Über Azure 
verdient Microsoft kräftig Geld daran, dass Nutzer Anwendungen auf 
dieser Software bauen und die dorthin deployen.

Finally: Als Unternehmen komme ich hier in Handlungszwang - nicht nur 
politisch, sondern auch wirtschaftlich in zweierlei Dimension. Zum einen 
bieten Azure, Google, ... teilweise Preismodelle an, mit denen lokale 
Partner schlecht mithalten können. Zum anderen aber wird der 
Konkurrenzdruck deutlich größer, weil Marktbegleiter in die eigene 
Nische eindringen und deutlich wirkungsvoller sein können, wenn sie 
gleich auf derartige Technologien aufsetzen und fokussiert und schnell 
vorgehen können, ohne die Steine aus dem Weg räumen zu müssen, mit denen 
wir uns in der Vergangenheit und teilweise noch Gegenwart herumschlagen 
mussten. Ersteres ist nur nervig, zweiteres potentiell ruinös. Und in 
dieser Gemengelage bewegt sich anno 2020 die Idee von "Software Libre" 
und teilweise eine unscharfe Abgrenzung zwischen "Freier Software", 
"Nachhaltigkeit", "digitaler Unabhängigkeit" und Selfhosting (teils auch 
vor einem "es-war-schon-immer-so"-Hintergrund). Und ich denke eben, 
konkret mit Blick auf Azure und FLOSS-Stacks dort drin, dass zurzeit 
FLOSS nicht hilft, solche Probleme einzufangen - ganz im Gegenteil. Mit 
Azure verdient Microsoft an Freier Software, während gleichermaßen ein 
"Libre-" oder auch nur "unabhängiges" vergleichbares Hosting in dieser 
Ausbaustufe fehlt. Ich kann perfekt "FLOSS" nutzen und trotzdem einen 
Monopolisten unterstützen. Deswegen denke ich mehr als nur einmal, in 
2020 wäre Lösung genau dieses, des Hosting-Problems, mit mehr Fantasie 
als nur "Eigenbetrieb" oder Genossenschaft (wobei letzteres Modell schon 
mal gut ist) deutlich wichtiger in der Diskussion als die Frage nach den 
Lizenzen für den Source-Code...


(Sorry, extrem langer Exkurs - ich hoffe, der ist nicht völlig 
zusammenhangslos.)

Viele Grüße,
Kristian