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:
Hetzner Cloud startet ARM Angebot
Der deutsche Cloud Hosting Provider Hetzner erweitert sein Angebot um ARM Server auf Basis von Ampere® Altra® CPUs, welche bereits in der Google Cloud Verwendung (TAU T2a Instanzen, Ausgabe #68) finden.
Das Angebot der Shared vCPU Instanzen hat es in sich:
- 2vCPUs / 4 GB RAM / 40 GB Disk – 4,52 €/Monat
- 4vCPUs / 8 GB RAM / 80 GB Disk – 7,73 €/Monat
- 8vCPUs / 16 GB RAM / 160 GB Disk – 14,87 €/Monat
- 16vCPUs / 32 GB RAM / 320 GB Disk – 29,15 €/Monat
Bei Google sind solche Instanzen deutlich teurer:
- 4vCPUs / 16 GB RAM / 80 GB Disk – 122,08 €/Monat
- 32vCPUs / 64 GB RAM / 320 GB Disk – 488,28 €/Monat
Ja, die sind nur bedingt vergleichbar, bei Google bekommt man den doppelten RAM bei gleicher CPU – der Preisunterschied ist jedoch schon eklatant (zum Preisrechner mit beiden Hosts). Bei Google gibt es die Tau-Instanzen nach wie vor nicht in Frankfurt, deshalb ist hier die Niederlande als Region ausgewählt.
Die Performance hat ein Hetzner Mitarbeiter mit einem AMD Epyc verglichen (zur Auswertung bei Geekbench).
Die Leistung ist meist recht ähnlich, der Preis jedoch nicht – gerade, wenn man eine größere Anzahl an Cores wählt.
Ein Twitter User hat hingegen das Digital Ocean ARM Angebot mit dem von Hetzner verglichen. Hetzner hat in den meisten Punkten die Nase vorn (Disk Speed, Bandbreite, Network Speed, Ping) und gewinnt hier ebenfalls im Geekbench Vergleich. Und der Preis ist bei Hetzner mit 4,17 $ gegen die 24 $ bei DO für die kleine Maschine einfach super.
Passend zum Launch bei Hetzner gibt es ein neues Hetzner Datacenter & Cloud Video von Manuel von HardwareDealz.
Hast du schon ARM für deine Workload getestet?
Preis/Leistung sieht jedenfalls sehr interessant aus.
Hetzner introduces arm64-based cloud servers
Azure „Preisanpassungen“ lösen Empörungen aus
Die ursprünglich als Währungsanpassung angekündigten Preisanpassungen von Microsoft/Azure zum 1. April 2023 haben eine Welle der Empörung ausgelöst. Teilweise ist gar von Erpressung die Rede (siehe verlinkter Artikel).
Ich hatte Ende Januar in Ausgabe 89 bereits darüber berichtet, irgendwie hat Microsoft es geschafft, die News dazu eher „klein“ zu halten. Damals sprach man von „FX Rate Adjustments“ (FX = Foreign Exchange) und man hat dies ursprünglich so formuliert:
Starting April 1, 2023, the following adjustment will be effective for Microsoft Cloud services:
Danish Krone (DKK), Euro (EUR) and Norwegian Krone (NOK), prices will adjust +11% Swedish Krona (SEK) prices will adjust +15%
Der Generalsekretär des Verbandes „Cloud Infrastructure Service Providers“ sagte, dass Microsoft Kunden „keine andere Wahl haben, als zu zahlen“. Im letzten Jahr passte Microsoft erst seine Office365 Preise um 25 % nach oben an, nun gibt es eine weitere Anpassung von 11 % aufgrund der Wechselkurse.
Laut Daten von „Liftr Insights“ hat AWS mit den Preiserhöhungen bereits im Jahr 2019 angefangen – und die Anpassungen weiter erhöht:
Over the past year, there has been a 23.0% increase in average prices of on-demand compute instances at AWS. Liftr Insights data show that not only did AWS increase their average prices in 2020, 2021, and 2022, but the increases have been higher each year since 2019.
Quelle: prnewswire.com
Laut dem Artikel habe Azure bisher nicht so kräftig erhöht wie AWS – vielleicht gibt es jetzt hier auch eine Trendwende?
Natürlich kann nun jeder 1 oder 3 Jahre Commitment einkaufen (falls bisher nicht geschehen) – allerdings wird das Erwachen in 3 Jahren dann umso heftiger werden.
EU-Cloud-Wettbewerber: Microsofts Preissteigerungen reichen an Erpressung
Sponsored
„Die Braut in der Cloud mit KRUU und „We Manage“
Mit unserem Kunden KRUU und dem Cloud-Anbieter Gridscale haben wir eine ausführliche Case Study veröffentlicht (schicke PDF Version).
Die Case Study beschreibt unseren ganzheitlichen Ansatz einer „Rundum-sorglos-Betreuung“ mit einem maßgeschneiderten Angebot und Unterstützung bei DevOps- und SRE Herausforderungen.
Eine Übersicht unserer Leistungen findest Du hier – und
hier kannst Du uns in einem kurzen Videocall kennenlernen
37signals/HEY.com: Cloud Hardware für Cloud Exit
Die Damen und Herren von Basecamp/37Signals/HEY haben ihren ersten Schwung Hardware für ihren geplanten Cloud-Exit erhalten. Jeweils 2 Paletten mit 20 Dell R7625 Servern wurden in beiden Data Centern (Chicago, Ashburn) angeliefert.
Die Server haben jeweils 2 AMD EPYC 9454 CPUs mit je 48 Cores/ 96 Threads. Insgesamt wird die „37signals Cloud“ um 4000 vCPUs und, 7680 GB RAM und 384 TB NVMe SSDs erweitert.
DHH hat im Blog-Artikel sogar eine Rack Übersicht und Fotos der Racks veröffentlicht.
Nach aktuellen Plänen ist man mit dem „Cloud-Exit“ bereits Ende des Frühlings fertig – und nicht, wie noch vor 3 Monaten geplant – am Ende des Sommers. Schon nicht schlecht.
Spannend bei 37signals – die Applikationen werden in alten Versionen immer weiterbetrieben – das „Basecamp Classic, „das nun seit 13 Jahren nicht mehr aktualisiert wurde, wird heute noch von Kunden genutzt und ist ein „multi-million dollar“ Business.
Die eigenes entwickelte Kubernetes Alternative „MSRK“ ist auf knapp 30 Contributors angewachsen und mit Version v0.11.0 gibt es bereits das 11. Release – hast du das schon mal ausprobiert?
The hardware we need for our cloud exit has arrived
MongoDB Alternative FerretDB nun GA
Mit FerretDB 1.0 ist eine der bekanntesten Open Source Alternativen zu MongoDB nun GA gegangen.
FerretDB ist ein „drop-in replacement“ für MongoDB, welches Client-seitig kompatibel zu MongoDB ist. Im Hintergrund läuft aber – im Default – eine PostgreSQL als DB Engine. Man muss also seine Applikation erstmal gar nicht anpassen, sondern kann auf ein PostgreSQL Backend switchen, seine Queries aber (erst einmal?) weiterhin im MongoDB Client unangetastet weiter betreiben.
Spannend finde ich, dass die SAP aktuell an einer SAP HANA Integration arbeitet. Und es gibt bald „basic support“ für SQLite – eine Übersicht aller kompatiblen Backends findest du hier.
Ein paar Unterschiede zur Standard MongoDB gibt es, diese sind hier aufgelistet.
Neben dem Code selbst ist auch die High-level Roadmap auf GitHub öffentlich einsehbar.
FerretDB kann man einfach als Container betreiben, beispielsweise neben der PostgreSQL Infrastruktur. Damit kann ein Client dann über beide Wege zugreifen, gewinnt Zeit für eine Mongo => PostgreSQL Migration oder kann seine Applikation einfach weiterbetreiben.
Der Cloud Provider Scaleway hat FerretDB schon als „Managed“ Angebot in einer Beta-Version aufgenommen. Über zusätzliche Kosten zur PostgreSQL DB ist bei Scaleway noch nichts bekannt.
Announcing FerretDB 1.0 GA – a truly Open Source MongoDB alternative
FireHydrant: SVB Insolvenz als IT Incident
Der Incident Management Tool Anbieter FireHydrant hat in seinem Blog einen interessanten Artikel veröffentlicht.
Wir erinnern uns – vor ca. einem Monat war das Silicon Valley ordentlich in Aufruhr – die Hausbank vieler Start-ups, die Silicon Valley Bank, ging kurz vor einem Wochenende insolvent.
FireHydrant hat daraus einen Incident gemacht und nun die Timeline dazu veröffentlicht – quasi ein „Postmortem“ für das Handling einer insolventen Bank. An dem Beispiel kann man nun schön sehen, wie das Tool ansich funktioniert.
Nach einer Vergabe von Rollen (Incident Commander (in dem Fall der CEO), Planning (CTO) und mehreren Respondern (Finanzleute), erstellte man eine „private“ Status-Page. Diese erlaubte Stakeholdern (Investoren, Board Member) und den Mitarbeitern, dem Incident transparent zu folgen – es musste niemand genervt werden – was man in keinem Incident Fall brauchen kann.
FireHydrant erstelle zudem einen privaten Slack Channel mit allen an der Entstörung beteiligten Personen.
Im Slack Channel wurden transparent News und der Status von Tasks geteilt – beispielsweise die Eröffnung neuer Bankkonten bei anderen Banken, oder die News zur Übernahme der SVB durch die FDIC.
Großes Problem war insbesondere die Überweisung der Gehälter (Payroll), die in den USA oft wöchentlich bezahlt wird.
Zudem funktionierte das 2FA System der SVB nicht, war einfach überlastet.
In Summe ein interessanter Einblick in einen solchen Incident Prozess, und auch cool zu sehen, wie das Tool selbst im Hintergrund arbeitet und unter anderem Tasks dokumentiert und daraus eine Timeline erstellt, die dann für die Erstellung eines Postmortem genutzt werden kann.
How FireHydrant handled the SVB banking crisis
Database Sharding Herkunft ist „Ultima Online“?
Und passend zu den heutigen Datenbank-Themen noch ein Fakt, der mir bisher unklar war.
Der verlinkte Artikel aus dem Jahr 2009 erklärt, dass der Begriff Sharding bis zu Ultima Online zurückgeht.
Ultima Online ist ein MMO (Massively Multiplayer Online Role-Playing Game) aus dem Jahr 1997 – das ist schon ein Weilchen her, und ja, da hatten wir schon Farbe auf dem PC.
Jedenfalls gab es mehrere „Server“, als direkte Kopie mit den gleichen Welten, da nicht alle Spieler auf der gleichen Instanz spielen konnten – bei vielen MMOs ist das ja heute noch so. Diese „Server“ nannte man damals schon „Shards“, da sie meist nicht nur aus einem Server bestanden, sondern aus diversen Komponenten/Maschinen.
„Meridian 59“ funktionierte ähnlich, das hatte ich damals sogar selbst gespielt. Lang ist das her, „Meridian 59“ ist sogar seit 2012 Open Source und bei Steam kostenlos – das wusste ich gar nicht. Aber Achtung, du brauchst mindestens einen Pentium 2.
Zurück zu den Datenbanken – je nachdem, wem man nun glaubt, wurde Database Sharding dann bei Friendster geboren, was später zu Flickr wurde. Für Flickr gibt es hier noch Designdokumente aus dem Jahr 2006.
Da waren wir bei web.de damals früh dran (Ich war 2004-2007 dort). Hier hatten wir für den E-Maildienst „Freemail“ bereits ein ähnliches Sharding Konzept, das wir „Serien“ nannten. Eine Serie bestand aus einer DB (plus Replika) und mehreren Frontend-Maschinen. Davor gab es eine Routing Komponente, die die User nach dem Login auf die „Heimat“ Serie verteilte.
Database “sharding” came from UO?
Fragwürdige Defaults von Microsoft Edge
Wusstest du, dass Microsoft Edge deine Eingaben im Default an den „Microsoft Editor“ Service übermittelt, um dir grammatikalische und sprachliche Verbesserungen vorzuschlagen?
Oder dass Edge automatisch ein Teil der Links durch Affiliate-Links ersetzt?
Nein? Ich auch nicht.
Diese und weitere Optionen inkl. deren Deaktivierung zeigt Thomas Karpiniec im verlinkten Blog-Artikel.
Ich habe Edge nie wirklich benutzt, mit Chrome ähnlichem Verhalten gegenüber den Usern macht man sich aber keine Freunde.
Dabei ist doch gerade die Reichweite und die verwendete Chrome Rendering Engine eine große Chance, ein wirklich „privaten“ Browser zu bauen, dem man Vertrauen kann – sieht hier leider nach dem Gegenteil aus.
The dark defaults of Microsoft Edge
Prequel: RabbitMQ durch Postgres Queue ersetzt
Der Data Warehouse Pipeline Anbieter Prequel.co hat wohl ebenfalls das Konzept zu radicalsimpli.city gelesen.
In einem halben Tag hat man RabbitMQ als Queue durch eine einfache Tabelle mit read/write locks auf Row Ebene ersetzt.
Das Konzept dahinter ist so simpel und einfach, dass es seit der Implementierung einfach so funktioniert.
Und hat zudem den Vorteil, dass es keine 2 führenden Systeme für den „Application State“ gibt, sondern nur noch eines.
Der Umsetzung gingen diverse Probleme voraus, wie beispielsweise „komisches Reconnect Verhalten“, Worker, die ihre Verbindung verloren oder seltsames „Prefetching“ von RabbitMQ.
Und nicht falsch verstehen – in größeren Umgebungen machen Queues mit AMQP definitiv Sinn, in diesem Fall jedoch, scheint die einfachere Lösung die stabilere zu sein.
SQL Maxis: Why We Ditched RabbitMQ And Replaced It With A Postgres Queue
Schmunzelecke
Design-Wettbewerb: Wer macht den schlechtesten Lautstärke-Regler der Welt?
22 Kandidaten streiten sich hier um den Pokal.
💡 Link Tipps aus der Open Source Welt
Plane – Open Source Jira & Linear Alternative
Plane ist eine recht neue und vielversprechende Alternative zu Jira, Linear und Height – ein Tool für das Planen und Managen von (Software-) Projekten.
Aktuelle Features:
- Issues und Tasks planen
- Sprints in „Cyles“ organisieren – inkl. Burndown Charts
- Größere Projekte können in Modules heruntergebrochen werden
- GitHub Sync – um GitHub Issues mit Plane zu syncen
- und mehr – alle Features hier in der Übersicht.
Die UI sieht ziemlich schick aus. Plane kann wahlweise self-hosted via Docker Compose installiert oder als SaaS Variante in der Plane Cloud verwendet werden. In Summe sieht das Projekt vielversprechend aus – die Dokumentation ist hingegen noch nicht sehr vollständig.
https://github.com/makeplane/plane
Kontext – Kubeconfig Management leichtgemacht
Mit dem kleinen Helferlein kontext kannst du deine kubeconfig mit einem einfachen Command umschalten.
Du kannst auch kubeconfigs in „Gruppen“ zusammenfasst und damit besser organisieren.
Wie das Ganze funktioniert, siehst du in der Demo hier auf GitHub.
Der Autor von kontext, Nils Orbat, hat auf seinem Blog ein kleines Tutorial dazu veröffentlicht.
Download des Binaries direkt bei den GitHub Releases.
https://github.com/orbatschow/kontext
❓ 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: