allesnurgecloud #107 – Cloud-Exit bei Basecamp, Red Hat verärgert Community, Oracle EU Cloud, ARM Performance und mehr.

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:

507 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address
Diese E-Mail ist bereits registriert.
The security code entered was incorrect
Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.

Wichtig und in eigener Sache:
Ich bin ernsthaft am überlegen, den Newsletter auf „englisch“ umzustellen.
Bitte fülle dazu diese sehr kurze Umfrage aus oder schreib mir per E-Mail, ob du dich dann abmelden würdest oder dies aus anderen Gründen nicht gut fändest.
Zum Hintergrund: Ich schreibe den Newsletter nun seit 2,5 Jahren, und mir macht das viel Spaß.
Ehrlicherweise habe ich gedacht, dass ich den Newsletter viel schneller auf über 1000 Subscriber bekomme – das erhoffe ich mir vom Wechsel auf Englisch – da die „Nische“ dann nicht mehr so klein ist – allerdings gibt es auch viel mehr „Wettbewerb“.
Bitte schreib mir gerne, was du dazu denkst oder füll kurz die Umfrage aus – vielen Dank!

Basecamp/37signals hat die „Cloud“ verlassen

Den geplanten Cloud-Exit bei Basecamp habe ich ja schon ausführlich in diversen Ausgaben begleitet. Nun hat das Team es tatsächlich geschafft – und dies noch vor dem ursprünglichen Zeitplan!
37Signals hat alle Applikationen (Basecamp Classic, Highrise, Writeboard, Campfire, Backpack, Basecamp selbst) inkl. dem neuen E-Mail Dienst HEY aus der Cloud migriert. Die Instanzen wurden nun über mehrere Wochen verschoben, von den Usern hat keiner etwas gemerkt, es gab laut eigenen Angaben keine Ausfälle und Hickups.
Auf der Statuspage sieht man ein paar kleine Themen – teilweise aber nur „E-Mail Delivery delayed“ und solche Themen.
37Signals betreibt alle Applikationen nun über ihren eigens entwickelten Manage Remote Server Kontainer Dienst MRSK auf eigener Hardware in einem gemieteten Co-Location Datacenter von Deft. Insgesamt hat man HW im Wert von einer halben Million Dollar gekauft und dafür 4000 vCPUs, 7.680 GB RAM und 384TB NVMe Storage erhalten.

Interessant im jetzigen Artikel finde ich, dass das „Operations Team“ gleich geblieben ist:

And crucially, we’ve been able to do this without changing the size of the operations team at all. Running our applications in the cloud just never provided the promised productivity gains to do with any smaller of a team anyway.

This is possible because the way we operate our own hardware actually isn’t too dissimilar from how people use rental clouds like AWS.

DHH meint dazu, dass man etwas besser planen müsse, da man Server erst bestellen, einbauen und verkabeln muss – sie dann aber mit Software-Automatisierung genauso schnell produktiv hat, als wären sie in AWS. Der Unterschied ist, dass man seine Workload kennen muss.
Für nur leicht wachsende Unternehmen ist dies ja einfach zu berechnen und zu organisieren.
Die wenigstens Firmen benötigen wirklich die „Cloud Elastizität“ , für die man das Ganze Jahr ein Premium bezahle.
Bei 37signals habe man nun massiv überprovisioniert und habe damit genug Vorlauf, um neue HW zu bestellen und diese vorzubereiten. Da die HW nun 5 Jahre lang läuft, sei dies in Summe trotzdem sehr viel billiger als ein „Kosten optimierter“ Cloud Account.

Keine Info gibt es bisher dazu, wie Basecamp nun Datenbanken betreibt. Ob diese in MRSK laufen, auf Hardware direkt und wie diese Hochverfügbar sind – dazu habe ich keine Information gefunden. Im MRSK GitHub Forum gibt es eine Diskussion zum Thema, aber keine Information zu Basecamp. Jeremy Dear von 37Signals spricht nur Empfehlungen aus, erst mal entspannt mit einer Desaster Recovery Strategie zu starten. Habe deshalb mal @DDH auf Twitter gefragt und er hat sogar geantwortet 🙂
Datenbanken laufen nicht in MRSK, sondern ganz normal auf VMs.

Wie siehst du das Ganze?

We have left the cloud

Red Hat verärgert Community

Nach der Einstellung von CentOS (bzw. dem Umstieg auf Streams) hat Red hat 2021 schon einiges an Kritik einstecken müssen.
Nun schottet man sich weiter ab und will den Zugriff auf die öffentlich zugänglichen Sourcen einschränken.
Distributionen wie Alma Linux, Rocky Linux oder auch Oracle Linux, die auf den Quellen aufsetzen, sind hiervon direkt betroffen.

Im Blogbeitrag bei AlmaLinux kann man die Konsequenzen nachlesen, denn einem Alma Entwickler ist aufgefallen, dass Updates von RHEL 8 nicht mehr veröffentlicht werden, und daraufhin einen Bug aufgemacht. Der Red hat Support hat geantwortet, dass der Zugriff auf Sourcen in Zukunft Partnern und Kunden vorbehalten sei.
Kunde oder Partner zu sein bedeutet in dem Fall, dem Lizenzabkommen zuzustimmen. Laut der Lizenz darf man die Sourcen aber nicht selbst neu veröffentlichen.
Damit ist die Türe dann quasi geschlossen.

Bei „Rocky Linux“ war man wohl auf eine solche Änderung wohlvorbereitet und verspricht, dass die Änderungen keine Einschränkungen für die User der Distributionen bedeuten.

Die Community reagiert sehr verägert. Beispielsweise titelt Jeff „Geerlingguy“ Geerling in seinem Blog: „Dear Red hat: Are you dumb?“ und er überlegt nun als Antwort, den Support seiner Ansible Module für RedHat komplett einzustellen. Er habe sich einmal veräppeln lassen (CentOS Änderung), ein zweites mal passiere das nicht.
Auf Hacker News hat der Artikel dazu stand heute (Freitagnachmittag) über 380 Kommentare. Dort kommentieren dann Red Hat Mitarbeiter, ehemalige Mitarbeiter, Kunden und Co.

Überlegt man sich, dass das frühere Red Hat Motto mal „We grow when we share“ war, so passt dies nun nicht mehr zusammen.
Vielleicht liegt es am neuen Eigentümer IBM, der mehr Wachstum und Ergebnis sehen möchte?

Furthering the evolution of CentOS Stream

Sponsored

Incident Response – die Komplettlösung für Betriebsteams

Managen Sie Rufbereitschaften, reagieren Sie auf Vorfälle und kommunizieren Sie diese über Statusseiten in einer Software.

Jedes Feature in ilert wurde dazu entwickelt, um Ihnen zu helfen, schneller auf Vorfälle zu reagieren und die Uptime zu erhöhen.

Jetzt mit ilert kostenlos für bis zu 5 Nutzer starten

Zerforschung: Sicherheitslücken beim Freundschaftspass

Auf die ehrenamtlichen Sicherheitsforscher von Zerforschung habe ich schon öfter mal hingewiesen. Nun haben die Forscherinnen sich den „deutsch-franzoesischen Freundschaftspass“ angeschaut, einem Angebot mit 60.000 kostenfreien Bahntickets für junge Erwachsene.

Ironischerweise hat man die Findings nun mit Titeln von Bahnstationen versehen:

  1. DDoSingen – da die Tickets nach „First Come, First Serve“ verteilt wurden – gab es ein Ansturm auf das System. Fehlerseiten & Überlastungen waren die Folge. Man hätte auch einfach ein Warteraum System buchen können, aber nein. Bei solchen Events verschlimmert der „F5-Effekt“ den Ansturm dann noch weiter und die Systeme kommen aus der Überlastsituation nicht raus
  2. Passwort-Reset-Hausen: Die „Passwort Vergessen“ Funktion führte zu einer verwaisten Vercel Installation. Diese hat man sich dann zur Sicherheit gesichert, bevor es jemand anderes tut.
  3. Freitickets-für-alle-Allee: Es sollten nur 30.000 Codes vergeben werden, Interessent Nummer 30.001 sollte keine Kaufmöglichkeit mehr haben. Blöd, wenn man dies es System recht einfach umgehen kann.
  4. Wo die wilden APIs wohnen: Obwohl die 30.000 Codes vergeben waren, konnte man direkt an Der Bestell API noch weiterhin bestellen.
  5. “Wir sind leider außerplanmäßig zum Halten gekommen…”: Die Backend-API basiert auf der Open Source Firebase Alternative Supabase – wenn man diese nicht richtig absichert, ist halt ein wenig ungeschickt.
  6. “Datenleck mit 245.000 Datensätzen heute von Gleis 2 – direkt gegenüber”: Das Beste kommt bekanntlich zum Schluss. Für ein älteres Programm von 2018 waren die alten Inhalte noch online, ebenfalls über Supabase angebunden. Die Dashboard-URL konnte in den „Certificate Transparency Logs“ gefunden werden, und die API war ja bekannt. Jedenfalls hat man so über 245.000 Datensätze von jungen Erwachsenen gefunden.

Immerhin wurden sämtliche Lücken relativ schnell nach Meldung geschlossen, das haben wir bei solchen öffentlichen Projekten auch schon anders gesehen.

Eine Zusammenfassung der Thematik kannst du in diesem Artikel bei zeit.de nachlesen.

Wie wir ein Bahnticket buchen wollten und am Ende 245.000 Datensätze hatten

Souveräne EU Cloud von Oracle

Oracle hat den Zahn der Zeit und eine „souveräne europäische Cloud“ gestartet.

Laut eigenen Angaben sind die beiden Datacenter in Deutschland und Spanien komplett isoliert vom restlichen, öffentlichen Cloud- und Gouvernement Angebot von Oracle. Die „EU Souvereign Cloud“ soll sogar isoliert von Mitarbeitern in der EU betrieben, aktualisiert und supported werden.
Technisch sei alles komplett getrennt und die Daten sollen die EU nicht verlassen – die Preise, angebotenen Services und SLAs seien aber komplett gleich wie in den USA. Man hat also keine Einschränkungen, wie bei anderen Angeboten.
Die Cloud ist „noch nicht fertig“ und bei Interesse soll man „Sales kontaktieren“, über das Kontaktformular.

Oracle Addresses European Data Privacy and Sovereignty Requirements with New EU Sovereign Cloud

11 Jahre SaaS Hosting Erfahrungen

Tanda ist ein Unternehmen aus Australien, welches eine SaaS Personal-Planungssoftware mit diversen Add-ons anbietet.
Das Unternehmen ist seit 11 Jahren am Markt und der Co-Founder Alex Ghiculescu hat auf Substack eine interessante „Hosting History“ veröffentlicht.

  1. 2012 startete man auf Heroku – irgendwann wurde es dann zu „teuer“ – mit damals 104,95 $
  2. Man migrierte von Heroku zu DigitalOcean, und war dort eigentlich zufrieden – allerdings hatte DO keine Pläne für ein DC in Australien. Zudem verdoppelte man sich alle 9 Monate. Das Hinzufügen neuer Server war ein manueller Prozess (hm?) und man sei da einfach herausgewachsen.
  3. Da „Real Business“ auf AWS laufen, migrierte man 3 Jahre später zu AWS. Manche Dinge auf AWS klappten dann mit wachsender Größe auch nicht mehr.:
    „We’d had an oncall rotation for engineers for a while too, but we weren’t very good at training people on tricky parts of the stack beyond the Rails app“.
    Zusammenfassend kann man wohl sagen: Klassisch historisch gewachsen
  4. Man blieb auf AWS, führte aber ein „Platform Infrastructure Team“ (PIT) ein, welches rund um die Welt verteilt 24×7 verfügbar ist. Das Team hat die dedizierte Aufgabe, sich um Infra zu kümmern, aufzuräumen, neu zu bauen – und kann sich darauf konzentrieren. Das hilft natürlich enorm.

Alex nennt 3 Findings, die er seinem Ich vor 11 Jahren mitgeben würde:

  1. Managed Services: So lange wie möglich benutzen
  2. Früher ein PIT Team oder Ähnliches bauen
  3. auf sich selber Acht geben

11 years of hosting a SaaS

Hetzner ARM Performance für Bild Optimierung

Die Firma WebP Cloud Services bietet on-the-fly Bildoptimierungen im WebP Format an. Wer hätte das gedacht, bei dem Namen, ne?

Jedenfalls hat man die neuen Hetzner ARM64 CPUs getestet und festgestellt, dass die CPUs das versprochene Preis-Leistungs-Verhältnis in der Praxis bietet und hat die komplette Workload auf 4-Core CAX21 Maschinen migriert.
Die Performance sei zwar 8 % langsamer als beim 3-Kern CPX21, der Preis aber 14 % günstiger – und das bei doppeltem RAM.

Bei WebP hatte man früher ARM Server in der Scaleway Cloud verwendet. Allerdings war dies eine Eigenentwicklung, die Scaleway im Juli 2021 eingestellt hatte. So hat man nun einem Benchmark verschiedene Hetzner Cloud Server, Oracle Cloud Server und einen dedizierten Server miteinander verglichen und schließlich für die Verwendung der Hetzner Server entschieden.

The performance review of Hetzner’s CAX-line ARM64 servers and the practical experience of WebP Cloud Services on them

Forsetzung: Linux 292.612 mal gebooted

Zum „Linux 292.612 mal gebootet“ Artikel von letzter Woche gibt es aufgrund des Feedbacks bei „Richard WM Jones“ im Blog weitere Details zur Fehlersuche.
Unter anderem ist der Fehler zwischen Linux Kernel 6.0 und Kernel 6.4 aufgetreten. Dazwischen liegen 52.363 Commits – das ist dann wirklich die Suche nach der Nadel im Heuhaufen.
Der entscheidende Hinweis kam dann über die Kernel Mailingliste – toll, wenn das so funktioniert.

Follow up to “I booted Linux 292,612 times”

Schmunzelecke

Heute mal ein lustiges „DevOps“ meme von monkeyuser.com.

💡 Link Tipps aus der Open Source Welt

Dkron – Distributed Job Scheduler

Dkron ist ein open-source job scheduling system. Dkron ist für „Cloud-native“ Environments gedacht und ist in Go geschrieben. Das System kümmert sich um das Scheduling von definierten Jobs, bietet eine hübsche UI und ist hoch skalierbar. Du kannst Dkron per APT, YUM oder via Docker installieren.
Dkron hat quasi eine „shared nothing“ Architektur – der State wird in einer lokalen BuntDB abgespeichert, die über alle Dkron Server repliziert wird.
Einen neuen Job legt man dann per API an und Jobs können in einer Kette verbunden werden.
Eine Demo der UI kannst du dir hier anschauen.

https://github.com/distribworks/dkron

Papermark – Open Source DocSend Alternative

Papermark ist eine open-source Alternative zu DocSend. Wie der Name schon sagt, kann man damit Dokumente per kryptischem Link sicher sharen und sich dann Statistiken zu den Dokumenten anschauen.
Papermark kannst du selbst bei Vercel betreiben – du benötigst dazu neben einem Vercel Account auch noch Vercel Storage für die Files und PostgreSQL als Datenbank.

https://github.com/mfts/papermark

  • Neueste Beiträge

  • Neueste Kommentare


  • Share

    By About
    Abonnieren
    Benachrichtige mich bei
    guest

    0 Comments
    Inline Feedbacks
    View all comments

    allesnurgecloud.com

    © 2024 allesnurgecloud.com
    0
    Would love your thoughts, please comment.x