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
_______________________________________________
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de
Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt.
Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu
behandeln: https://fsfe.org/about/codeofconduct
