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:
37signals: Cloud Exit soll 7 Millionen Dollar sparen
Über die Pläne von Basecamp/Hey bzw. der Firma dahinter, 37Signals, der Cloud den Rücken zu kehren, hatte ich schon zweimal berichtet. Das erste mal beim initialen Announcement, beim zweiten Mal mit den aktuellen Cloud-Kosten und er Verteilung auf die Produkte.
Nun hat man nach eigenen Angaben die erste Applikation umgezogen und plant den Cloud-Exit bis zum Ende des Sommers – diesen Jahres. David Heinemeier Hansson beschreibt in diesem Artikel die Details zur Timeline und zeigt auch seine Rechnung bezüglich Hardwarekosten und Cloud.
Hierfür hat man sich nun Dell Hardware angeschafft und diese bei Deft verbaut – Deft ist ein „Managed Services“ Datacenter Anbieter, der sich auf Wunsch um Switche, Netzwerk, Loadbalancer, Router, Firewalls und Storage kümmert. Klar, 37signals selbst ist zu klein, als dass sich hier eine Einstellung lohne, die das dann auch noch redundant erbringen kann. Das skaliert mit solch einem Anbieter viel besser und ist auch besser planbar.
Jedenfalls hat DHH nun dargelegt, dass 37signals 7 Millionen Dollar Einsparpotenzial durch den Cloud-Exit habe. Das ist eine beeindruckende Zahl.
Natürlich gab es das übliche Backlash, auf das kontroverse Posting von DHH. Zustimmung gab es aber auch viel, beispielsweise von Adam Jacob, den Co-Founder von Chef:
Lots of folks predicting that 37signals will return to the cloud after realizing how „hard“ it is to run datacenters and computers. My friends, I am old. I have built datacenters by hand. I have automated things in every generation of the internet. I assure you, it is not harder to use managed services to rack, wire, and boot servers. It *is* harder to do it on demand.
Honestly, the best argument for keeping your static, predictable workload in the cloud rather than a data center is simply that we, as an industry, have pretty much forgotten how to do it any other way.
Da kann ich absolut nur zustimmen. Vieles wird auch mittlerweile zu kompliziert gedacht. Und das Wachstum und die Kosten bei Basecamp sehen SaaS typisch nach dem Abklingen des Hype Cycles sehr planbar aus – dafür benötigt man keine Cloud.
Ausgezeichnet gefallen hat mir auch dieser Tweet von @nukemberg:
The lesson here isn’t that should be rethinking your cloud presence, but rather your cloud architecture.
If your architecture looks like a virtual datacenter, you should be on a datacenter.
AWS is a cheap SaaS vendor but a very expensive DC
Klar, wenn wir einfach nur Lift-und-Shift machen und die Architektur nicht überdenken, dann verdient am Ende nur einer, bzw. eben die Hyperscaler.
Von Tim Banks gab es ebenfalls einen interessanten Tweet zum Thema Serverless:
– serverless doesn’t mean „I don’t need ops“
– serverless doesn’t mean less expensive. by contrast, for constant use or high-invocation workloads, it’s *MUCH* more expensive
– not investing in ops will cost you business at scale every time.
Ja, die Erfahrung mit der konstanten Workload auf Serverless Architektur hat sicherlich jeder schon gesehen, schlimm nur, wenn man nichts draus lernt.
Ein spannender, neuer Player auf dem Markt hat sich auch noch auf Twitter eingemischt: Oxide Computer:
The problem is the level of abstraction: the modern computer should be rack-scale and software driven, with built-in primitives for elastic compute, storage and networking that allow for services to be readily built. Having built it (at last!), we believe this more than ever…
Und ich denke, das zeigt gut das Problem – die normale OnPremise Landschaft ist zu heterogen, als dass man sie zu 100 % mit Infrastructure-as-Code betreiben kann. Oxide will die mit seinem neuen, wie ich finde, spannenden Produkt ändern.
Nach diversem Feedback hat DHH seine Argumentation nochmals öffentlich erweitert, denn ihm gehe es nicht nur im Kosten.
In „Five values guiding our cloud exit“ stellt er 5 für 37signals wichtige Werte vor:
- We value independence above all else: Unabhängig von Amazons Cloud sein, in deren Fall – aber auch von deren SaaS/PaaS Angeboten
- We serve the internet: Man möchte zurück zur dezentralen Idee des Internets, ohne Gatekeeper und bestimmenden Institutionen. (hyperscaler)
- We spend our money wisely: Geld sinnvoll ausgeben, lieber für eigene Leute und eigene Hardware
- We lead the way: Die meisten SaaS Businesses in der Größe von 37signals sollten die Technologie „ownen“ und nicht leasen
- We seek adventure: Wer rastet, rostet – oder so ähnlich.
Spannend, was hier alles passiert, und sorry, dass der Absatz etwas länger geworden ist.
Das ist ein wichtiges Thema, das entsprechenden Raum braucht, fand ich.
Lustiges Detail am Rande: Jeff Bezos ist Investor der ersten Stunde bei Basecamp/37signals…
Freue mich über Feedback, wie du das Thema siehst oder wie ihr das in eurer Firma behandelt.
We stand to save $7m over five years from our cloud exit
Levels.fyi: Millionen User mit Google Sheets Backend
Falls du Levels.fyi noch nicht kennst: Levels.fyi ist ein Gehaltsvergleich mit Fokus auf den amerikanischen Markt. Auch deutsche Firmen sind dort teilweise mit Gehältern gelistet, beispielsweise Zalando, SAP und Volkswagen.
Jedenfalls ist nun ein spannender Blog-Post zur Technologie hinter Levels.fyi aufgetaucht: Man verwendet dort Google Sheets als Backend und bedient damit 1-2 Millionen Unique User pro Monat – bei 31 Tagen sind das immerhin noch ca. 65.000 pro Tag.
In der ersten Version lief die Datenerfassung über ein Google Form Formular ab und wurde von dort in den Sheets gespeichert – mittlerweile läuft dies über eine API und eine AWS Lambda Funktion.
Der Read Flow lief insgesamt 24 Monate über das Google Sheets Backend, bzw. über ein JSON File Export auf Basis des Google Sheet Dokuments. Jeder User hat damit die Rohdaten geladen und der Rest wurde im Browser:
Yes, you read that right. In the first few years of Levels.fyi, every single salary (over 100k at some point) were downloaded in a single json. All graphs, statistics, calculations, etc were done in the browser.
Diese Architektur hatte natürlich ein paar Nachteile: Es gab Timeouts, man konnte keine zentralen Analysen fahren und die Sheets API war limitiert. Jedenfalls hat man die Architektur jetzt auf ein Backend mit Datenbank umgebaut.
Fan es trotzdem interessant, dass man so lange mit einem „Google Sheets“ Backend durchgehalten hat.
How Levels.fyi scaled to millions of users with Google Sheets as a backend
Sponsored
The New Era of Monitoring
Deine Applikationen entwickeln sich stetig weiter, und dein Test- und Monitoring sollte das auch! Checkly’s Launch Week beginnt am 27. Februar mit täglich neuen Features:
👨💻 Monitoring as Code – schreibe, teste und deploye dein komplettes Monitoring-Setup als Code!
🎭 Nativer Playwright Test Support – Schreibe deine End-to-End Tests mit dem Playwright’s Test Runner.
🚨 Dashboards & Incidents – Erstelle und gestalte Dashboards in deinem Brand-Design.
📊 Analytics API – Integriere Checkly in externe Systeme und bekomme Einblick, welche Folgen Downtime auf dein Unternehmen hat.
Nimm an der Launch Week vom 27.02. – 02.03. teil, um keine Neuigkeiten zu verpassen. Mit etwas Glück gewinnst du tolle Preise für dein Homeoffice.
Hier gehts zur Anmeldung 👉Checkly Launch Week
„Business Continuity Management“ etablieren
In diesem kurzweiligen Blog-Artikel beschreibt Kris, wie sie bei seinem vorherigen Arbeitgeber mit dem Thema „Business Continuity Management“ umgegangen sind.
Sprich, „was kann alles schiefgehen und wie reagieren wir darauf“, oder auch:
Specifically, there was a requirement to be able to lose a region completely without loss of business. The other requirement was to be able to have all systems CVE-free within 30 days (in emergencies: 3 days), and to be able to blackstart them.
That was of course impossible to implement.
Die Teams haben die Köpfe zusammengesteckt und Ausfall-Szenarien modelliert – und mögliche Reaktionen auf den Ausfall.
Diese Szenarien wurden trainiert und in Sprints immer wieder verfeinert – so entstand ein Playbook – wichtig dabei:
This, after only three to four years, is where our organisation has reached a state where teams and management can go with confidence into a scenario where access to one Region is lost, in a controlled way and with pre-announcement.
So etwas dauert, in der Größenordnung, ein paar Jahre – und da muss man auch kleine Brötchen backen, damit das Thema ein Erfolg wird:
The key to success for the MoD was the change from Project to Process. Do small things with individual teams, first with cooperative teams, then reaching out and making the process mandatory for all teams.
Master of Disaster – das ist eine Rolle, die ich so auch noch nicht kannte.
This is not a Drill, this is just Tuesday
Du brauchst nichts anderes als SQLite
Dieser Artikel ist aus dem letzten Jahr, aber da er zum Thema „Radical Simplicity“ passt, und in meiner Timeline aufgetaucht ist, wollte ich den hier aufführen.
Der Artikel fängt damit an:
The name SQLite is a nice name, but the „lite“ part is misleading, it sounds like it is only useful for tiny things – which is very wrong. SQLite should be named AwesomeSQL, because that is what it is. SQLite is probably the only database you will ever need in most cases.
Da stehen dann auch Dinge, die ich darüber noch nicht wusste: SQLite erlaubt „concurrenct reads an writes“ mittels busy timeout und write-ahead logging (WAL).
Natürlich hat SQLite auch Limitierungen, beispielsweise wenn mehrere Maschinen auf die DB zugreifen wollen, dann funktioniert das Konzept nicht mehr. Oder wenn man mit großen Datenbank arbeitet – im TB Bereich.
Für kleinere Web Applikationen ist SQLite aber eine feine Sache und auf jeden Fall einen Blick wert.
Pieter Levels, ein bekannter Indie-Hacker, hat beispielweise jahrelang für seine Projekte SQLite verwendet. Für neue Projekte macht er dies teilweise immer noch.
Über Server-Side SQLite bei Fly.io hatte ich in Ausgabe #62 berichtet – hier arbeitet man auch ständig an der Erweiterung des Portfolios und einer „Distributed SQLite“ über das FileSystem LiteFS.
SQLite the only database you will ever need in most cases
React.js Dokumentation von Honeypot
Im letzten Jahr hatte ich bereits auf die tolle Prometheus Dokumentation von Honeypot hingewiesen.
Man hat nun eine neue Dokumentation gemacht, diesmal zum Thema React.JS.
Die Dokumentation ist wieder hochwertig produziert und geht insgesamt 1h und 18 Minuten – anschauen kannst du die Dokumentation direkt bei YouTube – haben schon knapp 500.000 Menschen vor dir gemacht.
Im verlinkten Artikel beschreibt „Pragmatic Engineer“ Gergely Orosz wie die Dokumentation enstanden ist und wer alles mitgewirkt hat – beispielsweise sind dies:
- Adam Wolff – früherer director of product infra bei Facebook
- Christopher Chedeau – frontend engineering manager at Meta, co-creator of React Native
- Andrew Clark – React’s core team
- Lee Byron – co-creator von GraphQL
- Tony Casparro – engineering lead bei Netflix
Die Premiere fand in einem richtigen Kino statt – während der JSWorld in Amsterdam in diesem Jahr.
Behind the Scenes with React.js: the Documentary
Ubuntu 18.04 LTS bald EoL
Alle Jahre wieder sind auch die Ubuntu LTS Versionen mal EoL – dieses mal 18.04 LTS – released vor fast 5 Jahren, am 26. April 2018.
Zeit, auf die aktuelle LTS Version – 22.04 LTS „Jammy Fellyfish“ zu migrieren – diese hat dann bis zum April 2027 Support – ohne Extended Security Maintenance. Wer dann doch ESM benötigt, der kann dies über „Ubuntu Pro“ beziehen – afaik sind hier bis zu 5 Maschinen umsonst – ab dann 500 $ Pro Host/Jahr.
Eine schöne Visualisierung zum Thema EoL für Ubuntu gibt es bei endoflife.date.
GitLab 15.9 veröffentlicht
Wie an jedem 22. des Monats, gab es trotz der zuletzt schlechten Nachrichten aus dem Hause GitLab, auch im Februar ein neues Release: 15.9.
Neue Features unter anderem:
- Slack Notifications für GitLab SaaS nun in der Slack APP
- Die Incident Timeline wurde um Tags erweitert
- „Special Characters“ wie $, “ oder ‚ können in den CI/CD Variablen nun auch versteckt werden
- In einem Dashboard können nun Projekte anhand der Programmiersprache gefiltert werden.
- Die Discord User ID kann nun im GitLab Profile hinterlegt werden
- Die neue „Your Work“ Sidebar ist das erste Element des bevorstehenden „Navigation Redesigns“
- Markdown Checklist Items können nun in Tasks verwandelt werden – das finde ich sehr cool.
- NPM Packages können nun via CI/CD in eine eigene Registry gepackt werden.
Und wie immer gab es viele andere Features und Performance Verbesserungen. In Summe gibt es 105+ Verbesserungen in Release 15.9 mit über 410 Contributions aus der Community.
Linux stressen mit „Stress-ng“
Stress ist ein älteres Performance-Testing Tool für Linux, welches CPU, Memory, Disk und Cache „stressen“ kann.
Mit stress-ng gibt es nun eine neuere Variante davon, die ich bisher noch nicht kannte. stress-ng gibt es beispielsweise als Ubuntu Package.
Man kann die CPU belasten:
stress-ng --cpu 4 --timeout 60s --metrics-brief
IO:
stress-ng --disk 2 --io 2 --timeout 60s --metrics-brief
oder auch das Memory.
stress-ng --vm 2 --vm-bytes 1G --timeout 60s
Alles zusammen dann:
stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 1G --timeout 60s --metrics-brief
Ergibt auf einer Maschine mit 2 CPUs dann dieses Ergebnis:
Und jetzt viel Spaß beim stressen.
Stress Test CPU and Memory (VM) On a Linux / Unix With Stress-ng
Schmunzelecke
Wer schon immer mal wissen wollte, wie LAN Parties in den Anfängen der 2000er funktioniert haben – dem sei dieses ARD Kultur Video „Jugendtrend LAN-Party“ ans Herz gelegt. Ist natürlich nicht ganz ernst gemeint, mit der Mikrowelle hab ich niemand auf der LAN gesehen – aber ansonsten sind schon paar Wahrheiten dabei 😂
💡 Link Tipps aus der Open Source Welt
RustDesk – Open-Source TeamViewer Alternative
RustDesk ist eine Open Source Remote Desktop Lösung und somit eine Alternative zu TeamViewer.
Die Software ist – wie der Name schon sagt – in Rust geschrieben und kommt mit Clients für Windows, Linux, Max, Android, iOS und sogar einem WebClient (Beta). Als Rendezvous Server kann man öffentliche Server nutzen oder einen eigenen Server deployen.
Kanntest du das schon? Ich jedenfalls nicht – hat knapp 40.000 GitHub Sternchen. Man kann nicht alles mitbekommen.
https://github.com/rustdesk/rustdesk
Wallabag – Open-Source Pocket Alternative
Wallabag ist eine Open-Source Alternative zu Pocket. Pocket nutze ich selber, um Hinweise, Links und Artikel für den Newsletter zu sammeln. Das kannst du mit einer Browser-Extension, iOS und Android App auch bei Wallabag machen.
Den Wallabag Server kannst du beispielsweise via Docker deployen. Als Datenbank kann eine SQLite, MySQL oder PostgreSQL verwendet werden.
https://github.com/wallabag/wallabag
❓ 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: