Plattform Engineering scheint gerade in aller Munde und Malte
und ich, wir haben uns ja auch schon vor ein paar folgen mal
eine ganze Podcast Folge lang diesem Thema gewidmet.
Jetzt schauen wir uns Radios an, das ist n Technologie Vorschlag
von Microsoft, der an die Cloudate Computing Foundation
übergeben wurde, der das ganze Mal konkret werden lässt und
sagt, wie kann denn das technologisch aussehen, wie
können wir denn da die Verantwortlichkeiten verteilen,
darum geht es in dieser Folge. Und damit herzlich willkommen zu
Folge 89 des to do Developer Podcast mit Robin Manuel Thiel
und mir malte Lantine Robin Manuel, wie geht's dir, wie war
deine Woche? Anstrengend.
Ehrlich gesagt, ich habe die letzten 2 Wochen waren voll mit
Geschäftsreisen und ich bin ein bisschen ja Social tired.
Ich würde gerne irgendwie ich brauche glaube ich mal eine
Woche wo ich mich zu Hause im Homeoffice einschließe und mal
irgendwie Sachen Abarbeite und mal keine Menschen sehe und das
liegt auch gar nicht an den Menschen, die ich getroffen
habe. Ich habe ganz ganz, ganz tolle
Menschen getroffen. Woche über unter anderem ja auch
ein paar Hörer und Hörerinnen von von euch.
Wer sich erinnert, ich war ich war bei Kundenevents in Zürich
und in Frankfurt und hab da Gespräche mit euch geführt.
Vielen Dank auch. Danke, dass ihr uns da
ansprecht, wenn wir unterwegs sind und ihr und ihr uns seht,
da freue ich mich wahnsinnig, ich bin immer ganz ganz gerührt,
ich weiß gar nicht was ich sagen soll, wenn jemand live zu mir
kommt und sagt Hey ich höre euch regelmäßig, freue mich immer
sehr, aber irgendwie so ein bisschen.
War es anstrengend und ich habe jetzt auch noch ein Wochenende
vor mir, wo ich auch ganz viele Freunde sehe.
Da freue ich mich schon drauf, aber.
Danach, also nach nächstem Wochenende, glaube ich mal eine
Woche weniger Social Activity gemacht.
Wie ist denn bei dir? Mir geht es geht es ähnlich.
Ich war die ganze Woche mit unserem Team unterwegs.
Das Gute ist, wenn man auf Dienstreisen ist, hat man immer
so ein bisschen Zeit, auch Dinge in Ruhe abzuarbeiten,
insbesondere wenn man dem Zug sitzt.
Also ich bin nicht so leichtsinnig, da noch
irgendwelche Termine per online Konferenz reinzulegen, das heißt
im Zug im Zug habe ich so ein bisschen Zeit, mich auch zu
konzentrieren, Sachen abzuarbeiten und das habe ich
diese Woche dann auf 2 längeren Fahrten gemacht und unter
anderem habe ich mich auch mit dem Project Radius ein bisschen
beschäftigt. Nachdem du mir erzählt hast,
dass du im Podcast drüber sprechen möchtest, hab ich mich
ein bisschen reingelesen. Hab mir die Session von
Microsoft, ich glaub es war von der letzten Build Conference
noch mal angeschaut. Um einfach einen Eindruck zu
kriegen, worum geht es da eigentlich?
Du kommst ja aus dieser Cloud native Welt, für mich ist das
ganze Thema noch so immer so n bisschen fremd, weil ich wenig
Hands on Berührungspunkte mit dieser ganzen Technologiewelt
habe, von daher bin ich heute auch gespannt das mal mit dir zu
diskutieren. Werden und dann auch meine
Wissenslücken zu füllen. Aber bevor wir ins Thema
einsteigen, noch unsere üblichen housekeeping Aufgaben und da ist
es natürlich ganz wichtig, dass wir uns noch mal wieder herzlich
bedanken bei denjenigen oder diejenigen, der uns seit der
letzten Folge einen Kaffee ausgegeben hat.
Vielen Dank an Daniel für einen Kaffee.
Vielen. Dank aber nicht nur bei uns ist
diese Woche viel passiert, sondern auch in der
Technologiewelt, dass uns vielleicht noch ganz kurz 2
Minuten darauf investieren, weil es gab, glaube ich, 2 große
Themen diese Woche und das eine Thema, mit dem ich mich relativ
viel auseinandergesetzt habe, weil ich mich viel mit meinen
Kollegen dazu ausgetauscht habe in den letzten Tagen ist die
Ankündigung des neuen GPT Modells.
Was ich extrem spannend fand in der Demo und besonders
interessant fand ich, dass im Gegensatz zu vielen anderen AI
Modellen, die in den letzten Monaten präsentiert wurden,
wurde das Ganze quasi sofort freigeschaltet.
Für die User zumindest die mit. GPT Premium Chat, GPT Premium
und viele der Funktionalitäten konnte man direkt danach auch
selber auszuprobieren und dadurch natürlich ein bisschen
Zeit drauf. Investiert hat mir das ganze
anzugucken, ich fand es extrem spannend.
Wie war dein Eindruck? Ich fand es auch krass.
Ich hab es auch natürlich direkt irgendwie ausprobiert.
Ich fand auch irgendwie n gutes Thema Desktop App, cool, dass
man irgendwie quasi einen kleinen Begleiter in seinem
Alltag hat, der dann auch teilweise mein mein Bildschirm
sehen kann, zumindest in den Phasen wo ich den Freigebe und
dann würd ich sagen kann Hey schau mal, hier kannst du mir da
kurz einen Kommentar zu sagen oder findest du hier den Bug in
meinem Code oder wie würdest du das nochmal umformulieren, ohne
dass ich halt wirklich Text markiere?
Kopiere in Chat GPT einfüge, das ist glaube ich da freu ich mich
sehr drauf, das hatte ich jetzt die letzten Tage.
Ich glaub seit vorgestern oder so auch schon mal ausprobieren
dürfen und ich glaube das gerade so, dass dieses diese ja diese
Co Piloten im Alltag, ohne dass ich sie ganz aktiv irgendwo
aktivieren muss und diese kleinen Helfer zwischendurch,
dass die auch immer mehr werden und dass da auch wirklich
sinnvoll wird. Und tatsächlich, auch jetzt die
noch bessere und quasi in Echtzeit funktionierende
Sprachkommunikation fand ich wirklich echt beeindruckend, da
wirklich direkt die Interaktionen.
Mit Chat GPT zu haben ohne Halt viel tippen zu müssen oder
irgendwie speech to Text zu machen, das fand ich wirklich
beeindruckend. Das heißt, da wird viele
Anwendungsfälle geben und ich glaub jetzt Chat GPT ist wieder.
Der erste Einsatzzweck für dieses Modell aber natürlich
über die API, wird das dann jetzt in viele andere
Anwendungsfelder reinfließen und da bin ich gespannt, wie es da
weitergeht und was ich gelesen hatte ist das GPT Four O auch.
Auch schon inkognito an diversen Chat Agent vergleichen
teilgenommen hat und alle sich gefragt haben, was ist denn das
für ein Chat Agent der da die guten Ergebnisse macht.
Und tatsächlich stellt sich raus, dass.
Hier GPT Chat GPT mit GPT fo tatsächlich wieder zum
Marktführer wird was die Qualität betrifft, aber das ist
ne Momentaufnahme von daher ich bin gespannt was da kommt.
Vielleicht machen wir mal noch ne komplette Folge wieder zu dem
Thema. Aber heute soll es mal nicht um
AI im Detail. Gehen.
Wir können ja mal ne Folge machen, wo wir einfach Jet UPDVO
komplett interviewen, also gerade diese, wenn das dieses
diese live responses, die fand ich auch beeindruckend.
Ich bin auch mal sehr gespannt was dafür Use Cases und
Anwendungsfälle rauskommen, wahrscheinlich irgendwie so die
die virtuelle Freundin oder sowas weil also ich fand das ich
fand das Ding schon erstaunlich flirty also das ist irgendwie in
diesen ganzen Videos die man gesehen hat ich war überrascht
davon, dass das auf einmal irgendwie so oh oh oh meinst du
so ein bisschen ein bisschen flirty war?
Also ich glaube das hatte. Gerade so auf Twitter, da noch
viel Humor nochmal irgendwie abbekommen und liegt natürlich
dann oft auf der Hand, dass irgendwelche Leute sich dann
irgendwelche virtuellen Dates oder irgendwas bauen und auch
dieser Gag, der so ein bisschen durch Social Media gegangen ist,
von wegen. Dating Model komplett neue
Bedeutung bekommen. Ja, also auf jeden Fall viel mim
Potenzial, dabei aber natürlich technologisch super
beeindruckend. Dann würde ich gerne, bevor wir
ins Thema einsteigen, auch noch eine kleine Ankündigung in
eigener Sache haben. Und zwar haben.
Mich vor ein paar Folgen schon mal erzählt, dass ich jetzt in
dass die ein oder andere Zeitprojekt auch habe und 1
davon ist, dass ich zusammen mit einem Freund von mir einen quasi
ein developer Tool für Rollen und Rechtemanagement baue,
sondern so ne Plattform und die würden wir gerne in 2 Wochen auf
Product Hand launchen. Viele kennen bestimmt Product
Hand, das ist eigentlich so eine Plattform wo man eigentlich
täglich neue Tools und Helferlein und SD KS und irgend
sowas entdecken und mit Freunden teilen kann und da haben wir uns
überlegt, würden wir gerne in 2 Wochen eine Lounge machen und
dann quasi offiziell sagen so wir sind jetzt da.
Und vielleicht machen wir auch mal eine kleine Folge zu dem
Thema. Rollen und Rechtemanagement für
Developer haben wir da glaube ich schon so ein paar Sachen
erkannt haben, die komplexer sind, als es auf den ersten
Blick scheint und da würde ich mich wahnsinnig freuen, wenn wir
da Unterstützung hier von euch, aus unserer Community kriegen
würden, das heißt, wenn ihr sagt, Ey, das ist cool, wir
haben Lust euch da zu unterstützen oder euch das mal
anzuhören, dann legt euch doch vielleicht jetzt schon mal einen
Product Hunt Account an, denn Product Hunt.
Wertet irgendwie Likes und ab Votes von Leuten, die nicht erst
seit gestern einen Account haben.
Deutlich höher also wenn wenn ich euch da in 2 Wochen noch mal
um eure Unterstützung fragen darf, dann wird es mir sehr
helfen, wenn ihr vielleicht jetzt irgendwie in den nächsten
Tagen schon mal einen Account anlegt, vielleicht schon mal so
ein ganz klein bisschen aktiv auf Product Hand seid und dann
schauen wir mal, ob ich hier die Podcast Army nutzen kann, um uns
da ein bisschen zu pushen. Würde mich freuen, erzähl mir
dann noch mal in 2 Wochen wenn es soweit ist, ein bisschen mehr
drüber. Ich drücke auf jeden Fall die
Daumen, dass es voll durchstartet.
Dann lass uns ins Thema einsteigen.
Wir sprechen heute über Project Radius und Project Radius kommt
von Microsoft, ist aber ein offenes Projekt und entwickelt
sich jetzt Richtung Cloud Native Foundation und dient im
Wesentlichen dazu, diese Brücke zwischen Developer und
Operations zu schließen, die ja selbst.
In den letzten Jahren immer noch Bestand.
Klar, es gibt immer mehr Dev Ops Teams, aber natürlich gibt es
bestimmte Fähigkeiten, die immer schwerer sind in der Gänze zu
beherrschen. Wenn man sich dieses ganze Cloud
Native Eco System anschaut, gibt es einen riesigen Technologie
Stack und irgendwie hat sich über die letzten Jahre dann die
Erwartungshaltung entwickelt, dass jeder einzelne Developer
jedes Dev Team irgendwie alles beherrscht, was nicht nur für
die Entwicklung, sondern auch für den Betrieb der eigenen
Anwendung nötig ist. Aber mit dem Explodieren der
Möglichkeiten der technologischen Möglichkeiten
wird diese Annahme ja immer utopischer.
Dementsprechend hat sich das ganze Thema Plattform
Engineering herauskristallisiert, in dem
Halt. Dedizierte plattformteams Dinge
vorbereiten, Templates vorbereiten, Self Service für
Developer anbieten. Aber hier beschränkt er sich in
der Vergangenheit häufig dadrauf, dass bestimmte
Infrastruktur deployed wurde. Die durch das Plattformteam
beschrieben wurde. Aber was ein bisschen fehlte,
war die Beschreibung des Ganzen durch das Development Teams und
genau diese Brücke noch mal zu schließen und zwischen dem was
die Entwickler benötigen um zu beschreiben welche
Technologieabhängigkeiten sie haben plattformtechnisch und dem
was das Plattformteam als. Gadrails vorgibt, sprich wie
sollen diese Technologien in der Cloud bereitgestellt werden, in
der eigenen Infrastruktur bereitgestellt werden, welche
Konfiguration, welche Policies sind erforderlich und hier diese
Brücke zu schließen, damit beschäftigt sich Project Radius
und Du hast dich ein bisschen intensiver damit beschäftigt.
Hast du schon hands on ausprobiert und was kannst du
uns aus deiner Erfahrung berichten?
Ja, es ist tatsächlich so ein bisschen, dass die Idee vom
Plattform Engineering jetzt mal in den wirklichen Technologie
Vorschlag gegossen. Wir hatten, wie gesagt, wir
haben ja schon gesagt und ich habe eh auch so ein bisschen das
Gefühl, dass ich mit Plattformen Engineering wir uns wieder so
ein bisschen 23 Schritte zurück von diesem ursprünglichen,
ursprünglichen Depots, der. Aus Gedanken bewegen, indem er
dann irgendwie aufkam. OK, als dev Ops aufkam, hieß es
irgendwie alle, alle machen alles und Developer machen auch
Operations und Deployen auch und alle sind irgendwie das
gemeinsame im Team. Und wie du gerade richtig gesagt
hast, das ist aber irgendwann ja wahnsinnig komplex geworden.
Und was, was dann jetzt aufkommt, ist dieses Plattform
Engineering, wo es n Operations Team gibt, die Spielregeln
festlegen wie bei uns im Unternehmen, vor allem in großen
Unternehmen eben Dinge deployed werden und genau da setzt Radius
an und lässt Oper lässt das Operations Team eben diese
Spielregeln oder wie Radius es nennt Recipes, also Rezepte für
eine Datenbank für eine App, für einen Cash, für einen Proxy und
so weiter definieren. Und lässt dann Developer eine
einfach nur noch in ihrer App Beschreibung.
Wir haben so ein Application Model entwickelt, wo ich neben
meine App eigentlich so eine so eine Beschreibungsdatei lege was
meine App braucht. Lässt dort dann eben developer
sich irgendwie definieren was sie brauchen und in dem Moment
wo dann ein Deployment stattfindet, kommen diese beiden
Welten zusammen und die Developer, die jetzt vielleicht
beschrieben haben, ich brauche eine Mongo DB und die soll bitte
auf folgendem Port auf mich hören und so weiter und bitte
den Connections String von der Mongo DB brauche ich als
environment variable hier in meinem Container.
Das trifft dann auf diese Resse vom Operations Tiemenson
Deployment gibt, wo dann geschafft wird.
OK Mongo DB, wie wird die denn bei uns im Unternehmen sicher
nach nach nach nach unseren Standards skalierbar.
Gemäß unserer Policies, denn deployed und dann auch geschaut
in welcher Umgebung, weil man es könnte ja sein, dass das
Operations Team sagt, OK, wenn du the Mongo DB brauchst, wir
aber die Applikation lokal ausführen oder irgendwo on Prime
betreiben, dann ist es wahrscheinlich.
Ne bestimmte Konfiguration des Mongo DB Containers in einem
kobaniertes Cluster, wohingegen wenn wir dann vielleicht gegen
ne Cloud Umgebung deployen, dann nutzen wir die gemanagten
Services, die der Cloud Provider uns zur Verfügung stellt.
Und diese beiden Beschreibungen, einmal das, was das Operations
Team macht und einmal das was die Developer dann quasi
anfordern. Diese beiden Beschreibungen sind
eben in dieser Radius Technologie.
Dann zusammengeführt oder oder definiert und kommen dann eben
dann, wenn es ein Deployment gibt zusammen.
Das heißt also, wenn ich als Entwickler die Anforderung habe,
ich brauche irgendwie einen Radisscash und eine Sequel
Datenbank, dann ist es mir am Ende egal in welcher Cloud
Infrastruktur das bereitgestellt wird.
Jemand anders trifft wahrscheinlich die Entscheidung
darüber, was jetzt die Plattform der Wahl ist.
Betreibe ich das im eigenen Rechenzentrum auf der eigenen
Infrastruktur, betreibe, die betreibe ich so auf Abs auf
Erscha oder wer weiß wo und dementsprechend ist es ja total
sinnvoll diese Dinge voneinander zu trennen und zu abstrahieren,
das heißt ich als Developer definiere welches Services ich
brauche und jemand anders definiert wie diese in der
Zielumgebung. Korrekt konfiguriert, aber halt
auch nach den Unternehmensstandards Compliant
bereitgestellt wird und ich kann dann die Anwendung mal in die
eine Umgebung, mal in die andere Umgebung betreuen.
Aber als Entwickler hab ich letzten Endes die gleichen
Anforderungen an beide Umgebungen definiert über diese
Technologie und kann dementsprechend das Ganze so ein
bisschen weg abstrahieren, das ganze aber letzten Endes auch
immer noch als. Code so ähnlich wie
infrastructures Code wie wir es gewöhnt sind und wir als buysabt
Template als terraform Template für die unterschiedlichen Cloud
Plattformen auch. Aber ich muss jetzt nicht als
Developer hingehen und irgendwie mir einen terrorform Template
runterladen für eine spezifische Cloud Plattform, das dann mit
meiner Anwendung irgendwie managen, sondern ich abstrahiere
nochmal das ganze ein bisschen weg und gehe am Ende wirklich
nur noch auf die Services die ich für meine Anwendung brauche
und habe damit. Natürlich eine sehr gute
Kontrolle und eine Direktverbindung.
Über diese Recipes zu dem, was dann in der Cloud Plattform
bereitgestellt wird, weil das ist ja auch so n bisschen der
Nachteil von dem wie man es vielleicht erwartet aus dem was
wir in der Plattform Engineering Folge besprochen haben mit
diesem Developer Portal. Dann geh ich vielleicht in so n
developer Portal und stell mir da meine Konfiguration zusammen,
irgendwie in meiner Zielumgebung brauche ich folgende Datenbank
brauche ich folgende Betriebsumgebung aber was da
dann letzten Endes rausfällt sind ja auch irgendwelche
Infrastructure as code templates.
Wenn ich das ganze jetzt über dieses developer Portal
eigentlich getrennt von meinem Code provisioniere, dann hab ich
hab ich natürlich nicht diesen direkten Bezug in der Cloud
Plattform. Man sieht nicht direkt OK
welcher Service läuft eigentlich da und da drauf ne und welche
Teile? Welche Infrastrukturkomponenten
gehören eigentlich zu welcher Attrakt Anwendung an der Stelle?
Das heißt, ich kann natürlich entsprechend Label setzen, aber
man hat immer noch diese Trennung und jetzt führen wir
das Ganze wieder zusammen, aber mit der notwendigen Abstraktion.
Genau also in der Vergangenheit oder bisher ist es ja einfach
oft auch so gewesen, dass zum Beispiel Terrorformcode mit im
gleichen Reporsatory lag, wo die Anwendung liegt und so, und das
wird so n bisschen wieder entzerrt einfach, aber das heißt
nichts, nicht das Terrorformen oder Buysell oder welche
Infrastructure als Codes sprach man auch immer verwendet da
jetzt in diesem Radius Konzept keine Rolle spielt, im
Gegenteil, das ist dann halt die Art und Weise wie ein Operator
definiert, was bei uns der richtige Art und Weise zu
deployen ist. Zum Beispiel wenn wir bei diesem
Rediss Beispiel bleiben. Dann kann ich jetzt als Operator
hingehen und einfach definieren, was heißt es denn an Reddit bei
uns nach production requirements?
Ich kann da auch verschiedene Stages wählen, ich kann sagen
ja, in DEVK ist mir das egal, ob in Production könnte ich ja zum
Beispiel sagen mindestens 2 Instanzen, damit ich in gewisse
Failover habe, also mindestens 2 replicars.
Ich könnte auch sagen, dass ein Cash in eine bestimmte Region
oder ein bestimmtes Rechenzentrum in der Cloud
deployed wird oder dass der vorkonfiguriert wird oder dass
man direkt sagt, die richtige Creedence werden irgendwo in den
Secrets Store abgelegt und so weiter.
Und das kann ich mit Terrorform beschreiben oder auch mit mit
anderen Infrastructure als Codesprachen.
Und dann Bündel ich das eben in so ein Recipy und sobald das
dann definiert ist, können Developers dann wiederum nutzen,
um ihren Reddit Cash zu deployen, ohne dass sie sich
eben Gedanken darüber machen müssen, wie die Pleuchten, wo
die Pleuel denn hin. Wie konfiguriere ich den denn
denn korrekt? Und diese ganz klassische, ja
sag ich mal Separation of Conservance, die ermöglicht dann
eben auch den, den den Operatoren, die diese Plattform
bereitstellen, dieses Plattform Engineering Team.
Ermöglicht denen dann auch wieder zu skalieren und auch
quasi Support anzubieten. Über ganz, ganz viele interne
Teams hinweg, weil ich ja eben einmal an zentraler Stelle diese
Policies und diese Art und weisen definiert habe und dann
kann ich halt eben, wenn es irgendwo ein Problem gibt, bei
einem, bei einem der Teams muss ich dann nicht in die
individuelle Konfiguration reinschauen, sondern die Nutzen
eines dieser Recipes und daran merkt man vielleicht aber auch
schon, dass das Ehrenthema für sehr große Unternehmen mit
vielen. Teams und mit vielen Apps ist
und ja jetzt eigentlich sehr ähnlich zu dem Thema Plattform
Engineering wahrscheinlich eher spannend ist für n Operations
Team was sehr sehr viele verschiedene Abteilungen und
developer Teams und Applikationen betreut das.
Heißt du als mein Operation Team stellst verschiedene Rezepte
zusammen für die entsprechenden Zielumgebungen.
Vielleicht gibt es irgendwie eine Testumgebung, eine
Produktionsumgebung gibt es verschiedene Rezepte wieso etwas
aussehen kann für die einzelnen Komponenten und ich als
Developer kann dann aus diesen Rezepten etwas kochen quasi das
heißt ich nehme die Rezepte und sage okay ich brauche jetzt
folgende Datenbank folgende. Caches folgende
Betriebsplattform Inkubanitis folgende Services möchte ich
bereitstellen und dann kann ich das entsprechend nutzen und über
bestimmte Konfigurationsparameter dann
meinen eigenen Anforderungen anpassen, ohne mich im Detail
jetzt damit beschäftigen zu müssen.
Wie kann ich jetzt folgende Services über der bicyb Template
in Azure Konfliktieren? Sondern das Ganze wird durch das
Expertenteam konfiguriert. Über die entsprechenden
Templates und ich kann dann über diese Abstraktionsschicht dann
darauf zugreifen. Genau.
Und diese Abstraktionsschicht, die kann auch verschiedene
Tiefen annehmen, das finde ich bei Radius eigentlich ziemlich
spannend. Also ich kann entweder sagen, ey
mir ist total egal, ich brauche eine mongo DB und dann kann es
sein, dass das Team mir eine in Adabos bereitstellt, weil da
gerade was frei ist, weil da gerade ein guter Deal irgendwie
entsteht und so weiter ich. Aber auch als als Team hingehen
und sagen, ich brauche ganz speziell eine, weiß ich nicht.
Azure Cosmos DB mit dem Mongo DBSTK in dieser und jener Region
und dann kann das Operations Team eben quasi auch
entscheiden, ob es auch diesen Abstraktionsgrad bereitstellen
möchte. Das heißt ich als als jemand der
der diese Apps schreibt und dafür verantwortlich ist, muss
ich diese Recipes gar nicht in einer ganz hohen
Abstraktionsebene nutzen, sondern kann auch weiterhin
gesteuert davon wie tief ich da gehen darf.
Das ist eine Entscheidung die das Operations Team trifft, aber
auch sehr spezifisch werden, das ist jetzt.
Im im Kontext dieses Podcasts ein bisschen schwierig, ohne
ohne Code oder ohne Live Beispiele zu zeigen.
Aber ich glaube, man kann sich das vorstellen.
Man definiert halt einfach genau, was man haben will und
kann dann da entsprechende Konfigurationen bereitstellen
und haben diese diese Recipes dann eben nehmen und.
Genau. Also für mich ist das, das ist
eigentlich so und das das Developer Team sagt Pass auf ich
hab n Frontend, das ist Container a und das soll mit nem
mit nem Backend reden, das ist Container b die stelle ich
bereit hier findest du die Container im Images.
Aber mein mein Backend, also Container b, das fragt ne
Datenbank ab und mir ist egal was das ist.
Hauptsache das spricht Mongo DB mit mir und den Connection und
String, den möchte ich bitte da und da und da rein injected
haben. Und stand heute ist es so, dass
Radius jetzt erstmal das ist. Ne, Wir sind in der frühen Phase
nur in Kubanitus funktioniert, das heißt ich schieb als
Developer dann die diese Beschreibung von meiner App, das
ist wie gesagt in Rade ist ne eigene Sprache, die haben sich
hier. Buysep genommen, weil es eben
was snizaznahen Welt kommt, das ist die bestehende
Infrastructure as Codes Sprache von Microsoft Azure, aber bauen
auch gerade ne Implementierung für Terrorformen das einfach n
Bizeps terrorform Provider gibt auf jeden Fall, ich nehme das.
Und schmeiß es einfach in mein kobabiertes Cluster rein und in
meinem Kobaniertes Cluster. Da läuft dann ein ein, ein
Operator nennt man das, also etwas was dann versteht was ich
da rein gebe und was dann versucht ein passendes Rezept
für diese Anforderungen die ich definiert habe zu finden.
Und in der Regel sollte das auch dann n Treffer ergeben, weil ich
ja hoffentlich nur Rezepte verwende, die von meinem
Plattform Engineering Team dann bereitgestellt werden und dann
wird gemäß dieses Rezeptes meine Anwendung konfiguriert, irgendwo
ne Datenbank oder n Cash oder was auch immer deployed.
Und das coole ist, dass eben dann bei bei der Auswahl dieser
Rezepte diese Radios Anwendung auch sich darüber bewusst ist,
wo sie denn gerade läuft. Also wenn es n Cluster ist, was
auf einem On Premium Rechenzentrum läuft, dann wird
vielleicht ein anderes Rezept für die Anforderungen Mongo DB
aus dem Regal gezogen, wie vielleicht wenn das Ding in der
Cloud läuft, dann wird vielleicht für die Anforderungen
Mongo DB ein Cloud native gemanagter Service Rezept
genommen. Und wir haben jetzt ganz oft
Microsoft gesagt, aber letzten Endes ist das ein Open Source
Projekt, welches dafür gedacht ist, beliebige Zielumgebung für
die Bereitstellung von Applikationen zu unterstützen.
Bisher, soweit ich das verstanden habe, Microsoft Azure
und AWS oder halt lokale Umgebung, aber es sollen halt in
Zukunft auch weitere Cloud Plattformen dazu kommen und das
ganze wird halt wie gesagt aus dem Open Source.
Reich der Microsoft Azure Organisation bei Microsoft
vorangetrieben mit der Zielsetzung, das als offenes
Projekt bereitzustellen und letzten Endes, das nicht an eine
Cloud Plattform wie Azure zu binden, sondern Developer in
diesem Cloud Eco System ist einfacher zu machen.
Ihre Anwendung in Zusammenarbeit mit ihrem Operations Team im
Unternehmen bereitzustellen, ohne wirklich diese
Herausforderung sich mit diesen ganzen Technologiewelten zu
beschäftigen. Ist es n Unterschied ob ich eine
Mongo DB kompatible Datenbank in AWS oder in Azure Bereitstelle?
Da hab ich andere Konfigurationsmöglichkeiten, die
Services heißen anders für mich als Developers, das
gegebenenfalls ja völlig egal, sondern wie du gesagt hattest,
ich möchte einfach nur wissen, welches Protokoll spricht das
Ganze auf welchen Port kann ich es erreichen und wie ich das
ganze jetzt auf der Cloud Plattform X oder y bereitstelle
ist mir ja am Ende völlig egal, sondern darüber entscheidet das
Betriebsteam, welches für mich eigentlich die Entscheidung
trifft was jetzt die Cloud Plattform der Wahl ist.
Genau das ermöglicht natürlich auch dann mal irgendwann
vielleicht die Cloud Plattform zu wechseln oder eine
Applikation, die bisher on Premises betrieben wurde, in die
Cloud zu heben. Also eigentlich ist es eine
Abstraktion von Clouds und von Containerumgebungen wie Kubanite
ist oder vielleicht auch sogar einem lokalen Docker compose und
von Helm und von all diesen, diesen diesen Details und
Technologien, die dazu gekommen sind sowie auch nochmal
terrorform und Buyceps und das wird eigentlich alles so ein
bisschen weg abstrahiert und eigentlich geht es wieder so ein
bisschen back to the back to the roots das.
Das Development Team sich auf Development fokussiert und
gleichzeitig aber ermöglichen wir trotzdem diese ganzen coolen
Benefits und Tools und Features und Technologien, die über die
letzten Jahre aufgekommen sind und in dieser Cloud native Welt
sich zu Hause fühlen. Videos ist dann eben dann ja n
Application Modellen Vorschlag von Microsoft, aber wie gesagt
funktioniert auch jetzt schon mit ABS und hat zum Beispiel
schon ne Backstage Integration. Backstage ist eigentlich
sodas.de facto Plattform Engineering Tool was ich gerade
sehr großer Beliebtheit am Markt über alle Clouds und alle Kunden
und Firmen hinweg etabliert, was zum Beispiel auch ein Open
Source Projekt von Spotify ist. Und genau ist da auch schon drin
integriert, also wird auch ganz eng mit dieser Plattform
Engineering. Community entwickelt und wie
gesagt nochmal wichtig ist aber kein also für den Developer ist
kein SDK oder sowas, also Radius ist also ein Application Model
fürs Deployment der App, das heißt Radius ist total egal wie
mein Code geschrieben ist. Solange das ein Container ist.
Merk ich da als Developer gar nichts von?
Das ist eigentlich eher ne Konfigurationsdatei, die ich
neben meinem bestehenden Code neben meinem Projekt Containern
in mein Repository lege. Jetzt.
Stellt sich bei mir die Frage, wie weit ist das Projekt, kann
ich es schon einsetzen, wie ist der aktuelle Stand, hast du da
mehr Einblicke? Ja, es ist vor ziemlich genau
einem Monat am 16 April, der Cloud Native Computing
Foundation übergeben und auch angenommen worden und ich glaube
übergeben schon vorher worden, aber ist jetzt als Sandbox
Projekt eingestuft. Wer sich erinnert, in der Cloud
Native Welt gibt es diese Cloud Native Computing Foundation, die
Open Source Projekte quasi listet und einem gewissen
Reifegrad auch quasi da vergibt. Und den kann man auch generell
nur erreichen, wenn man wirklich Vendor neutral ist.
Wenn es ein Team gibt, was das auch regelmäßig mantained und so
weiter und da ist es eben an die Cloud Active Computing
Foundation übergeben und als Sandbox Projekt jetzt gerade
angenommen worden. Also ich würde eigentlich sagen,
jetzt ist genau. Die der Tag gekommen, wo man
sich das auch mal anschauen kann.
Vorher war das glaub ich eher so n bisschen ne n Tech Konzept und
ne Spielerei und es sind auch einige coole neue Features jetzt
genau mit diesem ersten Release dazu gekommen, wie zum Beispiel
so n so n Application Graph also ich kann es zum Beispiel sehr
gut sehen, weil Radius ist dann ja genau die Instanz die genau
weiß welche Applikation es gibt und mit welchen welchen Cloud
Services das da kommuniziert wird, das heißt da wird so ein
kompletter Graph erstellt, so eine Übersicht über meine
Microservices und deren Dependencies und den finde ich
dann zum Beispiel auch wieder in Backstage in dieser Backstage
Integration und können wir schauen.
Ey, das das Nachbarteam wie sieht denn deren Application
Graph aus und welche Recipes verwenden die denn und so
weiter. Und wenn das Ganze jetzt euer
Interesse geweckt hat, dann geht gern auf die Webseite, die
packen wir euch unten in die Show Notes, damit ihr doch
tiefer einsteigen könnt und gebt uns gerne Feedback.
Was haltet ihr davon, ist das etwas, was in eurem Alter
relevante Relevanz finden können, ist das für euer
Unternehmen, in dem ihr Arbeit sinnvoll oder ein weiteres
Projekt, welches nur für ganz große Unternehmen?
Geeignet ist und für die meisten Developer im Alltag vielleicht
gar nicht relevant werden wird. Da sind wir auch an eurer
Meinung interessiert. Ja, total.
Weil ich hatte auch Unterschiedliches drüber.
Also ich bin der Meinung, auch Developer müssen nicht wissen,
wie man postgress of a wast deployed.
Und die andere? Die Gegenmeinung ist aber oft,
dass so Abstraktionslayer dann oft einfach manchmal genau
dieses eine Feature, was ich aber, was aber vielleicht super
cool ist, in AWS bei bei bei Postgress was ich gerne nutzen
würde als die, bei der Panda gar nicht mehr reinbringt, weil ich
ja vielleicht irgendwie so n Abstraktionslayer gebaut habe.
Und da bin ich mal so spannend, so zwischen diesen beiden Polen
bewegt sich da oft das Feedback. Das Schöne ist, dass technisch
ginge das alles in Radios, also ich kann wieder sagen, ich
definiere postgress als als Recopy.
Oder ich definiere Post, dress or AWS und Postgres on Azure und
Postgres on GCP als 3 verschiedene Recipes, die dann
auch vielleicht für 3 verschiedene Features haben
können. Verliere dann aber natürlich so
n bisschen diese die Möglichkeit die ganze Applikation vielleicht
von on premise in die Cloud zu hieven oder so.
Aber lass uns da doch wirklich gerne mal wissen, wie da eure
Meinung ist. Ist es eher, ist es für euch so,
dass ihr sagt, eigentlich ist es in den letzten Jahren fast schon
erschlagend oder Überladend geworden, welche Technologien
und wie tief in dem kompletten Application Stack ich als
Developer mittlerweile? Mich auskennen muss und seid ihr
dankbar über so, über solche Abstraktion oder sagt ihr
eigentlich total cool, dass jetzt in diesem Dev Ops Gedanken
wirklich alle Ende zu Ende alles verstehen, oder sagt ihr
vielleicht ja ich als Developer verstehe zwar, wie man AWS, wie
man auf AWS ne Post res deployed.
Aber mein Operations Team weiß nicht wie man irgendwie ne
Funktion in meinem Code schreibt.
Also er war er. Er sind für mich mehr
Operationsaufgaben gekommen als wir das Operations Team,
vielleicht auch Mad Mad Death Aufgaben dazwischen zumindest
malte und ich auf Konferenzen viele Gespräche und deswegen ist
es eigentlich auch super cool, dass wir hier im Podcast die
Möglichkeit haben, da euch noch eure Meinung zu fragen, scheut
da also nicht davor zurück uns entweder eine E-Mail zuschicken
oder unter Spotify einen Kommentar zu hinterlassen und
wenn da spannende Diskussionen auftauchen, dann können wir das
ja auch gerne in der nächsten Folge nochmal.
Erläutern bis dahin. Wir haben ein paar Links in die
Show Notes gepackt, es gibt so einen, glaube ich 30 Minuten.
Über Radios, die fand ich ganz spannend.
Es gibt Blogposts und auch die Webseite ist ganz ist ganz, ganz
gut gemacht, also schaut da gerne mal rein, wenn euch das
Thema Radios generell irgendwie jetzt spannend vorkam.
Genau und neben dem Feedback, über das wir uns immer sehr
freuen. Lasst uns gerne, wenn euch die
Folge gefallen hat oder allgemein der Podcast euch
gefallen hat, eine Bewertung, da könnt ihr auf den großen Podcast
Plattformen wie Apple Podcast oder Spotify machen und wir
freuen uns natürlich auch immer, wenn uns jemand aus der
Community einen Kaffee ausgibt. Ganz genau auch nochmal der
Reminder. Ich freue mich auch wahnsinnig,
wenn ihr bei der. In 2 Wochen unterstützen
möchtet, also nochmal der Reminder macht euch gerne einen
Account oder klickt auch schon mal auf den Reminder.
Es gibt einen kleinen kleinen Link, wo man sich schon mal
anmelden kann, wie gesagt in 2 Wochen erzähle ich ein bisschen
mehr darüber, aber da freue ich mich dieses mal fast noch mehr
als über Kaffee. Ihr dürft natürlich trotzdem
malte schon mal einen Kaffee da lassen und.
Von daher würde ich sagen, wir hören uns in 2 Wochen zu deinem
großartigen Announcement wieder, werden dann natürlich auch neben
deinem Product Hand Launch ein weiteres Thema haben.
Legen wir noch fest. Aber wir würden uns freuen, wenn
ihr auch in 2 Wochen wieder mit dabei seid.
Bis. Dahin habt eine gute Zeit.
Danke fürs Zuhören und schreibt ganz viel Code.
Bis dann ciao.