Schau dich um. Zig Distributionen, alle werben mit dem selben.
Warum sich mit den Problemen eines Release-Upgrades rumschlagen, wenn man problems via Infrastructure as Code jederzeit einen definierten und versionierten Stand erzeugen kann?
Geht mir nicht um Release Upgrades und Infrastructure as Code ist nichts neues, sondern lediglich zu einem Buzzword verkommen.
Mir geht's darum, dass Leute Probleme nicht lösen, sondern ein ständiges neu starten als Fix gesehen wird. Die 90er oder frühen 2000er also wieder zurück Sinn in der man einfach mal neu startet, anstatt Fehler auszubügeln.
Es ermöglicht einen deutlich einfacheren, reibungsfreieren und ausfallsicheren Betrieb.
Hahaha. Deshalb verdient man als DevOp in großen DevoOps-Teams so gut, selbst als Junior. Weil alles so reibungsfrei und ausfallsicher läuft.
Während Kollege A noch vermeidbare Probleme diagnostiziert, kümmert sich Kollege B bereits um die Weiterentwicklung der IT-Landschaft.
Vermeidbare Probleme, wie?
Der Ansatz ist aus der Erkenntnis gestanden, dass man 100% Fehlerfreiheit und Ausfallsicherheit bei einzelnen Komponenten - sowohl Software als auch Hardware - niemals erreichen kann. Also macht man daraus eine Tugend und bereitet seine IT darauf vor, dass jede Komponente jederzeit ausfallen kann. Das Ergebnis gibt dem Ansatz recht.
Und was hat das jetzt mit dem zu tun was ich geschrieben hab?
Entscheidend ist der Mehrwert, den eine Lösung bringt:
- Was ist es mir wert, wenn meine Kollegen ihre Arbeitszeit in Weiterentwicklung statt in Wartung stecken können?
- Was ist es mir wert, wenn ich bei der Umsetzung meiner Anforderungen nicht von meiner veralteten IT ausgebremst werde?
- Was ist es mir wert, wenn ich jederzeit binnen Minuten komplette Kopien meiner IT-Landschaft als Testumgebung(en) erzeugen und wieder abbauen kann und ich so eine höhere Zuverlässigkeit erreiche?
- Was ist es mir wert, wenn ich durch eine höhere Flexibilität mehr Umsatz machen kann?
Deswegen wird momentan Geld in DevOps und Cloud-Lösungen investiert: es lohnt sich für die Unternehmen.
Ich weiß, das ist die stetige Behauptung. Ist aber in der Realität einfach nicht so.
Vor ein paar Jahren hat man einen Junior gehabt, im einfachen Fall oder ein paar Leute, die sich hauptsächlich damit beschäftigt haben, dass sie sich aus dem Job automatisieren. Da war's dann einigermaßen normal, dass man schaut , dass man auch Sachen so baut, dass man möglichst einen Fallback hat, dass man keinen Vendor Lock-In hat, dass man wenn es mal Probleme hat, ein zwei Tasten drückt und das System läuft wo anders, wie es auch bisher gelaufen ist. Konfiguration anständig zu verwalten, Dinge zu automatisieren, Failover und Skalierung hat ja nicht Amazon erfunden. Da hat man das halt nicht Infrastucture as Code sondern eben seinen Job genannt.
Im Vergleich dazu hat man heute so schöne Sachen, wo das Rad neu erfunden wird, wo man nette Probleme hat, wie dass die API von Google oder Amazon mal wieder Schwachsinn zurück liefert, dass vor einigen Jahren noch triviale Probleme ungelöste Probleme hat, dass selbst Amazon teilweise erst nach Jahren mitbekommt, dass sie bei ein paar Rechnern auf die Updates vergessen haben, einfach weil die zur Ausnahme mal gut funktioniert haben, auf der die ach so sichere Cloud läuft. Die sind ja auch auf magische Weise von Rowhammer, Spectre und Bugs in Xen oder KVM nicht betroffen.
Oh und dafür dass sie den Leuten VMs mit weniger Garantien zur Verfügung stellen verlangen sie ein zigfaches im Vergleich zu klassischen VMs.
Als DevOp/SRE/Sysadmin darf man jetzt wenn man die Dinge einigermaßen ernst nimmt raten, ob die Virtualisierung ein Grund für ein bestimmtes Verhalten ist. Das kontern die Cloudanbierter dann damit dass sie dir garantieren dass nur deine VM dort läuft und dir zusätzlichen Support verkaufen, zu natürlich noch höheren Preisen, damit du ihnen Bugs zu finden. Und schau dir mal an wie schnell sich das gerade entwickelt und wie die Komplexität steigt. Da so zu tun, als wäre das Ding bugrfree, da meintest du ja gerade dass das unrealistisch ist. Und ja, ich stoße regelmäßig auf 500er und Fehlverhalten, bei den Großen.
Virtualisierung ist auch nichts neues. Gab's auch schon länger. War halt bis vor dem Cloud-Boom noch die "billige Version". Oder man hat es eben selbst gemacht und konnte Dinge eben auch debuggen.
Ich finde es ein wenig übel wenn so getan wird als wären die positiven Sachen, wo es in letzter Zeit mehr Bewusstsein gibt (dass man seine Konfiguration auch versioniert, dass man Snapshots von Zuständen haben können will, dass man Lösungen zu Failover braucht, dass man Dinge automatisieren will, dass man Systeme sauber trennen wollte, CI/CD ist auch nichts neues) dem Vorhandensein von Leuten und Unternehmen zuschreibt, die hauptsächlich in Managermagazinen und auf Golfplätzen werben. Hätte fast nach einer Verschwörungstheorie geklungen, wenn ich's nicht aus erster Hand hätte.
Was man macht ist das neu erfinden des Vendor-Lockins. Ja, es gibt gute Entwicklungen. Das Beste an der ganzen Sache ist, dass Leute geradezu gezwungen werden Dinge anständig zu machen und nicht ständig alles neu zu machen. Aber das liegt null an so Dingen, wie Docker und schon garnicht an so etwas wie Azure, AWS oder GCP. Okay, es liegt vielleicht ein bisschen daran, dass die ganze Szene drum rum den Sysadmins ein paar Buzzwords zum Vermakten gegeben hat, für die früher nie Zeit war, dass Leute sich ein wenig am Riehmen reißen und State von Logik trennen, weil sie Cloudprovider zwingen.
Aber wenn man sich jetzt sagen wir mal Docker ansieht. Leute verwenden das in der Hoffnung, dass sie damit magisch Probleme lösen, die sie nicht haben. Dann gab's mit so Schönheiten wie Docker Swarm noch mehr Probleme und zusammen mit anderen Shortcomings, die das System neu aufgebracht hat werden jetzt mit Kubernetes und Nomad, die eigentlich aus anderen Gründen geschaffen wurden darum rumgefrickelt. Teilweise wird es dann so richtig sinnbefreit genutzt, und man startet einen physikalischen Server, auf dem man eine virtuelle Maschiene startet, auf dem man eine Docker-Instanz startet indem man ein statisches Binary ausführt, wo man dann dem Container mit der virtuellen Maschiene und im Extremfal Zugriff und Abhängigkeiten darauf auf die phsyikalische Maschiene gibt, aber anstatt das Unsinn zu nenen sagt der DevOp ohne Sysadmin-Experience jetzt das wäre damit Cloud Native. Noch besser wird es wenn dann geglaubt wird dass irgendwas in dem Setup dazu führt, als würde es von sich aus Maintenance reduzieren.
Ist generll eine lustige Sache, wenn Leute glauben, nur weil sie auf ihrem Ubuntu noch ein Ubuntu in einem Container starten dass damit die Infrastruktur irgendwie besser wäere. Ist aber so.
Die meisten Unternehmen sind in zunehmenden Maße auf Gedeih und Verderb auf eine funktionierende, flexible und leistungsfähige IT angewiesen. Mit IT-Prozessen aus dem vergangenem Jahrtausend ist man dem nicht gewachsen.
Ich bin dafür, dass wir weiter gehen und ich bin froh darüber was sich in den letzten zehn Jahren getan hat, aber wir gehen gerade als Industrie in eine Richtung wo wir die Fehler der 90er und frühen 2000er in einem viel größeren Maße wiederholen. Wir bauen gerade vendor lockins wo Amazon zum neuen Microsoft wird, nur dass man dann nicht mal einfach schnell umschwenken kann, wo wir so richtig dicke Layers von Over-Engineering betreiben, gerade jetzt wo gerade weite Teile der Branche begonnen haben dass simple Systeme ihre Vorteile haben übertragen wir genau den Fehler auf die Infrastruktur und während es mich einerseits freut, dass solche Themen ernst genommen werden, zerhauen wir uns das mit einer riesigen Welle an primär durch Marketing gesteuerte Entwicklungen wo's einfach nur darum geht dass Amazon oder Google drauf steht, was Leute dazu bringt deren Services zu nutzen. Im Endeffekt nehmen sich die Open Source Software die stabil und gut läuft, bieten sie gehosted an, eben weil sie nicht "Could Native" sind (weil's eben nicht nur irgendein stateless Binary ist sondern sagen wir mal eine SQL-Datenbank) oder Dinge, die schon seit Jahrezehnten gut funktionionieren (zum Beispiel der Bereich E-Mail oder Monitoring), vermarkten den Teuer, Unternehmen haben keine Infrastruktur mehr und Code der nur "Cloud Native", also nur auf Infrastruktur von einzlenen Marktteilnehmern wirklich funktioniert.
Klar, es gibt da ein paar Lichtblicke, zum Beispiel bei dem was Hashicorp so anstellt, wo scheinbar einigermaßen darauf geachtet wird, dass man nicht alles auf einen Anbieter setzen muss oder gar seine eigene Infrastruktur nutzen kann, aber der Großteil des Marktes ist gerade dabei alles wo nicht Docker, Azure, Google oder Amazon drauf steht als legacy zu bezeichnen und trocken zu legen und das wird genau den Fortschritt, den wir für moderne Systeme brauchen ausbremsen.
Es läuft und ich kenne mittlerweile große Amazon-Kunden, die das Problem haben, dass sie wenn sie von Amazon weg wollen würden einfach nicht die Möglichkeit haben das schneller zu tun als Amazon das will, einfach weil die Daten dort sind oder weil wenn die weggehen würden mal wegen deren API-Limits Monate brauchen würden um die Infrastruktur dort abzubauen. Ist echt mittlerweile ein Problem, dass da Job Queues gebaut werden müssen nur um Ressourcen abzubauen, nur weil es eine Umstellung gibt und Amazon würde sich selbst damit schaden wenn sie das effizienter gestalten würden. Da gehen ganz gute Beträge Tag für Tag rein.
Welche Faktoren willst du konkret beleuchten?
Natürlich ist das nicht trivial, aber Infrastruktur und Mitarbeiter die sich da drum kümmern im Vergleich zu dadurch entstehende Einnahmen.
Im Bereich Administration bzw. DevOps gibt es zumindest im deutschsprachigen Raum für BSD zu wenig und zu kleine Arbeitgeber (dito Auftraggeber). Das bringt einen ganzen Rattenschwanz an Problemen mit sich, von denen die schlechtere Bezahlung nur eines ist.
Gibt aber im deutsprachigen Raum auch ein paar größere Unternehmen, die auf BSD setzen und zwar mit großer Infrastruktur. Je nach dem was du im Sinn hast.
Bei mir ist es gerade so, dass ich ein paar Sachen mit BSD mache, die laufen halt und dann jeder Hilfe und "DevOps" für die macht-alles-besser-stabiler-einfacher Cloud braucht. Da wird dann im Vergleich zu "läuft einfach" Lösungen sehr gut bezahlt und gibt immer was zu tun. Oft ist das so in die Richtung "toll meine Entwickler können mit Dockerfiles vieles selbst entscheiden" und für Dev-Setups funktioniert das auch gut, aber sobald das dann in Production geht sieht man auch, dass vieles im Ecosystem nicht so production ready ist, wie gerne getan wird. Und ich weiß auch von ein paar größeren die deshalb wirklich wieder wegmigrieren bzw. sich vieles selbst zusammenbauen oder das planen. Das Problem ist einfach, dass die alle paar Jahre oder Monate auf was umgestiegen sind, was angeblich die Kinderkrankheiten von Docker beseitigt und der richtige und die langfristige Lösung ist, aber einfach gemerkt haben, dass das Problem immer nur verschoben wird und man ist dann halt mit eigenen Sachen doch etwas flexibler, als wie wenn man statt mit dem eigentlichen Produkt ständig mit der Infrastrur beschäftigt ist.
Und was viele im Endeffekt wirklich wollen ist, dass es anständige Prozesse gibt, dass sie Infrastruktur schnell aufsetzen können (geht auch mit guten alten Images), dass man das was jetzt als Infrastructure as Code bezeichnet wird, aber einfach nur Automatisierung ist über die man auch drüber schauen kann, das muss nicht das letzte Tool sein, das muss auch nicht so ehacktein paar hinge aus halb-deklarativen Lösungen sein (wie oft habe ich Ansible gesehen, das im Endeffekt einfach dafür sorgt, dass wo ein Shell-Script abläuft) . Ja, es ist gut, dass es sowas wie etcd und consul gibt, sich Leute über Configuration Management Gedanken machen, auch es da gerade die große Ernüchterung gibt, dass es da nicht das einfache Tool gibt, das alle Probleme löst. Das sind die guten Entwicklungen.
Mies ist halt, dass wir Monokulturen bauen, wo es nur noch einen Weg gibt um Sachen zu machen, dass es gefühlt unbedingt eine Art Geschichtsunterricht an Unis braucht, weil vieles neu erfunden wird, was genau so scheitert, wie das um die Jahrtausendwende schon in der Windowswelt gescheitert ist, oft muss ich zugeben aber auch einfach viel wiederholt wird, weil Dinge in der Theorie besser klingen, aber im laufenden Betrieb nur Kopfschmerzen bringen. Da setzt auch Marketingspeech ein. Also, wenn man sagt das ist Serverless und man so tut als wäre da wirklich kein Server und wenn man so tut als wäre Infrastruktur perfekt und fehlerfrei nur weil sie von einem großen Anbieter ist, weil sich der deklarive Ansatz für vieles am Anfang richtig anhört, man aber erst in der Praxis festellt, dass das Problem dass man lösen will doch nicht einfach nur ein Zustand ist, oder weil man mit den ganzen Statless-Sachen vergisst, dass State nicht nur in Datenbanken und Files existiert. Vielleicht als wichtigsten Punkt wird so getan als wären hinter all den Layern an Abstraktion keine Computer und normale Software, Betriebssysteme und Prozesse, wehsalb man nicht alles über Bord werfen sollte was man inden letzten 60 Jahren an codeifizierter Erahrung gewonnen hat.
Oder anders gesagt finde ich es gut, dass sich die Dinge in bestimmte Richtungen bewegen und man endlich begriffen hat, dass man auch Infrastruktur als echten Teil von Projekten sieht und man damit vieles ersparen kann und das auch nicht komplziert sein muss (siehe Dockerfile), aber nur weil man das verstanden hat heißt das nicht, dass zum einen die jetztige Implementierung die beste ist, noch, dass man deshalb alles vergessen und ignorieren muss was davor da war bzw. halt dann oft von Cloud Anbietern zur Verfügung gestellt wird, weil man sonst die Fehler blind wiederholt, man sich also im Kreis dreht, anstatt dass man voranschreitet.
Die interessanten Projekte - sowohl thematisch als auch finanziell - finden momentan häufig auf Basis von Container-Plattformen statt (Docker, Kubernetes etc.), dort ist BSD leider komplett außen vor.
Finanziell am Jobmarkt sind Docker und Kubernetes allemal, spannend naja. Zumindest ich fühl mich manchmal als wäre ich effektiv eine Art Tech-Sales-Person für Google oder Amazon. Es gibt einfach manchmal krass falsche Ansichten. Und es gibt diese Artikel in Managermagazinen wirklich und ein guter Freund von mir ist ein CEO eines Unternehmens. Die machen eine App, die recht gut funktioniert und es gibt halt diese Networking-Events und der hat mir erzählt, dass sich so die Buzzwords, wie "Cloud" mittlerweile wirklich zu so einer Art Statussymbol entwickelt hat. Also wenn man ein DevOps-Team oder mehrere hat, die sich um die Cloud kümmern das an sich schon einges an Prestige bringt (wie eine Yacht herzeigen eben).
Und dann hat man eben so Headlines darüber, wie alle unsichere Dockre Container in riesigen Massen verwenden und ich persönlich immer wieder recht deutlich sehe, dass DevOps mit über 90k Jahreseinkommen sehr wenig Ahnung von Systemen haben bzw. generell was die da machen. Dazu gibt es häufig die Annahme, dass Dinge einfach so sicherwähren, weil halt Cloud oder dass Probleme die man nicht auf den ersten Blick sieht oder wo man nicht sieht wie sie sich zusammenbrauen überhaupt nicht existieren. Man verlässt sich halt blind darauf, dass das was in dem Beispiel im Tutorial alles ist was man wissen und beachten muss, weil bestimmten Themen nach Abstraktionen nicht mehr hervortreten.
Ich hatte übrigens mitterweile das Vergnügen DevOps-Interviews zu machen Da gibt's echt Leute, die kaum basic Shell Commands können (ich rede von so Dingen, wie, dass es top gibt), aber Buzzwords in Sätze packen können ohne Ende. Schlussendlich haben die eine Karriere hinter sich, wo sie halt alle zwei, drei Monate den Job gewechselt haben und immer die Commands aus Tutorials kopiert haben und scheinbar schnell genug weg waren um den Untergang nicht mitansehen zu müssen.
Und nochmal zu den Fehlern. Cloud wird ja korrekt als Teuer angesehen, aber was ich bei meinem letzten Post geschrieben habe meinte ich wirklich so. Ich habe vor zehn Jahren oder so mal die wahre Geschichte gehabt von einem Service wo ohne Neustart wirklich nur einer oder eine Hand voll von Requests funktioniert haben dann crashte es und wurde neu gestartet. Wäre ein trivialer fix gewesen und man hätte ein paar Server weniger gebraucht um die mieße Performance zu kompensieren, wenn ständig alles neu startet. Später habe ich dann genau das Selbe gesehen nur dass das dann zu einem kompletten Niederreißen der VM geführt hat. Das Schöne an der Sache war, dass damit auch jeglicher Ansatzpunkt weshalb der Fehler auftrat mit zerstört wurde. Wenn wir jetzt also weil die Anforderungen wachsen den Umstieg von blind Prozsesse neu starten zu blind Server neu starten haben, was machen wir dann wenn wir der Meinung sind wir brauchen den nächsten Layer an Abstraktion?
Zuguterletzt noch ein anderes Thema, das außenvor geblieben ist. Wenn man sich eingehender mit den Themen beschäftigt warum Unternehmen die Cloud verwenden, dann ist der häufigste Grund eigentlich, dass sie statische Binaries und ein gutes Buildsystem und Deployment wollen. Für gewöhnlich ensteht das Buildsystem und das Deployment im Zuge der Umstellung und statt lediglich ein statisches Binary zu nehmen nimmt man einen ganzen Container. Alles andere was dabei mitgebracht wird ist streng genommen kompletter Overhead, also mehr Ausgaben für die Infrastuktur als solche und mehr Zeitaufwand von Mitarbeitern.
Ich mache wenn ich für BSD was bauen will, was in die Richtung von dem geht, was ich daus der Arbeit mit Linux kenne meist so, dass ich zunächst mit dem Bau beginne aber drauf komme, dass ich eigentlich etwas will was ohnehin schon prima funktioniert. So etwas wie Jail Configs, statt Docker Files oder teils auch ganz andere Sachen. Ab und zu wird aus "wäre cool das unter BSD auch zu haben" ein "ich muss mal was bauen um das unter Linux hinzubekommen".
Natürlich gibt es da Ausnahmen, auch will ich keinesfalls so tun, als gäbe es nicht das Eine oder Andere was man sich abschauen könnte, aber vieles was FreeBSD noch vor ein oder zwei Jahren unbedingt haben musste gilt schon wieder als outdated und "falsch".
Da genieße ich das auch ein wenig als Filter, dass ich garnicht erst in Versuchung komme. Es gibt einfach vieles was mir dadurch privat oder auch für mein eigenes Unternehmen erspart geblieben ist. Und gab ja einige gewaltige Reinfälle. Um Docker Swarm machen die größten Dockerfans mitterlweile einen ziemlichen Bogen, was sicher auch teilweise der Grund für den Aufschwung anderer Tools ist.
Ich hoffe es gibt in der Branche möglichst Bald eine Post-Hype-Phase in diesem Bereich, wo Dinge bis auf dort wo sie Sinn machen zuückgebaut werden und wo man vieles von dem oben genannten aus einem tatsächen Grund, der nicht nur "weil es hipp und modern ist und alle so machen" ist. Ich behaupte mal da schon die ersten Ansätze dafür zu erkennen.
Auch wenn man sicher gut verdienen kann wenn man mit Hypes mitschwimmt wäre es cool wenn der Industriezweig wieder auf den Boden der Tatsachen zurückkehrt und nicht so tut als wäre das ausführen eines Docker Containers die einzig richtige und mögliche Art einen Prozess zu starten oder AWS zu nutzen die einzige Art skalierende Services zu schreiben und um Infrastuktur zu kodifizieren. Es ist ja nicht so als hätte es vor 10 Jahren keine großen Websites gegeben oder als wäre alles städnig down gewesen. Auch bekommt man selbst physische Server für gewöhnlich innerhalb von Minuten.
Sorry, ich bin da etwas abgedriftet, aber wenn man nicht darauf angewiesen ist, dass die Welt BSD nutzt, sondern man es einfach für eigene Sachen oder in einem Unternehmen das es nutzt einen fixen Platz hat, dann ist es manchmal schön an einen Ort zu sein, wo man sich nicht wie ein Versuchskaninchen für Software und Services zu sein, die oft selbst nicht wissen, was sie sein wollen.
Oder vielleicht bin ich der Einzige, der auf simple Lösungen, die man auch vernünftig debuggen kann Wet legt.
Ging aber auch aus meinen Recherchen hervor. Was mir gefällt, das Docker doch ziemlich gut dokumentiert ist und es viele HowTo's im Netz gibt. Podman hingegen eher spärlich, aber da kann man ja wahrscheinlich auf die Doku von RedHat zurückgreifen. Ansonsten ist Podman ja (fast) Befehls kompatibel, nur es läuft kein Daemon, was sicherlich wiederum Resourcen spart. Was ich hier poste, gibt nur meine ersten Eindrücke wieder, es erhebt natürlich keinen Anspruch auf Vollkommenheit, da ich mit beiden Containersystemen erst am Anfang stehe. Dementsprechend ist auch mein WIssensstand eher theoretischer Natur, jetzt kommt die Praxis, denn es interessiert mich schon.
) auf Cloud und Co. abgeschweift. Die Frage nach der Sinnhaftigkeit wird häufig übersprungen oder mit "weil es modern ist" oder "weil es alle machen" - wobei das ehrlich gesagt auch ein wenig übertrieben dargestellt wird. Ja, wenn du dir Jobs die bei über 80k im Jahr beginnen ansiehst, dann wird du Ubuntu, CentOS, Cloud, etc. sehen. Wenn du dir aber Unternehmen ansiehst, die einfach nur groß und erfolgreich sind relativiert sich das schon wieder. Und da hat meine Behauptung angesetzt, dass das Einkommen pro sagen wir mal IT Ressource (Ausgaben für technische Infrastruktur und technische Mitarbeiter) womöglich unter den BSDs sogar auf einem höherem Niveau ist.
