Von Verfluchtnochmal-05995bd7b am Do, 2. August 2018 um 18:15 #
Bla - Container laufen üblicherweise so gut wie pberall INNERHALB von virtuellen Maschinen und ersetzen sie nicht und warum du prinzipiell VM mit VMware gleich setzt verstehst wohl auch nur du
Deine Messages würden nachhaltiger rüberkommen, wenn du nicht so herumpöbeln würdest.
Ich verstehe zwar nicht viel von dem Zeugs und habe beruflich schon gar nicht damit zu tun, aber der Titel der Meldung ("Container knabbern am Markt für virtuelle Maschinen") sagt ja bereits das gleiche wie du: VM sind in dem Marktsegment dominant.
Und ein Artikel wird nicht dadurch blöde, dass er einen Konkurrenten der etablierten Technik zitiert. Die meisten Leser werden so viel Lesekompetenz besitzen, dass sie das nicht als neutrale Aussage einschätzen.
Von Verfluchtnochmal-05995bd7b am Do, 2. August 2018 um 18:28 #
Anhand von "So gelten weitere Fragen auch den Kosten, die VMware-Lizenzen verursachen. Sie liegen bei 55% der Teilnehmer über 100.000 USD im Jahr" kannst du dir mal ausrechnen wer da eigentlich gefragt wurde
Keine Ahnung was man veranstalten muss um da hin zu kommen, auf alle Fälle verdammt gross sein, und selbst da setzen 60% ihre Container weiterhin in VMs auf
Wenn du mit 3 Hosts auskommst (Und da kannst du bei 2 Sockets pro Host einiges drauf laufen lassen) zahlst du für die Support-verlängerung keine 2000 *alle 3 Jahre* (Essentials Plus - vCenter, 3 Hosts, 6 CPU-Lizenzen, unlimited Cores) also hör auf von Dingen zu reden von denen du nichts verstehst
Warum setzt man Container AUF eine bestehende Virtualisierungsinfrastruktur?
Weil man damit Hochverfügbarkeit und Redundanz gleich miterschlägt und sich drauf verlassen kann dass die Container bei einem Hostauffall weiterlaufen ohne das wiederholt zu implementieren - Viel SPass auf Bare-Metal und viel Spass alles bei 0 neu aufzubauen und zu testen versus ein paar VMs durch weitere Konsolidierung in selbigen zu ersetzen
Aber niemand der noch ganz dicht ist erssetzt die komplette Infrastruktur mit Containern weil es keine probleme löst sondern sie nur verschiebt
Und aj, auch dort wo du 100k im jahr für VMware bezahlst ist das nur Peanuts sonst bräuchtest du keine Enterprise-Lizenzen auf hunderten pyhsischen Blechen, die laufen dort nämlich nicht zum Selbstzweck sondenr bringen die Kohle vielfach wieder rein
Dafür, dass du so rum posaunst und andere für dumm verkaufen willst, hast du dich erstaunlich wenig mit der Materie auseinandergesetzt.
Kubernetes macht genau das, was du als Pluspunkt für VMs ansetzt, auf Bare Metal. Performancetests zeigen, dass Leistung (insb. Latenzen) und Ressourcenverbrauch dabei deutlich verbessert werden. Wenn das Nutzungsszenario Container vorsieht, ist das durchaus eine Wahl, die man ins Auge fassen kann.
Und selbst wenn man es auf VMs betreiben will. Die Kosten sind dabei selbst bei VMware Essentials noch höher und Features geringer als bei manch anderer Lösung für ein unbeschränktes Komplettpaket. Essentials Plus ist ja doch sehr beschränkt.
Ist ja schön, dass du noch immer was verdienst, obwohl du Geld zum Fenster raus schmeißt. Andere wollen vielleicht einfach die paar für dich unbedeutende Kröten nochmals mehr verdienen.
Von Verfluchtnochmal-05995bd7b am Fr, 3. August 2018 um 15:40 #
Blöderweise ist aber das Isolationslevel von Containern ein wesentlich schlechteres als von virtuellen Maschinen womit du in der Praxis ohnehin beides brauchst und Virtualisierung nicht einfach komplett durch Container ersetzen kannst (Es sei denn du willst einen ganz grossen Fehler machen)
Also wirst du VMs definitiv nicht komplett los
Du musst also einigermassen blöde sein wenn du HA auf 2 Layern umsetzt statt deine Contrainer auf einer bereits vorhandenen virtualisierten Infrastruktur aufzusetzen
Wenn es um Server geht hat das Blech genau eine Aufgabe: Den Hypervisor booten, ob der jetzt VMware, Proxmox oder RHEV ist tut da erstmal wenig zur Sache
Erstens stimmt das so nicht, genau darum geht es ja gerade auch bei Containern: Isolation. Es gibt einen Unterschied zwischen Container und VMs, ja. Aus der ungeschützten chroot-Zeit sind wir aber lange raus. Die sind teils so gut isoliert, dass man in der Praxis auch Container an völlig unterschiedliche Kunden (somit sehr hohem Bedarf an Isolation!) vermieten kann. Einen Fehler macht man da noch lange nicht. Ganz im Gegenteil. Container sind sogar ein Mittel zu _größerer_ Isolation. Indem man Services isolieren kann (geringerer Ressourcenoverhead halt), die sonst innerhalb eines Userlands (einer VM) laufen.
Und zweitens benötigt man das oftmals überhaupt gar nicht.
Du hast nur deinen eigenen, offensichtlich eher beschränkten Usecase im Blick und sprichst jedem Dummheit zu, der diesen nicht mit dir teilt.
Teils gibt es Bedarf an tausenden isolierten Microservices, die locker mehrere ganze Bleche für sich beanspruchen können. Da ist es ein deutlicher Overkill und Ressourcenverschwendung, ganze Cluster aufzusetzen, auf denen jeweils pro Blech nur eine VM läuft. Zumal das sehr problematisch ist, denn bei Ausfall eines Nodes muss die VM ja im Ganzen von einem anderen Node übernommen werden. Doppelte Last? Nicht drin. Also müssen doch mehrere VMs pro Blech laufen, so dass man diese bei Ausfall gleichmäßiger verteilen kann. Und schon nimmt der Ressourcenoverhead weiter zu. Die Latenz geht in den Keller. Overhead, der nicht nötig ist.
Verteilt man im HA-Failover-Fall die einzelnen Container sowieso selber, kann man wiederum auf die HA-VM verzichten. Der Container-Host läuft am nackten Blech. Ein viel einfacherer und gleichmäßigerer Lastausgleich bei geringerem Ressourcenoverhead.
Kein Wunder dass selbst einfache Systeme für kleinere Betreiber (wie Proxmox) mittlerweile selber direkt Container verwalten können. Das Prinzip ist da zwar anders als bei Docker, der Container ein vollständiger Host und kein Microservice, eignet sich dennoch durch den deutlich geringeren Ressourcenoverhead für Aufgaben (z.B. für eine Verteilung vieler kleiner Services), für die VMs einfach Overkill sind. Größere Systeme ala OpenStack, Amazon, Azure, etc. gehen daher keinen anderen Weg. Da kriegt man für seine Microservices sicher _keine_ eigene VM und gut isoliert sind die allemal.
Sicher kann es durchaus sinnvoll sein, seine Container nur in einer VM laufen zu lassen. Aber nicht ausschließlich.
Von Verfluchtnochmal_5987109 am Fr, 3. August 2018 um 21:02 #
Bla - 99 Prozent eines containers kann ich mit einem fucking systemd service abbilden weil so gut wie alle relevanten Optionen recht simpel exposed und mit template units umgesetzt werden können
Ein wirklich gutes systemd unit hat die gleiche Isolierung eines containers ohne dessen Nachteile in der Verwaltung
NEIN du hast auf einem blech nicht nur eine VM weil das völlig schwachsinnig wäre, du hast auf diversen blechen einen Haufen an VM's die container bzw isolierte services hosten aber du entkoppelst wenn du kein Depp bist Hardware/Failover komplett von Anwendungen und ein container ist auch nur eine Anwendung
Weil sooo berauschend sind jetzt die Produkte vom VMWare auch nicht!
Bla - Container laufen üblicherweise so gut wie pberall INNERHALB von virtuellen Maschinen und ersetzen sie nicht und warum du prinzipiell VM mit VMware gleich setzt verstehst wohl auch nur du
Ich habe auch verstanden, warum der OP hier VMWare nennt. Siehe Artikeltext.
Wie du rausliest, dass er es mit VM gleichsetzt, verstehe ich nur nicht?!
Weil er genauso wie der blöde Artikel nichts verstanden hat
Da wurde jemand gefragt der Container vertreibt und dann über die Antworten wundern?
Deine Messages würden nachhaltiger rüberkommen, wenn du nicht so herumpöbeln würdest.
Ich verstehe zwar nicht viel von dem Zeugs und habe beruflich schon gar nicht damit zu tun, aber der Titel der Meldung ("Container knabbern am Markt für virtuelle Maschinen") sagt ja bereits das gleiche wie du: VM sind in dem Marktsegment dominant.
Und ein Artikel wird nicht dadurch blöde, dass er einen Konkurrenten der etablierten Technik zitiert. Die meisten Leser werden so viel Lesekompetenz besitzen, dass sie das nicht als neutrale Aussage einschätzen.
Anhand von "So gelten weitere Fragen auch den Kosten, die VMware-Lizenzen verursachen. Sie liegen bei 55% der Teilnehmer über 100.000 USD im Jahr" kannst du dir mal ausrechnen wer da eigentlich gefragt wurde
Keine Ahnung was man veranstalten muss um da hin zu kommen, auf alle Fälle verdammt gross sein, und selbst da setzen 60% ihre Container weiterhin in VMs auf
Wenn du mit 3 Hosts auskommst (Und da kannst du bei 2 Sockets pro Host einiges drauf laufen lassen) zahlst du für die Support-verlängerung keine 2000 *alle 3 Jahre* (Essentials Plus - vCenter, 3 Hosts, 6 CPU-Lizenzen, unlimited Cores) also hör auf von Dingen zu reden von denen du nichts verstehst
Warum setzt man Container AUF eine bestehende Virtualisierungsinfrastruktur?
Weil man damit Hochverfügbarkeit und Redundanz gleich miterschlägt und sich drauf verlassen kann dass die Container bei einem Hostauffall weiterlaufen ohne das wiederholt zu implementieren - Viel SPass auf Bare-Metal und viel Spass alles bei 0 neu aufzubauen und zu testen versus ein paar VMs durch weitere Konsolidierung in selbigen zu ersetzen
Aber niemand der noch ganz dicht ist erssetzt die komplette Infrastruktur mit Containern weil es keine probleme löst sondern sie nur verschiebt
Und aj, auch dort wo du 100k im jahr für VMware bezahlst ist das nur Peanuts sonst bräuchtest du keine Enterprise-Lizenzen auf hunderten pyhsischen Blechen, die laufen dort nämlich nicht zum Selbstzweck sondenr bringen die Kohle vielfach wieder rein
Dafür, dass du so rum posaunst und andere für dumm verkaufen willst, hast du dich erstaunlich wenig mit der Materie auseinandergesetzt.
Kubernetes macht genau das, was du als Pluspunkt für VMs ansetzt, auf Bare Metal. Performancetests zeigen, dass Leistung (insb. Latenzen) und Ressourcenverbrauch dabei deutlich verbessert werden. Wenn das Nutzungsszenario Container vorsieht, ist das durchaus eine Wahl, die man ins Auge fassen kann.
Und selbst wenn man es auf VMs betreiben will. Die Kosten sind dabei selbst bei VMware Essentials noch höher und Features geringer als bei manch anderer Lösung für ein unbeschränktes Komplettpaket. Essentials Plus ist ja doch sehr beschränkt.
Ist ja schön, dass du noch immer was verdienst, obwohl du Geld zum Fenster raus schmeißt. Andere wollen vielleicht einfach die paar für dich unbedeutende Kröten nochmals mehr verdienen.
Blöderweise ist aber das Isolationslevel von Containern ein wesentlich schlechteres als von virtuellen Maschinen womit du in der Praxis ohnehin beides brauchst und Virtualisierung nicht einfach komplett durch Container ersetzen kannst (Es sei denn du willst einen ganz grossen Fehler machen)
Also wirst du VMs definitiv nicht komplett los
Du musst also einigermassen blöde sein wenn du HA auf 2 Layern umsetzt statt deine Contrainer auf einer bereits vorhandenen virtualisierten Infrastruktur aufzusetzen
Wenn es um Server geht hat das Blech genau eine Aufgabe: Den Hypervisor booten, ob der jetzt VMware, Proxmox oder RHEV ist tut da erstmal wenig zur Sache
Erstens stimmt das so nicht, genau darum geht es ja gerade auch bei Containern: Isolation. Es gibt einen Unterschied zwischen Container und VMs, ja. Aus der ungeschützten chroot-Zeit sind wir aber lange raus. Die sind teils so gut isoliert, dass man in der Praxis auch Container an völlig unterschiedliche Kunden (somit sehr hohem Bedarf an Isolation!) vermieten kann. Einen Fehler macht man da noch lange nicht. Ganz im Gegenteil. Container sind sogar ein Mittel zu _größerer_ Isolation. Indem man Services isolieren kann (geringerer Ressourcenoverhead halt), die sonst innerhalb eines Userlands (einer VM) laufen.
Und zweitens benötigt man das oftmals überhaupt gar nicht.
Du hast nur deinen eigenen, offensichtlich eher beschränkten Usecase im Blick und sprichst jedem Dummheit zu, der diesen nicht mit dir teilt.
Teils gibt es Bedarf an tausenden isolierten Microservices, die locker mehrere ganze Bleche für sich beanspruchen können. Da ist es ein deutlicher Overkill und Ressourcenverschwendung, ganze Cluster aufzusetzen, auf denen jeweils pro Blech nur eine VM läuft. Zumal das sehr problematisch ist, denn bei Ausfall eines Nodes muss die VM ja im Ganzen von einem anderen Node übernommen werden. Doppelte Last? Nicht drin. Also müssen doch mehrere VMs pro Blech laufen, so dass man diese bei Ausfall gleichmäßiger verteilen kann. Und schon nimmt der Ressourcenoverhead weiter zu. Die Latenz geht in den Keller. Overhead, der nicht nötig ist.
Verteilt man im HA-Failover-Fall die einzelnen Container sowieso selber, kann man wiederum auf die HA-VM verzichten. Der Container-Host läuft am nackten Blech. Ein viel einfacherer und gleichmäßigerer Lastausgleich bei geringerem Ressourcenoverhead.
Kein Wunder dass selbst einfache Systeme für kleinere Betreiber (wie Proxmox) mittlerweile selber direkt Container verwalten können. Das Prinzip ist da zwar anders als bei Docker, der Container ein vollständiger Host und kein Microservice, eignet sich dennoch durch den deutlich geringeren Ressourcenoverhead für Aufgaben (z.B. für eine Verteilung vieler kleiner Services), für die VMs einfach Overkill sind. Größere Systeme ala OpenStack, Amazon, Azure, etc. gehen daher keinen anderen Weg. Da kriegt man für seine Microservices sicher _keine_ eigene VM und gut isoliert sind die allemal.
Sicher kann es durchaus sinnvoll sein, seine Container nur in einer VM laufen zu lassen. Aber nicht ausschließlich.
Bla - 99 Prozent eines containers kann ich mit einem fucking systemd service abbilden weil so gut wie alle relevanten Optionen recht simpel exposed und mit template units umgesetzt werden können
Ein wirklich gutes systemd unit hat die gleiche Isolierung eines containers ohne dessen Nachteile in der Verwaltung
NEIN du hast auf einem blech nicht nur eine VM weil das völlig schwachsinnig wäre, du hast auf diversen blechen einen Haufen an VM's die container bzw isolierte services hosten aber du entkoppelst wenn du kein Depp bist Hardware/Failover komplett von Anwendungen und ein container ist auch nur eine Anwendung