bodschDie IT verdummt zusehends
https://www.boone-schulz.de/2023/04/die-itT-verdummt-zusehends/
Falk Stern@bodsch Ich könnte noch mal genausoviel zum Netzwerkthema schreiben. Amen, brother.
Sebastian Mangelsdorf@bodsch Seit knapp 2 Jahren lerne ich Kubernetes und habe vielleicht 10% verstanden. In der ganzen Firma gibts vielleicht noch 2-3 mit denen ich wenigstens mal diskutieren kann, sonst hat auf die Komplexität und Halbwertszeit beim Wissen keiner Lust. Sichert halt den Arbeitsplatz wenns sonst keiner macht.
@cardes
ich geb dir brief und siegel, dass du nicht mal die 20% erreichen wirst.
zu schnell sind die hypes und funktionierende lösungen werden viel zu schnell verworfen.
diskutieren kann ich auch mit kollegen, leider bin ich der einzige senior, der erfahrung hat und hab eine meute junioren vor mir, die noch nicht mal ansatzweise meine argumente verstehen.
@bodsch Ist schon anstrengend genug die 10% zu halten, keine Chance je auf 20% (mit meinen Fähigkeiten) zu kommen zumal fürs tägliche Arbeiten reichen meist schon 2-3%. Der Herstellersupport durfte dann die kniffligen Fälle übernehmen 😅
0mega ☣ [hz]
Nico Kaiser@bodsch Spricht mir voll aus der Seele!
Ist das vielleicht so eine Art Langeweile-Problem? Also dass irgendwann die eigentlichen Probleme so langweilig geworden sind, dass man lieber immer mehr Zeit reinsteckt, ein „tolles“ „Tooling“ zu bauen und immer wieder neuzubauen?
Fällt mir im Backend auf (alles wird mit k8s beworfen), aber auch im Frontend (Transpiler, Bundler, Toolkits, bis niemand mehr ohne gigabyteweise module hinkriegt HTML/JS/CSS zu schreiben)…
@bodsch Viele der komplexen Tools machen ja im richtigen Kontext Sinn. Ich mag Docker, um selbst auf dem nicht-geclusterten Selfhost-VPS PHP-Glump von anderem Glump zu trennen ohne das Hostsystem zuzumüllen, und für k8s gibt es sicher irgendwo auch einen sinnvollen Anwendungsfall.
Aber sehr häufig wird sowas unhinterfragt eingesetzt, weils gerade cool ist… und nicht verstanden (Debugging? Zu komplex).
@nicokaiser
wobei PHP noch geht.
jedenfalls dann, wenn mna nicht dutzende abhängigkeiten via compose an bord zieht.
sehr viel schlimmer ist nodejs und dessen gesamte Infrastruktur dahinter.
wobei PHP noch geht.
jedenfalls dann, wenn mna nicht dutzende abhängigkeiten via compose an bord zieht.
sehr viel schlimmer ist nodejs und dessen gesamte Infrastruktur dahinter.
LokalmatatorDas spannende ist, das es vermutlich auch soweit gewollt ist, tatsächlich ist der Kunde dem oft ausgeliefert und wenn dann die IT doch nach 4 Wochen wieder läuft, dann hat man ja Glück gehabt und kann noch entsprechende Dienstleistung fakturieren.
Willkommen im Kapitalismus, irgendwoher müssen doch die 150% fakturierbaren Stunden herkommen ;).
@Lokalmatator
du bist dann eher bei 250%.
denn k8s macht ja alles viel einfacher. dann kann man natürlich auch die halbe mannschaft einsparen.
ich hätte wohl noch die beispiele der fehlgeschlagenen k8s updates mit aufschreiben sollen ...
du bist dann eher bei 250%.
denn k8s macht ja alles viel einfacher. dann kann man natürlich auch die halbe mannschaft einsparen.
ich hätte wohl noch die beispiele der fehlgeschlagenen k8s updates mit aufschreiben sollen ...
@bodsch
Aber der Fachkräftemangel…. ;).
Außerdem mal ganz ehrlich ob nun 50 Container gerade stehen oder automatisiert ausversehen hoch und runtergefahren werden, ist doch auch ganz geckig dem zuzuschauen.
Der Kunde bezahlt es doch eh.
@Lokalmatator
stellt sich immernoch die frage, ob es zwingend nötig ist dafür die Komplexität eines k8s zu benötigen.
stellt sich immernoch die frage, ob es zwingend nötig ist dafür die Komplexität eines k8s zu benötigen.
@bodsch
Natürlich, dadurch das wir hier mit Magie und massenhaft Schlangenöl arbeiten, ist es ja keinem anderen möglich, das zu negieren. ;)
So genug Sarkasmus für einen Montag morgen.
Szenarien differenziert zu betrachten und die Kommt drauf an Frage auzuformulieren ist doch sowas von 90er das könnte ChatGPT auch übernehmen.
Natürlich, dadurch das wir hier mit Magie und massenhaft Schlangenöl arbeiten, ist es ja keinem anderen möglich, das zu negieren. ;)
So genug Sarkasmus für einen Montag morgen.
Szenarien differenziert zu betrachten und die Kommt drauf an Frage auzuformulieren ist doch sowas von 90er das könnte ChatGPT auch übernehmen.
@bodsch spannend wäre ja die Antwort in deinem Kontext, aber wer sollte sie geben?
Generell kann Kubernetes im richtigen Umfeld auch die richtige Antwort sein, ich persönlich möchte einfach sehr gerne gegen eine deterministische Umgebung entwickeln, von der ich später entsprechen Differenzieren kann gegen das Produktivsystem.
Komplexität hin oder her, Dinge sind oftmals nicht einfach,
Generell kann Kubernetes im richtigen Umfeld auch die richtige Antwort sein, ich persönlich möchte einfach sehr gerne gegen eine deterministische Umgebung entwickeln, von der ich später entsprechen Differenzieren kann gegen das Produktivsystem.
Komplexität hin oder her, Dinge sind oftmals nicht einfach,
Cruising Steveswijk@bodsch Leider beobachte ich Ähnliches. Ich wünschte es wäre anders. 😔
.ｂｅｅｊａｙ@bodsch ein Problem ist, dass die IT zunehmend komplexer wird. Heute noch alle Systeme komplett verstehen zu wollen, benötigt viel manpower, die Unternehmen vermutlich nicht gewillt sind, zu investieren.
Ja, relativ simple services (nennen wir sie Basics) wie DNS und co sollte jeder Ausgebildete beherrschen. Aber wachsende Anforderungen an die IT bei gleichbleibenden, oder gar stagnierendem, Personal muss halt „bezahlt“ werden. In dem Fall mit blindem Vertrauen auf Automatismen.
Ja, relativ simple services (nennen wir sie Basics) wie DNS und co sollte jeder Ausgebildete beherrschen. Aber wachsende Anforderungen an die IT bei gleichbleibenden, oder gar stagnierendem, Personal muss halt „bezahlt“ werden. In dem Fall mit blindem Vertrauen auf Automatismen.
@beejay
sorry, kein ausgebildeter hat tiefergehendes Wissen bzw. Verständnis von DNS!
Geschweige denn von Lazenzen, oder eine Klassischen Infrastruktur.
Cloud und Container regeln das ja.
Selbst wenn Automatismen helfen, ist der Verlust immens und wird in ein paar Jahren nicht mehr aufzuholen sein.
Wir fangen an blind zu vertrauen ohne einma kritisch zu hinterfragen ...
sorry, kein ausgebildeter hat tiefergehendes Wissen bzw. Verständnis von DNS!
Geschweige denn von Lazenzen, oder eine Klassischen Infrastruktur.
Cloud und Container regeln das ja.
Selbst wenn Automatismen helfen, ist der Verlust immens und wird in ein paar Jahren nicht mehr aufzuholen sein.
Wir fangen an blind zu vertrauen ohne einma kritisch zu hinterfragen ...
Oliver Herold🇻🇦🧐📜🖥️🕹️🐉📖☕️@bodsch Ja klar, aber Information bedeutet auch nicht Computer schrauben, Netzwerktelemetrie, Coden, etc. pp. - es ist die Wissenschaft. Bei uns hieß Informatik in der Schule Turbo Pascal und wie die Aufbauer einer CPU ausschaut. Gelernt hatte ich zuvor noch Cobol und Forth kennengelernt und in einem früheren Leben als Fernmelder startete ich mit BTX, in einem zweiten Leben mit Novell Netware, usw. Hieß damals noch EDV. Studierst du Informatik, hast du mit all dem nichts am Hut.
@bodsch Klar Netzwerktopologie usw. gibts da auch als theoretischer Ansatz in einem mehr wissenschaftlichen Kontext. Kann es dort jemand aus dem FF, sprich Coden und Netzwerken, dann ist dies auch primär eine Eigenleistung nebenher.
vampirdaddy@bodsch
Betreue gerade ein IT-Serviceunternehmen, das Server für Kunden managt.
Deren eigene Server (08/15, also AD, Fileserver, ...) müssen von Externen betreut werden weil sie es selber nicht mehr können (entsprechend nie gepatcht, nie in Logs geschaut, ...)
Und sowas betreut die kritischen Server anderer.
Simon Kowalewski@bodsch Die ganze Containerei ist schuld. Kubernetes halte ich für den größten Fehler alle Zeiten in der IT.
dogfood@bodsch Schlechte Nachrichten: sieht auch im Frontend nicht anders aus, weil die coolen Kids gleich auf React und was sonst so grad der Hype de Jour ist, aufspringen, die Basics & Fundamente nicht lernen und in Themen die Tauchtiefe eines Nichtschwimmerbeckens nicht überschreiten.
Habe in einem Großprojekt jetzt zwei Frontendler gehabt, die die Mechanik des LABEL-HTML-Elementes an Formularelementen nicht kannten.
Moritz@bodsch Ich verstehe was du sagen willst, und würde dir eigentlich gerne zustimmen. Aber mit so viel Überheblichkeit, Pauschalisierungen, Rechtschreibfehlern und schrecklicher Interpunktion (Insofern hast du Recht: Die IT verdummt zusehends!) möchte ich in so einen Rant nicht einstimmen. Viel Erfolg in der einsamen Welt des Nerd-Elitarismus.
scops@bodsch kommt mir sooooo bekannt vor - und ist absolut genau so in der software entwicklung und nicht nur in der systemadministration. das implodiert alles über kurz oder lang mächtig gewaltig.
capo@bodsch Ich gebe dir in fast allen punkten recht.
Das Problem ist Haus gemacht. Jede Firma sucht nach Spezialisten. Da diese (anscheinend) besser zu finden sind.
Dies sind dann extrem gut auf ihrem Bereich. Aber was rechts oder links abgeht wissen sie nicht. Was meistens mit Security und hart definierten Verantwortlichkeiten zu tun hat.
Das Problem ist Haus gemacht. Jede Firma sucht nach Spezialisten. Da diese (anscheinend) besser zu finden sind.
Dies sind dann extrem gut auf ihrem Bereich. Aber was rechts oder links abgeht wissen sie nicht. Was meistens mit Security und hart definierten Verantwortlichkeiten zu tun hat.
tuxflo@bodsch Hmmm Docker bzw. Container Rants scheinen aktuell irgendwie in meiner Timeline in Mode zu kommen. Mir kommt bei solchen Posts immer der Gedanke, dass die Leute einfach keinen Bock auf DevOps haben und nach dem Motto "früher war alles besser" bleiben wollen. Insbesondere der Fall "ich konfiguriere meine Services noch auf dem Host selbst" ist für mich aus Sicht des Busfaktors und mangelnder Doku eine Katastrophe. Dann doch lieber ein Containerfile oder eine docker-compose.yml.
@tuxflo
Container sind ja nur eine Randerscheinung und auch nur ein Nebenschauplatz für den Rant.
Für mich geht es halt viel tiefer.
Mir bringt es halt keinen Sinn zusätzlich zu einem sauber installiert und konfigurierten nginx einen zusätzlichen Service namens docker ans Bein zu binden.
Mit der Gefahr, das beim Updates dieses Services alle Container stumpf und letztendlich ohne Not neu gestartet werden.
Von der Qualität der Container abgesehen.
Container sind ja nur eine Randerscheinung und auch nur ein Nebenschauplatz für den Rant.
Für mich geht es halt viel tiefer.
Mir bringt es halt keinen Sinn zusätzlich zu einem sauber installiert und konfigurierten nginx einen zusätzlichen Service namens docker ans Bein zu binden.
Mit der Gefahr, das beim Updates dieses Services alle Container stumpf und letztendlich ohne Not neu gestartet werden.
Von der Qualität der Container abgesehen.
@bodsch "sauber installiert und konfiguriert" heißt für mich in der Regel "das hat mal jemand gemacht und wenn der außer Haus ist hat keiner mehr eine Ahnung wie es gemacht wurde oder warum". Und für Container ohne Docker Service bzw. Daemon kann man Podman oder Rootless Docker verwenden. Aber das muss man halt wissen. Das ist dann genau die "Intelligenz" die bemängelt wird. Die ist nämlich keineswegs weg, sondern nur in andere Teilbereiche verschoben.
@bodsch und ja, es gibt in dem Bereich viele schwarze Schafe und sehr, sehr viele Container werden nicht anständig gewartet, da bin ich komplett bei dir. Aber das Problem hat zunächst mal nichts mit der Technologie an sich zu tun, sondern damit wie sie verwendet wird. Und es ist nicht so, dass Docker oder Podman es einem übermäßig schwer machen seine Container up to date zu halten. Und es gibt unzählige Tools die einem dabei sogar unter die Arme greifen.
@tuxflo
Genau .. ein "unzählige Tools, die einem dabei sogar unter die Arme greifen."
Wir erschlagen die Komplexität mit noch mehr Tools, oder Komplexität ... 😜
Genau .. ein "unzählige Tools, die einem dabei sogar unter die Arme greifen."
Wir erschlagen die Komplexität mit noch mehr Tools, oder Komplexität ... 😜
@tuxflo "Sauber installiert und konfiguriert" heisst für mich aus der Automatisierung.
Aber die hilft mir nicht, wenn ich ein Problem habe.
Weil jemand etwas falsches ins Git gepushed hat.
Das Wissen, einen Fehler zu analysieren und zu beheben geht verloren, nicht einen Container auszurollen!
Und dieses Wissen wird nicht verschoben, es wird gar nicht mehr aufgebaut!
Das ist eigentlich die Quintessenz aus meinem Rant.
Nicht das Docker per se Scheiße ist.
Aber die hilft mir nicht, wenn ich ein Problem habe.
Weil jemand etwas falsches ins Git gepushed hat.
Das Wissen, einen Fehler zu analysieren und zu beheben geht verloren, nicht einen Container auszurollen!
Und dieses Wissen wird nicht verschoben, es wird gar nicht mehr aufgebaut!
Das ist eigentlich die Quintessenz aus meinem Rant.
Nicht das Docker per se Scheiße ist.
@bodsch Naja das mit den weiteren Tools ist nun mal der Lauf der Dinge, wenn man nicht immer wieder bei Null anfangen will. Ansible/Chef/Puppet und Co sind ja auch nur wieder ein Tool um die Komplexität "Systeme zu automatisieren" hinzubekommen.
Und nein, ich denke es ist nur wichtig, dass man sich zu helfen weiß. Komplett unabhängig davon, in welchem Bereich Wissen aufgebaut wird.
Und nein, ich denke es ist nur wichtig, dass man sich zu helfen weiß. Komplett unabhängig davon, in welchem Bereich Wissen aufgebaut wird.
@bodsch Ich hatte neulich sogar ein Paradebeispiel für deinen Rant. Wir mussten FTP Dinge testen. Also habe ich mir flott einen ProFTPD aufgesetzt, konfiguriert und getestet (old school). Der Kollege wusste allerdings nicht wie man sowas macht und hat halt einen Container genommen.
Das Ziel war aber in beiden Fällen erreicht: jeder von uns hatte einen FTP mit dem er testen konnte und darauf wollte ich hinaus: nur die wenigsten profitieren davon zu wissen wie man einen proftpd konfiguriert.
Das Ziel war aber in beiden Fällen erreicht: jeder von uns hatte einen FTP mit dem er testen konnte und darauf wollte ich hinaus: nur die wenigsten profitieren davon zu wissen wie man einen proftpd konfiguriert.
@bodsch Solange man das Hauptproblem "ich will XY lösen" in annehmbarer Zeit hinbekommt ist doch der Weg recht oft egal.
Und ich persönlich schaue mir 10 mal lieber ein Dockerfile an um zu sehen, was darin vorgeht als ein 100 Zeilen langes Ansible Playbook. (mal abgesehen davon, dass man mit Docker auch gleich noch Probleme wie konfliktbehaftete Abhängigkeiten oder Netzwerksegmentierung lösen kann)
Und ich persönlich schaue mir 10 mal lieber ein Dockerfile an um zu sehen, was darin vorgeht als ein 100 Zeilen langes Ansible Playbook. (mal abgesehen davon, dass man mit Docker auch gleich noch Probleme wie konfliktbehaftete Abhängigkeiten oder Netzwerksegmentierung lösen kann)