All posts tagged: installation

Skillbyte Podcast #43: Helm – Der Kubernetes Paketmanager

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

In diesem Podcast geht es um das Thema: Helm – Der Kubernetes Paketmanager

// Inhalt //
01:23 – Definition: Was ist Helm und wie wird es eingesetzt?
04:14 – Einsatzszenarien für Helm Charts
08:03 – Warum benötigt man Helm Charts ?
09:13 – Vorteile von Helm Charts und deren Einsatz
14:32 – Zusammenfassung Vorteile Helm Charts
16:12 – Von Terraform über Kubernetes zu Helm
22:18 – Beispiele: Betrieb hoch-skalierbarer Anwendungen
26:09 – Neue Anwendungen werden Cloud-native entwickelt; selten Migrationen von Bestandssystemen
29:18 – Bestandteile und Funktionen eines Helm Charts
34:25 – Handhabung von Helm auf der Kommandozeile
36:23 – Helm 2 vs Helm 3
37:35 – Flux – CI/CD in Perfektion
41:53 – Fortgeschrittene Deployments: Canary und Blue Green Deployments; Istio

Show notes:

Podcast #25: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen
https://soundcloud.com/skillbyte/podcast-25-kubernetes-flexibles-und-leistungsfahiges-rechenzentrum-fur-unternehmen

Podcast #36: Terraform – Virtuelles Rechenzentrum mit dem Infrastructure as a Service Werkzeug
https://soundcloud.com/skillbyte/podcast-36-terraform-virtuelles-rechenzentrum-mit-dem-infrastructure-as-a-service-werkzeug

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Das Wichtigste zu verstehen ist, dass man mit Helm eigentlich nur kybernetisch Ressourcen verwaltet. D.h. Anstatt dass ich jetzt mit meiner Cubes Btl hingehe und sage create deployment create secret create config map, sag ich einfach nur Haman Stall und im Hintergrund läuft halt genau das. Aber das Schöne an der ganzen Sache ist, dass das alles kybernetisch Native ist. Also im Prinzip kann ich es nicht best practice, aber im Nachhinein kann ich beliebig auch die Ressourcen per Hand wieder editieren.

Ist natürlich nicht empfohlen, weil dazu gibt’s ja Helm. Herzlich Willkommen zum Skill bald Podcast Nr. dreiundvierzig Helm Der Kybernetisch Paket Manager abonniert unseren Podcast für mehr spannende Technologien aus dem Technologie Umfeld, wenn er IT Entscheider oder ity Fachkraft seid. Wenn ihr eine Frage habt im Verlauf der Episode sendet uns gerne eine E-Mail an Podcasts Skill BYD Punkt D Wir freuen uns auch immer über Bewertungen und ganz besonders wichtig für uns sind Weiterempfehlung an eure Freunde und Kollegen, die sich auch für Technologie Themen interessieren.

Wenn ihr aktuell ity Jobs sucht, schaut gerne auch auf das Gebiet Jopp Seite vorbei. Ich bin heute hier mit Julius, einem DevOps Ingenieur von Skill bald und ich freue mich super auf dich. Hallo Julius, hi Maurice. Ja und heute sprechen wir über Helm und das Thema kybernetisch bzw. was Helm genau ist. Und Helm ist eine Technologie. A kann man sagen, die in den letzten 2 3 Jahren doch deutlich an Verbreitung zugenommen hat und ja auch so ein bisschen gehypt es, oder?

Ja, auf jeden Fall. Also das Tool ist ja schon ein bisschen älter. Aber wie du gesagt hast, es ist jetzt in den letzten Jahren hat das enorm zugenommen. Auch. Vor allem wird das viel verwendet. Also eingebettet in andere Systeme, wie z.B. Rangiere oder so. Also das ist auf jeden Fall sehr populär zurzeit genauso.

Entwicklungsgeschichtlich kann man ja sagen, diese Kuba Metis Infrastruktur ist entstanden und die Leute haben begonnen eben ihre Anwendungen in kombiniertes Cluster zu Diplomen, die zu managen und haben dann aber festgestellt okay, so eine Anwendung aus mehreren Microservices im Kybernetisch Cluster, das ist relativ viel Handarbeit, diese zu warten und die einzelnen Komponenten zu aktualisieren. Es wäre doch schön, wenn man so eine Art Paket Manager hätte, wie man das aus z.B. Linux-Distributionen kennt wie APT, get oder Pacman und dieses Konzept auch für kybernetisch Anwendungen, die wie gesagt aus mehreren Microservices bestehen können, verwenden kann.

Das Ziel ist es eben kybernetisch Anwendungen möglichst einfach zu managen, also wie man bei abgeht install Paket Name sagt und Linux Pakete installieren kann. Genauso möchte man das auch in der Kybernetisch Welt haben und natürlich auch genau so einfach mit einem an install. Wofür hast du denn Helm bisher benutzt?

Ja, im Prinzip genau wie du jetzt gerade erwähnt hast. Also der Zustand, dass man eben irgendein fertiges Tool schnell installieren will, gerade auch zu Demo Zwecken oder um mal so ein kleines Proof of Concept zu machen. Wenn man zu einem Kunden fährt, den einfach zeigen will, was möglich ist und wie schnell das alles geht. Da benutzt man gern Helme, weil wie du schon gesagt hast im Linux Umfeld ist das ja auch sehr gängig, dass man da einfach schnell was installiert um es auszuprobieren, weil man sich eben nicht durch irgendeinen Install Wizard durchklicken muss und auch eben nicht viel konfigurieren muss, sondern das eigentlich out of the Box funktioniert.

Also Helm ist wie kybernetisch selbst auch OpenSource richtig. Genau. Ja, das ist ein Open-Source-Projekt, was von der Cloud Native Computing Foundation betreut wird. Und so kann auch jeder im Prinzip da dran mit basteln.

Contribution Ja, das machen ja die großen Cloud Provider. Alle oder die großen alten Namen bringen sich dann natürlich ein, weil sie auch gesehen haben der Trend geht ganz klar eben zum Paket Manager auf Kuba net des Container Anwendungen. Wenn unsere Zuhörer noch mehr zu kybernetisch wissen möchten, empfehlen wir auch gerne unsere Folge Nr. 25 Da geht es intensiv um das Thema Kybernetisch, um komplexe kombiniertes Anwendungen eben betreiben zu können oder installieren, deinstallieren, abzugrasen zu können. Wie genau macht man das denn mit Helm?

Stell dir einfach mal vor, wir haben entweder Ein und Promos Rechenzentrum oder ein Cloud kybernetisch Cluster hochgefahren. Ist ja egal, ob der jetzt bei einem der großen Cloud Provider läuft oder im eigenen Rechenzentrum. Und ich möchte die Helm Technologie einsetzen. Wie würde ich da denn jetzt dran gehen?

Ja. Also grundsätzlich gibt’s ja dann erstmal die Frage Möchte ich das jetzt für meine spezielle Anwendung, die ich zum vielleicht auch selbst entwickel machen oder für eine Anwendung, die eben noch nicht im Heim Repository mit drin ist? Oder eben so eine typische STANDARD Anwendung? Das weiß ich an Engine X Server oder typisch sind auch ein Monitoring primitives oder sonst was mit allen möglichen Abhängigkeiten. Im letzteren Fall würde man dann halt wirklich gucken, in welchem Repository das drin ist. Meistens sind die auch in den STANDARD Repositories drinnen.

Da gab’s jetzt plötzlich viel Umstrukturierung. Aber die großen Sachen, die sind eigentlich immer zu finden. Und dann würde man ähnlich wie beim Paket Manager tatsächlich einfach sagen Heim ins Daul den Release Namen. Also da kann ich selbst an einen Namen vergeben, der dann unique in meinem Cluster halt erscheint und dann eben der Name des Pakets. Im Prinzip also im Heim Umfeld nennt man das Helmut Shard. Und ja, man kann da beliebig dann auch Variablen in dem Shard verändern und anpassen.

Aber im. SIB reicht ein einfaches Heim in Stall, den Release Namen und das Shard, was ich installieren will und dann läuft das eigentlich schon von selbst alles an, mit allen Abhängigkeiten und einem möglichen.

Das heißt, ich konfigurierte Helm benutze ich von der Kommandozeile Karl gegen den kubanisches Cluster, gegen den ich es benutzen möchte. Ob on primus oder in der Cloud.

Richtig, genau genauso siehts aus. Und es gibt schon Repositories an die Helm Charts enthalten für STANDARD Komponenten wie z.B. Webserver, Engine X oder Datenbanken. Wobei Datenbanken in kubanisches Clustern ist immer so eine Sache, aber für fertige Komponenten und da kann ich meine eigene Software, die vielleicht ein Webserver braucht ne, wenn es Microservices ist, kann ich sozusagen darauf basieren lassen, oder?

Ja, das ist eben der Vorteil. Ähnlich wie beim Paket Manager wieder, dass sich eben Abhängigkeiten auch in meiner eigenen Anwendung einfach reinziehen kann. Und wie du schon gesagt hast, das ganze Management von Abhängigkeiten. Das passiert alles klein seitig und im Prinzip werden dann einfach ganz normal die Sachen nach und nach in kybernetisch Cluster installiert von Hän und ich muss mir da gar nicht viel Gedanken machen.

Also Helm geht dann hin, lädt die einzelnen @Helmut Charts die ich als Abhängigkeiten markierter. Bleiben wir mal beim Webserver runter, lädt die Docker Images runter Diplome die dem kybernetisch Cluster und sieh zu, dass alle Komponenten ordentlich starten. Und ja, die beschriebenen Wolli ums gemault teeth werden die Ports die angegeben werden freigeschaltet sind verschiedene krit. Dunkels gesetzt werden. Also als variablen Beispiel, sodass nach und nach die Anwendungen wirklich wie ausgepackt aus einem Paket in dem kybernetisch Cluster lauffähig gemacht wird.

Genau ungefähr so ist es natürlich schon noch so, dass Kuba Annettes sich um Sachen kümmert, wie jetzt die Container runterzuladen und so weiter. Das wichtigste zu verstehen ist, dass man mit Helm eigentlich nur kybernetisch Ressourcen verwaltet. D.h. Anstatt dass ich jetzt mit meiner Cubes Ctrl hingehe und sage create deployment create secret create config map, sag ich einfach nur ha’m. Im Stall und im Hintergrund läuft halt genau das. Aber das Schöne an der ganzen Sache ist, dass das alles kybernetisch Native ist.

Also im Prinzip kann ich es nicht best practice. Aber im Nachhinein kann ich beliebig auch die Ressourcen per Hand wieder editieren. Ist natürlich nicht empfohlen, weil dazu gibt’s ja Helm.

Das ist ja genau der Punkt, dass man eben nicht Anwendungen händisch installieren möchte. Das würde ja auch funktionieren. Und dass man dann hinterher sagt Okay, die Anwendung läuft. Ich habe drei Tage dafür gebraucht. Welche Befehle hab ich denn sozusagen abgesetzt, um die Anwendung zu installieren und daraus mir ein Script mache, sondern das genau soll ja Helm machen. Man beschreibt in diesem Helm schade, dass es eine Jamel Datei beschreibt man quasi die Abhängigkeiten und den Zustand der App und Helm sieht einfach zu, dass dieser Zustand hergestellt wird und führt die dazu notwendigen Kommandos aus.

Genau, ja.

Also das ist wie du schon gesagt hast, in DE klarer, tiefer Ansatz, typischer Orchestrierung. Use case also ich sag halt was ich haben will und Heyl guckt was hab ich und was muss ich tun, damit ich den Zustand erreiche? Also da haben wir noch gar nicht drüber gesprochen. Auch Sachen wie Updates und so weiter können von Heyme auch direkt behandelt werden. Und PAME vergleicht halt einfach nur Ist und soll und guckt dann, dass die Aktion ausgeführt werden, die nötig sind.

Ja, das ist ja auch wie bei einem Linux Paket Manager. Na da kann man ja auch die Updates direkt über dem Paket Manager machen und die werden dann eben eingespielt entsprechend.

Genau, ja. Also die Vorteile von HAMCHA sind ganz klar. Wir haben schon von der Jamel Datei gesprochen, dass man diesen Infrastructure Ascot Ansatz noch weiter treibt. Die Jamel Datei ist natürlich einfach eine flache Datei, die man in git Versionierung kann. Man sieht wer welche Änderungen gemacht hat, man hat reproduzierbare Installationen. Ich könnte ja jetzt auch sagen wir ich habe drei kybernetisch cluster test Akzeptanz Umgebung und Produktions Umgebung und könnte dann in schneller Folge ein komplexes Helmi Chat mit vielen Komponenten in allen drei Umgebungen installieren.

Das wäre überhaupt kein Problem. Richtig.

Genau das ist eben auch der Vorteil. Ich hab’s eben schon ein bisschen angerissen. Man kann diese Hemme Charts, die bestehen auch aus Templates. Also diese ganzen kubanisches Ressourcen werden getrampt rated und dazu wird go template im Englischen benutzt. Das heißt, dass ich dann auch abhängig von dem Environment, wo ich mein Deployment mache, auch Variablen setzen kann. Das heißt in Produktion kann ich z.B. sagen, die Praktikas von dem Container, also wie viele Container gleichzeitig für meine Anwendung laufen, ist höher als jetzt in einem Test in Valmont, wo ich halt eben nur kurz Funktionalität durch testen will.

Okay. Das heißt, die Ausfallsicherheit ist dann quasi noch die Umgebung anpassbar, sodass ich pro Umgebung das festlegen kann. Genau.

Also es kommt natürlich aufs hammerhart an. Wenn ich jetzt was vorge Bauteils nehme. Irgendein offiziös. Dann muss ich halt gucken, was ist da g Templates. Also was kann ich durch Variablen ändern? Aber wenn ich jetzt ein eigenes Chart Bauer z.B. für meine Anwendung, die ich jetzt selber entwickelt hab mit allen Abhängigkeiten kann ich beliebig in diesen kybernetisch Ressourcen wie jetzt bei eben schon erwähnt mittels den go templates kann ich dann einfach jeden beliebigen Punkt also ob es jetzt in der Environment variabel ist, obs Memory Limits oder sonst was sind, kann ich alles beliebig als variabel definieren.

Im Template und dann eben in einem separaten Pfeil kann ich dann sagen okay, das sind meine Values, die eben für Produktion sind. Das sind meine Waldis, die für die Testumgebung sind. Und so lässt sich das dann beliebig anpassen auf die Infrastruktur im Beispiel jetzt auch wenn man ein fertiges Chart hat. Das macht das Ganze auch so mächtig. Nicht jeder will sein Monitoring gleich aufsetzen. Der eine hat eben andere Ansprüche, auch an Verfügbarkeit oder auch die viele Daten überhaupt gespeichert werden.

Wenn es jetzt Richtung Valium Claims und so geht und das lässt sich dann halt eben beliebig konfigurieren und das macht das Ganze auch so mächtig. Ja, verstehe.

z.B. in meinem Alltag ist es total sinnvoll, dass man sagt in der Produktions Umgebung hab ich z.B. 50 Ports um die ganze Last abzuwickeln. Also dieser Produktions Anwendungen. Aber in meiner Testumgebung, der teste ja nur ich. Da brauche ich viel weniger Disk Space, kann die kleinen Cloud Instanzen nehmen, das kostet dann weniger Geld wenn man will ja nicht. Vielleicht zum ganzen Cluster nur für die Entwicklung dann Überstunden betreiben und kann das dann eben so konfigurieren, dass das passt.

Und das ist auf der einen Seite viel Last bewältigen kann, im Produktionsbetrieb aber im Development Betrieb dann sehr kostengünstig ist, dass man theoretisch ein paar Dollar am Tag jeder Entwickler seine eigene Umgebung hoch und runterfahren kann mit nur wenigen Maschinen aus dem gleichen Hemsworth heraus.

Genau das kann man auf jeden Fall machen. Wie gesagt, es kommt da immer auf das Template an, was genau jetzt konfigurierbar ist und was nicht. Aber das ist auch das Schöne an diesem ha’m Ansatz, wenn ich jetzt selber einen Chart entwickel. Wir hatten ja schon angesprochen, die Struktur ist so, ich hab da mal einen Chart dort Jamel mein Haupt Jamel Fall, was halt so einen Namen vergibt Version Abhängigkeiten und dann kommt halt ein Template Ordner, indem eben diese ganzen Ressourcen liegen.

Und im Prinzip kann ich erstmal von alleine kybernetisch Ressource ausgehen. Also wenn ich jetzt mir einen Cube Citi alte Skripte mache auf eine Ressource im Jamil Format, dann kriege ich im Prinzip schon die Datei, die kann ich in dem Template Ordner ablegen und dann ist das Ding erstmal gelaufen. Ich kann dann eben im Nachhinein sagen okay, hier steht jetzt Reply CAS 3 drin. Ich möchte das jetzt konfigurierbar machen und dann kann ich eben da ganz einfach das mit dem GO Template in Format teilt.

Ja, Template draus machen und da gibt’s natürlich ganz viel Advanced darf das man halt auch anfangen kann Funktionen zu bauen, die dann von bestimmten Sachen wie jetzt welchen Get Lab Branch ich das jetzt baue und so weiter die Variablen anpassen. Aber das ist alles advanced. Das Schöne ist, dass man halt wirklich so step by step das Ganze aufbauen kann.

Das heißt, man kann sehr schnell starten, weil man es einfach verstehen kann. Aber die Erweiterungen Möglichkeiten sind mannigfaltig, sodass man auch komplexe Enterprise Anwendungen im @Helmut Charts verpacken kann.

Genau hier also für jeden der kybernetisch benutzt, ist das eigentlich überhaupt kein Problem Helmuts zu bauen, weil man eben immer bei den Intels Ressourcen anfängt und dann eben bestimmte Sachen konfigurierbar macht.

Das heißt mit Helm Charts sind im Grunde diese Dateien gemeint, die eben diese Orchestrierung beschreiben.

Ja, also das ist ein bisschen verwirrend, weil das Startort Jamel ist ein Fail, was zu einem Heyme Chart gehört. Aber genau wie du sagst das ganze Paket. Also die Templates, das Valerius Free und das Chart dort Jamel, also die Beschreibung von dem ganzen Chart, das ganze Paket, das Wandel, das nennt man eben Chart.

Okay, verstehe. Das heißt, wenn wir nochmal die Vorteile von Helmi Charts zusammenfassen, was bringt mir deren Verwendung? Dann kann man schon sagen erstmal bündelt es die Anwendungs Informationen. Also welche Dienste brauche ich, welche Williams brauche ich, welche Ports brauche ich? Die sind da ja alle beschrieben und einfach erweiterbar. Also wenn man ein weiteres Molden brauch, kann ich das einfach da eintragen und es würde dann hinzugefügt. Änderungen durch die Git Versionierung keit können einfach nachverfolgt werden und es gibt bereits eine große Bibliothek von vorhandenen Pane Charts, die ich entweder inkludieren kann oder als Basis für eigene Entwicklung nutzen kann.

Ja genau. Was vielleicht noch ganz interessant zu wissen ist. Wir haben ja schon gesagt, Heyme macht eben diesen ist Säufer gleich und das gantzer Kommando. In diesem Fall wäre das dann Häme Upgrade. Das ist eidam potent, also idR impotent im Deutschen. Das bedeutet, ich kann das Kommando so oft ich will absetzen und es ändert eigentlich nichts, außer dass jetzt die Release Noma hoch gezählt wird im Cluster. Aber abgesehen davon läuft meine Applikation. Ohne angefasst weiter.

Wenn ich jetzt keine Änderungen gemacht habe und das ist natürlich eine super Grundlage für Scripting, dann also, wenn ich das jetzt in der Pipeline packe oder so, kann das halt dann super einfach immer abgesetzt werden, weil das sich eben selbst darum kümmert, die nötigen Schritte durchzuführen.

Naja, okay, verstehe. Das heißt, wenn zwei Maschinen fehlen und du setzt Upgrade ab, dann Start. Der hat die zwei Maschinen. Und wenn das gleiche Kommando eine Minute später nochmal abgesetzt würde, würde einfach gar nichts passieren, weil er erkennt Ah, der Zustand, wie ich ihn beschrieben habe im HAMCHA. Das ist der Zustand, der auch im Cluster vorliegt. Das heißt, ich muss nichts machen. Genau. Wir haben in Episode Nr. sechsunddreißig über Terraforming gesprochen.

Das nutzt ganz ähnliche Mechanismen, um die Basis Infrastruktur, also z.B. diesen Kybernetisch Cluster aus der Taufe zu heben. Auf einer Cloud Lösung oder einer vorhandenen Infrastruktur und das ist natürlich in Kombination mit Kobanê des und Helmut Scharz kann man sozusagen von den Maschinen über den Cluster bis hin zur Anwendung eine komplette Basis Infrastruktur aus der Taufe heben mit dem Infrastructure as a Service Ansatz.

Das ist vielleicht noch ganz interessant, wo du jetzt Terraforming erwähnst. Viele Leute bringen das ja durcheinander. Terraforming hän Antriebe. Wo ist jetzt hier die Abgrenzung eigentlich? Und wie du schon gesagt hast, Terraforming ist halt eher Infrastructure Xcode. Also da hole ich mir dann irgendwie einen Cluster aus dem stampfe ich mir aus dem Boden und im hellen Bereich. Da ist man dann halt eher so bei den Applikationen, Middleware und sowas wie du gesagt hast. Terraforming hält ja auch für Zustand.

Bei Terraforming ist es so, dass der Kleinen seitig gehalten wird in dem Pfeil. Dieses Fall kann ich auch angucken und bearbeiten. Bei Helm ist es so, dass sich das ist auch abhängig von der Version. Da hat sich auch viel getan von der Version 2 zu 3, aber im Prinzip werden die ganzen Informationen im Cluster gehalten. Bei der neuen Version Version 3, da werden die Informationen in dem Namespace gehalten, wo auch mein Release läuft, also die Applikation, die ich installiert hab.

Und das hat eben den Vorteil, dass dann auch so Sachen wie jetzt Rol based Access Control von kybernetisch aus direkt umgesetzt werden. Also dass der Benutzer, der dazu berechtigt ist, das Deployment zu ändern oder überhaupt was zu Diplomen die Möglichkeit kriegt, wobei jemand anders, der dann eben nicht die Rolle hat, diese Möglichkeit unterbunden ist.

Also so eine Art Zugriffs Beschränkung mit Hilfe der Aarburg Policy genau Vorjahr bei Hellem 2 war das nicht ganz so einfach.

Das hat super funktioniert, wo Kybernetisch Arbat noch nicht implementiert hat. Weida hatte noch einen Server im Kybernetisch Cluster der laufen musste. Der sogenannte Tilla Server oder Tilla wird er auch einfach nur genannt. Und dieser Tilla hat halt als Server funktioniert für das Ziel n Tool vom Client aus und der hat halt seine ganzen Ressourcen innerhalb seines Namens Spaces abgelegt. Also enorm viel war das in dem Cubes System namespace. Da lief halt der Tilla und der hat dann Config Maps erstellt oben eben seine Ressourcen und seinen Zustand zu halten.

Und jetzt? Neu ist eben bei Hemme 3, dass die Ressourcen in dem Target namens Bake, also da wo ich meine Deployment wirklich mache, abgelegt werden, was eben diesen Vorteil hat, dass man die Arak Funktion von Kybernetisch direkt mit einbindet. Na weil wenn ich jetzt mit meinem Kleintieren gehe und keine Rechte hab, dann kann ich natürlich auch diese config maps gar nicht lesen oder bearbeiten.

Ja, das ist auch Tilla. War ja auch so ein Sicherheitsproblem, weil halt alle Leute, die sozusagen mit dem Tiller sprechen können, auf alle verwalteten Ressourcen Zugriff haben. Und jetzt über die Arbaces kann man das etwas feien Granulat wa steuern? Also man sollte auch für unsere Zuhörer, wenn man heute anfängt, auf jeden Fall mit der Version 3 von Helm beginnen. Genau hier. Ja, das ist vielleicht nochmal, um diesen Zweck klarzumachen. Ich finde das ganz interessant.

Du musst dir einfach vorstellen, oder? Unsere Zuhörer können sich einfach vorstellen, man hat diese laufenden Server einfach im Rechenzentrum, also hunderte oder tausende davon. Mittels Terraforming bündelte ich einige dieser Server zusammen zu einem Kybernetisch Cluster. So und der Cubaner? Das Cluster ist sozusagen ein STANDARD, der ob er jetzt bei Escher läuft, bei Google in der Cloud läuft oder bei AWS Amazon in der Cloud läuft oder irgendwo anders auch im eigenen Rechenzentrum sich mehr oder weniger gleich verhält.

Und auf diesem kybernetisch Cluster oder in diesen kybernetisch Cluster kann ich jetzt mittels Helm meine kybernetisch Anwendungen diplomen. Und wenn man diese drei Werkzeuge zusammennimmt also Terraforming Kybernetisch Helm komme ich relativ weit weg von diesem Vendor Lock in genau.

Ja wie du schon sagst. Also ich meine Kuba Annettes generell ist schon ein richtiger Schritt in die Richtung, dass man halt einfach eine Basis schafft und dann eben man nimmt ja gerne den Begriff Cloud Agnostikern in den Mund, also dass man eigentlich sich nicht wirklich drum kümmern muss, was unterhalb von Kybernetisch läuft, weil man da eben diese fest definierten Standards von Kybernetisch hat, also die Ressourcen und so weiter. Und klar, wenn ich dann ein. Dann bin ich da flexibel.

Also wenn du Helm benutzt, bist du da flexibel und hast quasi den ganzen Steg aus dem Vendor Lock in herausgezogen. Genau hier. Das heißt also, das ist ja wirklich toll, diese drei Komponenten oder softer Komponenten, die auch frei verfügbar sind in Kombination binnen Minuten hab ich quasi aus STANDARD Servern hab ich ein komplettes System aufgesetzt. Ich hab meine Infrastruktur pro Visionär. Ich hab mein kybernetisch klasse laufen plus ich habe meine kubanisches Anwendungen laufen und kann zu Testzwecken ja ganz beliebig diese Infrastruktur binnen Minuten hoch und runter fahren.

Kann Updates einspielen, kann Roll backs durchführen. Das hast du eben schon angesprochen, dass Helmut Shard selber dient. Natürlich auch. Jetzt muss man sagen für Entwickler auch als eine Art Dokumentation der Anwendung, weil ja genau beschrieben ist, was hängt von welchen Komponenten ab, welche Ports kommunizieren miteinander. Alleine das hat ja schon ein Wert, dass man sozusagen eine Anwendungs Dependency Graw generieren kann. Aus dem Hemd Shard. Ich weiß nicht. Gibt es da ein Kommando, dass man es irgendwie visualisieren kann?

Deshalb gute Frage. Das weiß ich tatsächlich gar nicht. Aber wie du schon sagst, das ist ein enormer Vorteil, den ich auch immer wieder gerne kommuniziere. Dass man eben durch das Coden von Schritten, die man durchführen muss, im Prinzip die Dokumentation überflüssig macht und auch damit eigentlich Fehler beseitigt. Wenn jetzt Sachen manuell durchgeführt werden, dann können immer Fehler entstehen. Man muss jemanden da haben, der aktiv zur Seite steht, mit dem Kopf da ist und wenn man das eben einfach automatisiert hat, sowohl mit Tera Form an.

Simple aber auch eben helfen könne einen dieser Fehler nicht so schnell unterlaufen.

Um ein plastisches Beispiel zu geben Stell dir mal vor, du bist verantwortlich für den sagen wir mal für den Server oder für die Helm Anwendung, die hier die Server betreibt, wo jeden Tag 20 Millionen Leute die Liste der Coruña infizierten runterlädt. Also das Beckhams sozusagen verdienender Corona Server. Und du würdest jetzt feststellen oh, die Anwendung wird sehr oft aus den App-Stores geladen. Ich muss irgendwie hoch skalieren. Das wäre eine relativ einfache Änderung. Würdest du das dann im @Helmut Chat mittels Reply CAS ändern oder was genau würdest du da einstellen?

Lustigerweise ist das Coruña App oder Coruña Waren App Server Beispiel eigentlich ziemlich gut, weil man da mehrere Komponenten drin hat. Zum einen Documentation. Wenn ich jetzt meine Heimat Charts publiziere einem Ghetto Chopra Satori Open Source, dann kann jeder sehen was läuft da eigentlich? Wie ist die Infrastruktur aufgesetzt? Wo läuft das Ganze? Und das hilft halt wirklich dann auch bei der Dokumentation, dass der Punkt 1, wie du sagst. Dadurch, dass ich dann mit meinen Templates eben diesen Replika Faktor einfach schnell hochsetzen kann, kann ich dann auch super schnell reagieren auf irgendwelche Anfragen.

Der Anstieg von Anfragen gut kybernetisch macht das natürlich auch schon mittels Autos Gayle. Aber wenn man jetzt in die Richtung geht, dass man mehrere Standorte hat, also eine globale Applikation hat, dann kann ich halt auch wirklich sagen Hey, wir haben jetzt einen neuen Markt irgendwo in Asian Pacific Area, dann kann ich einfach sagen So, da fangen wir jetzt an und da brauche ich jetzt ein Rechenzentrum und da hilft mir halt sowohl Theaterformen für die Infrastruktur, aber auch ha’m, vor allem, weil ich eben meine Applikationen in Minuten ausrollen kann oder eher Sekunden.

Ja, ich glaube auch an ein anderes gutes Beispiel ist, wenn ein ganz verbreiteter Messenger für Mobilfunk, Geräte oder für Smartphones seine Policy, seine Daten Policy ändert und auf einmal die anderen Messenger einen immensen Nutzer Ansturm zu verzeichnen haben. Das wäre auch so eine Situation, die in klassischen Server Umgebungen oh Gott, jetzt muss ich Server bestellen und die Immi mieten. Okay, ich bin in der Cloud, das heißt, ich kann in ein paar Klicks hinzufügen, aber das möchte man eigentlich auch nicht.

Man möchte im Grunde eine Anwendung so resilient implementiert haben, dass sie von selber, wenn sie wächst mehr Server Kapazitäten WIP mit kybernetisch mit Autos galligen automatisch sich beschafft bis zu einem gewissen Schwellwert.

Naja, das ist definitiv ein Vorteil. Ja und das ist dann eben ne kybernetisch Funktion bzw. in Helm selber kann man ja auch darauf Einfluss nehmen. Ja also wenn man zwei Beispiele genannt der Coruña ERP Listen Server und die anmeldest Server für Smartphone Messenger. Das ist natürlich auch eine Unternehmenskunden, die uns zuhören. Interessant wenn sie Nutzer Ansturm haben bei gewissen ich sag mal Black Friday Verkäufen oder Medienberichterstattung zu einem Unternehmen oder wenn Marketingkampagne laufen, wo halt in kurzer Zeit viele Kunden die Angebote nutzen.

Oder ein jüngstes Beispiel aus der vergangenen Woche, wo teilweise Server von Brokern Probleme hatten, weil eben ganz viele Aktien gehandelt werden auf einen Schlag. Da kann man dann gegenhalten.

Auf jeden Fall. Das hilft halt einfach schnell zu reagieren, weil ich eben dann nicht manuell. Irgendwelche Schritte einleiten muss, meinen Experten, der dann vielleicht im Urlaub ist, irgendwie ans Telefon kriegen muss. Sondern ich habe eben einfach die Dokumentation mehr oder weniger da und eben kann ich auch einfach Änderungen vornehmen direkt im Code, muss nicht mal irgendwo groß rum klicken, sondern ich mach das halt wirklich genau an der Stelle, wo ich brauch. Und da es so einfach ist, kann das natürlich auch automatisiert passieren, also direkt vom Computer.

Bevor wir jetzt noch auf weitere Details von Helmut Charts eingehen, würde ich dich noch fragen. Gerne zu deinem Erfahrungsschatz. Und zwar ist es deiner Erfahrung nach so, dass Firmen eher anfangen, neue Anwendungen auf Kuba nettes zu entwickeln und dann auch direkt zu @Helmut Charts zu erstellen? Oder werden auch viele Bestands Anwendungen also vielleicht alte Monolithen, die jetzt noch nicht so dem Mikroskops Paradigma folgen auch in Kuba Annettes Pakete verpackt und dann auch mit Helm Charts ausgerollt? Wie ist da deine Praxiserfahrung?

Also meine Praxiserfahrung ist eigentlich fast immer das gleiche und zwar dieses ganze Klout Thema kommt ja auf die Firmen zu und die wissen auch, dass die da was tun müssen. Die meisten haben kurz vor 12, also da ist das wirklich ein heißes Thema. Und da dann meistens auch relativ viel Funding in der Region dann zur Verfügung gestellt wird, passiert das doch meistens, dass Anwendungen grundsätzlich nochmal neu überdacht werden und dann auch eben der Microservices Ansatz umgesetzt wird, weil man eben, wenn man sowieso alles umzieht.

In diesem alten monolithischen Umfeld hat man natürlich seine großen Anwendungen irgendwo auf dem Server, der von irgendwem mit Hand konfiguriert wurde und wahrscheinlich irgendwo ne ganz dicke Dokumentation auf dem Schreibtisch liegt. Und da jetzt zu sagen Okay, ich hole das jetzt alles in die Cloud, das ist sowieso Arbeit. Und dann überlegen sich die Unternehmen meistens, dass es dann sinnvoller ist, das Ganze sowieso direkt schon um zu design, weil diese großen monolithischen Anwendungen haben ja auch was Skalierung betrifft Probleme.

Die sind meistens auch überhaupt nicht dafür gebaut, Verteil zu laufen. Und diese ganzen Cloud Native Komponenten API, Gate, Boyce und allen möglichen Sachen wären da gar nicht wirklich gut eingebunden. Wobei, wenn man dann nochmal wirklich sich anguckt, was gibt’s heutzutage für Frameworks, was ist der Stand der Dinge, dann kann man da seine Applikationen schön direkt Cloud Native neu designen. Und das ist auch das, was ich zurzeit hauptsächlich beobachte dass der Schritt eben auch direkt gemacht wird und die Applikation neu Design wird.

Man hat ja auch aus seinen Fehlern gelernt. Man weiß, wo sind die Schwachpunkte und manchmal sind das ja wirklich grundlegende Sachen, wo halt die Struktur von dem alten System einfach nicht so richtig passt.

Ja, genau, also das ist auch meine Erfahrung. Die alten Systeme funktionieren ja irgendwie, sonst wären sie ja nicht mehr da. Die lässt man vielleicht noch einfach weiterlaufen und steckt da gar nicht so viel Liebe rein. Aber wenn zukünftige Anwendungen entwickelt werden, benutzt man natürlich die neuen Technologien oder erweitert die alten Technologien um eine Komponente, die dann eben schon in der Cloud läuft. So ist auch meine Erfahrung. Also ich habe auch noch nicht gesehen, dass man Monolithen eins zu eins einpackt und dann in Kybernetisch betreibt.

Das wäre sicher auch dann ungünstig.

Ja, da hat sich einfach sehr viel getan, jetzt auch in der letzten Zeit. Wie einfach Applikationen strukturiert werden und implementiert werden, also gerade Sachen Richtung Datenspeicher und so in der Cloud geht man halt nicht davon aus, dass man immer so lokal seinen Speicher direkt bei der Anwendungs Logik hat, sondern geht da dann eher hin und benutzt externe Komponenten. Es kann ja auch eine skalierbare Datenbank sein, die auch im Cluster läuft. Aber eben dadurch, dass alles fein Granularität strukturiert ist, kann ich eben auch beliebig hoch und runter skalieren, so eben wie die Funktion benutzt werden von der Anwendung.

Lass uns doch nochmal etwas ins Detail gehen und nochmal genau besprechen, wie ein Helm Shard genau zusammengebaut wird oder wie das funktioniert. Möchte uns da kurz mit an die Hand nehmen, um das einfach mal strukturiert nochmal von Anfang bis Ende kurz zusammenzufassen, weil wir haben ja jetzt schon hier und da das Thema mal angeschnitten.

Ja, also das Hemd Shard ist eigentlich ein Wandel aus verschiedenen Dateien. Und die Haupt Datei ist eben dieser Chat dort Jamel, die eben dann einfach nur grunt information über das Chat enthält wie jetzt den Namen Version Abhängigkeiten. Und weiter gehts dann eben mit dem Templates Folder. Das ist so standardisiert der Ordner, der eben diese ganzen kybernetisch Ressourcen beinhaltet. PM nimmt dann einfach alles in dem Ordner und Diplomat das ins Cluster. Das heißt, wenn ich ein Pfeil da drin habe was überhaupt nicht ein Template ist, was einfach nur eine kybernetisch Ressource ist, dann wird hier auch genauso im Cluster ausgerollt.

Dann kann ich natürlich keine Konfiguration Änderungen machen mittels variabel, aber manchmal ist das ja auch gewollt. Dann die des Template Ding selbst. Das funktioniert eben mit diesen Gol Templates und alle goh lang internen Funktionen Template Funktionen sind abgebildet. Also wenn man da in der Sprache schon ein bisschen Erfahrung hat, hilft das natürlich immens. Aber Heimat auch noch weitere. Funktion hinzugefügt, dies dann leicht machen eigentlich alles mögliche zu Templeton, was Person nur Beispiel Funktionen, die man nutzt.

Also ich hab jetzt noch nicht viel mit Go lang gemacht, aber gibt es vielleicht eine funktionierende häufiger nutzt und die dir hierzu direkt einfällt?

Ja, also es gibt verschiedene Möglichkeiten, aber es gibt ja auch bestimmte Anwendungen. Wollen ja auch irgendeinen random character String haben, z.B. um krypto grafische Strukturen zu initialisieren.

Und da könnte man dann jetzt einfach in dem hammerhart sagen Gib mir random alpha numerische Ziffern generieren er ID oder sowas und das ist mein zaehlt für irgendwie eine Verschlüsselung Funktion, oder?

Genau das wäre jetzt ein Beispiel. Ich meine, ähnlich würde es oft auch mit Passwörtern gemacht, die eben nur Admin Passwörter für irgendwelche Datenbanken, die nur innerhalb des Clusters einem Sekrete sein sollen. Und da will man das Passwort ja explizit auch randomisiert haben. Das heißt, dass man halt gar nicht erst irgendwie eine Schwachstelle hat, wo irgendwer das Passwort kennt zu irgendeiner Datenbank, sondern das wird einfach direkt alles innerhalb des Clusters abgespeichert und keiner braucht da Zugang zu genau bei den Templates.

Ist vielleicht noch interessant für die, die da jetzt noch nicht so mächtig sind. Mit der Jamel Syntax ist natürlich empfohlen, das in Jamel zu machen. Das wird ja in vielen anderen Bereichen auch verwendet, weil das eben so schön lesbar ist. Aber für die, die’s Probleme macht Jamil ist ja eine obere Menge von Jason, also jede valide Jason Struktur ist natürlich gleichzeitig eine valide Jamel Struktur. Das erlaubt mir dann auch Jamil zu schreiben und wenn ich mal nicht weiterkommen.

Kurz die Ressource oder die Struktur eben in Jason darzustellen. Das wird ganz normal dann verwendet von Ham wie jedes andere Jamil und ja, funktioniert auch so was dann vielleicht noch interessant ist, ist das Beliefs. Das hatten wir schon ein paarmal ein bisschen angerissen. Hier nochmal explizit das ist eben ein Fall, was einfach Variablen definiert. Alles, was ich in dem Chart konfigurieren kann, kann ich in diesem Various Fall anpassen. Das heißt, ich kann dann eben, wie wir schon vorher gesagt haben, die Replika aus einer Anwendung anpassen und ich kann eben auch verschiedene Valerius Fails für verschiedene in Wassermanns benutzen.

Das heißt, wenn ich jetzt z.B. einen Gegenpol Süd-Korea kann ich auf jedem Bronstein auch ein unterschiedliches Belgiers Fall ablegen. Wenn es jetzt Development ist, was dann in die Test in Valmont geprobt wird, will ich da vielleicht andere Werte, andere Hoch Verfügbarkeit Werte haben als jetzt bei Produktion in Wahrnehmens.

Ich könnte auch Suchtest Nutzernamen da unterbringen. Dann heißt der User auf Test heißt der User minus test und auf in der Produktion wird er ganz weggelassen.

Wo solche Geschichten dafür wäre das welches Faltern da genau das Beliefs Fall ist natürlich auch wenn ich mir jetzt irgendwie von extern eine Ressource rein hole. Wenn ich jetzt z.B. einen Promi fürs Monitoring aufsetze, dann ist das Fall eigentlich die einzige Komponente, die ich mir dann auch selber privat abspeichern muss in meinem Git Repository, wo ich meine Changes Tracker, weil ich im Prinzip mit dem Chat dann direkt gar nichts zu tun habe. Ich passe nur dann Sachen an wie jetzt wie viel Speicher klemme ich, damit eben bestimmte Metriken abgespeichert werden und so weiter.

Und das ist alles was, was ich einfach bei mir in dem Delius enda aber grundsätzlich die Templates des Shard, das fasse ich gar nicht an, weil wenn da dann Änderungen Fixes eingespielt werden, dann werden die halt auch eben mit jedem Upgrade dann automatisch ausgerollt.

Das heißt, ich hab jetzt das Hemd Shard zusammengebaut mit Radius Jamil Templates, TV-Gelder, Charts, Jamil hab das auf der Festplatte oder es ist ne sollte ich lieber sagen. Und wie installiere ich das jetzt? Also ich hab die Anwendung da orchestriert in dem Helm Chart. Und wie schafft die Anwendung es jetzt in den Kybernetisch Cluster?

Also ganz konkret passiert das eigentlich mit Helm in Stowe und dann kann ich dem eben mit Minus ein Wadephul geben und dann gebe ich dem ganzen noch einen Release Namen. Den kann ich mir eigentlich mehr oder weniger aussuchen und dann bestimme ich halt noch welches Chart das ist. Das kann natürlich ein externes sein. Da sage ich dann bei einem Engine X z.B. Vietnam Nami Schrägstrich Engine X, also aus dem Vietnam Repository, dass Engine X Chart und dann wird das direkt installiert.

Also dann werden die Schritte eingeleitet, dass im Prinzip alle Abhängigkeiten und alles installiert werden in dem Cluster. Wenn ich jetzt natürlich das Ganze schon am Laufen hab, dann würde ich nicht mehr ins Stäube nutzen, weil Naniten. Steul schlägt fehl. Ein Stall ist nicht wieder impotent, sondern das Install ist ein mehr oder weniger imperatives Kommando, was halt einfach die Installation vornimmt. Normalerweise benutzt man tatsächlich Helme Upgrade und ich benutze eigentlich am liebsten Helme Upgrade minus AI, was soviel heißt wie machen Upgrade und wenn nichts da ist installierst.

Also dieses Kommando ist sozusagen alles in allem. Das Shard wird installiert, wenn es nicht da ist. Und ja, das ist auch das, was man dann eigentlich in Çiçek Scripte oder. Wo bei Automation einbaut, weil das eben diese idem Potenz hat. Okay, verstehe. Das heißt, man braucht sich im Grunde nur ein Kommando zu merken Upgrade minus ai oder minus y und Trends nicht installiert. Es wird die Anwendung installiert in der Version und wenn sie bereits installiert ist in der gleichen Version wird nichts gemacht, außer das Toyo Release Nummer instrumentiert wird und wenn die Anwendung installiert ist in einer vorherigen Version wird auf die aktuelle Version gab geredet.

Genau. Also es gibt natürlich dann auch Advanced Sachen, also haben unterstützt auch Semantic Versionen. Aber also da kann man dann die Release Nummer entsprechend anpassen. Aber das sind dann Sachen, die relativ Fettwanst sind.

Für jeden der jetzt kurz nach einer Anwendung erstmal die Pointe reicht das auch erstmal so dann die Unterschiede zwischen der Helm Version 2 mit dem Tilla Server, der sozusagen im Kybernetisch Cluster läuft und alle Aktionen durchführt und der Version 3, die mittels Airbag auf die ihr zugewiesenen rechte Bereiche zugreifen kann, um die Aktionen durchzuführen. Da bist du ja schon drauf eingegangen. Wie verbreitet ist Helm denn und lohnt es sich das genauer unter die Lupe zu nehmen? Ich glaube da haben wir fast schon eine Antwort gegeben im Verlaufe des Podcast.

Aber vielleicht fassen das nochmal zusammen.

Ja klar. Also das ist auch wirklich haben wir die Sache ganz am Anfang ja angerissen, dass Helme einfach extrem an Popularität zugenommen hat. Also es ist einfach inzwischen auch Grundlage für viele andere Systeme. Also im Ranga Rangiere ist ein Overlay über ein kybernetisch Cluster und das vereinfacht einfach die Verwaltung von kybernetisch Clustern. Da gibt’s ne schicke Joi, wo man das alles verwalten kann und da gibt’s eben auch einen Katalog.

Also das ist im Prinzip wie so eine App Store voll Kybernetiker und der basiert natürlich auf Helme und andere Bonnard sozusagen unter der Motorhaube im Hintergrund.

Genau da läuft dann natürlich Helm ganz normal und da sind auch die offiziellen Helme Repositories. Dann weiter geht’s ja dann noch, das geht ob’s Tool Flachs, Version 2 und das benutzt auch Helm Charts für Deployment. Also das Richtige ist hier natürlich die Version 2, weil da hat sich ja viel geändert zur Version 1, aber das ist so ein Get up Stuhl, wo man eben seine ganze Infrastruktur und Deployment alles entgeht, Repositories hat und Flachs bildet. Die Brücke zwischen den Geth Repositories und der Infrastruktur also ist guckt einfach aktiv.

Hab ich Änderungen in den Geth Repositories? Wenn ja, dann führt das eben die nötigen Kommandos aus. Also sozusagen das Scripten von Ham Upgrade.

Das finde ich richtig cool, muss ich mal sagen. An der Stelle du hast Watcher auf dein Git Repository yum, der bei Änderungen losgeht und dein kybernetisch cluster Status aktualisiert oder updated. Also das ist schon SII ICD auf höchstem Niveau finde ich persönlich es auf jeden Fall.

Das ist für mich auch so der letzte Schritt, der eigentlich alles zusammen packt. Dann war man hat natürlich das Problem, dass die Akzeptanz von Infrastructure oder auch Konfiguration oder sonst was. Ascot halt immer ein bisschen unterschiedlich ist. Es gibt ja auch gewisse Kollegen, die dann auch doch Änderungen manuell vornehmen. Wenn dann wirklich die Hütte brennt, dann hat man manchmal auch das Gefühl, jetzt hier in den Code zu gehen, das zu ändern, das zu Kometen Commit Message zu schreiben, zu pushen, dann wieder nicht woanders einzuloggen, eine Pipeline zu triggern oder sonst was.

Da haben viele dann irgendwie das Gefühl, wenn dann wirklich mal was los ist, dass das zu lange dauert. Und dann kann es schnell passieren, dass der Zustand, in dem geht Repository und in der Infrastruktur divergieren. Und soweit ich da bin, wird’s wirklich kompliziert. Das Schöne ist beim flachst, dass ich den Benutzern gar nicht mehr die Möglichkeit geben muss, manuell Sachen zu ändern. Bei jeder oder jeder. Der muss hat Zugang zu den Repositories und kann da einfach seine Änderungen machen.

Und das wird dann einfach im Hintergrund automatisch auf die Infrastruktur ausgerollt.

Ich sehe da noch einen ganz anderen Vorteil und zwar bis flux. Ja, so eine Art erweiterter Commit Hook. Das heißt, ich weiß, wenn ich mein Kotaku Mitte und auf Master Merge oder auf einen Release Branch merge, der wird dann automatisch Diplomat. So und das auf Entwickler Seite erzeugt dann eine Art erhöhtes Qualitäts Gefühl. Lass mich das nochmal sagen. Ich glaube auch, dass Flags und die Konsequenz daraus, dass wenn ich etwas Kommittee und auf den Master Branch merge, dass das automatisch Diplomat wird.

Das führt dazu, dass man das Testing noch ernster nimmt und noch mehr Tests schreibt, um einfach zu sagen Okay, wenn ich das jetzt hier committee, kontrolliert das kein Mensch mehr, sondern es wird wirklich produktiv ausgerollt. Wenn man das möchte und so einstellt. Und ja, das ist eigentlich eine gute Sache, dass man im Prinzip dann noch mehr Tests schreibt oder die Tests nochmal gründlicher checkt. Manuel checkt, um zu sagen Das muss ja alles Test Bar sein, sonst kann es sein, dass sich vorne was kaputt mache.

Das hilft auf jeden Fall dabei. Und das hilft natürlich auch der. Die Akzeptanz, also, dass Änderungen dann auch wirklich zur Infrastruktur kommen. Die Zeit ist einfach geringer, weil ich weiß, sobald ich was da rein packe, ich muss niemand Bescheid sagen, ich muss keinem sagen Hey, ich hab hier wieder eine Änderung. Roll das doch mal bitte auf die Infrastruktur aus, sondern das passiert dann einfach. Und das ermöglicht natürlich auch wiederum ganz andere Reaktionen bei den Entwicklern, weil die natürlich ihre Changes instant auf der Infrastruktur haben und einfach die Anwender profitieren ja auch ganz deutlich.

Da ein fertig gestelltes Feature ja schneller ist, in die Produktion schafft und schneller dann auch aktiv genutzt werden kann, von den entweder ein Nutzer da draußen oder den Unternehmens Benutzern. Das möchte man ja auch, dass man die Time to Market würde man im BWL Kontext sagen ich sag mal code to user time möglichst gering hält. Auch als Entwickler ist es ja möglichst erstrebenswert, dass wenn doch noch Probleme oder Rückfragen kommen, dass man die möglichst zeitlich nahe zur Implementierung dann erhält und nicht Monate später, wenn man sich dann nochmal eindecken muss.

Unser Muss. Okay, was war denn jetzt nochmal genau Sachstand da?

Okay Julius, vielen, vielen Dank für die intensiven Einblicke in das Ökosystem von Helm Kybernetisch Terraforming. Es hat mich super gefreut.

Sehr gerne, ja. Mich hat es auch gefreut, dabei zu sein. Vielleicht nochmal einen kleinen TISA am Ende. Was natürlich möglich macht, es in Verbindung mit anderen Tools auch komplexe Deployment Strategien umzusetzen, also z.B. Canary Deployment oder Blue Green Deployment. Bei Canary Deployment würde ich halten Feature erstmal an eine kleine Gruppe von Leuten ausrollen und dann testen wie reagieren die da drauf? Ist die Responses Zeit von dem User? Also wie lange braucht der User durch die Seite zu browsen?

Ist die schneller? Ist die langsamer? Wird das UI plötzlich verwirrend oder wird das eindeutiger für den Benutzer? Und dann kann ich Stück für Stück das halt als Produktions STANDARD haben. Und bei Blue Green ist eben dieser Situation, dass ich im Prinzip meinen Production impliziere und meine neue Version in ein zweites Produktion in Valmont, die Pleuger und dann eben einfach den Traffic komplett von dem einen Production in das andere Router und so halt dann auch ohne irgendeine Art Downtime halt einfach um switchen kann auf eine andere Version und Tools wie jetzt zum Beispiel ist Théo, die helfen mit Helm zusammen ebenso Sachen automatisiert umzusetzen und sowas ist natürlich Next Level.

Also das ist wirklich advanced. Aber das ist auch das, was man wirklich braucht, wenn man Ansprüche an Verfügbarkeit hat und Automatisierungsgrad.

Wenn unsere Zohra eine Frage haben oder Feedback zur aktuellen Episode, freuen wir uns über eine E-Mail an Podcast Skill bei Gilbert. Wir freuen uns immer über Bewertungen des Podcasts und natürlich Weiterempfehlung an eure Freunde und Kollegen. Das ist ganz ganz wichtig, wenn ihr die Podcast Episoden und die Inhalte als wertvoll erachtet. Empfehlt den Podcast gerne an Freunde und Kollegen. Weiter schaut Rolfs Gilbert de Slash Blog vorbei für weitere spannende Technologie Themen. Vielen Dank Julius für die Einblicke in Helm.

Und bis bald.

Bis bald.

Maurice KnoppSkillbyte Podcast #43: Helm – Der Kubernetes Paketmanager
Mehr

Skillbyte Podcast #34: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions, Google Cloud Functions richtig verwenden

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

In diesem Podcast geht es um das Thema: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions,
Google Cloud Functions richtig verwenden

// Inhalt //
01:04 – Was ist Serverless Computing?
03:15 – FaaS – Functions as a Service
06:43 – Cloud Anbieter für Serverless Computing
07:52 – Abrechnung von Serverless Computing Ressourcen
09:25 – AWS Lambda am Beispiel von Amazon Alexa
11:56 – Vorteil: Zeiteinsparung bei der Administration ist signifikant
14:25 – Vorteil: Abrechnung nur verbrauchter Ressourcen
15:16 – Vorteil: Kosten werden Transparent
17:09 – Vorteil: Kleine Teams können Anwendungen Millionen von Menschen zur Verfügung stellen
18:10 – Nachteil: Vendor Lock-in
20:04 – Nachteil: Keine Performance-Garantie
23:43 – Nachteil: Ressourcenbeschränkungen (CPU Zeit, RAM, Laufzeit, etc.)
25:34 – Nachteil: unflexible Laufzeitumgebungen mit fixen Softwareversionen
28:35 – Debugging bei der Entiwcklung von Functions
30:30 – In diese Szenarien ist Serverless Computing besonders sinnvoll…
35:34 – …und in diesen sind sie nicht besonders sinnvoll

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

Feedback und Fragen gerne an podcast@skillbyte.de

// AUTOMATISCH GENERIERTES TRANSKRIPT //

Herzlich Willkommen zum Skill bald Podcast Episode Nr. 34 Servile Computing Hype oder Chance Apps, Landa, Escher Functions, Google Cloud Functions und so weiter richtig verwenden abonniert unseren Kanal für mehr spannende Themen aus dem Technologie Umfeld. Wenn die Entscheider oder IT Fachkraft seid, lasse auch gerne eine 5-Sterne Bewertung da oder sendet uns eine E-Mail mit euren Fragen an Podcast Skill bei. Wir freuen uns auch immer, wenn ihr den Podcast an eure Freunde und Kollegen weiter empfehlt.

Ich bin heute hier mit Max von Skill bald Hallo Max, Hallo Moritz, es freut mich ganz besonders, da wir ja schon wirklich über ein Jahr zusammen arbeiten, dass wir heute diese Episode zusammen machen können.

Freue mich auch dabei sein zu können. Es hat mich immer gereizt, jetzt immer auch mein Thema gefunden und einen Zeitpunkt wo verpasst.

Ja und was für ein Themas ist auf der einen Seite ein hoch spannendes Thema Server es Computing. Auf der anderen Seite hab ich den Eindruck, dass es aktuell auch etwas gehypt wird. Wir können ja mal darauf eingehen, was servile Computing eigentlich ist. Was verstehst du denn darunter?

Ich verstehe zwei Sachen Wissen. Lattmann da sei einmal Server, alles im reinen Sinne oder so wie es jetzt im Moment und den Cloud Providern beworben wird. Bedeutet zwar aber, dass er erstmal, dass man sich selber nicht um die Hardware kümmern muss. Das heißt, dass man im Endeffekt den Cloud, wobei der dafür bezahlt, dass sie die Infrastruktur bereitstellen, wo man dann nur noch seine Anwendungen drauf ausrollen muss. Und das ist eben für mich erst mal der grundlegende Server des Computing an der Stelle.

Aber natürlich gibt es auch die engere Definition, die dann vor allen Dingen auch heute im Podcast eher die größere Rolle spielt. Bowls dann eher in Richtung Funktion Access Service geht, wo dann eben auch der ausführende Layer sozusagen nochmal abstrahiert ist, sodass man wirklich nur sehr wenig Aufwand selber hat, was man sozusagen bereitstellen muss. Genau, also die Wartung der Plattform.

Du hast eben gesagt Server lässt, man muss sich nicht mehr um die Hardware kümmern. Genau genommen muss man sich ja auch um einige Ebenen der Software nicht mehr kümmern. Also kümmern im Sinne von installieren, warten, Updates einspielen, den Server tauschen, wenn er mal alt ist. All diese Dinge also ganz klar sollten wir vielleicht sagen Server List Code läuft natürlich nach wie vor auf Servern, nur man hat keinen direkten Kontakt mehr dazu, weil eben diese Schicht weg abstrahiert ist.

Ich denke, das spannendste Thema für unsere Zuhörer ist die Abstraktionsebene Functions, also Service oder App. Faas.

Das ist auch die geschichtlich neueste Stufe der Server alles Ebene. Da geht es darum der Anbieter stellt eine Laufzeit Umgebung zur Verfügung. Also das kann eine Python Runtime sein. Das kann eine Java Run Time sein, eine dort net run time. Alle möglichen Plattformen sind hier denkbar. Und auf dieser Plattform werden dann eben einzelne Funktionen oder Programmteile ausgeführt und diese werden dynamisch gestartet anhand von bestimmten Triggern und auch skaliert. Also ob ich ein Bild konvertiere beispielsweise oder tausend Bilder konvertiere parallel.

Das ist damit dann möglich. Rampen für Cloud Provider eben dafür zuständig €000 Laufzeit Umgebung bereitzustellen, die dann parallel den Job abarbeiten können. Hast du in letzter Zeit selber schon Functions, also Service Funktionen entwickelt?

Hab ich in der Tat. Das war bei zwei verschiedenen Projekten jeweils verschiedene Anwendungsfälle. Einmal haben wir das genutzt, um Web Application also an der Stelle einer Westlake JAL bereitzustellen, die eben von außen aufgehoben wird. Dann Processing mach. Und je nach bestimmte Antwort zurückgibt. Der andere ist mehr asynchronen Fal, wo sozusagen durch Daten Anlieferung Funktion getriggert wird, die dann eben Daten einliest, transformiert und dann wieder raus schreibt. Und dann kann auch in einer Kaskade dahinter eben neue Fangzähne getriggert werden, sodass dann sozusagen dieser übliche Ettl Job durch mehrere verschiedene Functions abgebildet wird, wobei jede Funktion immer nur eine Transformation ausführt und dann Pappi Events wie Datei wurde geschrieben oder neue Datei existiert.

Angetriggert werden und dann entsprechend ihre eigene Verarbeitung an der Stelle fortsetzen. Das heißt, die Verkettung der Trigger ist quasi ein Stück weit der neue Programmcode. Wieso?

Bei einer Dominostein Reihe genommen würde ich sogar vielleicht noch einen Schritt weiter gehen und sagen, dass wenn man mit Pantheons arbeitet und da komplexere Logik umsetzen will, ist man eigentlich gezwungen Microservices mehr oder weniger in Reinform zu denken und umzusetzen, weil dazu, wenn er später noch kommen Franzens bestimmte Limitationen haben, was vor allen Dingen Performance angeht, also CPU Rechenzeit. Und dann ist so eine Funktion tatsächlich auch nur gedacht als einen logischen Schritt, sodass man, wenn man verschiedene Schritte in seiner Ausführung hat, hat man sozusagen immer wieder einen neuen Micros Service, der gekrault wird oder durch ein Event ausgeführt wird, einfach um ein plastisches Beispiel zu.

Geben Wir sind ja noch bei der Definition, was Server des Computing ist. Früher hätte man so eine klassische Webanwendung oder ein Webshop hätte eine Anwendung beinhaltet, wo dann die Bestellung ausgelöst wird, das Etikett ausgedruckt wird für den Karton, der später versendet wird. Plus die Zahlung von der Kreditkarte, mit der der Kunde bezahlt hat. Eingezogen wird und im letzten Schritt wird der Warenbestand um 1 Dex demontiert, um eben diese Bestellung dann darzustellen. Und im Server ist reich, während das einzelne Funktionen, die sich nacheinander aufrufen oder das kann er teilweise sogar auch parallel geschehen.

Aber Microservices in Reinform. Diese kleinen Funktions Blöcke, die sich dann eben nacheinander aufrufen, was man vielleicht noch sagen sollte, weil das Wort oder der Begriff Server des Computing oft marketingtechnisch ausgeschlachtet wird meinen kann, sind auch so Docker Container Round Times also die bezeichnen sich auch als Server. Alles das ist hier im Kontext dieser Podcast Episode nicht gemeint. Mir meinen wirklich nur einzelne Funktionen, die miteinander verzahnt werden können und nicht ganze Programme, Bausteine oder ganze Programm Plattformen die eben hochgefahren werden, wo man dann auf einer niedrigeren Abstraktionsebene einsteigen würde.

Im Grunde, wenn man die Geschichte der Applications Entwicklung sieht, sind Server lässt die neueste Stufe, denn es wird auch. Ich habe in einem Artikel gelesen DevOps als DevOps auf Steroiden bezeichnet. Man kümmert sich im Grunde nur noch um die Programm Logik, also die einzelnen Funktionen und die Verschaltung dieser Funktion von Deist als das Beispiel, was du gegeben hast. Max, dass die Funktion über eine API aufgerufen werden und dann eben weitere Schritte wieder über Abis anstoßen. Schon wahrscheinlich das Paradebeispiel im Server des Computing Bereich.

Mit welchen Anbietern hast du denn? Und Laufzeit Umgebung? Hast du denn jetzt schon Erfahrung gesammelt?

Persönlich hab ich schon so gut wie in den drei größten Cloud Anbietern gearbeitet. Also Amazon habe erst an der Stelle Track Software an Google Cloud Computing allerdings lediglich in Apps und den Ärger mit den befangene Pandoras gearbeitet. Das wäre an der Stelle daneben Landa Funktionen bei Apps und einmal ja Funkens, dann bei Microsoft.

Ich glaube bei Google heißt es Cloud Functions und bei IBM heißt es auch Cloud Functions. Aber das unter dem Begriff Lambada und dem jeweiligen Provider wird man ganz sicher den Produktnamen ausgraben können. Okay, ich glaube, da haben wir schon mal ein gutes Grundverständnis gegeben, was Server Computing ist. Also vielleicht noch ganz kurz Welche Laufzeit Umgebung hast du eingesetzt? Ich nehme an Python, oder?

Genau. Bei mir war es jedesmal Theißen. Allerdings wenn die relativ die Wert mittlerweile aufgestellt. JavaScript funktioniert und auch jede andere große Programmiersprache wird mittlerweile auch an der Stelle unterstützt. Vielleicht noch ein Wort zur Abrechnung.

Also klassische Server bezahlt man ja, indem man einfach die Server mietet oder? Beim Cloud Server wird ja auch pro Minute abgerechnet. Beim Server Computing ist das so ein Mix aus verbrauchten CPU Ressourcen. Remme Ressourcen und Durchsatz. Das unterscheidet sich glaube ich auch bei jedem Anbietern. Bisschen gab es unterscheidet sich auch dann nochmal zusätzlich, in welchem Kontext du sie verwendet. Also ich weiß, dass man bei Apps verschiedene Modi haben kann. Man kann die typische Lambda Funktion haben.

Man kann auch Lambda haben. Man kann die Landa Funktionen mehr oder weniger direkt dem Internet preisgeben oder ein API Gateway benutzen und je nachdem welches Modul man dann je nach Funktionsweise benutzt. Damit wird es auch nochmal ein bisschen anders abgerechnet. Beim Großen und ganzen kann man eben sagen, man bezahlt für die Ressourcen, die man auch tatsächlich einsetzt. Lambada bedeutet, dass die Funktions Ausführung möglichst nahe an den Endkunden herangeführt wird, oder?

Genau das hat. Ich glaube in dem Kontext zwei Bedeutungen. Einmal wird eben z.B. das API Gateway nicht benutzt, was dann eben auch nochmal zusätzlich ein Netzwerk Delay verursachen würde. Und wie du richtig gesagt hast, werden dafür auch Server benutzt, die eben sehr nahe beim Kunden stehen. Das wirkt dann, wenn man das so möchte und bucht quasi und auch bezahlt weltweit auf die verschiedenen Server verteilt, sodass dann je nachdem von wo der Kunde das aufruft, das dann an den nächst gelegenen Server geht.

An der Stelle noch ein Beispiel Bevor wir zu den Vor und Nachteilen von Server des Computing kommen, ist Amazon Alexa also der Sprachassistenten von Amazon selber. Jedesmal wenn man mit Alexa spricht, ruft man im Hintergrund quasi eine Lambda Funktion auf, die dann antwortet. Das fand ich ganz interessant, dass Amazon die eigene Technologie für ja doch dieses Blockbuster Produkt verwendet, was natürlich dann auch Signalwirkung haben soll. Seht her, das ist stabil genug, darauf kann man sich verlassen.

Okay, jetzt haben wir schon einige Vorteile. Implizit angesprochen. Lass uns doch nochmal durchgehen, ob wir nicht was vergessen haben. Skalierbarkeit hatten wir eben schon angesprochen. Amazon Alexa kann man sich z.B. vorstellen, dass am Anfang gab es vielleicht einige tausend Nutzer, die regelmäßig mit ihrer Alexa gesprochen haben. Mittlerweile dürfen das einige Millionen sein. Und diese ganzen Anfragen können eben parallel durchgeführt werden, ohne dass man sich darum kümmern müsste, die Infrastruktur entsprechend zu skalieren.

Das macht der Cloud Provider und auch das Konzept für die Fans sind, denen ausgelegt sind, wo man quasi nur eine Funktion vom Code her bereitstellt, mit vordefinierten Inputs und definierten Outputs. Diese Art der Programmierung dadurch ist trivial möglich, dass auch tatsächlich die Anwendung eben skaliert. Weil n klassischen Anwendungen muss man potentiell eben auch nochmal Gedancken reinstecken, ob die Anwendung überhaupt staatlich ist, ob sie skalieren kann und so weiter. Und diese Sachen sind implizit automatisch gegeben, wenn man entsprechend diese Umgebung nutzen will, weil dann muss man sich diese Gedanken alle vorher machen.

Angekommen vom Cloud Provider sozusagen ein vordefinierte Event eingereicht, mit dem man arbeiten kann. Mehr hat man nicht. Man kann natürlich auch externe Systeme noch anfragen, aber erstmal hat man nur dieses Event und tut dann eben mit diesem Event was. Und dass es in sich allein von den logischen Gedanken beliebig skalierbar, sodass allein die Herangehensweise an die Programmierung so einer Funktion eben an der Stelle das Skalieren quasi gratis mitliefern.

Ich hab bei der Recherche so einen schönen Satz gefunden. Ich glaube es von Google. Das heißt from prototype to production to planet scale, also dass im Prinzip der parallelisiert Kargheit dieser Service Funktion keine Grenzen gesetzt sind. Physikalische Grenzen sind natürlich schon durch den Cloud Provider gesetzt, aber die liegen so hoch, dass man dort erst einmal keine Probleme haben sollte.

Okay, dass man sich nicht mehr um die Beschaffung von Hardware, die Installation des Betriebssystems, die Wartung und das Update des Betriebssystems und etwaiger anderer Software Komponenten kümmern muss. Das hatten wir eingangs schon erwähnt. Ist aber ein wichtiger Punkt, denn ich wette in vielen vielen Admin Teams wird signifikant viel Zeit für diese Tätigkeiten aufgewendet. Soviel zu meiner Erfahrung. Ich weiß nicht, welche du da gesammelt hast, doch das ist ja identisch.

Muss man sich ja nur einmal in der Fachliteratur ein bisschen umschauen. Es tauchen gefühlt jede Woche mindestens eine Sicherheitslücke auf, wo man dann das Team eigentlich überprüfen muss. Okay, der Server, auf denen unsere Anwendung läuft, ist da die Open Access Bibliothek jetzt drauf, die betroffen ist oder nicht? Wenn ja, wie? Installieren wir das? Können wir das im laufenden Betrieb machen und so weiter. Und all das entfällt eben, wenn man in diesem Server lebt, Kontext unterwegs ist.

Dafür bezahlt man am Ende dann den Cloud Provider, dass die sich dann eben um Wartung, Update und so weiter kümmern. Und man selber bekommt von der Situation überhaupt nichts mehr mit. Und dann muss sich auch keine Gedanken machen, was an der Stelle eben irgendein Produktionsausfall oder sowas ist. Oder dass die Funktion erstmal nicht mehr erreichbar. 2 Grad der Hauptsatz aber ja, updatet oder sonst was.

Das hat man eben an der Stelle überhaupt nicht, da auch das Thema, was oft unter den Tisch fällt Hardware Ausfall. Vielleicht erinnerst du dich an ein Projekt, wo wir beide waren, was noch nicht so lange her ist, dass eine fehlerhafte Netzwerkkarte also wirklich wochenlang Haare raufen gesorgt hat, bis sie im gefunden und deaktiviert wurde und ab dann konnte normal weitergearbeitet werden. Das sind auch Sachen. Also nicht, dass es die defekte Netzwerkkarte in einer Cloud Umgebung nicht geben kann.

Aber ich denke die STANDARD Hardware dort ist so gut Monitor, dass das relativ schnell auffällt. Genau. Und soweit ich das weiß, haben sie ja auch nochmal spezielle Software laufen, die Unstimmigkeiten im Netzwerk aufspürt oder insgesamt Unstimmigkeiten in der Hardware. Und dann wird mal einfach ein kompletter Server Schrank aus der aktiven Hardware rausgenommen, falls nur die Ahnung ist, dass da mit dem Server schon was nicht in Ordnung ist, weil Cloud Provider haben natürlich so viel Ressourcen oder so viele Backups auch, dass das einfach mal möglich ist.

Was natürlich für ein normales durchschnittlichen Unternehmen nicht einfach mal möglich ist. So viel über pro. resümierte Hardware dazu haben, dass man meinen gesamten Server Schank aus dem Rechner Cluster rausnehmen kann.

Und wer eine Woche mit Debugging von Hardware Problemen verbracht hat, der wünscht sich, dass er damit nichts zu tun haben möge.

Preis ist auch ein Vorteil. Wir haben es unter Vorteil gelistet, aber ich würde sagen, da muss man etwas aufpassen, denn es gibt durchaus auch Szenarien, wo es günstiger ist, wenn man einen eigenen Server mietet, der z.B. kontinuierlich unter Hoch Last steht oder der sehr spezielle Anforderungen erfüllen muss, also sei es Spezial Hardware oder sehr viel Arbeitsspeicher aufweisen muss, dann sind Server alles Funktionen leider keine Option.

Genau, also das muss man je nach Anwendungsfall immer evaluieren. Es gibt eben meistens bei der Cloud nicht die STANDARD Aussage. Ja, das ist günstiger als alles andere, weil dann gäbe es das andere auch nicht. Mehr dementsprechend. Wie du richtig gesagt hast, mein Server ständig ausgelastet wäre, dann ist der häufig günstiger, als wenn man die gleichen Neuyork laut über Funktionen an der Stelle Fahndungen.

Ein weiterer positiver Punkt, der in vielerlei Hinsicht positiv ist, ist die Abrechnung für verbrauchte Ressourcen, also CPU Zeit, RAM Io. Und nicht nur, weil man tendenziell, wenn man ein System, das man nur für die Last starken Zeiten im Prinzip bezahlt, sondern es wird auch sehr deutlich im Projekt oder bei mehreren Projekten, welche Projekte wie viele Kosten verursachen und wo genau bei welchem Arbeitsschritt und welchem CPU Dienst oder bei welchem Programmteil die höchsten Kosten anfallen und die meiste Berechnung anfällt und man kann dort gezielt optimieren.

Das finde ich auch sehr schön eigentlich. Früher hat man gesagt, die Datenbank läuft 24 Stunden am Tag. Dann können wir auch hier alles rein und rausrechnen und Backup machen. Jeden Abend 100 Gigabyte übers Netzwerk schieben, das ist ja eh da und jetzt muss man sich das schon genauer überlegen. Also kann natürlich auch negativer Punkt sein, weil man sich jetzt damit beschäftigen muss. Aber generell halte ich das für eine gute Sache, dass man weiß, wo welche Aufwände erzeugt werden und man einfach so nochmal einen Überblick bekommt.

Genau.

Also vielleicht auch das Beispiel, das sein Wickler ein bisschen anders entwickelt kann. Ich habe selber gemerkt, dass wenn man sich jetzt eben genau an diese neue Serviceleistung Banken mit arbeitet, dann denkt man auch mal zwei oder drei mal mehr nach, um zu überlegen Okay, brauche ich jetzt diese Datenbank Anfrage oder nicht? Wie du eben so schön gesagt hast wenns im normalen System läuft und die Datenbank Ishtar, dann macht man im Saft. Hab eine Anfrage Mehrheit dahin, obwohl es natürlich auch Bermann Snack optimieren würde.

An der Stelle bringt das natürlich auch Vorteile in jeder anderen Umgebung. Aber gerade in diesem Klout Umgebung hat man sowieso nochmal einen monetären Vorteil dadurch, sodass man dann auch als Entwickler gleich Kaymer überlegt, ob man das nicht wieder schöner oder performant an der Stelle schreiben kann.

Also es wird einfach transparent und man kann sich gezielt darum kümmern oder sich gezielt dafür entscheiden, sich nicht darum zu kümmern. Was ich noch als gigantischen Vorteil seh ist, dass dieses Wissen für die Administration, was ja in jedem Unternehmen aktuell vorhanden ist und auch früher für die Produktentwicklung unabdingbar war, nicht mehr unbedingt notwendig ist. Und auch kleine Entwicklerteams, die vielleicht nur aus Entwicklern und einem 2 DevOps Menschen bestehen, dass sie Anwendungen entwickeln und betreiben können, die von Millionen von Nutzern genutzt werden können da draußen und das ohne eigenes Infrastruktur Team.

Wenn man sich auf Zerfalle Computing konzentriert, also das entbindet einen nicht von allen administrativen Aufgaben. Man muss sich natürlich auskennen und dieses DevOps wissen sich auf schlauen was ist eine IP Adresse? Wie funktionieren Netze, wie sicher ich das ab und so weiter. Und wie Provision niedrig die Infrastruktur auf meinem gewählten Cloud Provider. Also diese klassische Rolle zwischen Entwickler und Betrieb dann aufnehmen. Aber ist es wirklich kein Admin im engeren Sinne mehr notwendig für eine Anwendung, die Millionen von Leute nutzen?

Das ist ja auch schon mal was. Also Apps zum Beispiel. Aber wie das so ist, auch wenn es wunderbar klingt und wer jetzt die Vorteile aufgezählt haben, da gibt es natürlich auch ein paar Nachteile, die wir schon gestrichen haben.

Ich glaube, der größte Nachteil, wo man sich immer bewusst sein muss, sobald man in der Cloud unterwegs ist und vor allen Dingen bei den sogenannten Managed Service. Was Fangnetze Service an der Stelle ist, ist, dass wir ein Vendor Login haben. Das heißt, wenn wir uns jetzt entscheiden, bei Apps in der Landa Funktion was zu tun, dann können wir das nicht eins zu eins so auch danach bei Google z.B. laufen lassen, falls das wichtig ist. Allerdings, das muss man natürlich auch zugeben ist, dass dadurch das Konzept hinter den Fangzähne bei den meisten festgeschrieben ist, muss man natürlich nicht die komplette Funktion neu schreiben, sondern an der Stelle eher den Input und Output so neu formatieren, dass er auch die neue Cloud passt.

Allerdings kannst du dann auch nochmal sein, dass er nach anderen Cloud ein bestimmtes Paket nicht verfügbar als Voda. Man kann es nicht nach installieren oder lohnt was. Also man legt sich erst mal auf eine Cloud fest, wenn man eben eine bestimmte Funktion Umgebung auswählt. Am Ende dessen muss man sich bewusst sein, was natürlich auch am Ende der Tweet of ist. Zwischen dem Komfort, den wir eben erwähnt haben, bezahlt man einer gewissen Stelle dann natürlich damit, dass man den Cloud-Anbieter treu sein muss.

Es hat sich noch keine Open Source Server alles Computing Platform herauskristallisiert, so z.B. kybernetisch. Es ist ja das DevOps Rechenzentrum oder der STANDARD für Container Computing kann man sagen, der von allen Cloud Anbietern angeboten werden muss, weil er einfach so omnipräsent ist. Und für Server des Computing gibt es so einen verbreiteten offenen STANDARD eben noch nicht, der ja vielleicht noch kommen kann. Es wäre zu wünschen, dass man dann zwischen den Anbietern eben auch wechseln kann.

Ich glaube, da besteht ein hohes Bedürfnis, gerade von großen Unternehmen. Aber wer weiß, was die Zukunft bringt. Einen weiteren Nachteil sehe ich im ansprecht Verhalten einer Sour, weil es Funktion. Es gibt keine Garantie, dass diese sofort eine Antwort liefert. Manchmal ist so eine gewisse Ramp up Periode notwendig von wenigen Sekunden, bis dann die Funktion eben ausgeführt werden kann. Das ist insbesondere dann kritisch, wenn ich eine interaktive Anwendung habe, also wo der Nutzer Eingaben tätigt und er dann auf die Rückantwort wartet.

Muss aber gestehen, ich habe hier noch keine Hands on Erfahrung. Ob das wirklich so ein großes Problem ist? Wir haben tatsächlich an der Stelle einmal die Erfahrung gemacht also diese Vampir Periode ist tatsächlich nur am Anfang oder wenn die Funktion eben noch länger nicht ausgeführt wurde oder immer nur sehr sporadisch ausgeübt. Dann hat man eben dieses von dir erwähnte Problem und wir hatten tatsächlich den Fall, als wir eben die erwähnte Vest API bloed haben bzw. Konsequenz von unseren Websiten aus gekrault haben.

Da ist der Traffic schlagartig angestiegen und an der Stelle das Skalieren fand nicht schnell genug statt. Auch wegen dieser WMP Zeit. Und da hat es dann eben die ersten 5 bis 10 Minuten sehr viele Bettwil Requests Server, Time Outs und so weiter gegeben. Was an der Stelle jetzt nicht so kritisch war, weil das keine Daten waren, die das Nutzerverhalten zu sehr beeinflusst hätten. Aber je nachdem in welcher Situation man ist, kann man sich das eben nicht erlauben an der Stelle.

Wir sind danach auch etwas schlauer geworden, dass wir dann eben entsprechend, bevor wir ein anderes neues Deployment oder ein neue Landa Funktion woanders eingebaut haben. Kann man das eben auch einmal händisch selber vorheizen in Anführungsstrichen, wo man dann eben entsprechenden Traffic simuliert, dass eben vorhanden ist. Und ich glaube, mittlerweile gibt es auch seit längerem eine Checkbox, die man in den entsprechenden Oberfläche setzen kann, wo dann eben die Funktionen auf Standby gehalten wird, sodass dann eben diese Scale out oder das Skalieren sehr viel schneller geht.

Allerdings muss man den eben einmal setzen und ich glaube, es kostet auch was eine gewisse Betrag, sodass man da nämlich ständig setzen sollte. Aber es ist gut zu wissen, wenn der Cloud Provider das nicht hat, dann sollte man eben einmal quasi händisch vorheizen, sodass dann bei dem produktiv ausrollen. Wenn man nicht die Möglichkeit hat, prozentual über mehr Traffic abzugeben, dann muss man eben einmal händisch das sicherstellen, dass der Traffic erarbeitet werden kann. Händisch vorheizen.

Das hört sich ja an wie bei einer alten Dampflokomotive her.

Ich war auch amüsiert, als ich das erste Mal den Vorhalt Begriff in diesem Kontext gehört habe. Aber am Ende ist es genau das.

Das ist einfach eine technische Notwendigkeit. Die Cloud Provider haben natürlich tausende oder Millionen Funktionen registriert von all ihren Kunden auf diesen Laufzeit Umgebungen und da wird wahrscheinlich nur ein Bruchteil konstant genutzt und alle anderen werden schlafen gelegt, damit es bei diesen geringen Kosten bleiben kann. Und wenn eine Funktion angefordert wird, dann muss erst einmal eine Laufzeit Umgebung Provision tiert werden oder diese Funktion dort zur Ausführung gebracht werden. Und das kann dann eben diese berühmt berüchtigten ein, zwei, drei, vier Sekunden dauern.

In der Zeit hat man keine Antwort oder die Anwendung kann ich weitermachen? Ja genau.

Und nach dieser Vampir Periode ist das eigentlich kein Problem mehr, weil die meisten glaubt wieder an der Stelle im hingehen und diese entweihen, wo die Funktion ausgeführt wird eben sozusagen Kelchen. Das erst mal nachdem die hochgefahren wurde. Diesen sauberen State sozusagen wird dann mehr oder weniger als Abbild für alle anderen Funktionen der Nacht genommen, sodass dann eben nicht mehr die gesamte Umgebung hochgefahren werden muss, sondern nur noch dupliziert werden muss, was an der Stelle sehr viel schneller geht.

Ein weiterer Nachteil und da sind wir selber, das weiß ich aus erster Hand schon häufiger dran gestoßen und haben da Lösungen für entwickelt. Ist die Ressourcen Beschränkung innerhalb einer Server Ulis Funktion? Das ist wahrscheinlich auch oder es macht einen Unterschied. Je nach Anbieter gibt es da unterschiedliche Ressourcen Beschränkungen. Aber generell kann man glaube ich festhalten, dass man in einem sehr, sehr engen Korsett steht, also beispielsweise, dass eine Funktion maximal 40 Sekunden Laufzeit aufweisen darf. Danach wird sie zwangs beendet oder dass sie nur ein Speicherbedarf von ein Gigabyte RAM konsumieren darf und kann dann nicht weiter wachsen.

Und diese Beschränkungen sorgen zum einen dafür, dass man sich natürlich sehr kurz fasst und die Funktion wirklich nur einen sehr kleinen Teil des Programms dann eben übernimmt. Auf der anderen Seite kann es ja vielleicht doch nötig sein, eine große Anzahl an Bildern zu konvertieren und dann müsste man das irgendwie anders lösen. Genau.

Also das ist so ein bisschen dem Anwendungsfall geschuldet. Ich glaube, das liegt in der Konzeption begründet, dass eben Bankwesens kleine logische Einheiten sind, die häufig wenig Ressourcen Anspruch haben und schnell antworten. Aber das dann in millionenfach sozusagen. Wie du richtig erwähnt, das haben wir auch schon häufiger Probleme gehabt mit diesem Kontext, einfach weil sich dann am Ende das Anwendung. Szenario doch anders entpuppt hat, als es ursprünglich erdacht war, sodass man dann am Ende dann doch auf eine andere Technologie ausweichen musste.

Und man muss sich wirklich vor Augen halten. Also nach diesen 40 Sekunden als Beispiel Wert wird die Funktion Ehard beendet, also mit einem Kill abgeschossen. Wenn man da noch offene Datenbank Transaktionen hat, werden die nicht abgeschlossen oder verbleiben dann in diesem Schwebezustand. Also das muss man wirklich bedenken, wenn man da eine Anwendung, die Zeit, einen weiteren Nachteil.

Wobei ich sagen muss, ich seh das gar nicht als so großen Nachteil, weil die Cloud Provider sich ja doch sehr viel Mühe geben, sind die unflexible Provisionszahlungen der Laufzeit Umgebung. Also ja, wir haben eben schon gesagt Java wird angeboten, Pfeifen wird angeboten, sie Charb wird angeboten. Alles was Rang und Namen hat, JavaScript wird angeboten, aber dennoch muss man sich Vereine dieser FOR konfektioniert Laufzeit Umgebungen entscheiden und kann nicht frei seinen eigenen Sophistik dort aufbauen.

Genau das ist auch je nach Cloud Provider ein bisschen anders gelöst und das von dir angesprochene Korsett einmal enger geschnürt als bei anderen, sodass man da eben Dependency es zum Teil können eben relativ leicht nache installiert werden. Gemeint sind Pulsen Umfeld ist ein Python Paket kann man eigentlich in allen Umgebungen nochmal nach installieren, weil das eben einfach der normale Weg ist. An der Stelle aber zum Beispiel System Bibliotheken, auf die zum Teil bestimmte Pakete angewiesen sind, weil das eben nicht nochmal neu implementiert wird in der entsprechenden Programmiersprache, sondern eben auf normalerweise vorhandenen System Bibliotheken zurückgegriffen wird.

Die können zum Teil Probleme bereiten, wenn eben entsprechend in der Laufzeit Umgebung das einfach nicht vorinstalliert ist.

Hast du da ein Beispiel? Also Verschlüsselung oder Open CSL? Würde mir direkt einfallen, dass man vielleicht nicht jedes Cypher Sued hat.

Genau an der Stelle ist es ein relativ spezielles Beispiel, also das Knuff PGP quasi. Die asymmetrische Verschlüsselung ist an der Stelle nicht installiert in den Äther Pantheons. Zumindestens hab ich das an der Stelle nicht rausgefunden, wie ich es laden könnte. Und so gut wie alle landesüblichen heißen Pakete, die eine einfache Interaktion mit nur P&G verschlüsselten Dateien ermöglichen, setzen eben darauf, dass entsprechend die Bibliothek dafür vorinstalliert ist, was an der Stelle daneben dann nicht der Fall war und was daneben zu sehr viel Rechercheaufwand geführt hat.

Am Ende mussten wir uns auch an der Stelle aus anderen Gründen auch für eine andere Umgebung entscheiden, einfach weil sich herausgestellt hat, dass die Daten am Ende zu groß waren für die Funktion.

Da kann man mehrere beschränkende Faktoren zusammen, also Software Estag und diese Ressourcen Beschränkungen, sodass man sich dann dort von der andere nicht zur weiles Computing Lösung entscheiden musste.

Ein anderes Beispiel, was ich auch noch nennen kann es QT benutzt, was Leuten, die mit einer Maschine noch nicht vertraut sind, wahrscheinlich was sagen wird. Es ist nicht mit dem STANDARD C Compiler kompiliert, zumindest standardmäßig nicht meine ich, dass das zumindest das zugrundeliegende Problem war. Auf jeden Fall ist es nur sehr schwierig möglich, das in z.B. PKW’s zum Laufen zu bekommen. Es funktioniert, aber man muss dann doch wieder mehr Aufwand da reinstecken, dass man das eben selber kompiliert, weil die Laufzeit Umgebung sich eben leicht unterscheidet zu dem, was man normalerweise vorfindet, wo das Paket normalerweise ausgeführt wird.

Naja, und das sind dann genau diese Details Probleme, die dann doch wieder Zeit kosten. Was ich noch als Nachteil sehe.

Wobei da muss ich auch sagen, dass es bei manchen Cloud Providern doch relativ gut gelöst ist, das Debugging, während man diese Funktion entwickelt als man brauche so eine Art Remote Debugger, der dann in diese Server alles Computing Environment den dieBürger dort andockt und dass man die Funktion dann eben Schritt für Schritt durchlaufen kann. Da gibt es auch ganz gute Lösung, aber man hat halt all die Probleme, die man mit Remote Backing hat. Die Ports müssen offen sein, man muss die Funktion registrieren, es klappt nicht immer und man sieht nur die Funktion oder kann halt dadurch steppen.

Dadurch, dass man den Ausführung Stack nicht kennt, weiß man nicht. Okay, hab ich vielleicht einen Speicher Problem oder man sieht einfach nicht so viel wie wenn man das auf einer nativen Maschine macht. Genau.

Es gibt an der Schalotten unseren Ansatz. Zumindestens kenne ich den bei Apps so, dass sie tatsächlich einen lokalen Emulator für die Landa Funktionen bereitstellen. Der läuft dann meistens in Docker. Ich glaube es gibt auch alternative Installations Möglichkeiten, aber da hab ich mich dann für Docker entschieden. Und da wird dann quasi ein Docker Image Gisborne, wo dann deine Funktion Godwein kopiert wird und darum herum wird eben dann diese Funktion Logic simuliert. Funktioniert auch ganz gut, wenn man eben sozusagen die Events gucken will, ob die übereinstimmen, ob der Programmcode überhaupt ausführbar ist.

Was allerdings nicht ein Porst wird, zumindest zu dem Zeitpunkt wo ich es genutzt sind genau die angesprochenen CPU Limits MMW Limit. Execute belämmert in der Größe und so weiter, das wird an der Stelle dann eben nicht geprüft, sodass selbst wenn es dann eben lokal ausgeführt werden kann, man trotzdem in der Cloud noch auf Probleme stoßen.

In der Podcast Episode mit Olli haben wir ja über diese zwei Faktoren gesprochen, dass die Ausführung Umgebung möglichst der Entwicklungsumgebung entsprechen sollte. Und durch diesen Bruch hier kann man sich dann eben neue Probleme einfangen. Hier ist das dann nicht gegeben. Jetzt haben wir die Vor und Nachteile besprochen und ich glaube, jetzt kann man ganz gut ein Bild zeichnen, in welchen Szenarien servil es Computing denn besonders sinnvoll oder eben nicht sinnvoll eingesetzt werden kann. Alexas Gilt’s hatten wir schon als Beispiel.

Du hast gesagt, Dienste, die Überrest APIs miteinander sprechen, eignen sich auch sehr gut, weil das einfach die natürliche Sprache der servile Funktionen ist. Wir haben gesagt, es gibt verschiedene Trigger, mit denen die Funktion gestartet werden kann. Also neue Datei in einem Cloud Folder hochgeladen. In einer Message Cue steht ein neues Objekt an. Ein Rest API Call ist auch ein Trigger Import. Daten sind vorhanden, klopfen irgendwo an, in einer Datenbank entsteht ein Eintrag. Wenn die Anwendung sich darauf stützt, kann man das auch sehr einfach abbilden und bei hoch parallelisiert Baan Anwendungen also zum Beispiel könnte man sich vorstellen einen Web Dienst wo Leute ihre Audiodateien hochladen können im Wave Format und bekommen einen komprimiertes MP3 zurück.

Das wäre ja perfekt. Parallelisiert war eben pro User oder sogar pro User Datei. Das wäre so ein Anwendungsfall wo man sehr gut dann eben sovieles Computing Funktionen einsetzen könnte.

Genau. Wobei man natürlich auch an der Stelle nochmal anmerken muss, dass man sich im Vorhinein überlegen muss, ob man entsprechend Größen Beschränkungen z.B. im Mäzenen, den Kommentierungen Beispiel zu bleiben größten Beschränkungen für die Josa auferlegt, damit das eben garantiert ist, dass in der benötigten Zeit abgearbeitet werden kann. Apropos benötigte Zeit ich bin auch über einen Artikel gestolpert, wo eine Architektur vorgeschlagen wurde, dass eben die sovieles Funktionen möglichst über Message KÜS miteinander verbunden werden sollen. Das Problem liegt darin, wenn man die Server Funktionen miteinander verknüpft und eine Funktion auf die Antwort einer zweiten Funktion wartet, dann wird das berechnet, weil die erste Funktion aktiv auf den Rückgabewert der zweiten Funktion wartet.

Und der Vorteil bei Message Cues ist, dass die erste Funktion ihren Job abschließt, in die Message Kyu ein Objekt anhängt. Die zweite Funktion läuft los, führt ihren Arbeitsschritt durch. Das Ergebnis wird wieder in die Message Kyu eingehängt und jetzt startet die erste Funktion wieder mit dem Ergebnis der zweiten Funktion und kann damit weiterarbeiten. Und das das kann man sich leicht vorstellen. Bei vielen, vielen 000. Funktionen, die vielleicht parallel ablaufen, doch sehr viel Zeit sparen kann und unterm Strich natürlich auch Kostenvorteile bringt.

Wobei an der Stelle würde sehr wahrscheinlich eher so laufen, dass du insgesamt drei Funktionen und zwei Medikus hast. Hast du sozusagen die erste Funktion in die erste mildtätigen schreibt, dann die zweite Funktion aus der ersten liest und in die zweite mit Süd-Korea einschreibt und dann die dritte Funktion darauf wieder reagiert. Dann hast du eben die Trennung der Microservices noch klarer, weil sonst hast du in der ersten Funktion zwei Logiken drin einmal den externen Trigger sozusagen und dann nochmal Handfeger.

Wenn, wie deine Antwort in die Meterdicken geschrieben wird an der Stelle genau serverseitig macht es natürlich Sinn, das auch noch aufzuteilen. Mir war jetzt eigentlich nur wichtig zu zeigen, dieses aktive Warten einer sovieles Funktion. Das sollte man vermeiden, eben aus Kosten, Gesichtspunkten.

Und ein anderer Vorteil natürlich bei diesem asynchronen ist, dass dann, wenn eine davon Ressourcen intensiver als einfach durch die Hörer Verarbeitungs Zeit, dann ist das eben auch an der Stelle abstrahiert. Ich glaube es ist insgesamt ein guter esein Hinweis für die Microservices Architektur, dass du die Kommunikation möglichst asynchron machst an der Stelle, wo du es kannst, dass man die Message Cues das machen lässt, wofür sie gedacht sind, eben per Sistieren von Objekten und die Koppelung der Funktionen.

Dann eben im Grunde wie bei einer Fabrik mit ganz vielen Fließbändern. An die Fließbänder sind da die Message QoS, dass man das dann so aufbaut. Mach doch das Recovery einfacher. Wenn einzelne Dienste streiken oder es zu Problemen kommt, dann sind die Nutzdaten weiterhin in den Message cuius vorhanden, in der Mehrzahl der Fälle aber sinnig verloren. Die Prozessors führen kann ein resoniert werden. Ich denke generell, dass sovieles Computing bei der Neukonzeption von Anwendungen, insbesondere Webanwendungen die Stärken ausspielen kann, wenn klar ist, dass die Anwendung in der Cloud betrieben werden soll, wenn klar ist, welche Funktionen dort umgesetzt werden können, auch mit Nutzer Interaction oder Import-Export Jobs.

Im Grunde so eine klassische Webanwendung kann schon oder weitestgehend Services umgebaut werden. Glaube ich schon. Im Grunde hat man mit der Services Computing Technologie oder Funktion, also Service. Ziel wie mit den Container Technologien nur auf der Abstraktionsebene höher. Man möchte Ressourcen schonen, wenn eine Funktion nicht laufen muss. Möchte man sich nicht darum kümmern und keine Hardware vorhalten oder die Hardware, kann man für andere Funktionen benutzt werden. Und nur die Funktionen, die jetzt gerade laufen müssen, sollen dann eben auch Hardware in Beschlag nehmen.

Genau wie bei Container Technologien auch plus Skalierung plus Ausfallsicherheit. Diese ganzen Benefiz, die man dazu bekommt bei der Container isierung, bekommt man natürlich auch beim Server des Computing dazu. Dennoch gibt es auch einige Szenarien, wo Functions A Service nicht sinnvoll sind.

Genau, also zwei prominente Beispiele. An der Stelle einmal das von uns bereits angesprochene Sache, dass wenn ein Server zum Beispiel 24 Stunden am Tag sieben Tage die Woche komplett ausgelastet ist, dann kann das potenziell günstiger sein, sich tatsächlich dann den virtuellen Server dahin zu stellen oder auch zwei oder drei je nach Last Verteilung an der Stelle. Was aber für mich der wichtigere Punkt ist, ist, dass man eben auch Limitationen hat. Man hat Lais Herz die Ressourcen, die man benutzen darf CPU, RAM und vor allen Dingen Dauer der Funktion, aber auch die Limitationen im deiner Umgebung.

Das heißt, wenn du Ebene Software Komponente hast, die bestimmte Bibliotheken benötigt, die man nicht ohne weiteres nach installieren kann, dann ist das eben definitiv ein Fall, den man nicht in den Fanzines umsetzen kann. Zumindestens aktuell nicht. Es kann natürlich sein, dass sich das in Zukunft ändert, aber nackte entstand hat man da einfach zu wenig Freiheiten, als dass man jede Anwendungs Situation da komplett abbilden kann?

Ich denke auch, es gibt ja durchaus Szenarien, wo man die volle Kontrolle über die Software Komponenten die man einsetzt haben möchte. Einfach weil man eine Anwendung betreibt, die zertifiziert ist mit einer bestimmten Version einer Datenbank. Und dann ist zwar weiles Computing auch nicht geeignet, einfach weil man alle Variablen kontrollieren muss, um die Anwendung konform zu betreiben, eben mit diesen zertifizierten Komponenten und der Cloud Provider, sogar wenn er die Anwendung anbietet. Es kann immer sein, dass es nächste Woche ein Update gibt und dann die nächste Version benutzt wird ungefragt und man dann quasi nicht mehr zertifizierte Software einsetzt.

Genau. Und noch ein anderer Punkt, der je nach Unternehmen weniger wichtig oder wichtiger ist, ist die Portabilität. Weil wir haben an der Stelle ja schon hervorgehoben, dass je nach Cloud Anbieter sich eben die Pantheons leicht unterscheiden und man dann eben die Anforderungen hat, das sehr leicht sehr schnell zwischen verschiedenen Clouds hin und her gewechselt werden kann. Dann empfangt uns an der Stelle nicht das Richtige, sondern dann muss man sich zum Beispiel mit Containern und der Cuba net selbst Bentheim angucken, die so standardisiert eigentlich in jeder Cloud auch als Managed Service angeboten werden.

Die Limits einer Server Umgebung als Nachteil. Also wenn man die nicht halten kann. Das haben wir schon angesprochen, dass das problematisch ist. Also wenn man sehr viel Memory braucht oder kontinuierlich CPU braucht einen Punkt, den man noch gar nicht angesprochen haben und der auf jeden Fall ein Nachteil ist. Denn der Server des Computing Welt ist das Thema Security, denn man muss sich eben vor Augen führen. Der eigene Code wird parallel mit Code von ganz vielen anderen Unternehmen ausgeführt.

Generell ist das schon gegeneinander abgeschirmt, aber wenn man jetzt an die Prozessor Fehler der großen 86 Hersteller denkt, ist das natürlich ein Thema. Also man läuft mit Code von anderen Unternehmen, mit Daten von anderen Unternehmen Memory parallel und es gibt einfach Anwendungsfälle, wo man das rechtlich nicht darf oder wo man das einfach nicht möchte. Und in diesen Fällen ist Server des Computing oder generell Cloud Computing ist auch schon schwierig. Dann vielleicht nichts für ein naja. Also in den Fällen muss man wie du schon sagst, generell bieten Cloud Provider Möglichkeiten, dass man eben exklusiv auf Service läuft, also auf tatsächlich Hardware Maschinen.

Ich bin mir nicht sicher, ob das in den Pantheons vorgesehen ist. Wenn ja, bezahlt man da deutlich mehr, weil dann natürlich die gesamte Hardware bezahlt werden muss, auch wenn man sie nicht nutzt. Das heißt, da sind dann potenziell andere Services durchaus besser geeignet, wenn man eben diese Bedenken berechtigterweise dann hat.

Das muss man dann abwägen, je nach Anwendung, die da ausgeführt wird und natürlich auch, welche Arten man am Ende verarbeitet.

Herr Server, weil Computing eignet sich insbesondere dann, wenn man dieses Microservices Service Masch eben hochfahren kann oder die Anwendung sich darauf abbilden lässt. Und man kann glaub ich sagen in anderen Szenarien opfert man den einen oder anderen Vorteil. Dieser SVR Wallis Umgebung dann schon eben zugunsten von mehr Kontrolle. Kann auch Szenarien geben, wo man z.B. Abhängigkeiten zu externen Diensten hat. Also bei meinem aktuellen Projekt gibt es z.B. viele Stammdaten liegen einem SAP System, was mehrere Sekunden benötigt, um komplexe Anfragen zu beantworten und hier Ergebnisse zu liefern.

Und da würde ich mich auch schwertun direkt Server Funktionen anzudocken, ohne. Ein Caching ler dazwischen. Weil ich sonst nicht sicherstellen kann, dass ich diese 40 Sekunden Marke oder diese Zeit SchrÃnke der Server alles Funktionen nicht irgendwann mal reiße und dann abgebrochen wird und in undefinierten Zustand habe. Genau. Häufig ist es eben, solange man sich in der Cloud selber bewegt. Vor allen Dingen beim gleichen Anbieter ist man relativ sicher, was diese Timelords angeht. Hat natürlich niemals davor gewappnet.

Es gibt auch da Systeme, die einfach nicht auf zeitige Antworten ausgelegt sind. Aber wie du richtig sagst, sobald man externe Systeme noch dazukommen, hast du einfach da nicht zwangsweise die Kontrolle drüber. Zumal man, wenn man jetzt nochmal sagt externe Systeme, die man selber gar nicht kontrolliert, weil es nochmal von einem anderen Anbieter kommt, dann muss man eben schon auch gucken, ob da die Anforderungen eingehalten werden können.

Ja, wenn das GAP zwischen alter Technologie und servile Computing oder funktionelles as a Service, die ja wirklich ganz neu und an vorderster Front der Entwicklung stehen, wenn Scepter dazwischen zu groß ist, dann muss man schauen, wie man das minimiert, damit man nicht zu viele Abstriche machen muss in beiden Welten. Ja, vielen, vielen Dank, Max, dass du heute da warst. Wenn unsere Zuhörer Fragen haben oder Feedback senden möchten, können sie das gerne tun unter der E-Mail-Adresse, Podcast etc.

. Gilbert E. Lasst uns gerne eine Bewertung dar und abonniert unseren Podcast. Und wir freuen uns immer, wenn ihr diesen auch an Freunde und Kollegen weiterleitet. Für mehr spannende Technologie. Tim schaut auch gerne auf Skill bei TE Slash Blog vorbei. Max, ich bedanke mich ganz herzlich bei dir für dieses wahnsinnig interessante Gespräche rund um Server des Computing und das Thema Functions Service. Es hat einen Riesenspaß gemacht. Danke Meads, auch Spaß gemacht, dabei zu sein.

Wunderbar! Ich wünsche dir noch einen schönen Abend.

Danke. Gleichfalls.

Maurice KnoppSkillbyte Podcast #34: Serverless Computing – Hype oder Chance? AWS Lambda, Azure Functions, Google Cloud Functions richtig verwenden
Mehr