Die Betrachtung greift für meinen Geschmack zu kurz
Ja. Wenn man sie isoliert betrachtet, dann schon.
Aber meine Aussage war ja: Komplexität reduzieren
Wenn durch Abstraktion etc. Komplexität hinzukommt, dann diese möglichst klein halten.
Auf den Container übertragen:
Du hast eine Anwendung X. Tust jetzt noch Containerkomplexität hinzu. Die Anwendung kann dadurch nicht mehr als vorher. Das einzige was Du gewinnst ist, das Du Anwendung X besser in Deine beschissene Umgebung integriert kriegst. Anstatt die beschissene Umgebung zu repaireren, machst Du aber Container.
Es gibt natürlich Szenarien wo das Sinn macht. Und Du kannst natürlich auch (völlig berechtigterweise) sagen: Ja. Die Umgebung und Systeme sind beschissen, aber andere haben wir nicht und ich muss mit dem Leben was ich in der Praxis vorfinde und kann nicht alles gerade biegen.
Das ist auch vollkommen verständlich. Ändert aber nichts daran, das diese Lösung dann trotzdem suboptimal ist. Sie kann für den Augenblick pragmatisch sein. Aber sie ist eben nicht gut.
Man muss ja auch ganz klar sagen, das vieles an Konzepten welche wir heute haben aus der Computerhistorie stammt. Zu Anfang ging es ja weniger darum etwas besonders sicher oder etwas besonders fehlerfrei zu haben, sondern den Kram überhaupt zum laufen zu kriegen. Früher ja dann oft auch noch unter dem Druck arg begrenzter Hardwareressourcen. Und vieles aus der Zeit überdauert halt bis heute.
Container machen Automation deutlich leichter (siehe unten).
Nein. Tun sie nicht. Den Eindruck hast Du nur. Ja. Sie machen den umgang mit beschissener Software einfacher. Und es gibt so viele beeschissene Software. Darum sind sie so erfolgreich.
Bessere wäre es natürlich gute Software zu haben bzw. die beschissene Software reparieren zu können. In der Praxis ist das aber nicht immer so einfach. Da hat man oftmals weder die Möglichkeit (Quelltext) und/oder nicht die Ressourcen.
Kurzfristig können da natürlich Container helfen. Auf lange Sicht führt das nur zu mehr Komplexität (bei schlechter Komplexität-Nutzung-Ratio) und damit zu Problemen.
Anders gesagt: Du hast jetzt Probleme die Du billig lösen willst und verschiebst diese Lösung aber in die Zukunft.
Und es ist ja auch nicht so, das ein solches Vorgehen nicht verständlich ist. Niemand weiß halt, was die Zukunft bringt. Und es bringt mir auch wenig wenn ich jetzt schon richtig Zeit in eine Lösung investiere, aber die mir dann halt fehlt um z.B. mein Produkt auf den Markt zu bringen und Einnahmen zu generieren.
Mir ist schon klar, das all dies nicht so einfach ist und es auch Nebenbedingungen gibt, denen man unterworfen ist. Das ändert aber nichts daran, das vieles aus technischer Sicht eine schlechte Lösung ist und das, wenn ich nicht gut aufpasse, mir irgendwann auf die Füße fallen kann. Und auch unweigerlich wird. Deshalb sollte man den Aspekt nicht wegignorieren.
Willkommen in der Welt der menschlichen Natur. Abseits der Software läuft es ganz ähnlich, wenn ich meinen Freunden abseits der IT glauben schenken darf.
Ja. Aber das macht es ja nicht besser.
Das Phänomen ist mir bestens vertraut - leider. Die Menschen wirst du nicht ändern, du kannst sie höchstens behutsam mit der Geschwindigkeit eines Gletschers in eine Richtung bewegen.
Ich denke, bei vielen Sachen stimmen wir durchaus und grundsätzlich überein. Sowohl was solche Sachen angeht als auch die technische Seite.
Bei Reibungsflächen wie Container mag auch eine Rolle spielen, das wir uns die Sache aus unterschiedlichen Perspektiven anschauen.
Um noch mal bei dem Container-Beispiel zu bleiben: Wenn man sich das hier und jetzt anschaut, sicherlich ne Lösung.
In der langfristigen Perspektive ein weiterer Baustein auf dem ohnehin schon hohen Technologiestapel. Das ist der Aspekt, den ich so eher betrachte.
Allein der Hardware-Bedarf und die Turnaround-Zeiten sind mit VMs deutlich größer als mit Containern
Ich wollte Container auch - um Gottes willen - nicht durch VMs ersetzt haben. Da ist das Komplexitätsproblem ja noch schlimmer.
An der Stelle sei nochmals gesagt das ich Container keinesfalls kritisch sehe. Sondern als durchaus nützliche Technologie. Ich sehe halt nur das Problem, das sie 1.überall eingesetzt wird und auch da wo es nicht nötig wäre
2.sie versucht lediglich vorhandene Probleme zu übertünchen ohne sie wirklich zu lösen
Deswegen habe ich mich ganz auf die Technik konzentriert und Marketing ausgeklammert, um dem sonst hier üblichen Argument vorzubeugen, die größere Verbreitung von Linux denn FreeBSD in Unternehmen würde ausschließlich an Faktoren wie Marketing liegen.
Ok. Und nur um Missverständnissen vorzubeugen:
Mir gings jetzt nicht darum die Argumentationskette aufzuziehen, das man Container nicht braucht und deshalb deren fehlen in FreeBSD halb so wild ist.
Ich wollte lediglich meine Kritik an solchen Technologien ansich anbringen bzw. genauer gesagt: Dessen oftmals nicht ganz durchdachter Einsatz.
Es erhöht die Produktivität. Die Fürsprecher für DevOps kommen viel aus der Entwickler-Ecke, weil die keinen Bock mehr haben, von einer Betriebsabteilung abhängig zu sein, die keine API hat.
Das ist aber eher eine Sache der Organisation. Das Problem ist ja, Devs und Ops haben ja teilweise auch gegenläufige Perspektiven auf die Sache, die aus ihrer Sicht auch berechtigt sind. Wenn die Ops weg fallen und die Devs deshalb alleine das machen können, was sie für richtig halten, dann muss das das Ergebnis nicht unbedingt verbessern. :-)
Aus dem Grund haben wir ja auch unabhängige Tester und lassen nicht (nur) die Devs selber testen. Die finden die Devs auch nervig. Und die hätten sicher nix gegen, wenn die wegrationalisiert würden.
Ich glaube nicht, dass es überall so ist - aber es wird für meinen Eindruck anteilig besser. Wir bauen heute natürlich wesentlich mehr Software als früher, die wesentlich häufiger am Netzwerk bzw. Internet hängt
Schwer zu sagen.
Die Anzahl echter Angriffe auf Software finde ich auch noch relativ moderat. Woran das liegt, darüber kann man natürlich spekulieren.
Meine Theorie ist ja, solange es reicht Leuten Phishing-Mails mit Fragen nach Passwörtern oder Anhängen a-la jolie_naked.jpg.exe funktionieren, macht sich niemand die Mühe Sicherheitslücken auszunutzen. Kann man natürlich auch anders interpretieren. Das sozusagen die hohe Anzahl solcher Mails belegt, das die Software sicher ist und man deshalb über sowas gehen muss. :-)
Aber wir wissen halt auch vieles nicht. Man weiß nicht gesichert, wieviel Angriffe über welche Wege geschehen und welche davon erfolgreich sind und welche nicht. Und selbst wenn was rauskommt, dann steht dahinter eine vermutlich sehr viel größere Dunkelziffer.
Themen wie Testabdeckung oder statische Code-Analyse waren vor 1015 Jahren Randerscheinungen; heute sind sie auf breiter(er) Front im Einsatz.
Also klar. Es hat sich etwas gebessert. Nur wächst halt die Komplexität mit die all die Vorteile die man theoretisch hätte wieder auffrisst.
Wie schon gesagt. Auf irgendwelche Bugs in Software trifft man dauernd. Das war früher weniger. Gut. Vielleicht guckt man auf die Vergangenheit etwas verklärt und hat das deshalb nicht mehr so im Gedächtnis. Aber selbst bei einem genauso viel hätte ich ja nicht wirklich was gewonnen.
Aber wie gesagt. Anhand solcher subjektiven Sichtweisen zu diskutieren ist schwierig. Und objektive Daten dazu haben wir nicht.
Ich finde aber schon, dass sie auch ein wenig aus dem Ruder läuft. Denn die Komplexität und Fehlermöglichkeiten von Programmiersprachen und die Abläufe diverser Entwicklungen beziehen sich nicht unbedingt auf FreeBSD.
Genau. Ist über den Tellerrand hinaus geblickt. :-)
Am Beispiel Docker wird erklärt, dass FreeBSD eine Entwicklung verschläft und genau an diesem Beispiel wird auch hinterfragt, ob das nicht sinnvoll sein kann und Docker (wie gesagt, als hervorstechendes Beispiel) eigentlich auch nicht wirklich gebraucht wird.
Nein. So wollte ich das nicht verstanden wissen.
Ich hoffe, dies wurde mit diesem Posting klarer.
Das kann eine Motivation sein, es gibt aber auch andere.
Gut. Apple hat natürlich eher gehofft, das sie davon profitieren. In der Weise, das sich ein paar Entwickler finden die da mitmachen und Apple das dann in ihr MacOS einbauen können. :-)
Keiner hat CUPS geforked oder ne Alternative gebaut. Kann also nicht so schlimm gewesen sein, oder?
Ich weiß nicht mehr, was das Problem war und wie es gelöst wurde. Ich habe lediglich darauf hingewiesen, das es eines gab oder gibt.
"Passabel" reicht leider nicht, um gegen die Platzhirsche Windows und Mac anzukommen. FreeBSD müsste hier ja schon enorme Vorteile bieten, allein schon um gegen den Faktor Trägheit anzukommen.
Gegen Windows spricht eigentlich hauptsächlich die Schadsoftwareproblematik. Mit Windows will man eigentlich nicht ins Internet. :-)
. Aber ich würde erst das Hauptproblem mit Linuxanwendungen lösen.