allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
Willkommen zu allesnurgecloud.com – Ausgabe #114!
Sommerpause ist vorbei, und mit allesnurgecloud.com geht es erst mal weiter, wie gewohnt – auch dank eines neuen Sponsors – Vielen Dank!
Mal schauen, ob ich demnächst die Zeit finde, den Tech-Stack umzubauen, es wäre mal dringend nötig – aber irgendwie, verschiebt man solche Änderungen ja doch immer wieder, auch wenn man es selber besser weiß .
Im Podcast hatte in dieser Woche in Folge 37 die Caro von Cyttraction.com zu Gast. Caro baut mit Cyttraction an einer digitalen Lernplattform für Cybersecurity. Den Podcast findest du unter „Happy Bootstrapping“ im Podcast Player deiner Wahl.
Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen – nach anfänglichen Schwierigkeiten scheine ich das nun verstanden zu haben
Dir gefällt meine Arbeit hier?Gerne kannst Du meine Arbeit nun auf Patreon supporten, mir ein Bier ausgeben oder mal auf meiner Amazon-Wunschliste vorbeischauen – Danke!
Der Admin – ein hoffentlich aussterbender Beruf?
In einem neuen Blog-Artikel fasst Kris ein paar Mastodon „Toots“ zusammen, die als Antwort auf einen Artikel bei Heise über Admin-Gehälter entstanden sind.
Er beschreibt, dass der „klassische“ Admin als Beruf aussterben und die Tätigkeit in Richtung „Infrastrukturentwicklung“ gehen wird. Das ist jetzt bis dahin nichts Neues.
Interessant finde ich sein zweites und drittes Argument:
„Der Wert und die Schwierigkeit von Operations“ sei etwas, was von „vielen Feature-Entwicklern und Software-Entwicklungsorganisationen“ unterschätzt werde – da kann ich absolut zustimmen. Viele verstehen noch immer nicht, dass wir keine Bücher drucken und dass es viel Arbeit macht, dass Anwendungen einfach nur ordentlich betrieben werden und niemand im Maschinenraum sich langweilt.
Noch besser das 3. Argument: Struktur durch Cloud (bzw. durch AWS):
Der “Wert” von Amazon besteht darin, dem Betrieb genau messbare Kosten und harte betriebliche Einschränkungen zu geben, um die sich eine Firma nun auf einmal gezwungenermaßen herum organisieren muss, während sie vorher unkontrolliert Druck auf interne Betriebsteams ausgeübt hat
Grenzen und Kosten, die vorher nicht fassbar waren, werden nun greifbar. Firmen sind gezwungen, sich damit ernsthaft zu befassen. Insofern ist Cloud eine gute Sache, weil sie Läden ins Meta zwingt.
Das kann man besser nicht beschreiben – der große Vorteil von Cloud ist, dass wir uns nicht mehr verbiegen müssen und „alles möglich machen“ müssen. Dinge, die bei AWS nicht technisch nicht gehen, die gehen aus gutem Grund nicht – da kann auch niemand bei AWS anrufen und die Technik dort überreden, es doch zu machen. Klassisch On-premise ist das aber passiert und es entstand ein Zoo von Tools, Software und Hardware, dessen Betriebsaufwände kaum sauber zu berechnen sind.
Häufig sind diese Betriebsteams dann noch „understaffed“ und hängen mit ihren Themen hinterher – bei einer Cloud Migration werden die Kosten dann transparent, und die sind dann aus diesen Gründen meist viel höher als gedacht.
Zum Thema Kubernetes geht Kris auf 2 Argumente ausführlich ein:
In „Kubernetes ist zu fett?“ erklärt er, warum man Kubernetes benötigt, um moderne Hardware effizient auszulasten. Auf 2 Höheneinheiten bekommt man heute eine Menge Leistung, diese Leistung muss man vernünftig auslasten, da Platz, Strom und Netzwerk begrenzt ist. Man hat daher zwangsweise keine saubere Trennung mehr von Server nach Anwendung, sondern mischt diese. Dafür benötigt man eine Orchestrierung – da landet man bei entsprechender Größe schnell bei Kubernetes und Openstack.
Weiter geht es dann in „Kubernetes ist nicht komplex, das Problem ist es“. Hier erklärt Kris ausführlich, warum man eine Standardisierung der Orchestrierung benötigt und was die Vorteile davon sind. Angefangen von der „Installation einer Anwendung“, über deren „rückstandsfreie Entfernung“ bis hin zu Änderungen im Betriebsablauf (Metriken & Obversability).
Er schließt den Artikel mit einem Absatz zum Thema „Kosten“, und erklärt, warum sich unter anderem Personalkosten „nur verschieben“ und mit einer Cloud Migration nicht verschwinden. Man gewinne durch Cloud auch viele Dinge, beispielsweise:
Aber eventuell bekommst Du durch die harte administrative Grenze und den Zwang zur Kostenkontrolle als Organisation eine Motivation, Deine betrieblichen Abläufe besser zu dokumentieren, strukturieren und in Beziehung zu den betriebsWIRTSCHAFTLICHEN Abläufen zu setzen.
Du musst bzw. kannst nicht mehr zu allem „Ja und Amen“ sagen – in Summe ist es eben ein Paradigmenwechsel auf vielen Ebenen.
Empfehlenswerter Artikel – schick mir gerne Feedback dazu.
GitLab, die „All-Remote“ Company im Harvard Business Review
In der gedruckten Version des Harvard Business Review erschien bereits im April 2023 ein Artikel von GitLab CEO Sid Sijbrandij zum Thema „All-Remote“ bei GitLab.
Der Artikel beschreibt die Erfahrungen von GitLab, das von Anfang an eine vollständig dezentrale Arbeitsweise gewählt hat. Das Unternehmen hat mittlerweile über 2.000 Teammitglieder in etwa 60 Ländern und Regionen weltweit und verwendet hauptsächlich virtuelle Zusammenarbeitstools wie Slack, Zoom und Google Docs.
Ein Schlüsselaspekt der erfolgreichen dezentralen Arbeitsweise ist die Betonung der Ergebnisse gegenüber der Anwesenheitszeit im Büro. GitLab misst die Leistung anhand von Output und nicht von Input, wobei jeder Bereich bei GitLab eigene Metriken definieren kann. Bei GitLab setzt man auch stark auf die kulturelle Ausrichtung und Werte, wobei Transparenz und Iteration als besonders wichtige Werte genannt werden.
GitLab betont Transparenz, sowohl intern als auch extern, und veröffentlicht viele Informationen in einem öffentlichen Handbuch. Dieses Handbuch dient als Wissensquelle und schafft Vertrauen bei Kunden, Investoren und Mitarbeitern. Für mich zeigt es einmal mehr, dass man mit Transparenz Vertrauen gewinnen kann, auch im Umgang mit Herausforderungen und Fehlern. Zudem werden die GitLab Mitarbeiter ermutigt, selbstständig zu arbeiten und mit ihren Teams zu kommunizieren.
Abschließend betont Sid Sijbrandij im Artikel, dass GitLab glaubt, dass tech-basierte dezentrale Teams die Zukunft der Wissensarbeit sind. Bei Gitlab habe man durch die konsequente Anwendung ihrer Prinzipien Erfolg erzielt und hoffen, dass andere Organisationen ihrem Beispiel folgen und lernen, wie man eine dezentrale Arbeitsweise erfolgreich umsetzt.
Persönlich war ich jetzt überrascht, dass da Wort „async“ im Artikel gar nicht auftaucht – Ich dachte immer, dass dies ebenfalls ein wichtiger Aspekt der Arbeit bei GitLab sei. Vielleicht ist es aber auch nur dem Editing zum Opfer gefallen.
Und zudem denke ich, dass es viel einfacher ist (aber nicht einfach), zum Beginn gleich Remote/async zu starten, als ein Unternehmen auf diese Arbeitsweise umzubauen
GitLab’s CEO on Building One of the World’s Largest All-Remote Companies
Sponsored
Have your head in the clouds?
Das kann mal passieren! Cloud Computing stellt die Cybersicherheit vor neue Herausforderungen; On-Premise und Cloud wachsen zunehmend zusammen und die Funktionalitäten erweitern sich rasant. Dadurch stellt sich Dir die Frage: Wie sicher ist meine Cloudumgebung eigentlich?
Beim Finden der Antwort, unterstützen wir Dich gerne: Das Cloud Security Assessment von SCHUTZWERK schafft Risikotransparenz und hilft Dir Deine Cloud bestmöglich zu schützen.
👩💼 Professionelle Betrachtung: Mit dem Cloud Security Assessment bieten wir Dir eine umfassende Prüfung, die auch die Anbindung an das Unternehmensnetzwerk und die administrativen Prozesse berücksichtigt.
☁️ Individuelle Bewertung: Wir beginnen das Assessment mit einem Workshop zur Analyse möglicher Bedrohungsszenarien, damit wir unsere Arbeit genau auf Deine Situation abstimmen können.
🔎 Sorgfältige Prüfverfahren: Wir führen sowohl automatisierte als auch manuelle Prüfungen durch, um Deine Cloudumgebung auf Herz und Nieren zu untersuchen.
📄 Umfangreicher Report: Wir liefern Dir einen detaillierten Bericht und konkrete Empfehlungen, um Deine Cloud optimal abzusichern.
OpenTF Terraform Fork nach Lizenz Änderung
In der vorherigen Ausgabe hatte ich ausführlich über den Lizenzwechsel zur BSL bei HashiCorp, insbesondere bei Terraform, berichtet.
Als Antwort auf die Aktivitäten von Hashicorp hat sich nun Ende August die OpenTF Foundation formiert und einen Fork von Terraform angekündigt. Im OpenTF Manifesto erklären sich die Team Member ausführlich zum Fork. Der Plan sei erst einmal, HashiCorp zu einem Kurswechsel zu bewegen. Funktioniere dies nicht, will man Terraform auf Basis der letzten „frei“ verfügbaren Version forken und weiterbetreiben.
Der Plan scheint erstmal ambitioniert, allerdings argumentiert das Forking-Team damit, dass die große Mehrheit der Terraform Provider (für AWS, Azure, Google, und co.) nicht von HashiCorp geschrieben wurden, und dass dies die eigentliche Basis des Erfolgs von Terraform sei. Im Ökosystem tummeln sich nun über 14.000 Module, die zum Großteil nicht von HashiCorp geschrieben wurde. Ganz zu schweigen von den unzähligen Videos, Tutorials und Online-Kursen, die im Umfeld Terraform von nicht HashiCorp Mitarbeitern entstanden sind.
Auch kritisiert das Team, dass viele Community PRs abgelehnt wurden, die das System selbst verbessert hätten, aber mit den Monetarisierungsplänen von HashiCorp in Konkurrenz stehen (Beispielsweise State Encrypten, PR auf GitHub).
Man trackt nun erst einmal Änderungen, wie diese „Terms of Service“ Änderung im neuen OpenFT GitHub Repository.
Zudem haben über 100 Firmen, mehr als 10 Projekte und 400 Menschen ihre Unstützung zugesichert. Am 25. August (Zeitpunkt des Manifestos) hatte das Manifesto noch „nur 4000 GitHub Stars“, heute, am 1.9.2023 sind es schon über 31.000. Das Interesse scheint enorm zu sein, damit Terraform selbst ein offenes System bleib
Hetzner überrascht mit neuem Cloud Server Pricing
Während viele Cloud-Anbieter an diversen Stellen an der Preisschraube drehen, überrascht Hetzner mit einem echten Knaller-Angebot.
Vor einiger Zeit hatte man bereits Server mit Intel „dedicated“ CPU abgekündigt, nun kündigt man die aktuelle AMD Generation ebenfalls ab. Allerdings führt man dafür eine neue Generation ein, bei der man etwas mehr Leistung (neue Generation) bekommt, aber ungefähr 30 % weniger bezahlt.
Man erhält so beispielsweise einen CCX13 mit 2vCPUs, 8 GB RAM, 80 GB NVMe SSD und 20 TB traffic für 14,27 € /Monat.
CCX – das sind immer Maschinen mit „dedicated“ CPU – also einer CPU, die exklusiv für einen Kunden bereitgestellt wird und nicht vom Cloud-Provider über-provisioniert wird.
Bei den größeren Maschinen ist das Einsparpotential dann enorm:
- ein CCX42 (16 vCPUs, 64 GB RAM, 360 GB Disk und 20 TB Traffic) kostet aktuell 182,55 € / Monat
- der neue CCX43 (16 vCPUs, 64 GB RAM, 360 GB Disk mit 40 TB Traffic) kostet nur noch 114,82 €/ Monat
Beim aktuellen Topmodell ist der Unterschied noch etwas größer:
- ein CCX62 (48 vCPUs, 192 GB RAM, 960 GB Disk und 20 TB Traffic) kostet aktuell 522,89 €/ Monat
- der neue CCX63 (48 vCPUs, 192 GB RAM, 960 GB Disk und 60 TB Traffic) kostet nur noch 342,71 €/ Monat
Die Preise sind schon eine Ansage an den Markt und zudem außergewöhnlich, da es in die andere Richtung geht.
Alleine der Inklusiv-Traffic ist enorm – Hetzner hat bisher 1,19€ / TB Traffic abgerechnet – auch das kann man in der Kalkulation noch berücksichtigen.
Neue Dedicated vCPU Cloud Server zum Sensationspreis
Einfluss von Third-Party Incidents auf deine Anwendung
Einen Nachteil, den man von Cloud und SaaS wahrnimmt, ist die Abhängigkeit von Third-Party Services. Egal, ob Authentifizierungsdienst, Zahlungsanbieter API oder ein Service für den Versand von transaktionalen E-Mails – eine moderne Anwendung hängt häufig von so vielen externen Services ab, dass man nur schwer den Überblick behalten kann.
Im Blog von Rootly erklärt der verlinkte Artikel, warum es wichtig sei, hier eine saubere Inventarisierung und Überwachung der externen Services durchzuführen.
Schließlich kümmert es deinen B2B/B2C Kunden nicht, wessen Schuld es nun ist – kann der Kunde nicht kaufen, kann er halt nicht kaufen – was dahintersteckt, ist erst einmal egal.
Grundsätzlich sei es daher empfehlenswert, einen sauberen Service-Katalog mit verwendeten 3rd Party Services zu pflegen. Der Katalog sollte beantworten:
- Ob die Abhängigkeit deines Dienstes zum 3rd Party Service „kritisch“ ist
- Wie die Kontakt & Servicewege zum 3rd Party Dienstleister sind
- Welche Teile deiner Anwendung mit dem Service kommunizieren
- Historie der Incidents katalogisieren
- etc.
Persönlich sehe ich aber als ersten Schritt – die Überwachung im eigenen Monitoring Tool – das kann ja auch der erste Schritt eines „Service-Kataloges“ sein.
Zudem kannst du nicht nur sehen, ob der Service Down ist, sondern man sieht auch die Response-Times.
Die alleine helfen ja schon, die Service-Qualität zu messen und Rückschlüsse auf das Verhalten der eigenen Anwendung zu ziehen.
But It’s Not Our Fault! When Third-party Incidents Affect Your Service
CPU Tutorial bei cpu.land
Mit „Putting the YOU in CPU“ hat Lexi Mattick im Juli ein tolles CPU Tutorial gestartet.
In 7 Kapiteln erklärt sie dabei, wie eine CPU eigentlich funktioniert und zugewiesene Befehle ausführt:
- The „Basics“ – wie funktioniert eine CPU, wie der Kernel, Was ist ein Syscall
- Slice Dat Time – Timings und Interrupts
- How to Run a Program – der Name ist Programm
- Becoming an Elf-Lord – ELF Header, Dynamic Linking & Co.
- The Translator in Your Computer – Paging, Memory Adressierung und Swapping
- Let’s Talk About Forks and Cows – Forking und Linux
- Epilogue
Cool gemacht!
Wenn du willst, kannst du die Source Inhalte auf GitHub anschauen und verbessern.
Interessant auch ihr Take zu GPT-3.5 und GPT-4:
I talked to GPT-3.5 and GPT-4 a decent amount while writing this article. While they lied to me a lot and most of the information was useless, they were sometimes very helpful for working through problems.
LLM assistance can be net positive if you’re aware of their limitations and are extremely skeptical of everything they say. That said, they’re terrible at writing. Don’t let them write for you.
Ach der Einstieg ist übrigens auf der Domain cpu.land – auch cool, die Domain.
Skalierbarer Twitter Clon auf Mastodon Basis
RedPlanet Labs beschreibt im verlinkten Blog Artikel, wie sie eine „Twitter-scale“ Mastodon Instanz gebaut haben, die nur aus 10.000 Lines of Code besteht – 100 mal weniger Code, als über die Twitter Code Basis bekannt ist.
In der Instanz posteten 100 Millionen Bots 3.500 Posts pro Sekunde. Insgesamt wurden zur Laufzeit (15. bis 24. August 2023) über 2,66 Milliarden Posts erstellen und über 1 Billion Timeline Ansichten ausgeführt. Jeder Account hatte im Schnitt 403 Follower, der größte Account 22M Follower. Beeindruckende Zahlen.
Laut dem GitHub Repository lief die Infrastanz bei AWS und wurde dann aufgrund der Kosten wieder deaktiviert.
Das Ganze hatte den Zweck, „Rama“ vorzustellen – eine neue Plattform, die RedPlanetLabs in den letzten 10 Jahren für die Skalierung von Anwendungen entwickelt hat.
How we reduced the cost of building Twitter at Twitter-scale by 100x
Schmunzelecke
JavaScript developers deciding on the best way to render static HTML – @flaviocopes auf Twitter(X)
💡 Link Tipps aus der Open Source Welt
Open Source IaC Orchestration mit Digger
Ey, Digger – sagen das deine Kids mittlerweile auch?
Da kannst du nun mit, Digger bietet ein Open Source Infrastructure as Code Orchestration Tool an, mit dessen Hilfe du deinen IaC Code einfacher in deiner CI Pipeline ausführen kannst. Digger führt TF Code sicher in deiner Pipeline aus – ohne Secrets mit der Terraform Cloud oder anderen Systemen zu sharen.
Digger funktioniert dabei mit sämtlichen CI Systemen (GitLab, GitHub, Azure DevOps), mit „private Runner“, mit dem „Open Policy Agent“ und Tools wie „Terragrunt“.
In Zukunft soll Digger zudem „Drift detection“ und „Cost Estimation“ supporten.
Alle Features findest du hier in der Übersicht. Digger finanziert sich über eine Pro und Enterprise Version, wie man es bereits von anderen Tools kennt.
https://github.com/diggerhq/digger
Chrome Extension Little Rat
Diese Chrome Extension kennen viele vermutlich schon – mit Little Rat kannst du dir anschauen, welche andere Chrome Extensions Daten zu anderen Services übertragen und diese entsprechend blocken. Also eine Art Firewall für Chrome Extensions.
Die Lite Version der Chrome Extension findest du im Chrome Web Store. Die Full Version findest du im GitHub Repo des Projekts.
https://github.com/dnakov/little-rat
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: