Dies sind nicht die Container, nach denen Sie suchen



<div _ngcontent-c14 = "" innerhtml = "

In einem vorherigen PostIch habe argumentiert, dass im Fall von Kubernetes der Hype der tatsächlichen Einführung voraus sein könnte. Die Antworten auf diesen Artikel reichten von grundlegenden Fragen zu Containern bis hin zu sehr festen Ansichten, dass viele Menschen bereits eine Infrastruktur mit mehreren Clustern und mehreren Cloud-Containern betreiben. Aus letzterer Sicht weiß ich aus Erfahrung, dass kleinere, agilere Unternehmen dazu neigen, die Komplexität hinter den langsameren Reaktionen großer Unternehmen auf Veränderungen zu unterschätzen (Ian Miell leistet einen hervorragenden Beitrag zum Abbau der Langsamkeit von Unternehmen in New York) dieser blog post). In diesem Artikel versuche ich drei Dinge zu tun:

  • Versuchen Sie, einige grundlegende Definitionen für die Nicht-Technikfreaks zu verschärfen, die sich immer noch fragen, worum es bei dem Aufruhr geht
  • Erwähnen Sie das häufigste Attribut Nummer eins, das ich bei Unternehmen gesehen habe, die mit Containern Erfolg haben
  • Erklären Sie, warum der Umstieg auf Container nur die Spitze des Eisbergs Ihrer IT-Probleme ist

"Sieh es aus dem Fenster"Foto von Robert Alves de Jesus auf Unsplash

Läuft meine monolithische App in einem Container weiter

VMware
Cloud-native?

Tut mir leid zu sagen, aber es hängt davon ab. Denken Sie daran, dass ein Container nur ein Softwarepaket ist, das in einer Infrastruktur ausgeführt werden kann, und dass es (mindestens) zwei Arten von Containern gibt.

Systemcontainer gibt es seit den Tagen von LXC (2008) oder den Tagen von Solaris Zones davor schon länger. Dies sind vereinfacht gesagt kleine und effiziente Einheiten, die sich wie virtuelle Maschinen verhalten. Sie können mehrere ausführbare Anwendungen unterstützen und bieten Isolation sowie andere Funktionen, mit denen sich Systemadministratoren sicher fühlen können, wie beispielsweise die einfache Verwaltbarkeit. Dies ist ideal für traditionelle Apps, die Sie in Container umwandeln möchten, ohne Ihre IT-Praktiken vollständig zu revolutionieren. Der Vorteil ist einfach: Erhöhung der Anwendungsdichte pro Server um mehr als das Zehnfache gegenüber einer virtuellen Maschine.

Anwendungscontainer müssen nur eine einzige Anwendung ausführen. Dies ist die Welt des Docker-Bildformats (nicht dasselbe wie Docker Engine, Docker Swarm oder Docker Inc.) und

OCI
und worauf sich die meisten Menschen beziehen, wenn sie das Wort „Container“ erwähnen. Aus IT-Sicht bietet dies den Vorteil, dass Anwendungscontainer, die eine Microservices-App ausführen, das volle Potenzial von Cloud-Native zum Leben erwecken: hohes Liefertempo, nahezu unendliche Skalierbarkeit und verbesserte Ausfallsicherheit. Diese dramatischen Ergebnisse erfordern einen bedeutenden Kultur- und Technologiewechsel, den ich später ausführlich erwähnen werde.

Container sind nur Pakete und werden im Großen und Ganzen tun, was ihnen gesagt wird; Microservices ist ein architektonischer Ansatz zum Schreiben von Softwareanwendungen. Cloud-native ist eine Methode zur Bereitstellung dieser Anwendungen. Um die oben genannte Frage zu beantworten: Das Entfernen vorhandener Ressourcen und das Ignorieren von Geschäftsergebnissen bei der Verfolgung eines Ideals ist wahrscheinlich eine schlechte Praxis. Wenn Sie also eine VMware-Umgebung haben, sollten Sie dies tun um zu bleiben, dann ist das wahrscheinlich vorerst Cloud-native genug (die Übernahme von Heptio durch VMware ist in diesem Sinne für den zukünftigen Anwendungsfall interessant). Das Fazit ist, dass das Aufhängen des einfachsten Elements (Container), das auf dieser Liste zu finden ist, ein häufiger Fehler ist.

Thors Hammer existiert in der IT nicht

Vor kurzem traf ich mich mit einem Cloud-Chef eines großen britischen Finanzdienstleistungsunternehmens, das mir erzählte, dass der bisherige CIO seinen Posten aufgeben musste, nachdem er die Strategie "Direkt an Serverlos" nicht umgesetzt hatte, dh die Cloud und der Container sprunghaft umgingen revolutions, um Workloads auf dem gut genutzten privaten Rechenzentrum des Unternehmens mit serverloser Technologie zu betreiben. Dass der CIO ausscheiden musste, ist keine große Überraschung: In jeder Branche müssen wir die richtigen Werkzeuge für die richtigen Jobs einsetzen, insbesondere wenn diese Jobs komplex sind. In der Cloud bedeutet dies, dass wir in den meisten Fällen wahrscheinlich eine Kombination aus Bare-Metal-Systemen, virtuellen Maschinen, Containern und Serverless in einer beliebigen Kombination aus privater Serverfarm, privater Cloud oder öffentlicher Cloud verwenden.

Zweifellos ist das einzige, was ich als einen ersten Schritt einer erfolgreichen IT-Umstellungsreise gesehen habe, folgendes: Nicht zu versuchen, eine dramatische IT (r) -Evolution zu vereinfachen. Verstehen Sie es stattdessen unter einem ganzheitlichen Aspekt und beurteilen Sie es anhand von Unternehmensergebnissen und -zielen. Es ist gut, sich zu bemühen, aber nicht alle Unternehmen verfügen über die Ressource, Cloud-native Puristen zu sein, und es gibt auch in kleineren Schritten deutliche Vorteile, z. B. mehr Zeit für die Analyse der Auswirkungen der Technologie oder ein besseres Risikomanagement. (Dieser Beitrag Von der Containerfirma Cloud 66 kann man die kurzfristige Effizienz und die langfristigen Einsichten durch das Verschieben einer monolithischen App in einen Container gut beschreiben.)

Bekannte Unbekannte und unbekannte Unbekannte

Letztendlich wären wir jedoch nicht so begeistert von der Containerrevolution, wenn es nur darum geht, monolithischere Anwendungen unter Druck zu setzen. Eine Microservices-App, die in Containern ausgeführt wird, auf mehreren Substraten orchestriert ist, und das alles nach Cloud-basierten Prinzipien – das ist etwas, für das es sich lohnt zu schwitzen. Bei einer Anwendung, die schnell und zuverlässig mit weniger Betriebsmitteln skaliert, sich schnell an die Kunden- und Wettbewerbsdynamik anpasst und sich selbst heilt, zielen viele von uns darauf ab.

Auch hier sind Container nur ein Teil davon. Berücksichtigen Sie die technologischen Herausforderungen: Wie sieht es mit der Orchestrierung aus? Und netzwerk Und stateful Dienstleistungen? Und Cloud-native-bereite Pipeline-Tools?

Vielleicht noch wichtiger, betrachten wir kulturelle Herausforderungen: Was muss sich mit unseren Entwicklungspraktiken ändern? Wie finden und binden wir die richtigen Talente? Wie können wir ältere Talente neu ausbilden und Generationen überbrücken? Wie wird sich das Risiko-Gleichgewicht ändern?

Ein Beispiel: Open Source ist bereits Teil Ihrer Strategie

Es ist eine gut dokumentierte Tatsache, dass der Aufstieg von Cloud und Open Source miteinander verbunden ist, was auch einige interessante Spannungen mit sich bringt, wie ich es in meinem Kapitel untersucht habe Vorheriger ArtikelIn Containern scheint diese Synergie stärker als je zuvor zu sein. Der Juggernaut hinter Kubernetes und vielen verwandten Open-Source-Projekten ist die Cloud Native Computing Foundation (CNCF) ist Teil der Linux Foundation. In der CNCF-Charta sind die Absichten der Stiftung klar:Ziel ist es, ein Ökosystem von Open Source- und herstellerneutralen Projekten zu fördern und aufrechtzuerhalten. & nbsp; Seit der Einführung der CNCF im Jahr 2014 ist es daher immer praktikabler geworden, einen komplexen cloud-nativen Stack mit einer großen Mischung dieser Open-Source-Projekte (einige interessante Daten in der Stiftung) zu verwalten Jahresbericht). Je mehr Sie mit den Methoden der Containernativen umgehen, desto mehr Open Source verwenden Sie.

Die andere Seite dieses Bildes ist, dass Open-Source-Pakete einen erheblichen Teil der kostenlosen und proprietären Anwendungen ausmachen. Während Ihre gesamte App proprietär sein kann, kann das, was Ihr Team tatsächlich geschrieben hat, sehr klein sein. Als die Status des Open Source-Sicherheitsberichts zeigt, dass die Nutzung von Open Source eng mit der digitalen Transformation gekoppelt ist und daher zunehmend geschäftskritischer wird; Allerdings schätzen nur 17% der Betreuer ihre Sicherheitsexpertise als hoch ein, was bedeutet, dass viele dieser Pakete ein operationelles Risiko darstellen.

Ein weiterer Aspekt ist die Community: Durch die Verwendung von mehr Open Source wird die Organisation zu einem Stakeholder. Daher sollte sie mit der jeweiligen Community in Verbindung stehen, um zu sehen, wie sie einen Beitrag leisten kann und wie sie sich so schnell wie möglich mit Roadmap und Sicherheitswarnungen auseinandersetzen kann .

Nein, das enthält

Zusammenfassend lässt sich sagen, dass eine „einfache“ Entscheidung über den Beitritt zur Containerwelle den Nutzen der Organisation und den Einsatz von Open-Source-Software erheblich erhöht. Diese Software kann von großen Sponsoren unterstützt werden oder nicht, wird wahrscheinlich von Freiwilligen in einem sinnvollen Umfang gewartet werden und wird wahrscheinlich eine lebendige Community hinter sich haben – alle müssen von Benutzern engagiert werden, die auf diese Projekte angewiesen sind.

Mit anderen Worten, nicht einfach. Container sind ein kritischer Teil einer digitalen Transformation, aber nur ein Teil. Die gesamte Transformation, von der Teile in Ihren Software-Bereitstellungssystemen erscheinen werden, ohne dass Sie davon ausgehen, kann große Auswirkungen auf Ihre Anwendungen haben, wenn Sie mit der richtigen Vorgehensweise angesprochen werden Mischung aus Offenheit, Reife und Verantwortung.

& nbsp;

">

In einem früheren Beitrag habe ich argumentiert, dass der Hype im Falle von Kubernetes der tatsächlichen Einführung voraus sein könnte. Die Antworten auf diesen Artikel reichten von grundlegenden Fragen zu Containern bis hin zu sehr festen Ansichten, dass viele Menschen bereits eine Infrastruktur mit mehreren Clustern und mehreren Cloud-Containern betreiben. Aus letzterer Sicht weiß ich aus Erfahrung, dass kleinere, agilere Unternehmen dazu neigen, die Komplexität hinter den langsameren Reaktionen großer Unternehmen auf Veränderungen zu unterschätzen (Ian Miell leistet in diesem Blogpost hervorragende Arbeit, um die Langsamkeit des Unternehmens zu überwinden). In diesem Artikel versuche ich drei Dinge zu tun:

  • Versuchen Sie, einige grundlegende Definitionen für die Nicht-Technikfreaks zu verschärfen, die sich immer noch fragen, worum es bei dem Aufruhr geht
  • Erwähnen Sie das häufigste gemeinsame Attribut, das ich unter Unternehmen gesehen habe, die mit Containern Erfolg haben
  • Erklären Sie, warum der Umstieg auf Container nur die Spitze des Eisbergs Ihrer IT-Probleme ist

"Sieh es aus dem Fenster"Foto von Robert Alves de Jesus auf Unsplash

Läuft meine monolithische App in einem Container weiter

VMware
Cloud-native?

Tut mir leid zu sagen, aber es hängt davon ab. Denken Sie daran, dass ein Container nur ein Softwarepaket ist, das in einer Infrastruktur ausgeführt werden kann, und dass es (mindestens) zwei Arten von Containern gibt.

Systemcontainer gibt es seit den Tagen von LXC (2008) oder den Tagen von Solaris Zones davor schon länger. Dies sind vereinfacht gesagt kleine und effiziente Einheiten, die sich wie virtuelle Maschinen verhalten. Sie können mehrere ausführbare Anwendungen unterstützen und bieten Isolation sowie andere Funktionen, mit denen sich Systemadministratoren sicher fühlen können, wie beispielsweise die einfache Verwaltbarkeit. Dies ist ideal für traditionelle Apps, die Sie in Container umwandeln möchten, ohne Ihre IT-Praktiken vollständig zu revolutionieren. Der Vorteil ist einfach: Erhöhung der Anwendungsdichte pro Server um mehr als das Zehnfache gegenüber einer virtuellen Maschine.

Anwendungscontainer müssen nur eine einzige Anwendung ausführen. Dies ist die Welt des Docker-Bildformats (nicht dasselbe wie Docker Engine, Docker Swarm oder Docker Inc.) und

OCI
und worauf sich die meisten Menschen beziehen, wenn sie das Wort „Container“ erwähnen. Aus IT-Sicht bietet dies den Vorteil, dass Anwendungscontainer, die eine Microservices-App ausführen, das volle Potenzial von Cloud-Native zum Leben erwecken: hohes Liefertempo, nahezu unendliche Skalierbarkeit und verbesserte Ausfallsicherheit. Diese dramatischen Ergebnisse erfordern einen bedeutenden Kultur- und Technologiewechsel, den ich später ausführlich erwähnen werde.

Container sind nur Pakete und werden im Großen und Ganzen tun, was ihnen gesagt wird; Microservices ist ein architektonischer Ansatz zum Schreiben von Softwareanwendungen. Cloud-native ist eine Methode zur Bereitstellung dieser Anwendungen. Um die Frage zu beantworten: Vorhandene Ressourcen wegzuwerfen und Geschäftsergebnisse zu ignorieren, um ein Ideal zu verfolgen, ist wahrscheinlich eine schlechte Praxis. Wenn Sie also eine VMware-Umgebung haben, die bleiben soll, dann ist dies wahrscheinlich Cloud-native genug für den Moment (die Übernahme von VMware) von Heptio ist in diesem Sinne interessant für den zukünftigen Anwendungsfall). Das Fazit ist, dass das Aufhängen des einfachsten Elements (Container), das auf dieser Liste zu finden ist, ein häufiger Fehler ist.

Thors Hammer existiert in der IT nicht

Vor kurzem traf ich mich mit einem Cloud-Chef eines großen britischen Finanzdienstleistungsunternehmens, das mir erzählte, dass der bisherige CIO seinen Posten aufgeben musste, nachdem er die Strategie "Direkt an Serverlos" nicht umgesetzt hatte, dh die Cloud und der Container sprunghaft umgingen Revolutionen, um Workloads auf dem häufig genutzten privaten Rechenzentrum des Unternehmens mit Serverless-Technologie zu betreiben. Dass der CIO ausscheiden musste, ist keine große Überraschung: In jeder Branche müssen wir die richtigen Werkzeuge für die richtigen Jobs einsetzen, insbesondere wenn diese Jobs komplex sind. In der Cloud bedeutet dies, dass wir in den meisten Fällen wahrscheinlich eine Kombination aus Bare-Metal-Systemen, virtuellen Maschinen, Containern und Serverless in einer beliebigen Kombination aus privater Serverfarm, privater Cloud oder öffentlicher Cloud verwenden.

Zweifellos ist das einzige, was ich als ersten Schritt einer erfolgreichen IT-Umstellungsreise gesehen habe, Folgendes: Ich möchte nicht versuchen, eine dramatische IT (r) -Evolution zu vereinfachen. Verstehen Sie es stattdessen unter einem ganzheitlichen Aspekt und beurteilen Sie es anhand der Geschäftsergebnisse und -ziele. Es ist gut, sich zu bemühen, aber nicht alle Unternehmen verfügen über die Ressource, Cloud-native Puristen zu sein, und es gibt auch in kleineren Schritten deutliche Vorteile, z. B. mehr Zeit für die Analyse der Auswirkungen der Technologie oder ein besseres Risikomanagement. (Dieser Beitrag der Containerfirma Cloud 66 beschreibt gut die kurzfristige Effizienz und die langfristigen Einsichten, die durch das Verschieben einer monolithischen App in einen Container erzielt werden.)

Bekannte Unbekannte und unbekannte Unbekannte

Letztendlich wären wir jedoch nicht so begeistert von der Containerrevolution, wenn es nur darum geht, monolithischere Anwendungen unter Druck zu setzen. Eine Microservices-App, die in Containern ausgeführt wird, auf mehreren Substraten orchestriert ist, und das alles nach Cloud-basierten Prinzipien – das ist etwas, für das es sich lohnt zu schwitzen. Bei einer Anwendung, die schnell und zuverlässig mit weniger Betriebsmitteln skaliert, sich schnell an die Kunden- und Wettbewerbsdynamik anpasst und sich selbst heilt, zielen viele von uns darauf ab.

Auch hier sind Container nur ein Teil davon. Berücksichtigen Sie die technologischen Herausforderungen: Wie steht es mit der Orchestrierung? Und netzwerk Und stateful Dienstleistungen? Und Cloud-native-bereite Pipeline-Tools?

Vielleicht noch wichtiger, betrachten wir kulturelle Herausforderungen: Was muss sich mit unseren Entwicklungspraktiken ändern? Wie finden und binden wir die richtigen Talente? Wie können wir ältere Talente neu ausbilden und Generationen überbrücken? Wie wird sich das Risiko-Gleichgewicht ändern?

Ein Beispiel: Open Source ist bereits Teil Ihrer Strategie

Es ist eine gut dokumentierte Tatsache, dass der Aufstieg von Cloud und Open Source miteinander verbunden ist, was auch zu interessanten Spannungen führt, wie ich in meinem vorherigen Artikel untersucht habe. In Containern scheint diese Synergie stärker als je zuvor zu sein. Der Juggernaut hinter Kubernetes und vielen verwandten Open-Source-Projekten, der Cloud Native Computing Foundation (CNCF), ist Teil der Linux Foundation. In der CNCF-Charta sind die Absichten der Stiftung klar: Ziel ist es, ein Ökosystem von Open Source- und herstellerneutralen Projekten zu fördern und zu erhalten. Seit der Gründung der CNCF im Jahr 2014 ist es daher immer praktikabler geworden, einen komplexen cloud-nativen Stack mit einer großen Mischung dieser Open-Source-Projekte zu verwalten (einige interessante Daten im Jahresbericht der Stiftung). Je mehr Sie mit den Methoden der Containernativen umgehen, desto mehr Open Source verwenden Sie.

Die andere Seite dieses Bildes ist, dass Open-Source-Pakete einen erheblichen Teil der freien und proprietären Anwendungen ausmachen. Während Ihre gesamte App proprietär sein kann, kann das, was Ihr Team tatsächlich geschrieben hat, sehr klein sein. Wie der Status des Open Source Security Reports zeigt, ist die Nutzung von Open Source eng mit der digitalen Transformation gekoppelt und wird daher zunehmend geschäftskritischer. Allerdings schätzen nur 17% der Betreuer ihre Sicherheitsexpertise als hoch ein, was bedeutet, dass viele dieser Pakete ein operationelles Risiko darstellen.

Ein weiterer Aspekt ist die Community: Durch die Verwendung von mehr Open Source wird die Organisation zu einem Stakeholder. Daher sollte sie mit der jeweiligen Community in Verbindung stehen, um zu sehen, wie sie einen Beitrag leisten kann und wie sie sich so schnell wie möglich mit Roadmap und Sicherheitswarnungen auseinandersetzen kann .

Nein, das enthält

Zusammenfassend lässt sich das obige Beispiel zusammenfassen. Eine „einfache“ Entscheidung über den Beitritt zur Containerwelle wird den Nutzen der Organisation und den Einsatz von Open-Source-Software erheblich erhöhen und den Nutzen dieser erhöhen. Diese Software wird möglicherweise von großen Sponsoren unterstützt oder wird möglicherweise nicht unterstützt. Wahrscheinlich werden sie von Freiwilligen in einem sinnvollen Umfang gewartet und haben wahrscheinlich eine lebendige Community hinter sich – alle müssen von Benutzern engagiert werden, die sich auf diese Projekte verlassen.

Mit anderen Worten, nicht einfach. Container sind ein kritischer Teil einer digitalen Transformation, aber nur ein Teil. Die gesamte Transformation, von der Teile in Ihren Software Delivery-Systemen erscheinen werden, ohne dass Sie davon ausgehen, kann große Auswirkungen auf Ihre Anwendungen haben, wenn Sie mit der richtigen Vorgehensweise angesprochen werden Mischung aus Offenheit, Reife und Verantwortung.