Andrena entwickelt – Der Podcast

Thema: Cloud und Cloud-Migration: Cloud-Migration, Dev-Ops, Cloud-Services und unsere Erfahrungen dazu.

[Musik spielt]

Einzelne Zitatausschnitte als Intro

Mit einer Person braucht man kein Plattform-Team.
Also das war jetzt kein Thema, was wir in zwei Monaten abgeschlossen hatten oder in einem Vierteljahr.

Intro-Jingle: andrena entwickelt. Der Podcast von andrena Objects. Von EntwicklerInnen für EntwicklerInnen.

Daniel: Willkommen zu einer weiteren Folge Andrena entwickelt. Heute zu meiner Seite Andi.

Andi: Hallo Daniel.

Daniel: Wir haben heute zu Gast den Fabian.

Fabian: Hallo.

Daniel: Und den Thorsten.

Thorsten: Hallo.

Daniel: Wollt ihr euch beide mal kurz vorstellen?

Fabian: Ich bin der Fabian. Ich bin seit 2012 bei Andrena. Ich bin Java-Entwickler. Einiges Vorwissen in Richtung Linux-Administration und so. Das heißt, eine natürliche Verbindung zu den ein bisschen op-sigeren Sachen. Und habe jetzt in der Vergangenheit Projekte mitgemacht, in denen ich in die Cloud migriert bin. In verschiedenen Kontexten. Ich habe AWS ausprobiert, habe ein bisschen mit IONOS rumexperimentiert und bin gerade dabei, im Kontext von GCP rum zu migrieren.

Thorsten: Ja, ich bin Thorsten. Ich bin seit 2016 bei Andrena und eher Full-Stack-iger unterwegs, also nicht rein Java-mäßig. Und hatte aber auch schon in verschiedenen Cloud-Projekten mit Google Cloud vor allem und IONOS was zu tun. Ja, im Moment benutze ich auch wieder ein auf Google Cloud basiertes System. Ich habe eben verschiedene Sachen da auch schon gesehen.

Daniel: Ihr habt das ja jetzt beide schon angesprochen. Also das Thema dieser Folge dreht sich um Cloud oder beziehungsweise Entwicklung für die Cloud. Sowohl für Hyperscaler wie AWS, GCP oder Azure, aber auch den europäischen Alternativen wie IONOS oder auch Stackit. Ihr beide habt zumindest mal Berührungspunkte auch bei IONOS gehabt. Deswegen werden wir auch mal da in die Vergleiche reingehen. Aber was mich erstmal interessieren würde, ihr hattet jetzt beide Migrationsprojekte Richtung Cloud. Und wie seid ihr da vorgegangen? Möchtest du da was zu sagen, Fabian?

Fabian: Gerne. Das erste Migrationsprojekt hatte eine gewisse Vorgeschichte im Sinne von erstmal, der Ausgangspunkt war, es ist ein Team und es gibt irgendwo ein Ops-Team. Und wenn wir irgendwas machen, dann haben wir einen definierten Zeitpunkt und irgendwann landet es eben da drüben. Es wird ausgeführt auf interne Infrastruktur und hat eben das übliche Spiel, dass man sich da eng absprechen muss, dass man nicht flexibel ist als Entwicklungsteam und eben darauf angewiesen, dass das Ops-Team gut funktioniert oder die Dinge so tut, wie man sich das vorstellt. Und da war der erste Schritt tatsächlich in Richtung DevOps. Da ist einer vom Ops-Team, der Interesse hatte, den Horizont für sich zu öffnen, sag ich mal, mit zu uns ins Entwicklungsteam gehüpft. Und hat dann uns quasi auf dieser, okay, hier deployt ihr mit einem Tomcat und da macht ihr SSH hin und so da rangeführt. Und dann haben wir nach einer gewissen Zeit haben wir dann auch das Vertrauen der relevanten Leute errungen als Entwicklungsteam, dass wir das eben gut können. Und dann ist tatsächlich irgendwann dieser Ops-Mensch, also mit diesem Fokus auf Ops, ist dann weitergezogen und hat gesagt, ah ja, ihr schafft das. Und dann waren wir da und haben dann im Rahmen von allgemeinen Vorgaben und Flexibilisierung unserer Möglichkeiten, die wir da machen wollten, haben wir entschieden, okay, jetzt haben wir eine gute Grundlage und jetzt gehen wir in die Cloud. Und was müssen wir denn dafür tun und haben verschiedene kleine Schritte und haben eben versucht, das kleinschrittig hinzukriegen. Also nicht das große Big Bang, wie es bei den vorherigen Sachen, die wir mitbekommen haben, immer ablief, wo du nichts anderes mehr entwickelst und keine Feature mehr liefern kannst, bis du dann live bist mit dieser neuen tollen Cloud-Lösung, sondern dass eben parallel dazu, zu dieser Migration, ganz normal Feature geliefert wurden. Das hat natürlich dazu geführt, dass das nicht von jetzt auf gleich ging. Also das war jetzt kein Thema, was wir in zwei Monaten abgeschlossen hatten oder in einem Vierteljahr. Ich glaube, unsere ersten Sachen haben, unsere ersten Vorbereitungen haben da ein gutes Jahr begonnen, bevor wir eine unserer Stages, die erste Stage live genommen haben in der Cloud. Und bis wir dann produktiv waren, waren es wahrscheinlich anderthalb. Aber das war eben an sich nicht so schlimm, weil es da keinen konkreten Blocker gab. Es gab nicht das Ereignis, auf das wir hinarbeiten mussten oder das Feature, was jetzt total entscheidend war. Und deswegen, genau, haben wir das nach und nach angehen können, haben letztlich als ersten Step die Dinge, die da auf irgendwelchen Linux-Kisten direkt liefen, dockerisiert, haben andere Sachen uns zumindest im Kleinen geschnappt und Cloud-fähiger gemacht, sodass wir es parallel eben intern weiter betreiben konnten, intern weiter Features und Deployments machen konnten, aber parallel dazu manche Komponenten vollständig ersetzt oder eben in einer Variante in der Cloud dann schon betreiben konnten und zunehmend in die Cloud geschoben haben mit verschiedenen Feature-Flags, um dann die gleiche Komponente eben in verschiedenen Umgebungen haben zu können. Und auch mit dem Wissen, okay, wir werden jetzt nicht alles hundertprozentig im ersten Schritt so umswitchen, dass wir die absolut cloud-nativsten Lösungen wählen, sondern vielleicht erst mal noch ein NGINX mehr gerappt in einem Container hochziehen, damit wir mit, oder sogar, ich glaube, ja stimmt, wir haben sogar auch Apex, also die Infrastruktur war in dem Fall eben Apache und Tomcat-Zeugs basiert primär. Also haben wir tatsächlich im ersten Schritt ein Apache mit hochgezogen, weil da dann diese komplex gewartete Konfiguration dann mehr oder minder näher übernommen werden konnte in die Cloud. Und das haben wir dann irgendwann später, als wir dann live waren, wieder abgelöst, aber also das war so ein bisschen unsere Strategie. Wir wollen eben, weil wir den Big Bang nicht wollen, wollen wir möglichst lange das parallel betreiben können, bis wir dann tatsächlich den Schritt gehen durften. Da war eben ein kniffliger Teil im Übergang, dann so diese klassischen, wir sind im Konzernkontext und haben natürlich Firewalls, Firewall-Freischaltung von irgendwelchen Teams. Und da musste man dann natürlich auch gucken, okay, wie kriegen wir raus, dass das alles funktioniert? Wie können wir das mal testweise schon deployen und schauen, dass die Verbindungen tun, dass die Requests durchgehen? Wie können wir das alles testen, ohne jetzt das Ganze kaputt zu machen vorher, also nach außen sichtbar kaputt zu machen? Also konkret ging es auch um eine Webseite, das spricht zwar von außen erreichbar, wurde aber dann fröhlich durch interne Infrastruktur getunnelt, um da hinzukommen. Auch das ein Zwischenschritt, um möglichst wenig Änderungen gleichzeitig zu machen. Aber letztlich hat sich das ausgezahlt. Wir sind dann mit den Stages nach und nach live gegangen, konnten dann irgendwie den Switch umdrehen, umschalten und genau, haben dann die Journey für den ersten Schritt, wir sind jetzt alles mit allem in der Cloud geschafft gehabt und konnten dann über die nächsten Jahre, also es war, wie gesagt, so ein Projekt nebenher, über die nächsten Jahre dann tatsächlich die nativeren Features nutzen, aktivieren, weil wir dann eben nicht mehr zweigleisig fahren mussten. Also eigengewartete Container, sprich infrastrukturnähere Sachen rausschmeißen und ersetzen mit Service-siegeren, also von der Cloud-Infrastruktur bereitgestellten Sachen ersetzen. Soweit erstmal.

Daniel: Da war jetzt schon echt mega viel drin, wo ich gerne auch später nochmal drauf eingehen möchte. Aber Thorsten, du hattest ja nicht im selben Projekt gearbeitet, du hattest ein ganz anderes. Magst du deine Erfahrung auch noch teilen?

Thorsten: Ja, es war auch nicht in dem Sinne ein Legacy-Projekt, was dann online genommen wurde. Es war eher, wir hatten einen Prototypen gebaut und mussten den irgendwie online nehmen. Und das Online-Nehmen war dann tatsächlich eine Cloud und da waren wir dann zunächst in der Google-Cloud unterwegs und dann hat sich herausgestellt, dass wir die aus rechtlichen Gründen nicht benutzen durften. Und dann sind wir einmal, haben wir noch die Cloud gewechselt und sind zu IONOS umgezogen. Und ja, also es ging sehr gut, weil von vornherein in dem Projekt relativ klar war, dass wir uns nicht zu sehr auf einen Cloud-Anbieter verlassen können. Und dann wurde das eher Richtung Kubernetes-Native entwickelt und es gab ein paar kleine Störungen beim Umziehen, weil verschiedene Kubernetes-Installationen dann doch etwas unterschiedlich sind. Aber es ging am Ende. Also es ging am Ende relativ flott, dass das dann auch beim, dass der Anbieterwechsel dann einfach auch geklappt hat. Die Anwendungen, das waren Microservices, die in Docker-Containern liefen und das war relativ von Grund auf so auch vorgesehen gewesen, dass wir eben so verschiedene Container hatten, die da miteinander interagieren. Deswegen war das an der Stelle relativ einfach, überhaupt in die Cloud zu kommen. Aber man musste dann halt nochmal gucken, wie man von A nach B kommt.

Andi: Weil du es gerade kurz angesprochen hattest und das ja auch bei vielen Unternehmen und Projekten ja so reinspielt, überhaupt die Abwägung zu haben, nicht auf AWS, GCP, Azure oder wie die anderen Hyperscaler heißen zu gehen. Du hast ja jetzt gerade rechtliche Sachen angedeutet. Kannst du da ein bisschen ins Detail gehen, sofern möglich?

Thorsten: Es ging um den Datenschutz. Und ich habe da für eine Organisation gearbeitet, die bestimmte Anforderungen hatte. Und Google hat halt gesagt, ja wir sind Google, hier sind unsere Angebote, macht was ihr wollt. Und das hat halt nicht gereicht. Und IONOS hat damals gesagt, okay komm, wir lassen mit uns reden, wenn ihr das braucht. Und das sind einigermaßen vernünftige Anforderungen und es waren einigermaßen vernünftige Anforderungen. Klar, unterschreiben wir da auch einen Vertrag mit euch. Und ja, das machte das dann wesentlich einfacher für uns. Und deswegen sind wir dann diesen Weg gegangen.

Andi: Also es war dann nicht jetzt ausschlaggebend, dass Google oder so ein US-Unternehmen ist und IONOS jetzt in dem Fall ein deutsches Unternehmen, sondern es waren wirklich, dass sie sich nicht auf gewisse Vertragsdetails eingelassen haben.

Thorsten: War damals noch nicht so heiß mit dem, zu welchem Land welches Unternehmen gehört. Und es ging vor allem wirklich darum, lassen die sich überhaupt darauf ein, was wir benötigen. Also was das Projekt benötigt hat oder was der Kunde benötigt hat.

Daniel: Ich würde nochmal zurückgehen zu Fabians Migrations-Story. Du hattest ja gesagt, ihr hattet an sich die Ops-Expertise, um das auch so on-premise zu betreiben. Aus anderen Migrationen kenne ich jetzt eher so die Story, wir haben die Expertise halt nicht. Wir gehen in die Cloud, damit die Infrastruktur für uns gemanagt wird. Was waren denn bei euch da die Motivationen?

Fabian: Also ich meine, man muss natürlich sagen, wir konnten uns auf irgendwelchen Servern, SSH und so einloggen und durften auf verwobenen Wegen an Tomcat und Apache-Settings rumdrehen. Aber es war jetzt so aus Entwicklungsteamsicht schon so ein bisschen von hinten durch die Brust, weil wir natürlich da auf irgendwelchen Shared-Systemen zum Teil unterwegs waren. Sprich, da waren noch andere Teams. Wir durften also oder sollten nicht Dinge tun, die die betreffen. Also war da immer so ein bisschen ein Korsett drum und gleichzeitig haben wir zumindest, also es war nicht ganz so, also ja, es war eine Webseite, aber letztlich war hinten dran eben ein CMS, was eigentlich nicht cloudfähig war und verschiedene lustige Verstrickungen mit Systemen, die noch weiter hinten waren und außerdem ein gewachsener Zoo an Microservices. Das heißt, wir hatten so verschiedene Ideen, was wir gerne machen würden und schon allein irgendwie Container intern laufen lassen, statt das alles über deren Festgezurrte, es gibt A und B-Systeme und ihr switcht immer von A und dann nach B und dann bringt ihr irgendwelche Gruppen rein. Also es waren irgendwelche lustigen vorgegebenen Ideen, wie man halt deployed und wie man wieder die Systeme laufen und das hat immer wieder auch zu Problemen geführt und war irgendwie aufwendig. Wir haben das schon versucht, so durchzuautomatisieren, wie es nur ging, gehört häufig und möglichst schmerzfrei deployen wollten und unsere Änderungen reinbringen wollten. Aber einerseits war eben da die Möglichkeit zuverlässig und häufig zu deployen erschwert und andererseits unsere Ideen zumindest und unsere Anforderungen daran, was denn die Infrastruktur bereitstellen soll, in dem Umfeld schwieriger, schwierig oder zu schwierig im Vergleich zu, wir haben in der Cloud einfach fertige Services, die wir dann nutzen konnten, was ich, irgendwelche Container-Services zum Beispiel und die wir dann zusammen vertraten können, wie wir halt wollten. Wenn man jetzt von dem Grundgedanken ausgeht, dass wir einigermaßen Ahnung davon hatten, was denn, was sind Netzwerktopologien, wie macht man Container, wie tickt das Ganze auf Ops-Ebene, wenn man das mal voraussetzt, dann haben wir einfach viel mehr Freiheit gehabt, um unsere Ansprüche umzusetzen in der Cloud, als wir es auf dem On-Premise-Ding hatten. Ich sage mal, nicht grundsätzlich natürlich ein Blocker, also man könnte ja auch diese ganzen Möglichkeiten auf dem On-Premise-Dingen anbieten. Also sprich, wenn wir da lang genug rumgewurschtelt hätten, dann hätten die uns wahrscheinlich auch irgendwelche VMs intern gegeben, aber dann kommen wir wieder in das Ding, dass wir dann auch plötzlich dafür zuständig sind, System-Updates, also OS-Updates und sowas einzuspielen und uns zu überlegen, wie dann auf der Ebene Fallbacks, Ausfallsicherheit etc. zu bewerkstelligen sind. Und das hat die Cloud, je weiter du in der Abstraktion im Stack hochläufst, also genügend Software-as-a-Service oder Plattform-as-a-Service weit genug weg bist von der Infrastruktur. Das bietet die dir halt. Und dann hast du diese ganzen Sorgen nicht mehr. Du könntest vielleicht in deiner Build-Pipeline dafür sorgen, dass dein Container-Image regelmäßig aktualisiert wird, was als Grundlage dient. Aber du kannst es halt auch auf der Ebene schön durchautomatisieren, schön sehen, ob diese ganzen Änderungen, die du da im Image hattest, Probleme darstellen auf den unteren Stages und sowas. Also dieses Ganze, wir hätten eigentlich gerne Container gehabt, weil das auch schon, das ist jetzt 2020, glaube ich, grob sind wir da mit dem, weiß ich mehr mit welcher Stage, ob das dann schon Prod war. Also da sind wir jedenfalls, haben wir angefangen live zu gehen mit dem Krams. Da waren Container auch schon das Gängige und das gab es halt einfach eben nicht. Ob das ein Team gemacht hätte, was weniger Ops Ahnung gehabt hat, schon allein wegen diesem nicht Cloud-fähigen CMS, was wir dann selber in Container gepaketiert haben. Das war halt eine Kaufsoftware. Die haben auch ihre eigene Cloud angeboten, aber das war viel zu teuer für den Kunden. Also sprich, wir haben da eigene Wege gefunden, um das zu machen. Ich glaube, das wäre ohne die richtige Expertise nicht gegangen. Und so gesehen ist es ein bisschen eine andere Story als, oh, wir haben gar nicht die Expertise, das hier zu betreiben. Deswegen gehen wir in die Cloud, weil die das alles schon anbieten. Sondern es war eine Mischung. Also mehr Flexibilität, dafür ähnliche Komplexität, aber mit mehr Möglichkeiten in der Cloud. Und zumindest der Option und der Perspektive auch zu vereinfachen. Also sprich, diese Infrastruktur, Wissensgeschichten da wieder rauszunehmen und auf Standard, was ich, ein AWS Lambda oder was auch immer einzusetzen.

Daniel: Ja, danke für die Erklärung. Ich fand das eine super Zusammenfassung von Gründen, wieso man in die Cloud gehen kann. Jetzt mal nochmal von der anderen Seite gesprochen. Ihr kennt ja jetzt vor der Cloud, nach der Cloud. Gab es da jetzt auch Sachen, wo ihr gesagt habt, vorher war es besser?

Thorsten: Also bei einfachen Systemen, die Betriebskosten in der Cloud sind erstmal gar nicht so niedrig, wie man sich das manchmal vorstellt. Also gerade wenn man jetzt einfach, wenn man anfängt, irgendwie ein Kubernetes-Cluster aufzuziehen und da nur eine Webseite draufpackt, dann ist das ganz schön teuer. Also man muss sich schon überlegen, was man da eigentlich wirklich braucht. Und On-Premise-Sachen können billiger sein. Also das habe ich auf jeden Fall gemerkt. Man muss halt Leute haben, die es betreiben. Das ist dann immer so das Thema.

Fabian: Ja, ich würde auch in die Kerle schlagen mit dem, man braucht halt die richtigen Leute oder braucht vielleicht potenziell andere Skills. Also für mich ist die Frage so ein bisschen, betreibst du es selber oder hast du ein Ops-Team? Weil das ist für mich fast nochmal orthogonal. Also ich finde das, in der Praxis sind diese zwei Fragen ein bisschen verknüpfter, aber eigentlich ist es ja orthogonal. Wer betreibt es, ob es jetzt ein Ops-Team in der Cloud betreibt und ich als Anwendungsentwickler schmeiße da nur was rüber. Oder ob die das On-Premise betreiben, das ist dann tatsächlich eine Frage der Kosten und what wollen die und wie müssen die skalieren können und so ein Zeugs. Aber das hat in meinem Verhältnis dazu, wie viel Stress habe ich damit, wie tief muss ich mich da auskennen, hat das ja nicht so viel zu tun. Aber meist ist es eben doch so, dass das irgendwie in Kombinationen kommt. Also dass du die interne Infrastruktur, vielleicht weil sie eben zu wenig Service, ich biete ein Service an und Self-Service mäßig meine ich jetzt, gebaut ist. Da hast du dann klassischerweise eben weniger als Entwicklungsteam mitzutun. Musst dich also auch nicht um, zumindest auf Infrastrukturebenen so mit SLAs und Zeugs beschäftigen. Wenn was ausfällt, wird dann schon der Admin das Ding neu starten oder sowas. Keine Ahnung, das sind so die Klassiker, ist nicht erreichbar, dann muss ich halt neu starten. Denn in der Cloud ist es dann eben meistens in der Praxis anders. War jetzt zumindest bei uns so, dass wir, wenn irgendwas nicht tat, dann haben wir das Bedürfnis gehabt und die Verantwortung gesehen, dass wir da drauf gucken. Lustigerweise hat das dann in der Praxis eigentlich immer im Ergebnis bedeutet, wir sind zwar nicht erreichbar, aber es liegt an den Komponenten, die wir seit der Migration noch nicht von On-Premise wegbekommen haben, weil die Requests dann doch, die Requests doch über die internen Systeme kamen und die sind überfordert gewesen oder was auch immer. Also in der Praxis war es sehr ruhig. So gesehen würde ich jetzt da aus der Entwicklungssicht sagen, ist jetzt kein Nachteil gewesen, aber es ist auf jeden Fall komplex, eine komplexe Lernkurve für Leute, die damit eben nichts zu tun gehabt haben vorher. Gegenüber, ich schmeiße das nur über den Zaun. Aber das, wenn ich anfangen muss, mich mit Linux-Servern und Apache oder NGINX oder was auch immer Konfigurationen zu beschäftigen, dann habe ich halt auch das Problem. Also es ist immer die Frage, wie da die Skills sind.

Thorsten: Ich denke, das Problem ist auch, also bei mir im Projekt war, es war sehr klein, also es war quasi Start-up-mäßig unterwegs und wenn ich jetzt auch noch hätte selber Server managen müssen, also ich war tatsächlich allein während der Zeit, das wäre sehr aufwendig gewesen, dann wäre ich noch langsamer geworden. Also es bietet einem schon die Möglichkeit, eine gewisse Abstraktionsebene zu erreichen, wo man dann auch eine Chance hat, irgendwie alles im Blick zu behalten. Ich denke, das ist der große Vorteil von der Cloud. Ich denke, ganz einfache Systeme kann man auch On-Premise betreiben, aber ja, wenn es komplizierter wird, dann braucht man entweder ein Ops-Team oder, da stimme ich dir ganz zu, oder es wird halt echt schwierig dann.

Fabian: Ich habe noch einen Gedanken in Richtung, was haben wir vielleicht als Nachteile erlebt und bezüglich Komplexität. Ich habe auch in der Cloud den Eindruck gehabt, je mehr du so ein Software-as-a-Service-ähnliches Ding nimmst, also was dir mehr Funktionalität bietet und du dich weniger um den Unterbau kümmern musst, desto beschränkter oder desto opinionateder, also desto mehr hat sich dann in dem Fall AWS überlegt, wie man das Ding denn zu benutzen hat. Und wenn dann unsere Anforderungen nicht genau da reingepasst haben, dann hast du halt ein Problem gekriegt. Also sprich, wenn du eine einfache Seite betrieben hast, die genau auf eine bestimmte Weise zuzugreifen gewesen wäre, so ein statisches Ding, dann hast du halt ein S3-Bucket als Webseite betrieben. Wolltest du SSL haben und eine eigene Domain, dann bist du schon wieder rausgefallen. Ich weiß nicht, wie der aktuelle Stand ist, aber sobald dann gewisse Anforderungen dazukamen, hat das schon wieder, das Vorgefertigte schon wieder nicht geklappt. Also sprich, wir sind durchaus ein paar Mal in so Sackgassen gelaufen, wo wir dachten, naja, das ist der Service, der offensichtlich dafür zuständig ist hier bei AWS und wahrscheinlich aus Mangel an Erfahrung, haben wir das dann probiert, damit umzusetzen und sind in die Situation gelaufen, ah, okay, du darfst hier maximal so und so viele Rules haben und wir brauchen jetzt gerade eine Rule mehr in diesem Regelsatz. Das ist jetzt schade, wie kommen wir jetzt da drum rum? Oder wir mussten irgendwie das umformen, weil nicht so und so viele Bedingungen gleichzeitig in irgendeinem Ding ging. Das sind völlig obskure Begrenzungen, die man sicherlich in der Doku-Hilfe vorher hätte herausfinden können, aber die wir halt nicht, von der wir nicht wussten. Und dann sind wir da in irgendeiner Ecke, haben wir in irgendeiner Ecke entwickelt, bewusst eigentlich an einem fertigen, bereitgestellten Service hin orientiert, der uns dann aber so ein bisschen, ja, doch behindert hat und von dem wir uns dann letztlich darauf basierend vielleicht doch wieder gelöst haben, weil wir gesagt haben, okay, da brauchen wir was Eigeneres oder ach, was wäre doch so ein NGINX, den man einfach frei konfiguriert, schön an der Stelle. Also da würde ich sagen, ist auch nicht alles Gold, was glänzt in diesem AWS-Ding beispielsweise. Oder ich vermute mal, es ist bei vielen Hyperscalern so, du hast halt tausende an Services, aber die sind nicht unbedingt alle in ihrer maximalen Breite ausgeprägt, wenn man es jetzt vergleicht mit vielleicht ähnlichen Open-Source-Projekten. Also wenn es nicht gerade ein Open-Source-Projekt ist, was einfach bei denen gehostet und ein bisschen gemanagt wird.

Thorsten: Bei den kleineren Läden, da hat man die Wahl dann einfach nicht. Also da muss man sich dann halt an diese Standardlösungen eher halten und eventuell auch selber mehr basteln. Aber da hat man auch mehr Freiheiten, das ist dann schon so. Also wenn du halt keinen Ingress zur Verfügung gestellt kriegst, dann musst du dir halt deinen Ingress selber bauen oder selber reinmachen. Und dann kannst du dir auch aussuchen, was für einen Ingress im Kubernetes du drin hast. Und wenn du Function-as-a-Service haben willst, dann musst du halt irgendwie, ich glaube, das heißt, dann musst du irgendwas auf Kubernetes draufsetzen, was das dir dann unterstützt. Also es ist dann, ich denke, diese Funktionalitäten kann man alle zur Verfügung stellen, aber es braucht dann halt Können. Und dann, wenn man das Können hat, kann man die Sachen auch umbiegen, wie man sie haben will.

Daniel: Thorsten, würdest du jetzt sagen, das sind so die einzigen Limitationen, wenn man jetzt auf einen, Anführungszeichen, kleineren Anbieter wie jetzt IONOS wechselt, von einem Hyperscaler wie AWS oder GCP?

Thorsten: Naja, also man hat bestimmte Software einfach nicht. Also bestimmte Dinger, die bei den Hyperscalern vorhanden sind. Und es gibt manchmal sehr seltsame Einschränkungen. Also beispielsweise zu der Zeit, wo ich da unterwegs war, ein S3-Bucket war immer einer Person zugeordnet. Und das war ein bisschen eine Schwierigkeit, weil wir unsere Backups über S3-Buckets gemacht haben. Und wenn dann jemand die Organisation verlässt, wie geht man dann damit um? Das war so ein bisschen die Seltsamkeit. Ich hoffe, dass die das inzwischen gelöst haben. Aber man muss manchmal ein bisschen mehr basteln. Das war einfach so das, was ich mitgenommen habe. Also die Einschränkungen, es gibt weniger Features und ab und zu seltsame Dinge, die noch nicht funktionieren. Auf der anderen Seite waren die auch sehr zugänglich. Also wenn was nicht funktioniert hat, hat man auch wirklich mit Leuten gesprochen, die wirklich Ahnung hatten und die einem auch weitergeholfen haben, soweit es eben ging.

Fabian: Zur Frage Unterschied und Schmerzen fällt mir gerade noch ein, dass man sich dann schon, je nachdem, was für ein Support-Level man da gebucht hat bei diesen Hyperscalern, fühlt man sich schon mehr so als sehr kleines Rädchen. So von wegen, ja, poste halt in diesem offenen Forum, wo sich Leute mit ihren Problemen rumtummeln, wenn dein Service gerade nicht funktioniert. Auf der Holzklasse beginnt das Ganze halt und im Zweifel kriegst du dann, kriegst du bei Sachen, die so ein bisschen kniffliger zu analysieren sind und die nicht unbedingt das Produktivsystem betreffen, braucht es dann eine Weile, bis du da irgendwie Feedback bekommst oder du kriegst, ja, hast eben im Gegensatz zu einem Anbieter, der kleiner ist und Interesse hat, neue Kunden zu finden, vielleicht nicht ganz so den Kontakt. Aber klar, mit Geld kann man dann da aufsatteln und mehr Aufmerksamkeit sich erkaufen. Aber gleichzeitig fällt mir noch als Unterschied zu intern und Cloud auf, dass die bezüglich der Zusicherung von wie gut läuft denn das, was du hier nutzt, ist ja auch nur sehr vage. Oder klar, auf dem Papier steht dann irgendwas, du hast die in die SLA, aber wenn es dann nicht verfügbar ist, dann im Maximum kriegst du wahrscheinlich deine Gebühren zurück, die in der Zeit aufgelaufen sind. Aber eigentlich ist es deine Aufgabe als Team, deine Infrastruktur so aufzustellen und mit so einer Ausfallsicherheit, also sprich nochmal eine andere Availability Zone oder so, dass sich das dann im Idealfall nicht betrifft oder du musst es eben aushalten. Aber das fühlt sich halt nochmal ein bisschen anders an, als der ganze Laden raucht, weil irgendein System intern nicht erreichbar ist und hast da volle Aufmerksamkeit. Und ja, bei AWS oder sowas hatte ich den Eindruck, wenn es nur wenige betrifft, dann ist auch der Trubel nur wenig und du bist ein bisschen auf dich alleine und hättest lieber noch mehr Ausfallsicherheit einbauen sollen oder sowas.

Andi: Wenn ich euch jetzt beide richtig verstanden habe, habt ihr ja in euren beiden Projekten eher den, sagen wir mal, plattformunabhängigeren Ansatz gewählt? Gab es trotzdem irgendwelche Punkte, an denen ihr quasi ein bisschen den Vendor-Login von einem der Anbieter reingelaufen seid, weil ihr irgendwelche Berechtigungskonzepte oder so irgendwas von den einzelnen Anbietern nutzen musstet oder auch verwendet habt, weil es einfacher war?

Fabian: Ja, wir haben, also das hat sich vielleicht so angehört, als wären wir total generisch und ohne Vendor-Login, aber wir haben zum Beispiel eben nicht Kubernetes gewählt gehabt, weil das Extrakosten pro Monat produziert hätte. Also ein Kubernetes-Cluster kostet ja erstmal, ohne dass du Nodes hast, kostet bei AWS erstmal Geld. Und das Gegenkonzept, die ECS, Elastic Container Service oder sowas, die kosten halt, da ist der, sozusagen der Manager von dem Ding ist kostenlos. Also haben wir gesagt, na gut, möglichst managed, nehmen wir das. Mit entsprechend Randfällen, in denen man sich fragt, wie kann das sein, dass das immer noch nicht gefixt ist. Aber letztlich halt trotzdem Container. Also sprich, die gemeinsame Geschichte war eben, wir haben alles containerisiert und schieben da Container hin und her. Und wer das dann ausführt, ist da ein gewisses Detail. Das ist nicht mehr ganz so, da sind wir nicht mehr ganz so gebunden dran. Aber trotzdem, der ganze Kram drumherum ist ja immer noch extrem cloud-spezifisch. Also diese ganze, wer darf was, Berechtigungsgeschichte innerhalb der Systeme. Du willst ja, dass dieses, diese Rolle, technische Rolle innen drin, nur genau dahin darf und nur genau auf das S3-Bucket oder was auch immer zugreifen kann. Das ist natürlich in einer super, oder haben wir zumindest, vielleicht gibt es da auf Kubernetes-Ebene dann auch Abstraktionen, die einem helfen würden. Aber meine Erfahrung ist bislang, da bist du dann doch tief in den Details des jeweiligen Cloud-Anbieters und waren wir auch damals in dem Projekt. Das heißt, da zu sagen, ah ja, ihr seid ja jetzt in der Cloud, jetzt könnt ihr ja rüber wechseln zu einem anderen Anbieter, geht auch zu Azure oder zu GCP oder IONOS. Spätestens da wäre dann, glaube ich, ein Großteil der Arbeit auch mit drin. Auch wenn die Anwendungen natürlich Cloud-fähig dann sind, also darauf vorbereitet, dass die, keine Ahnung, Environment-Variablen von außen geben die Config vor und so ein Zeugs. Man hat kein lokales Dateisystem mehr, was irgendwie gemounted sein muss und solche Geschichten, die halt vorher On-Premise der Standard waren. Das hätte es jetzt flexibler gemacht, davon wegzugehen, aber trotzdem hat man natürlich noch ganz viele Details, die einen binden oder uns gebunden haben damals und die vielleicht in manchen Aspekten, wenn wir Kubernetes verwendet hätten, zum Beispiel, als gefühlt die Standard-Container-Plattform jetzt, wäre das vielleicht noch mal ein bisschen anders gewesen. Ich weiß nicht, wie, Thorsten, du hast ja, glaube ich, auf Kubernetes, von Kubernetes zu Kubernetes oder irgendwie sowas.

Thorsten: Wenn ich euch jetzt beide richtig verstanden habe, habt ihr ja in euren beiden Projekten eher den, sagen wir mal, plattformunabhängigeren Ansatz gewählt? Gab es trotzdem irgendwelche Punkte, an denen ihr quasi ein bisschen den Vendor-Login von einem der Anbieter reingelaufen seid, weil ihr irgendwelche Berechtigungskonzepte oder so irgendwas von den einzelnen Anbietern nutzen musstet oder auch verwendet habt, weil es einfacher war?

Thorsten: Ja, und selbst da sind dann Probleme aufgetreten. Also es liegt einfach daran, dass die unterschiedlichen Kubernetes-Installationen natürlich nicht identisch sind und die Hyperscaler haben in der Regel irgendwie ein paar eigene Services da drin. Dann ist das halt ein spezieller Ingress, der dann halt das Format auf eine ganz bestimmte Art und Weise subtil anders ist. Das ist alles nicht so schlimm, aber man muss sich darauf einstellen, dass man ein bisschen was umstellen muss. Ja, wir sind wirklich relativ wenig in diese spezifischen Sachen eingestiegen, weil wir auch relativ früh gewechselt haben und bei IONOS diese spezifischen Sachen nicht so wirklich vorhanden waren und haben dann aber auch eigene Sicherheitsfeatures eingebaut, die halt auf Kubernetes basiert haben und hatten aber auch nicht so wahnsinnig komplizierte Anforderungen, gerade was das Autorisierungsmanagement, was es teilweise in den Clouds gibt. Das ist ja dafür da, dass man es auch bei großen Organisationen verwenden kann. Und wenn man die Rolle Entwickler hat, darf alles, dann braucht man da nicht so ein kompliziertes Management. Deswegen war das alles relativ harmlos. Oder vielleicht gab es auch noch zwei Rollen. Ich weiß nicht mehr. Admin und Entwickler und Admin durfte alles und Entwickler durfte nur auf Kubernetes pushen und nicht irgendwelche neuen Nodes hochziehen. Genau, also solche Unterschiede sind da gewesen.

Daniel: Jetzt habt ihr ja gesagt, dass es ja schon doch Unterschiede gab zwischen jetzt dem Kubernetes, dass man sich jetzt mal auf dem Rechner installiert, versus dem, was in der Cloud läuft. Wie habt ihr das denn mit der lokalen Entwicklung gelöst? Hattet ihr dann was, was relativ nah dran kam oder hattet ihr quasi einen Entwicklungscluster in der Cloud? Wie ist das gelaufen?

Fabian: Also lokal haben wir tatsächlich, gut, wir konnten jetzt kein lokales Kubernetes laufen lassen und das müsste jetzt auch nicht genau, also wir haben zumindest kein ECS-Lokal-Dings eingesetzt. Ich weiß nicht, ob es sowas gegeben hätte. Aber jedenfalls auf der Containerebene, verpackt das Ding in den Container und lasst da laufen, das ging ja erst mal lokal. Die andere Sache oder das komplett ohne Container ausführen ging auch. Also wenn man jetzt so auf der lokalen Entwicklungsebene unterwegs war und die Infrastrukturaspekte haben nicht so dominiert, um die es vielleicht bei der Entwicklung dann nicht ging. Dann war es auch uninteressant, ob es jetzt auf Infrastruktur intern hätte laufen müssen oder in der Cloud. Das ist dann eher so ein, wie kriegt das Ding die Info, dass es jetzt lokal läuft und vielleicht gegen einen Testcontainer oder sowas laufen soll, Datenbank mäßig oder dergleichen. Aber sobald es in Richtung, okay, ich will jetzt hier gerade was an der Cloud tweaken, ich habe an meinem Infrastructure-as-Code-Zeugs was gedreht, in dem Fall haben wir CDK eingesetzt. Da haben wir dann nichts lokal testen können und nichts lokal getestet, sondern letztlich auf den untersten Stages ausprobiert, was es für einen Effekt hat beziehungsweise im Zweifel auf einer Stage, die gerade nicht so viel verwendet wurde. Also so ein bisschen hemdsärmelig, weil wir haben da in dem Kontext tatsächlich keine so, also manchmal kann man ja einfach eine Stage per Knopfdruck aufbauen. Den Aufwand haben wir uns damals nicht gemacht oder es hat sich nicht ausreichend gelohnt. Sprich, wir hatten halt eine feste Anzahl an Stages, die schon alle per Code definiert waren, aber eben größerer Act und größere Kosten auch involviert, weil es eigene AWS-Accounts und so weiter waren. So gesehen gab es nur die und dann haben wir uns eine ausgesucht, wo gerade ansonsten keine kritische Entwicklung drauf unterwegs war oder keine Tests liefen, die wir gestört hätten und haben dann da versucht, rauszukriegen, okay, passt das jetzt. Weil, ja, da ist schon ja auch durch die Komplexität und durch, wir sind jetzt, wir versuchen jetzt hier vielleicht was zu machen, was wir noch nicht kennen, ist dann die Fehlerwahrscheinlichkeit nicht so gering gewesen, dass man da in den ersten Zyklen vielleicht noch nicht ganz den Volltreffer erwischt und, ja, genau, das heißt, da war mit lokalem Testen dieser Cloud-Infrastruktur-Sachen eher weniger, da war dann eher so mit schlauen, lokalen Dingern, Golden Master-mäßig, ob jetzt die Definition, die da rauspurzelt aus unserem Infrastructure-as-Code, ob die dem entspricht, was wir erwartet hätten, aber das hat jetzt mit, das funktioniert dann auch tatsächlich nicht so viel zu tun gehabt, sondern, ja, einfach nur, wenn ich in meinem Infrastruktur-Code-Refactored habe, ob das sich dann nicht verändert oder so verändert hat, wie gedacht, genau.

Thorsten: Ja, wir hatten damals, glaube ich, man konnte die Anwendung lokal starten, die aus verschiedenen Mikroservices bestand, ich weiß jetzt nicht mehr, ob wir es mit Docker-Compose gemacht haben damals oder ob wir einen kleinen 3K 3D hatten, aber wir hatten auf jeden Fall zwei Stages, also eine Testing und eine Prod und das war wichtig, weil wir haben mit Istio ein Service Mesh reingezogen und das ist alles etwas komplizierter und bis wir das mal richtig zum Laufen hatten, das war wichtig, dass wir eine Testing-Umgebung hatten, wo wir einiges ausprobiert hätten, sonst hätten wir ein paar Tage lang kein Prod gehabt und das wäre blöd gewesen. Genau, also da, die, so Sachen wie innerhalb von Kubernetes, da die Verkabelung neu aufzuziehen, das war dann schon wichtig, dass wir da auch entsprechend mehrere Stages hatten.

Andi: Mich würde jetzt interessieren, ob ihr es vielleicht beziffern könntet, wie hoch wären für diese Projekte, in denen ihr wart oder vielleicht auch die aktuellen Projekte der Aufwand, wenn ihr jetzt den Cloud-Anbieter wechseln müsstet, sei es jetzt, der Anbieter ist insolvent, der Anbieter erhöht die Preise dermaßen oder sagt, ja, hier Europa biete ich nicht mehr an, weil politische Gründe, wie hoch wäre da der Aufwand, um das ganze System auf einen anderen Anbieter zu verschieben, zu migrieren?

Thorsten: Also damals wäre es sehr niedrig gewesen, weil wir es eben schon mal gemacht hatten. Im aktuellen Projekt, in dem ich bin, verwende ich eine Cloud-Lösung von Elasticsearch und die hat verschiedene spezifische Features, die es dann in einer Lösung von jemand anderem nicht gäbe. Und da wäre der Aufwand nicht gering. Also ich denke schon, dass man das in ein paar Monaten hinkriegen würde, aber es wäre, als wenn man das jetzt plötzlich machen würde, wäre das, da müsste man sich schon umgucken und mal überlegen, wie machen wir das jetzt schnell? Also das ist nichts, was von heute auf morgen geht.

Daniel: Also das ist dann auch etwas, was dann in die Risikobeurteilung oder Betrachtung des Projektes halt mit eingeflossen ist oder einfließen sollte?

Thorsten: Einfließen sollte, zu dem Zeitpunkt, wo das angefangen wurde, war die Diskussion in die Richtung noch nicht so heiß.

Fabian: Ich würde mich auch anschließen für das Projekt, glaube ich, wäre das ein signifikantes Ding, das rüber zu hieven. Ich glaube, ich bin jetzt nicht mehr da, aber ich glaube, die arbeiten oder haben zumindest Pläne gehabt, in Richtung Kubernetes zu wechseln von ECS weg. Das würde ich vielleicht noch ein bisschen standardisieren. Aber so insgesamt ist das, glaube ich, schon ein Klopper. Und so gesehen ist das, wenn das Risiko gesehen würde oder die Option irgendwie im Hinterkopf wäre, wir wollen vielleicht switchen, dann sollte man sich das bei jeder Architekturentscheidung, die da getroffen wird, auf jeden Fall im Hinterkopf behalten. Wir haben beim Kunden letztlich zwei Cloud-Optionen gehabt. Die beiden wurden quasi angeboten. Manche Abteilung haben eher das eine AWS und die andere eher Azure genutzt. GCP war da nicht im Gespräch. Ich weiß nicht genau, warum. Aber jedenfalls haben die quasi gesagt, dass wenn ihr eins von denen benutzt, ist das in Ordnung. Und dann war das für uns, wird da keine tiefere Risikoanalyse gemacht. Aber ja, wie Thorsten schon sagt, das war damals vielleicht auch noch ein bisschen unkritischer, als es heute wäre. Aber da weiß ich jetzt auch von keinen Bemühungen, da irgendwie wegzuwandern. Sollte man sich gut überlegen.

Andi: Also höre ich da raus, wenn man jetzt ein neues Projekt oder eine neue Migration macht, sollte man das eher in seine Risikobetrachtung aufnehmen? Oder schätzt ihr das als ein vernachlässigbares Risiko ein?

Thorsten: Also wenn ich in ein neues Projekt käme, würde ich es automatisch in meine Risikobewertung aufnehmen. Ob das der Kunde genauso sieht, weiß ich nicht. Aber dass man zumindest mal so einen Blick drauf hat, was das bedeutet, ist auf jeden Fall, denke ich, keine schlechte Idee. Also im Idealfall, wenn man das von einer Sicherheitsperspektive sieht, dann ist das Wichtige, dass man das den Verantwortlichen klar macht, was eben die Aufwände sind. Und wenn die abnicken und sagen, ja, wir können damit leben, wenn unser System halt im schlimmsten Fall down ist, dann ist es halt so. Aber, also ich denke, dass die Transparenz ist da das Wichtigste.

Fabian: Ich meine, ein Stück weit, ich finde es immer schwierig, auf sowas Abstraktes auch ein Aufwandslabel oder sowas zu kleben. Ein Stück weit ist natürlich ein Unterschied von, ich bin noch überhaupt nicht mit einer Cloud aufgestellt, System zu starten und in die Cloud zu gehen, egal in welche, versus, ich bin in irgendeiner Cloud und habe entsprechend Sachen schon so ein bisschen so modelliert oder im Idealfall gut passend modelliert, dass sie halt, ich nenne es mal Cloud nativ ticken und dann ist der Aufwand naturgemäß kleiner als in die Cloud zu migrieren, sondern es ist ein Stück weit nur die Details, die sich ändern. Das sind durchaus einige Details, je nachdem, wie eng man sich eben an Details gekoppelt hat. In unserem konkreten Projekt würde ich vermuten, so in groben Zügen wäre das schon ohne weiteres in eine beliebige Cloud migrierbar, aber da jetzt eine Aufwandsschätzung dran zu kleben, fände ich schwierig und gleichzeitig würde ich sagen, man sollte das grob machen, wenn man eben nicht auf das Ding verzichten kann, weil man ist ja natürlich naturgemäß von einem Anbieter abhängig, der könnte, da kann ja alles mögliche passieren, gerade bei den geopolitischen Rahmenbedingungen kann man sich vermutlich auf nichts mehr so richtig hundertprozentig verlassen. Da würde ich das zumindest im Hinterkopf behalten, wie Thorsten schon sagt, halt transparent machen, dass es da ein Risiko geben könnte und dass es durchaus vielleicht einen signifikanten Aufwand bedeuten würde und dann ist das okay, hätte ich gesagt.

Daniel: Das heißt, das Risiko bei einem externen Anbieter ist ja schon nicht vernachlässigbar. Jetzt hatten wir die Thematik, dass die Cloud-Lösungen trotzdem sehr attraktiv sind hinsichtlich Infrastructure-as-Code und so weiter mit der Flexibilität. Eine Alternative wäre ja auch, Plattform-Engineering zu machen, zu sagen, wir haben jetzt ein extra Team, was quasi intern On-Premise ein Kubernetes-Cluster oder ähnliches hostet. Was haltet ihr denn von solchen Ideen?

Thorsten: Ich denke, man hat da auf jeden Fall die Chance, gewisse Komplexität wegzuabstrahieren. Also was ich an Plattformen bisher gesehen habe, lief es darauf hinaus, ja, die Nutzer, die müssen nur noch irgendwie ein Template erstellen, wenn sie jetzt irgendwie ihre Anwendung in die Cloud bringen wollen und dann hat man eine schöne CI/CD-Pipeline, die dann im Prinzip den Rest erledigt. Und was dann da unter der Haube tatsächlich wo lief, das war wurscht. Also wenn man das Ideal macht, dann hat man sein Plattform-Team, also dazu braucht man natürlich eine entsprechend große Organisation auch, dass sich das überhaupt lohnt. Aber wenn man das Ideal hat, hat man sein Plattform-Team, die stellen einem die Plattform zur Verfügung, erklären den Entwicklern, okay, wenn du jetzt hier, keine Ahnung, eine Datenbank brauchst, dann musst du Folgendes reinschreiben, wenn du einen Container brauchst, dann schreibst du Folgendes rein und dann muss man als Entwickler eigentlich gar nicht mehr viel machen. Und falls es dann tatsächlich zu einem Wechsel käme, dann müsste eben das Plattform-Team die Plattform einfach austauschen unten drunter. Das ist dann natürlich bestimmt schwierig für die, aber das betrifft dann die anderen nicht.

Fabian: Ich meine, ein Stück weit zahlt das dann auch auf diese Skill-Frage vom Anfang ein, also dieses, okay, was ist denn, wenn meine Leute im Entwicklungsteam gar nicht die tiefen Ops-Skills haben, um da alle Details zu verstehen und da irgendwie wild drin rumzuwerkeln, wenn du auf einer höheren Abstraktionsstufe unterwegs bist, dann hast du das Problem natürlich nicht und das muss nicht zwingend ein Hyperscaler, also ein Service von einem Hyperscaler sein. Das kann auch zugeschnittene Lösung eben von einem Plattform-Team sein. Also ich finde, das ab einer gewissen Organisationsgröße ein absolut hervorragendes Konzept, vorausgesetzt, es wird richtig gemacht. Also das kann man natürlich auch falsch gestalten und die Teams dann doch auf eine Weise einschränken, die dann die Business-Cases behindern oder eben zu klein das Team haben, sodass sich alle darauf verlassen, dass das Plattform-Team schon die Unterstützung bieten wird, aber die sind dann völlig überfordert und können das gar nicht leisten. Also man kann auch viel falsch machen, aber wenn das gut gemacht wird, dann hast du im Idealfall auch so eine Bandbreite von dem ersten Projekt, von dem ich dir die ganze Zeit erzählt habe, da war es tatsächlich so, dass man zumindest schon per Klick innerhalb der Organisation einfach sein AWS-Account dazu bauen konnte und jetzt im aktuellen Projekt, wo ich drin bin, da ist noch deutlich mehr geliefert. Also da kriegen wir letztlich ein Kubernetes-Cluster gestellt für verschiedene Stages und Pipeline-Schnipsel in GitHub, also GitHub-Actions-Sachen und die können wir nutzen oder wir ergänzen die per Pull-Request beim Plattform-Team, so wie wir es brauchen oder wir bauen eben nebendran ein Stück weit auf, zumindest soweit das von den allgemeinen Regeln zugelassen wird. Sprich, du kannst eben diese Abstraktion hochhängen über das Plattform-Team, du kannst aber nebendran auch, wenn das denn deine Regeln bezüglich ich möchte gerne Vorgaben machen, was Security oder sonst irgendwelche Compliance angeht, wenn du da die Möglichkeiten bieten möchtest, dann kannst du eben auch Stufen unten drunter anbieten mit weniger Abstraktion und dann kannst du halt ein freies Container-Gedöns deployen, nicht nur ein spezifisch an einem Helm-Chart orientiertes oder sowas. Und wenn man das richtig gestaltet, dann denke ich, hast du alle abgeholt, dann hast du sowohl das kleine, keine Ahnung, du hast ein Einzelkämpfer-Team, was eine Standardaufgabe lösen will und deswegen nicht tief einen eigenen, Thorsten meinte, Kubernetes-Cluster hochfährt oder sowas, was ja völlig überdimensioniert wäre, sondern das kann dann eben das klassische Ding darauf bezogen nutzen oder ganz am anderen Spektrum, du hast halt ein vielköpfiges Team, wo Ops-Experten mit drin sind und die dann komplexere Nicht-Standard-Anforderungen vielleicht auf zum Teil der gleichen Infrastruktur, aber eben viel individualisierter deployt nutzen können und dazwischen dann alles, was halt interessant ist.

Daniel: Ihr hattet beide gesagt, die Firma muss groß genug sein, damit es sich lohnt. Jetzt einfach mal Schnellschuss. Ab wie viele Personen würdet ihr sagen, lohnt es sich?

Thorsten: Gut, ich meine, es hängt natürlich davon ab, wie viel IT du hast. Du kannst eine riesige Organisation haben und wenn deine Hauptaufgabe ist, Steine zu zerkleinern und du gar keine Software betreibst, dann ist das eine kleine Firma in dem Sinne.

Daniel: Na gut, wie viel IT?

Thorsten: Also, wenn du 100 Entwickler hast, sicher ja, aus meiner Sicht. Wenn du 10 Entwickler hast oder 10 IT-Leute, dann ist halt die Frage oder da lohnt es sich wahrscheinlich nicht, davon 5 abzustellen, die dann die Plattform bauen. Vielleicht lohnt es sich, dass dann 2 sich mal hinsetzen und gucken, ob man das irgendwie gerade ziehen kann, aber das ist dann nicht so eine große Plattform. Also ich denke, irgendwo dazwischen wird der Punkt liegen.

Fabian: Ja, also ich weiß nicht genau, ob es da so eine strikte Definition von einem Plattform-Team gibt, aber diese Aspekte, wie Thorsten schon sagt, wachsen, glaube ich, einfach so graduell mit. Nehmen wir mal an, du hast irgendwie 2 Teams und die wollen beide ähnliche Dinge tun, dann ist es ja irgendwie eine natürliche Geschichte, dass es da Synergien gibt und irgendwann, ja, irgendwann lohnt es sich dann, aber wann? Du wolltest einen Schnellschuss, ich kann es dir nicht wirklich liefern, eine Wabere rum, aber ich hätte gesagt, das kommt relativ schnell, aber das wird dann wahrscheinlich kein 5-Personen-Team sofort sein, sondern es sind dann vielleicht halt 2 Leute oder sowas und irgendwann werden es dann mehr oder vielleicht sind es auch einfach, ist es ein Hut, den Leute aus den Teams auch aufhaben, um eben so eine, diesen Aspekt bereitzustellen, weil die sich dafür stärker interessieren und dann eine stärkere, tiefere Expertise haben in der Ecke, aber solche Self-Service-Sachen oder anders, Plattform Engineering hat ja viele Facetten und wenn wir dann bei so einem Developer Portal oder wie das heißt, ich bin mir gerade bei dem Begriff nicht ganz sicher, aber jedenfalls irgendwas, wo du so Self-Service-mäßig rumklickerst oder gar eine API bekommst, wenn du da nicht ein fertiges Ding einfach da hinstellen kannst, dann wird sich das wahrscheinlich erst lohnen, wenn du viele, viele Teams hast und ansonsten ist es vielleicht eher was Manuelleres, aber du hast eben vielleicht trotzdem einen Kreis an Leuten, die sich da tiefer mit auskennen und unterstützen. Also ich würde sagen, das skaliert so langsam im Umfang hoch und deswegen kann er schon früh Nutzen bieten, aber ja, bei unseren, bei meiner Beispielorganisation waren das halt, keine Ahnung, viele, viele, hundert oder tausend, ich weiß gar nicht, das waren große Organisationen entsprechend, ist das da gelohnt. Jetzt bei dem aktuellen sind das auch einige Teams, das sind ja mehr so, ich weiß gar nicht, wie viele Entwickler das denn insgesamt sind, ich sage mal 50 oder 80, irgendwie so in der Größenordnung zumindest ist und da hat man sich dann eben auch ein Plattformteam organisiert, was glaube ich für den, für das konkrete Ding auch noch größer aufgestellt sein könnte, die haben dann leider noch Altaktivitäten, also da würde ich sagen, hat man vielleicht zu wenig skaliert, das Team skaliert, meine ich, für die konkrete Aufgabe.

Thorsten: Ja, also ich, wie gesagt, in dem Projekt damals mit einer Person braucht man kein Plattformteam, aber, oder auch mit zweien, das ist dann so, da sind dann halt alle irgendwie involviert, aber ja, ich bin jetzt auch gerade in einer Organisation, die etwas größer ist und da braucht man es dann halt schon, das ist, also es ist praktisch, ich meine, ein Muss ist es auch nicht, aber es wird einfach, ich glaube, also dieses manuelle Betreiben und dieses, über diese Prozesse zu gehen, wird dann irgendwann sehr aufwendig, deswegen lohnt sich das dann schon.

Fabian: Ist ja auch knifflig, dann irgendwelche Compliance-Sachen oder Security-Themen einheitlich über deine Organisation abzubilden, wenn du nicht da so ein bisschen Infrastruktur und Vorgaben und sowas auf der Ebene bereitstellst und so gesehen ist es glaube ich schon allein aus der Ecke heraus ein wichtiges Ding.

Thorsten: Es passiert dann halt teilweise etwas zufällig, das stimmt und das ist nicht so ideal in dem Bereich.

Fabian: Aber ich stimme dir zu, verpflichtend würde ich das, oder es geht auch ohne, du verlierst halt, du verlierst natürlich an Effizienz, weil jedes Team das dann selber betreiben muss in irgendeiner Form.

Daniel: Wir haben jetzt von euch beiden relativ viel über die Entwicklung für die Cloud und die Migration in die Cloud gehört. Dafür vielen Dank. Hättet ihr jetzt beide noch irgendwelche Ratschläge für jemanden, der jetzt hier zuhört und der im Projekt vor einer Migration in die Cloud steht oder generell in einem Projekt ist, das sich mit der Cloud beschäftigt oder die Anwendung in der Cloud hatte? Hättest du da irgendwas mitzugeben, Thorsten?

Thorsten: Also ich persönlich fand es immer eine gute Idee, sich auch einfach mit den Technologien ein bisschen auseinanderzusetzen, also zu sagen, okay, ich möchte jetzt zumindest einigermaßen wissen, was Kubernetes ist und einigermaßen wissen, was für Möglichkeiten es da gibt und nicht so anwendungsspezifisch unterwegs zu sein. Ich denke, je nachdem, wo man unterwegs ist, lohnt es sich vielleicht trotzdem anwendungsspezifisch auch zu handeln. Also wenn man jetzt einfach in einer kleinen Bude ist und mit einem Lambda und einem S3-Container seine Anwendung in die Cloud bringt und dadurch irgendwie Gewinn erwirtschaften kann, klar, warum nicht? Aber wenn man da länger unterwegs ist, lohnt es sich auf jeden Fall, denke ich, sich die Basistechnologien anzugucken und dadurch ist man auch unabhängiger von dem Anbieter.

Fabian: Ich ergänze einfach mal von meiner Perspektive. Mein Erfahrungshorizont ist ja jetzt primär gewesen mit Migrationen von ich bin nicht in der Cloud, habe aber irgendwas und will jetzt in die Cloud. Also dieses ich bin frisch und kann mir das ganz frei überlegen, da kann ich jetzt nicht so viel dazu beitragen, außer dass ich vielleicht ergänzen würde, ein Lambda und ein S3-Bucket mit statischen Inhalten ist vielleicht sogar vergleichsweise kosteneffizient im Gegensatz zu irgendwas anderem, aber wenn ich jetzt mal auf die Migrationsgeschichten mich beziehe, dann war für mich der große Vorteil gefühlt weniger, ich bin jetzt bei einem Hyperscaler und habe ganz viele Services und mehr die Möglichkeit, mich aus dem Konzept der internen Infrastruktur und IT-Prozesse zu lösen, raus in ich bin irgendwie flexibler und die Technologie, die unabhängig von allem Möglichen für mich irgendwie das Entscheidende bezüglich Entwicklungsvereinfachung auch ist, ist dieser Container-Ansatz. Also es hat eigentlich mit Cloud gefühlt nicht so viel zu tun, aber alles in den Container zu packen und damit standardisiert zu betrachten, da habe ich ursprünglich nicht genau verstanden, was der Sinn dahinter ist, aber in der Praxis das alles schön in den Pipelines durchlaufen zu lassen, genau zu wissen, okay, wenn ich mir das ziehe und das lokal ausführe, dann ist es eigentlich genau das Gleiche und eben dieses Standardisierte läuft überall und hängt wirklich nur noch von den Parametern außen ab, das hat doch viel an Transparenz, Einfachheit und so geliefert. Das ist natürlich auch nur ein Aspekt in der Cloud und diese ganzen Software-as-a-Service-sickeren Sachen gehen davon zum Teil ja auch weg, also du hast dann keinen Container mehr, auch bei einem Function-Ding hast du keinen Container. Das sind für mich Sachen oben, drauf, aber Container zu verwenden, das Hurra und eben aus den internen Sachen auszubrechen ist auch nur dann wirklich spannend, wenn die internen Sachen so ein Korsett sind. Also wenn du intern Plattform Engineering quasi hast, egal wie sie es nennen, dann ist es mir eigentlich egal, ob da hinten dran dann eine Cloud bei AWS hängt oder ob das die interne Infrastruktur ist, sinnvolle Infrastruktur bereitstellen, dann passt das ja und dann macht das für mich keinen Unterschied, ob Cloud oder interne Cloud sozusagen. Aber das zu haben, diesen Service, diese schöne Service-Landschaft, egal ob intern oder extern, das ist schon ein großer Vorteil bei Sachen, die so ein bisschen über die Standards hinausgehen. Also wenn deine Anforderungen eben nicht das Standard gedöhnt sind, dann profitierst du davon.

Daniel: Dann noch einmal vielen Dank an euch beide, Thorsten und Fabian, dafür, dass ihr euch heute die Zeit genommen habt, um über eure Erfahrungen mit dem Thema Cloud und Cloud-Migration zu sprechen und auch danke an dich, Andi, dass du mir heute zur Seite standest als Co-Host und falls ihr da draußen Fragen, Feedback oder Themenwünsche habt, schreibt sie gerne an uns an podcast-feedback at andrena.de und damit tschüss.

Alle: Ja. Ciao. Tschüss. Ciao.

[Musik spielt]