Skillbyte Podcast #25: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Kubernetes: Flexibles und  leistungsfähiges Rechenzentrum für Unternehmen

// Inhalt //
01:07 - Kubernetes: Aus welchen Komponenten besteht es? Was leistet es?
06:24 - On-Premise und in der Cloud
07:26 - Yaml Beschreibung für Applikation Zielzustand
09:07 - Services, Secrets, Ingress, Namespaces, Loadbalancer,... Wie hängt das zusammen?
13:43 - Namespaces
15:18 - Kubernetes Softwarepakete mit HELM
18:05 - Kubernetes steigert Geschwindigkeit und verkürzt Innovationszyklen
25:32 - Security Checks automatisieren
27:24 - Monitoring durch Health Checks
28:11 - Entwickler übernehmen Verantwortung für Infrastruktur
30:09 - Cloud Native Softwareentwicklung
35:11 - Werkzeuge entwickeln sich schnell

DevOps Folge: https://soundcloud.com/skillbyte/skillbyte-podcast-2-devops

Was ist die Twelve-Factor App?: https://www.dev-insider.de/was-ist-die-twelve-factor-app-a-894702/

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Was man nicht mit Geschwindigkeit Du kannst vieles ausprobieren und anhand des Feedbacks dann weitermachen, das heißt, es macht auch ein Businessmodell, macht es plötzlich Dinge möglich, die vorher nicht möglich war?

Herzlich willkommen zum Skill bei Podcast Episode Nummer 25 Kybernetische, flexibles und leistungsfähiges Rechenzentrum für Unternehmen abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn er eine Frage habt, schickt uns gerne eine E-Mail an Podcast. Wir freuen uns auch immer über Bewertungen des Podcasts oder Anregungen an die gleiche E-Mail-Adresse senden.

Ich bin heute hier wieder mit Masa Heimerziehung. Es freut mich, dich mal wieder zurück zu haben nach einigen ausschweifenden Suchen. Und wir sprechen heute über das Thema Kybernetische und welche Herausforderungen sich für die unternehmensalltag ergeben in Kombination mit kybernetische und natürlich auch, welche Vor und gegebenenfalls Nachteile sich um das Hauptthema Kubanisches ranken. Ich denke, wir sollten erst mal ein paar Begrifflichkeiten im kybernetische Kontext einführen und besprechen, kurz sagen, was das ist für die Zuhörer, die noch nicht so viel kubanisches Erfahrung haben und sich erst mal aufschlagen möchten.

Was ist Kybernetische überhaupt?

Kybernetische ist eine Orchestrierung, Plattform für Docker, Container. Jeder, der sich vielleicht mal mit Arisierungen und Containern beschäftigt hat, weiß, dass man die Container im Prinzip als Service für eine bestimmte Applikation baut. Services spielen hier eine Rolle. Jede eigenständige Applikation oder Micro Service wird in einen Container gepackt, und diese Container kommunizieren miteinander. Bei ein, zwei Containern ist das noch relativ einfach. Hier kann man entweder direkt mit dem Docker Command Interface starten und verbinden, wenn es mehr und komplexer wird.

Dann kann man z.B. Docker Composer nutzen. Aber Docker Combos ist mehr gedacht für lokale Entwicklungsumgebung, um schnell mal eine Umgebung zu starten. Verschiedene Dienste wie zum Beispiel Majas gelten als Frontend und ein, zwei Backend Container. Sobald es in Produktion geht, dann wird es schwieriger, das mit Docker, Combos oder auch selbst mit Swarm zu managen. Da braucht man ein etwas robustes System, und das sind dann halt Plattformen wie Kobanê oder meeses, Marathon oder Opernchef.

Die Docker Container, die rohen Docker Container benutzt man eher lokal zur Entwicklung, wenn man sich nicht sein lokales Entwicklungs System mit Dependance zu Mülln möchte, sondern schnell verschiedene Dienste nebeneinander installieren möchte und kybernetische ist sozusagen der Puppenspieler, der die Docker Container dann orchestriert.

Das ist ein schönes Wort. Puppenspieler? Genau, genau. Ja, es ist vielleicht nochmals im Hintergrund. Historisch gesehen war es früher so, dass man ein Server installiert hat, darauf Dienste installiert hat, und die Dienste hatten ihrerseits wiederum Abhängigkeiten, bestimmte Software, Bibliotheken oder andere Dienste. Und das war sehr flexibel, weil man z.B., wenn man zwei verschiedene Versionen nebeneinander installieren wollte, von beispielsweise Majas Cruel. Dann gab es halt die Probleme, dass die Abhängigkeiten nicht richtig stimmen und dass man sehr viel manueller Aufwand betreiben musste, um mehrere Versionen nebeneinander betreiben zu können, so es denn überhaupt möglich war.

Und mit Docker hat man eben diese ganzen Applikationen zusammen gepackt und fährt jetzt nebeneinander eben diese einzeln Container hoch, die alles mitbringen. Und somit ist auch der Betrieb von unterschiedlichen software-version einer Komponente kein Problem mehr. Also eine Flexibilisierung in der softer Schicht Kybernetik ist sozusagen. Ja, ich glaube, dass Altgriechisch für Steuermann. Google hat es ursprünglich entwickelt und dann unter einer offenen Lizenz gestellt. Der Steuermann steuert die Docker Container aus, je nachdem, welche Gesamtklang schafft man denn haben möchte.

Also ich glaube, technisch ist es so Kobanê. Es besteht aus einem Master und mehreren Worker Notes. Ich weiß nicht, ob es auch mehrere Master Notch geben kann.

Ja, natürlich. Wenn du in einer hoch verfügbaren Umgebung bist, dann brauchst auf jeden Fall mehrere Master. Da spielt das genutzte Protokoll eine Rolle, wie sich diese Master quasi miteinander synchronisieren. Das ist im Wesentlichen ist das basierend auf CD, quasi den Status des Clusters. Das ist die kritische Komponente und das benutztes Protokoll. Das heißt, für eine hoch verfügbare Umgebung braucht man eine ungerade Zahl an einem Master. Das heißt drei, fünf, sieben und so weiter.

Damit man immer beschlussfähig ist, sozusagen, wenn eine Maschine ausfällt.

Richtig, deshalb man Majority und Votings und so weiter zu tun. Deswegen habe ich bis jetzt fünf. War das Maximum, was ich erlebt habe. Kommt doch drauf an, wie schwer die Master runterlassen sind, wie viel sie zu arbeiten haben. Aber grundsätzlich kommt man mit drei, maximal fünf Marston aus in einer hoch verfügbaren Umgebung, dem Master.

Oder der Master unterscheidet sich nur dadurch von den Wolken, dass dort eben der Master. Dienst läuft, der Master Kybernetische Dienst läuft, dem gibt man sozusagen vor, ich hätte gerne folgende Umgebung mit folgenden Docker Containern. Und der sorgt dann dafür, dass auf den Worker Schnauz die entsprechende Last verteilt wird und diese soll Umgebung, die ziel. Umgebung sozusagen hochgefahren wird.

Combined ist an sich, besteht aus vielen Einzelkomponenten selbst, und Master besteht aus einem Server ETSI Knoten, wobei dieser Knoten nicht auf dem Master selber laufen muss, das dann auch ein eigenständiges Cluster sein. Dann haben wir den Ebikon Schola. Wir haben den Scajola. Das sind alles Komponenten, die den Master quasi ausmachen. Man kann es auch so konfigurieren, dass einzelne Wirk lots, also die Container, die auch auf dem Worker laufen, auch auf dem Mars läuft.

Aber grundsätzlich in der Umgebung verhindert man, dass das Workflows auf dem Master laufen, sondern das dem Master wirklich Matheaufgaben haben und nicht noch Workouts laufen haben.

Also den Master Nod muss man sich so vorstellen wie den Tower beim Flughafen, der sozusagen die Aufgaben die Landebahnen zuteilt, auf die einzelnen Flugzeuge kybernetische. Frei Das heißt, ich kann das in meinem eigenen Rechenzentrum einsetzen. Alle großen Cloud Provider bieten auch managed kybernetischen Umgebungen an, sodass man auch in einem Cloud Rechenzentrum direkt auf diese Kobanê Infrastruktur zugreifen kann. Und ich kann das auch verbinden. Ich könnte eine Cross und Tramitz Cloud kombiniertes Umgebung schaffen. Richtig?

Ja richtig, die Worker, wo die laufen, ob sie in der Cloud laufen, laufen, hybrid laufen. Das spielt für Kybernetische selber keine Rolle. Das ist abstrahiert das Netzwerk, solange die Dinger miteinander sich connector können. Diese Worker überall laufen können.

Das heißt, für Unternehmen, die jetzt viele Dienste in die Cloud migrieren, ist das eine sehr interessante Technologie. Einfach aus dem Grund, weil man ja auch so ein bisschen Hersteller unabhängig wird. Wenn alle Clouds diese kubanisches Umgebungen anbieten und ich die auch am eigenen Rechenzentrum verwenden kann, dann bin ich mich ja nicht an proprietäre Dienste von AWS oder AJA oder der Google Cloud. Jetzt habe ich schon die Komponenten Master Notes Worker Notes. Haben die einzelnen Docker Container? Wie sag ich denn jetzt kybernetische, wie mein Ziel Zustand ist?

Da benutzt man doch die Jamel Beschreibung Sprache, um verschiedene Dokumente anzulegen, um Kobanê das zu sagen.

So und so möchte ich das genau. Der Workflow ist wie folgt Du beschreibst deine Wünsche, wie zum Beispiel, welche Applikationen, also welches Docker Image mit wie vielen Instanzen auf welchen Ports hören soll. All diese Dinge beschreibt in sogenannten Jamel Dateien und mit einem Kommandozeile tool genannt hatte also bzgl. sagst du Kobanê, dass er die Jamel Datei nehmen soll und aufs Cluster abspielen soll. Und das machst du dieser Kommandozeile. Die Kommandozeile Tool unterhält sich immer mit diesem Speicher, quasi.

Du kannst dein gegarte Lokal auf deinem Laptop haben und ein Cluster kann sonst irgendwo stehen. So lange dieser Episode auf dem Haus und auf dem Port erreichbar ist.

Das ist dann quasi verbunden Der Dienst von einem Laptop kommuniziert zu dem Master in der Cloud oder im Rechenzentrum.

Je nach Security ist auch durchaus denkbar, dass wir nur mal als Beispiel auf Amazon unterwegs bist oder in anderen Cloud Umgebungen. Ist es auch denkbar, dass du aus Angst oder Not, wo du quasi mit einem Laptop erst über s.a. Verbindung zu dem Kamphaus hast und von dort aus Bergkuppe dann die Befehle absetzt?

Ich glaube, Kube Cattle ist die Kurzform für Cube Control Kobanê. Sollten wir vielleicht sagen, in dieser jamil Beschreibung Sprache kann ich dann ja verschiedene. Ja, ich sag mal kubanisches Artefakte beschreiben. Also Secrets sind Ingress, die in verschiedenen Naim Spaces liegen. Laut Ballonfahrt kann ich beschreiben, was es damit auf sich. Vielleicht gehen wir einfach mal durch, was ein Service ist.

Kubanisches hat viele verschiedene sogenannte epü Objekte, und die Aromas ist Pott. Der ist sowas wie ein Container. Aber laut Spezifikation kann so ein Pott auch mehrere Container beinhalten. Grundsätzlich ist das Muster, dass man einen Container in einem totlaufen laufen lässt. Es sei denn, du hast spezielle use cases, wo du einen sogenannten Tschaika Container innerhalb des Ports laufen lässt, sodass mein Container hast plus einem Container. Das kann z.B. sowas sein. Win win lock Schipper, der locks des Containers auswertet und hin.

Und das möchtest du auch mal separat für sich beschreiben. Und die Pleuel, und das läuft oder kann zum Beispiel in einem Ort als zweiter Container mitlaufen. Also Pod ist quasi die kleinste Beschreibung dieser Einheit. Man sollte aber niemals mit einem. Direkt arbeiten, weil so bekommt IPI aus dem Osten bestimmten Reinsch. Was du auch konfigurieren kannst innerhalb von Kobanê, ist nur, wenn der Potz stirbt und davon. Das ist ein Paradigma, was man verstehen sollte. Man bewegt sich einem sehr volatilen Umfeld.

Das heißt, weder Amazon noch Google noch AJA garantieren, dass ein Bohrkerne zum Beispiel, den sie dir zuweisen, auch permanent läuft. Man muss dagegen designen und gewappnet sein, dass so ein Bordkanone einfach mal stirbt und ein anderer zur Verfügung gestellt wird. Davon muss man ausgehen, man darf nichts anderes voraussetzen. Und ein Pott, wenn er denn und das macht auch Kobanê werden, wenn ein Cannot ausgetauscht wird, dann kann er sehr transparent die Potz umziehen, offenen anderen funktionierenden Nod und du bekommst das noch nicht einmal mit, weil er das Routing, Traffiq und so weiter alles automatisch finde.

Ich manage nur, wenn so ein Pott woanders hochfährt. Bekommt er zum Beispiel eine neue I.G. Das ist laut Spezifikationen so, und dann kommt ein weiterer NPD-Fraktion Layer dazu. Service Ein Service ist quasi vorgeschaltet vor einem Ort und garantiert dir zum Beispiel eine bestehende IP-Adresse oder eine permanente IP-Adresse aus diesen Reinsch. Solange das epi Objekt des Services da ist, ist die IP auch fest, und du kann sich darauf verlassen, dass du zum Beispiel dein Backend Container oder was auch immer immer gegen diese IP laufen lassen kannst.

Und dann ist quasi erreichst Der Vorteil eines Servers ist es auch noch, dass du mehrere Instanzen des Potz hinter einem Service haben kannst, und der fungiert dann quasi auch als Pilot. Balance?

Okay, das heißt, ich darf niemals mit der FDP direkt sprechen, sondern mit dem Service, weil IPI Nummer ist nicht garantiert. Und wenn ich immer mit dem Service spreche, dann managed Cohn-Bendits die Kommunikation für mich. Ob es jetzt nur man kann sich eine Anwendung vorstellen, wo z.B. eine Such Komponente drin ist. Einfach eine Website Suche Such Komponente aufgerufen wird, dann würde ich mit dem Service Suche sprechen und nicht mit irgendeiner festen IP.

Und dann könnte dahinter ein Pod laufen, der diese Suche durchführt. Wenn gerade viele suchen. durchgeführt werden, könnten aber auch fünf Such Potts dahinter laufen und ich würde einfach mit dem Service sprechen und Kobanê? Es würde die Last automatisch balancierend zwischen die exakt potz die da hinten Dreierreihen. Okay.

Dieser Service ist unter der Haube quasi ein Managed für die. Das ist der sogenannte Proxy. Das heißt, wenn ich auf dem Bohrkernen unterwegs bin, mir die Prozesse angucke, dann Proxy finden, und das ist dieser Service Dienst, und der nutzt einfach IP T-Bills, um deine Pakete entsprechend richtig Suruç.

Das ist schon ziemlich low level. Also darum kümmert sich Cohn-Bendits. Absolut wichtig, glaube ich. Für unsere Zuhörer ist, dass man sagt Okay, deine einfällt. Micro Services dürfen nur mit dem Service sprechen und auf keinen Fall mit festen Tipis, weil die können sich ändern, die sind volatil. Und wenn man einfach auf diese Services Ebene geht, dann kümmert sich Kybernetische um den Rest.

Das Interessante ist, dass dieser Service quasi auch bei der Jamil beschrieben wird. ummehr mit Kube cattle, in den Kobanê die S-Klasse eingespielt wird, automatisch dafür sorgt, dass der Service Name nur in der Jamel festgelegt ist, quasi gleichzeitig der Host Name ist und von jedem Nod aufgerufen oder aufgelöst werden kann.

Das heißt, für die Anwendungsentwicklung selber wirkt dieser Service Name wahrscheinlich wie DNS Name exakt.

Genau das ist es ja, das ist ja auch ein Konzept.

Innerhalb von Kybernetische legt man einen Naim Space an, also der STANDARD namens BAW heißt, glaub ich, default, den man nicht benutzen sollte. Also man legt namens Bacons an für unterschiedliche Services, und innerhalb der Namens bases sehen sich die Services, oder die Ports können miteinander kommunizieren, und man kann dadurch eine höhere Sicherheit erreichen, dass man zum Beispiel Services, die nicht von außen erreichbar sein sollen, dann weg kapselt.

Die Nehmens Bacons ist erstmal ein organisatorisches Konstrukt. Kannst du zum Beispiel verwenden, um verschiedene Produkte, verschiedene Projekte, verschiedene Abteilungen in deinem Unternehmen abzubilden? Security technisch so eine Art Folder Werbung, wo die Sachen reingehört. Security Technisch muss man ein bisschen mehr machen, weil die standardmäßig die Ports aus den verschiedenen Namib. Sich gegenseitig erreichen und aufrufen können. Parke aber Security. Technisch gibt es halt Möglichkeiten, dass man diese hart abschottet, dass es übergreifend keine Kommunikation und so weiter möglich ist.

Okay, namens Spaces. Man kann es sich jetzt vorstellen In einem Rechenzentrum mit 100 Anwendungen würde man jeder Anwendung einen eigenen Namen Space zuweisen und die jeweiligen Ports, aus denen die Anwendungen dann besteht, genau die einzelnen Dienste. Die würden dann unterhalb des jeweiligen Namens Spaces laufen könnten.

Cross Application aber kommunizieren genau nach dem, was du halt in deinem Polleschs festlegt. Du kannst auch User einrichten, wo du sagst, der darf z.B. nur. Rechte auf diesen Namen Space. Jetzt hast du schon gesagt, dass man mit Cube Control oder Cube Kanzeln die einzelnen Befehle oder die Konfiguration von Kybernetische verändern kann. Also ich kann ein Service hinzufügen Ich kann ein POW hinzufügen. Ich kann diesen Schritt für Schritt, diesen Wunsch, Zustand herstellen. Aber was man ja eigentlich möchte, wenn man das kennt man ja, zum Beispiel aus dem Linux Umfeld oder MacOS Umfeld.

Man möchte ja eine Anwendung paktieren, was man ein Paket hat, was man ausliefert oder wie so eine ZIP-Datei, die im Prinzip alles enthält und die Anwendung dann innerhalb dieser Copernicus Umgebung entsprechend provisionsbasis und hochfährt. Da gibt es das Tool Helm ist, glaube ich, altgriechisch für Ruder. Und das ist ja der Kuper. Nettes Paket Manager.

Wir haben ja diese ganzen egy Objekte erwähnt. Weißt du, was du hast? Du hast Ingress und jede Menge mehr. Die kann ich natürlich alle einzeln mit Kube Karte platzieren und dieser Pakete manage ist einfach dafür. Da bin ich komplexere Applikationen, hab die mit mehreren Abhängigkeiten und so weiter quasi als Paket zusammen schnüren. Und dann mache ich einfach ein Helm install meine Applikation, und der sorgt dafür, dass alles Notwendige herangezogen wird und die Plaid wird.

Der Vorteil ist jetzt hab ich das Paket, das Helm Paket oder das Hemd. Schardt hab ich ja quasi auch diese Infrastruktur Ascot Paradigma erfüllt. Ich tippe nicht mehr mit Kube Kuddel irgendwelche Befehle und hinterher kann es keiner mehr nachvollziehen, was genau ich da gemacht habe, sondern mit Helm kann ich sagen Helm in Stahl und das Paket wird installiert oder Helm an in Stohl das Paket, dann wird es wieder installiert, und ich habe immer konsistenten nachverfolgt baren Zustand, den man dann auch entsprechend pensionieren kann, um verschiedene Releases ein und derselben Anwendung nach und nach aufzubauen und auszurollen.

Also Helm Ich hab ja immer so ein paar Beispiele aufgelistet. Was kann man mit Helm machen? Also die Anwendung paktieren, Abhängigkeiten definieren beispielsweise einen Micro Service, der vom Internet aus erreichbar sein soll. Der könnte dann noch ein Luftballon vorgeschaltet bekommen ein Kobanê, kybernetische Software, Luftballons, Suchdienste können. Williams Mountain, Persistent Williams Mountain war mal an der Datenbank. Denkt die, muss er die Dateien irgendwo ablegen und verschiedene Services enthalten für anwendungs Komponenten. Also wenn man Mikroskops hat, er auf die Datenbank zugreifen will, dann muss der Service sich bei der Datenbank irgendwie authentifizieren, damit User und Passwort.

Dafür würde man dann eben einen Service USA anlegen, diesen als Siegrid. Das ist auch ein Kobanê, das Objekt ablegen und das all dies gleichzeitig geschieht und der Micro Service mit der Datenbank kommunizieren kann. Das würde man dann auch anders mit aufnehmen und in einem Rutsch sozusagen mit ausrollen. Super. Ich glaube da haben einen guten Einblick gegeben, was Kybernetische alles leisten kann und wie es aufgebaut ist. Was sind denn die Herausforderungen für die Unternehmensseite, die heute was sind die Business Probleme, wo kybernetische helfen kann?

Im Wesentlichen geht es bei diesen Plattformen. Es muss nicht einmal kybernetiker sein. Natürlich sprechen wir jetzt in dieser Episode über Kybernetische. Aber grundsätzlich geht es um Geschwindigkeit. Das heißt, was habe ich als Business One von Geschwindigkeit? Ich kann schneller auf Marktgegebenheiten und Veränderungen reagieren. Ich verbrauche meine Ressourcen in Form von Zeit, Geld und Personal nicht, um ein System am Leben zu halten und Fehler zu fixen, sondern ich kann diese Ressourcen verwenden, um schneller neue Features zu bauen und schneller am Markt zu positionieren.

Schneller zu skalieren bin ich plötzlich durch eine Marketingaktion oder durch einen glücklichen Zufall? Viele, viele User auf meiner e-commerce-plattform habe, dann kann ich durch die Geschwindigkeit, was ich manifestiert, durch Automatisierung z.B. verschiedene Nod hochfahren, um diese Last abfangen zu können. Und diese Geschwindigkeit erreiche ich, wie gesagt, durch Automatisierung. Dafür aber, damit ich das automatisieren kann und Ressourcen sparen kann, brauch ich die Beschreibung meiner Plattform als Code. Das heißt als Jamel Manifeste, die dann getriggert durch verschiedene Gegebenheiten automatisch ablaufen können.

Die Vorteile, die die verschiedenen Cloud Platform mitbringen, nämlich dass ich ein Nod hochfahren kann und so weiter, das macht sich Kybernetische zu Nutze. Und ich kann durch Kombination von verschiedenen, was ich früher erreicht habe, durch Puppet und Chef, um gewisse Dinge zu automatisieren. Das ist alles in dieser Plattform Kybernetische. Die native Unterstützung der Cloud-Anbieter für Kybernetischen automatisiert, und das kann ich auf Knopfdruck quasi lostreten. Ich brauch kein Admin, der 24Stunden 24/7 auf irgendwas achtet und aufsteht.

Natürlich brauche ich das auch in irgendeiner Art und Weise, aber es ist nicht mehr wie früher, weil alles automatisiert ist.

Das heißt auch die Rechenzentrums Landschaft. Verändert sich also so wie ein klassisches Rechenzentrum, hat verschiedene Server und Spezial Appliances Slot Balance, die für einzelne Anwendungen beschafft wurden. Es gibt den zehn Jahre alten Server in der Ecke und den neuen Server für die Anwendung von letztem Jahr, sondern dadurch, dass Kobanê eben diese Standardisierung vorantreibt. Kann man eigentlich sagen ein TMS Rechenzentrum oder ein Cloud Rechenzentrum? Man packt einfach standardisierte Server zusammen, die günstig sind im Einkauf, wenn man einfach viele davon abnehmen kann, und weil sie millionenfach verkauft werden, und hält diesen Pool an Rechenkapazität vor.

Und jetzt kann man mit Kybernetische die einzelnen Anwendungen in dieses ja vorhandene Rechenzentrum die Plotin laut Ballonfahrer sind Software mäßig oder werden per Software umgesetzt. Man kann natürlich auch Hardware Luftballons hernehmen für richtig kritische Anwendungen, und ich kann Server tauschen. Ich kann Server, die vorhanden sind, nutzen, bis sie irgendwann. Ich sage mal Anführungszeichen kaputtgehen, weil wenn sie ausfallen, wird der Potro woanders gestartet, und meine Anwendung merkt es gar nicht so. Dieses Konzept der virtuellen Maschinen kann ich dann auch auf anwendungs Ebene fortführen und bin sehr flexibel, wann eine Anwendung auf einmal deutlich mehr Ressourcen benutzt.

Kann ich das sowohl im eigenen Rechenzentrum bieten, aber auch in die Cloud hinaus skalieren, wenn ich das brauche? Genau. Denn Geschwindigkeitsvorteil, den du ansprichst, der manifestiert sich ja insbesondere ein Kernfächer von kybernetiker ist ja das schnelle Deployment, das sich eine neue Version der Anwendung sozusagen ausspielen kann und erst nur auf 100 Prozent der Potz ausrollen kann, sodass jeder zehnte Benutzer die neue Version bekommt. Und wenn das fehlerfrei funktioniert, dann kann ich nach und nach diese neue Version dann für alle Potz ausrollen.

Also ich bin da super flexibel. Ich glaube auch Security mäßig, aber da bist du der Experte. Lassen sich die Dienste sehr gut voneinander abschirmen, die, die gar nicht mit dem Internet kommunizieren sollen. Aber auch wenn ich Anforderungen habe, das die Dienste z.B. innerhalb der Cloud oder des eigenen Rechenzentrums verschlüsselt miteinander kommunizieren sollen, dann kann ich eine Sidka Komponente benutzen. Die nennt sich istso damit Dienste die legacy Dienste, die nie dafür gemacht wurden z.B. verschlüsselt zu kommunizieren über diesen Proxy dann auf einmal doch verschlüsselt miteinander sprechen und gar nichts davon wissen.

Aber auch, dass neuere Dienste eben direkt verschlüsselt miteinander kommunizieren können.

Die Einsatzgebiete sind riesig. Also wenn man im Umfeld von Kubanisches von Automatisierung spricht, dann ist das eine konsistente und allumfassende Automatisierung. Wir haben zum Beispiel gesagt, dass EPI ein Objekt ist, das Deployment. Du kannst das Deployment so konfigurieren, dass zum Beispiel, wenn man eine neue Version einer Software live stellt, das im Hintergrund erstmal. Ich sage mal Nehmen wir an, du hast drei Instanzen E-Commerce verlaufen, und es ist eine neue Version. Und jetzt hast du verschiedene Möglichkeiten, die Deployment durchzuführen, die eine ist.

Das nennt sich Blue Green Deployment. Bedeutet, das du gleichzeitig drei weitere Instanzen hochfährt? Kybernetische für dich die neue Software. Die neue Version und anhand von definierter hält checks check er, ob die Version quasi oder die Instanz gestartet ist. Wenn alle drei Instanzen das sind, dann Switch quasi um auf diese neue Version und die alten Ports wieder runter. So mag das sinnvoll oder nicht sinnvoll sein. Man muss auch Bedenken bedenken Wenn man in der Cloud umfällt, ist das nicht immer von drei Instanzen, sondern kann durchaus auch 30 Instanzen sein und 30 Instanzen parallel hochfahren.

Bedeutet doppelte Ressourcen. Dann plötzlich braucht. Das kann ich wiederum fein justieren. Aber es gibt zum Beispiel auch ein anderes Deployment Paradigma.

Ich kann sagen, was du angesprochen, dass das sogenannte Canary Deployment, wo ich eine gewisse Prozentzahl nur weiterleiten darf, was ich neue Features schnell ausprobieren und ohne die Mehrzahl der User damit zu konfrontieren, sondern erstmal nur zehn Prozent oder zwei Prozent und sehe, wie das funktioniert. Tauchen Fehler auf? Wie reagieren die User? Und wenn ich sicher bin, dass das funktioniert, kann ich dann entweder mehr Prozent oder 100 Prozent um Unruhe. All das wird möglich. Ganz plötzlich.

Experimentieren, was früher nicht so einfach war, das meine ich mit Geschwindigkeit. Du kannst vieles ausprobieren und anhand des Feedbacks dann weitermachen. Das heißt, es macht auch für dein Businessmodell macht, dass plötzlich Dinge möglich, die vorher nicht möglich waren. Zum Thema Sécurité Du kannst also zum. Neben diesem kybernetische Paradigma gibt's natürlich das nach wie vor das klassisches Continuous Integration und Continuous Deployment, was du quasi auch völlig automatisieren kannst. Man kann es so weit automatisieren, dass du sagst, ein Code kommt, in einem durchschimmert.

Control System nimmt sich den Code getriggert durch den Code mit. Baut das Platters in eine Kesting oder Staging Umgebung wartet. Thema Quality Gate wartet, bis jemand getestet hat und irgendwo gesagt hat Passt zum Beispiel mit einem Ulrik Fest und einem Mörz und sagt dann alles klar, ist quasi genehmigt und führt dann selbstständig in der Produktion aus. Man kann diese komplette Strecke automatisieren, sogar selbst Sécurité. Stichwort Check ups, wo du den kompletten Security Check, angefangen von einer statischen Analyse, sprich hast du vielleicht schon Bax oder Security relevante Dinge im Code eingebaut.

Da gibt es Libris, für die du, die du einbinden, Cabs, jeden Code checken und zum Beispiel gegen Datenbanken im Internet checken, ob deine Leibgericht bestimmte, weil ich haben kann, das ordnenden Bild abbrechen bis hin zu dem dynamischen Applikationen. Wenn es die Leuth ist, kann es zum. Da gibt es von sowas. Das ist eine Organisation, die sich um das Thema kümmert, wo du zum Beispiel die 100 meist durchgeführten Hex automatisch auf deine Applikation durchführen kann.

Also großzieht scripting, Shakes, Scuol Injection, Jabs und so weiter. Du siehst also, wo die Reise hingeht. All das, wofür man Tage und Wochen gebraucht hat. Früher kannst du jetzt quasi in einer Pipeline komplett weg automatisiert verstehen.

Dadurch springt natürlich die Qualität der Anwendung nach oben. Exakt. Man hat einmal diesen Integrations Aufwand, aber dann nutzt man quasi diese sich auch wahrscheinlich selbst automatisieren Libraries. Wenn neue CVS oder Security Lücken auftauchen, sind sie direkt da drin und man kann automatisiert die ganze Anwendung gegen diese neue Lücke testen lassen, sogar bis hin zu Compliance-Regeln.

Da gibt es auch Tools, wo du sagen kann, das und das und das sind meine. Meine Compliance-Regeln wie beispielsweise ganz einfach, benutze nicht das Original. Im Falle von Java, weil es Probleme hat und das Tool merkt Aha, verletzt und bricht ein Bild ab. Und Reporter? Und da gibt es richtig mächtige Tools. Würde diese ganzen Campanile Compliance-Regeln hinterlegen kannst.

Einen weiteren Vorteil das hast du schon mal anklingen lassen, ist natürlich das Monitoring durch Checks. Also ich habe jetzt Kybernetische ein Ziel stand vorgegeben und sagen So und so soll meine Anwendung aussehen. Und im Kybernetische prüft ja jetzt in regelmäßigen Abständen, ob jeder Posth gesund ist. Und wenn ein Pod nicht reagiert, dann kann man halt konfigurieren ok, bitte sofort einen neuen hochfahren, oder wenn ein die CPU Last auf einem Port eine gewisse Marke überschreitet, dann werden zusätzliche Potz hochgefahren.

Durch diesen Autos Krailling Mechanismus das vereinfacht ja auch das Monitoring der Anwendungen ganz erheblich. Das ist das, was ich eben sagte. Man kann die Hardware im Grunde viel länger nutzen, zumal wenn sie ausfällt, ist es nicht so schlimm. Combined merkt das sofort und fährt dann neuen Ports hoch. In dieser Multi Service Umgebung, was ich auch bemerkt habe, ist und das ist jetzt ein ganz deutlicher Paradigmenwechsel. Die Entwickler dadurch, dass die Infrastruktur auch durch Code beschrieben wird.

Das ist ja dieses DVB-S Paradigma, wo wir ja auch eine ganz eigene Podcast Episode zugemacht haben. Denke ich auch in der Beschreibung. Die Entwickler sind auch immer mehr verantwortlich für die Infrastruktur und die eigentlichen Admins. Früher war das ja oft so oder? In den PMS Rechenzentrum ist es oft so, dass die Entwickler bei den Admins etwas bestellen. Ein User, ein Server, eine Ressource, eine harddisk irgendwie. Und die Admins liefern die irgendwann. Jetzt musste der Developer im Grunde kann in seinem Manifest sagen Okay, ich brauche eine Disk mit 10 Gigabit, und die ist persistent und so weiter und ist quasi selber dafür verantwortlich.

Kobanê, das so zu Konfigurieren des Kabinetts prüft, das die Disk nicht voll läuft, sie entsprechend vergrößert wird und so weiter. Falls die Admins entlastet und die Developer müssten die IT-Infrastruktur verstehen, was laut Ballonfahrer. Wie funktioniert IPI Mask Reading? Was ist Nath? Diese ganzen Fachtermini, die mit Netzwerk Aufbau im Grunde genommen zusammenhängen, und bekommen diese Aufgabe zusätzlich.

Thema Das Du als Entwickler auch das spielt Richtung Geschwindigkeit. Früher, wenn du irgendwas gebraucht hast, dann hast du als Entwickler immer mit einem Admin Kontakt aufnehmen müssen. So viel Platz. Ich brauch neuen Server. Ich brauch dieses jenes und das kannst du jetzt selber geben. Du diese Jamel Dateien schreibst selber haben, und zwar innerhalb von Sekunden.

Man muss natürlich verstehen was man tut. Das verstehen, aber das ist halt der Paradigmenwechsel. Und das ist halt genau dieses Niveau, was die Unternehmen sich aufbauen müssen, ihre Entwickler entsprechend Schulwissen. Das ist halt die Herausforderung im Moment. Viele Entwicklungen, Entwicklungen stehen der Herausforderungen für die Unternehmensseite.

Um wirklich alle Vorteile von Kobanê ausnutzen zu können, muss man die Software ja etwas anders. Als das ich sage mal bis vor ein paar Jahren der Fall war das Stichwort wäre z.B. diese Klout native Anwendungen. Es ist auch möglich, alte Monolithen in kybernetische zu betreiben. Das ist nicht so flexibel, weil bei einem Monolithen wenn da der Pod ausfällt, hast du trotzdem diese Ausfallzeit bis der neue Pod gestartetes Plus. Die Anwendung muss so entwickelt sein, dass sie das auch dann handeln kann, wenn sie ausfällt.

Und viele ältere Monolithen wissen eben nichts von Kybernetische und können damit nicht entsprechend umgehen. Wie muss man Software entwickeln? Diese feingliedrige Software, die parallel laufen kann, wo Ausfälle einzelner Komponenten nicht zum System Ausfall führen, sondern einfach kompensiert werden können von Kobanê? Und wie erreicht man das?

Die größte Herausforderung ist jetzt mal von der Größe der Applikation Vor und Nachteile einer Schw, eines schwergewichtigen Monolithen und einzelner Miko. Mal davon abgesehen, weil das ist im Prinzip ein eigenes Thema für sich. Aber grundsätzlich, wenn man Software machen möchte, ist das wichtigste Thema steht. Es gibt die Summer Factor App, das beschreibt, das ist im Prinzip ein Best practices für Software, um Cloud laufen zu können.

Ich kann jedem empfehlen, sich diese App, Spezifikationen oder Beschreibungen mal anzugucken, weil das beschreibt eigentlich sehr genau eine Applikation gestrickt sein muss, um Kourtney laufen zu können. Zwei Themen aus diesen Faktoren ist einmal Stabs. Das heißt, man darf nicht voraussetzen, dass die Applikation den Status, wenn man aus dem Java Umfeld kommt, jemand JCC und Session auf dem Server der Applikation eine Session hält, weil, wie gesagt, immer sein kann, dass die Applikation von jetzt auf gleich woanders hingezogen wird.

Und dann ist der Status futsch. Man denke an Shopping Card oder was auch immer sauber gehalten wird. Das heißt, ich darf keine Sessions in der Applikation halten.

Es muss alles präsentiert werden in Datenbanken.

Im Grunde genommen direkt, ja, oder? Es gibt doch andere Möglichkeiten. Du kannst zum Beispiel einen radix haben, radix Cluster, quasi eine Datenbank, wo die Session außerhalb deiner Applikation gehalten wird. Und schnell, weil wenn so eine Session abtaucht oder Applikation ungezogen wird, dann hast du halt deine Session Memory. Da gibt es Lösungen für eine zweite Faktor. Aus diesen Faktoren ist das Du Konfiguration nicht in die Applikation legst, sondern immer von außen reingepasst, sodass quasi ein Container und eine Applikation völlig unabhängig von der Umgebung laufen kann.

Lokal State oder Produktion und Umgebung? Spezifische Konfigurationen oder Parameter kommen von außen als Umgebungen variable. Das sind, so Cloud, Faktoren. Wie gesagt, ich würde mir diese Apps mal durchlesen und strikt befolgen, weil das ist das, was ich für Applikationen in der Cloud.

Das ist auf jeden Fall ein heißer Tipp. Und da wird wahrscheinlich auch beschrieben, wie man mit Anwendungen die Anwendung komplett Container frisiert, wie man Micro Services aufbaut, wie man die Zugriffe untereinander regelt.

Also nicht in der Tiefe, sondern es ist so eine Art Manifest und beschreibt so eine Art Birth, wie diese Dinge sein müssen, damit das funktionieren kann. Da geht es um das Thema Abhängigkeiten, Konfiguration, Prozesse und so weiter. Das muss man sich einfach mal durchlesen. Das ist wirklich extrem nützlich.

Das heißt? Bölts Salvo ist ein schönes Stichwort Cloud Native Anwendungen. Das kann man, glaube ich, generell sagen. Besitzende hohe Testmarkt, weil sie ja tendenziell aus sehr kleinen Komponenten bestehen. Und das eignet sich natürlich auch, um so kleine inkrementelle zu bauen für Bowling Releases. Um die Anwendung, kleinstädtische weiterzuentwickeln, dann eben auch zielgenau zu skalieren. Man muss ja vorstellen, wenn man den Staat jetzt nicht mehr in der Anwendung hält, sondern in einem Memory Story radix oder in einer Datenbank.

Dann ist es ja auch möglich, mit parallelen Prozessen und parallelen Zugriffen darauf zu schreiben und zu lesen. Man muss ein bisschen synchronisieren, dass nicht zwei Services gleichzeitig beispielsweise einen Warenkorb schreiben. Aber das ist ja schon ein Paradigmenwechsel. Wenn man denen dann vollzogen hat, bekommt man eben die ganze, die ganzen Benefiz von Cohn-Bendits ganz genau, und man kann eine Anwendung sehr, sehr flexibel einsetzen. Also wenn man mal an eine Webanwendung denkt, wo die Webserver vielleicht in Deutschland erst einmal gehostet werden, und man expandiert jetzt auf den nordamerikanischen Markt, dann könnte man ja einfach in Nordamerika in der Zone weitere Webserver hinzunehmen, müsste nichts anderes machen.

Und die Leute in Nordamerika haben direkt eine bessere Erfahrung, weil die Zugriffe einfach schneller erfolgen. Und funktioniert natürlich nicht nur mit Nordamerika, sondern weltweit und kann so nach und nach einzelne Gebiete hinzunehmen. Gibt es da noch Werkzeuge für die Entwicklung, oder? Planung, die du auf jeden Fall empfehlen würdest. Also Docker und geht nehme ich jetzt mal als gesetzt. an, aber so Spezialwerkzeug, die dir in der Vergangenheit gute Dienste geleistet haben.

Alles, was das ökosystem Kobanê angeht, da könntest du Tage und Wochen erzählen, weil da kommst du gar nicht zum Ende. Weil wir nur am Ende bist, gibt's ein paar neue zugelangt.

Die Entwicklung ist sehr schnell. Es ist abartig. Ich hatte das Thema der Check ups erwähnt. Ja, das ist auch relativ neu. Dann gibt es schon das Thema gibt Tipps, wo du die komplette Laichzeit einer Software von Entwicklung bis hin zum Deployment komplett übergibt. Das heißt, selbst in die Kobanê setz gar keine Befehle mehr selber ab, oder? Sondern einfach mit Quests reichen, um diese Kette abzubilden. Der Vorteil ist, dass du alles dokumentiert hast. Das hast du siehst jederzeit.

Wann wurde die Leuth? Warum wurde die Leuth? Du kannst die Kommentarfunktion in Gips nutzen.

Plus die Geschwindigkeit plus die Geschwindigkeit. Also du hast das Feature entwickelt, gemurrt, getestet, und es ist sofort. Zehn Minuten später ist es in der Anwendung und kann verwendet werden.

Ja, auch die Kollaboration. Du kannst ja auch quasi Kommentare hinzufügen. Du kannst es ja mal Teams oder Slack einbinden, was wiederum das Wort Stops ins Spiel bringt, wo du quasi mit slack Befehlen diese Karte weiterspinnen kannst. Also Thema ist komplette Agilität. Nein, das sind die Werkzeuge, die du hast nutzt, um es Software abzubilden, ohne jetzt direkt konfrontiert zu sein mit Kobanê. In all diesen low level Komponenten haben, weil da halt ein paar andere Layer dazwischen sind, die irgendwas steuern.

Es geht total schnell. Du musst echt am Ball bleiben, damit du gucken kann. Was passt zu meinem Kunden am besten? Welches Setup hatte aktuell? Das ist mitunter sehr anstrengend, aber macht auch sehr viel Spaß, weil sehr viel Bewegung drin ist.

Das Deployment aus dem Chat heraus zu starten oder ob ich da jetzt noch mitmachen muss, das ist ja fast schon akademischer Natur. Aber ich glaube, das Wichtige ist einfach, dass die Zeit, die vergeht, von einer Feature Entwicklung, also feature to market, wenn man so möchte, dass die möglichst kurz ist, dass man auch dann wieder lernt. Man hat dieses Feature eben entwickelt. Die Kunden nutzen es, die Nutzer nutzen es, und man bekommt Feedback.

Ah, okay, das ist es gelungen. Das und das ist vielleicht noch nicht optimal, dass man die Entwicklung der Anwendung in die richtige Richtung sehr schnell vorantreiben kann und eben dieses Builds Development sag ich mal betreiben kann. Also genau an den Kundenbedürfnissen ausgerichtet.

Vielleicht müssen wir mal das Thema ökosystem von Kybernetische, also welche Tools und neueste Entwicklungen? Das kann man dann eine eigene Episode daraus machen.

Das können wir gerne planen. Vielen Dank für die Session. Gerne. Wenn unsere Zuhörer Fragen haben zu dem interessanten Thema, können Sie uns gerne eine E-Mail senden. An Podcast abonniert unseren Podcast und lassen uns gerne eine Bewertung da und schaut auch auf Skill slash Blog vorbei. Wenn Ihr weitere spannende Technologie Themen lesen möchtet. Masa Ich bedanke mich ganz herzlich bei dir.