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:
Entwickler wollen doch kein Ops machen!?
DevOps, Agile Methoden, „You build it, you run it“ – haben wir in den letzten Jahren in unzähligen Artikel gelesen und in diversen Präsentationen gehört.
Emiliy Freeman, die Autorin von „DevOps for Dummies“, hatte Im März hierzu dann einen konträren Tweet geschrieben:
I’ve been saying for a while now that devs don’t want to deal with operational concerns, for the most part. And I always get push back.
Eine der Antworten sticht für mich heraus und trifft den Nagel auf den Kopf:
I do have a preference of getting back to be able to master a specific craft in programming rather than be a jack of all trades because the responsibilities spread me too thin now. Both are full time responsibilities that get half attention now. 😩
Dies ist exakt das, was ich in den letzten Jahren beobachtet habe. Man springt zwischen Verantwortlichkeiten und Prioritäten hin und her, hat Schwierigkeiten sich zu fokussieren und kann beide Themen nur zur Hälfte erfüllen.
Im Artikel sind diverse Studien und weitere Artikel verlinkt, die das Problem beschreiben und mit Zahlen und Umfragen untermauern.
Für einige Unternehmen scheint SRE (Site-reliability Engineering) die Lösung zu sein, jedoch sind die meisten Unternehmen nicht „Google“ und haben neue Herausforderungen mit dem Thema SRE:
Introducing SRE does make people feel like we are siloing ops again into that role.
meint Christina Yakomin, SRE bei Vanguard. Die Implementierung von SRE in Organisationen kann unterschiedlich erfolgen – als beratendes Team, als wandernde Mitarbeiter oder auch komplett autark. In Ausgabe #63 hatte ich „Embedded SRE bei Mercari“ vorgestellt. Mercari hatte verschiedene Modelle vorgestellt und sich selbst für ein passendes entschieden.
Was ist nun die Zukunft?
Vielleicht „Platform Engineering“ und interne Entwickler Plattformen? Dies schlägt jedenfalls der Artikel zum Ende vor und zitiert einen weiteren populären Tweet, diesmal von @sidpalas – „DevOps is dead 💀, long live Platform Engineering!“.
Allerdings scheint auch dies ein Balance Akt zu werden.
Cloudflare ersetzt NGINX mit Pingora
Cloudflare hat in einem Blog Eintrag in seinem Tech-Blog Pingora vorgestellt. Pingora ist ein in Rust entwickelter HTTP Proxy, der NGINX ersetzt und über eine Billion Anfragen pro Tag beantwortet.
NGINX könne die notwendige Leistung aus diversen Gründen nicht mehr liefern, beispielsweise seinen die CPUs aufgrund der Worker Architektur unterteilt ausgelastet und CPU intensive Tasks können andere Threads blockieren oder ausbremsen.
Das größte Problem bei NGINX aber sei der Connection Pool, der pro Worker vorgehalten wird. Ein bereits existierende Backend Connection kann also nur wieder genutzt werden, wenn der Request auf dem gleichen Worker lande. Die hat vor allem Einfluss auf die TTFB (time-to-first-byte).
Die Neuentwicklung in Rust kommt mit einer ebenfalls neu entwickelten HTTP Bibliothek, welche diese Probleme beseitigt.
Im produktiven Einsatz gibt es nun interessante Zahlen. Pingora erstellt nur noch ein 1/3 neue Verbindungen als NGINX, kann also viel mehr bereits existierende Verbindungen wiederverwenden.Für einen größeren Kunden konnten die neuen Connections um den Faktor 160 reduziert werden. Ebenfalls benötigt Pingora 70% weniger CPU und 67% weniger Memory.
Pingora soll in Zukunft Open-Source veröffentlicht werden.
How we built Pingora, the proxy that connects Cloudflare to the Internet
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.
Status Pages erzählen nur die halbe Wahrheit
Wer kennt es nicht: Deine App oder oder Dein Shop ist down, du hast nichts geändert – trotzdem funktioniert etwas nicht richtig.
Die Status-Pages deiner SaaS und Cloud Provider sind noch „leer“ – und du begibst dich auf die Suche nach der Ursache.
Bei größeren Providern kann man einfach auf Twitter suchen, beispielsweise ein Ausfall bei Fastly, Cloudflare, AWS, Google oder Azure macht sich dort recht schnell in einer Vielzahl an Tweets bemerkbar.
Jedoch kannst Du dich auf deren Status Pages häufig nicht verlassen, häufig werden diese
- manuell aktualisiert – obwohl es automatisch möglich wäre
- langsam aktualisiert – Informationen oder Begründungen müssen abgestimmt erfolgen, gerade bei börsennotierten Unternehmen
- initial nur mit vagen Informationen veröffentlicht – „Some customers may be affected“
Manchmal sind die Status-Pages auch selbst down, da diese gleich „gehosted“ und betrieben werden, wie die eigentlichen Applikationen. Und in der Regel sind Status-Pages nur eine andere Form der PR.
Der verlinkte Artikel bei Metrist ist hierzu interessant, bewirbt aber natürlich auch deren Produkt.
Mit einfachen Mitteln kannst du schon direkt prüfen, ob du ein Problem mit einem Hoster oder 3rd Party Provider hast. Ein kontinuierliches Monitoring der in deiner App verwendeten APIs ist sehr zu empfehlen – reagiert die Payment API gerade nur langsam oder gar nicht, funktioniert die Newsletter API gerade nur schlecht und beeinträchtigt so indirekt deinen Checkout – all dies will man wissen und kann das in eigenen Monitoring Tools abdecken.
Weitere Infos zum Umgang mit 3rd Party Providern findest du in Ausgabe #66.
Why Status Pages Are Lying to You and What To Do About It
Security Incident bei Uber
Ein 18 jähriger Hacker war bei Uber einfach überall.
Scheinbar fand er/sie Credentials in einem PowerShell Script auf einem Netzwerk Share. Die Berechtigungen darin verhalfen ihm/ihr zum administrativen Zugriff auf AWS, Google Cloud, HackerOne, Slack und VMWare. Einige Screenshots könnt ihr in diesem Twitter Thread bei @vxunderground sehen.
Uber selbst gibt bisher nur spärlich Informationen zum Vorfall heraus: Daten von Usern und Fahrern und die Systeme selbst seinen nicht betroffen. Interne Systeme wurden sicherheitshalber gestoppt und seit Freitag so langsam wieder gestartet.
„Total kompromittiert“: 18-Jähriger hackt Uber, interne Dienste offline
Warum bewerben sich Mitarbeiter bei Startups?
Im Artikel stellt Vasili diverse Möglichkeiten für Startups vor, Mitarbeiter zu überzeugen, sich doch endlich zu bewerben.
Meiner Meinung nach gelten die Mehrzahl der Methoden für sämtliche Firmen, nicht nur für Startups.
Im derzeit hart umkämpften Job Markt braucht es eine Vielzahl an Maßnahmen, um die Attraktivität des Arbeitgebers zu erhöhen.
Der Artikel ist recht lang und konzentriert sich auf diese 4 Fragen:
- Wer sind die Gründer und was motiviert sie?
- Wer ist das Team und was treibt es an?
- Wie ist die Firmenkultur?
- Wie geht es dem Business selbst?
Viele der Inhalte haben mit der Transparenz von Themen zu tun. Gerade Corporates tun sich eher schwer, transparent mit Ihren Zahlen, mit dem Team und der Motivation der Gründer umzugehen. Erfrischend anders war hier Herbert Diess, der ehemalige Vorstandsvorsitzender der Volkswagen AG, und die transparente Darstellung und Kommunikation von wichtigen Zukunftsthemen auf Linkedin – man benötigt also nicht immer gleich ein eigenes Blog dafür.
PostHog, ein Open Source Startup, stellt beispielsweise in der „Company Story“ seine Reise als Startup transparent mit Zahlen dar.
Die Macher von Fibery schreiben monatliche Beiträge in ihrem Startup Diary. Die Calendly Alternative cal.com veröffentlicht sämtliche KPIs transparent auf einer Website.
Es steckt viel Arbeit darin, sich als attraktive Firma offen und transparent darzustellen.
Der Aufwand scheint sich aber zu lohnen.
How to communicate why your startup is worth joining
Cloudflare und ClickHouse
Vor einer Weile hatte ich bereits ClickHouse, die Open-Source Datenbank aus dem Hause Yandex, hier vorgestellt.
Cloudflare ist ein early Adopter von ClickHouse – bereits 2017 stellte man im Blog vor, wie man mit ClickHouse bis zu einer Million DNS Queries pro Sekunde analysiert. Im Jahr 2018 veröffentlichte man dann eine ähnliche Story, diesmal aber mit Fokus auf den Use-Case HTTP Analytics – Cloudflare schrieb schon damals über 6 Millionen Requests pro Sekunde in ClickHouse zur späteren Analyse weg.
Im aktuellen Beitrag erfährt man nun Details zur Logging Pipeline – wie werden die Logs gesammelt, aggregiert und nach ClickHouse gebracht. Wer den Beitrag nicht lesen möchte, der kann auch das 23 Minuten lange Video von der Monitorama PDX 2022 Konferenz anschauen, hier hatten 2 Cloudflare SRE Mitarbeiter die Logging Infrastruktur und deren Migration von Elasticsearch nach ClickHouse vorgestellt.
Log analytics using ClickHouse
AWS gzip zu zstd Migration spart 30%
Laut einem Tweet des ehemaligen AWS Advisors Adrian Cockcroft spart AWS durch die Migration des Zip Algorithmus seiner S3 Daten über 30% Speicherkapazität ein. Da man sich im Exabyte Bereich bewege und hauptsächlich Log-Files speichere, sei die Einsparung gravierend.
Man verwende nun Zstandard (zstd), ein Open-Source Algorithmus von Facebook, und ersetzt damit den Standard gzip. Gzip verwendet bis zu 100% einer CPU und erzeugt dabei schlechtere Kompressionsraten. Zstandard benötigt nur 20-30% einer CPU und ist sowohl bei Kompression und Dekompression deutlich schneller und effektiver.
Da mir das Ausmaß bisher so nicht bekannt war, hab ich das eben mal selbst ausprobiert.
Ein 5,3 GB MySQL Dump packt zstd in 24 Sekunden auf 532MB. gzip benötigt dafür 1 Minute und 28 Sekunden und komprimiert auf 554MB. gzip braucht also mehr als 3 mal so lange, um ein etwas schlechteres Ergebnis zu erzielen.
Zeit alles nach zstd umzustellen, oder?
AWS switch from gzip to zstd – about 30% reduction in compressed S3 storage
Hat Deine Website nur 14kb?
Meine auch nicht, ich weiß auch nicht, wie das gehen soll.
Im Artikel bei bei endtimes.dev kannst du nachlesen, warum Webseiten mit 14kb Größe deutlich schneller sind als mit 15kb.
So ziemlich genau 14kb passen nämlich in einen TCP Round Trip. 14kb mit Kompression können übrigens so 50kb in Summe sein. Platz genug?
Ich weiß nicht so recht, selbst der verlinkte Artikel bei endtimes.dev selbst kommt bei mir mit 408kb an, und die ist ziemlich minimalistisch.
Why your website should be under 14kb in size
Schmunzelecke
- Quake 1 läuft auf der Apple Watch – siehe YouTube & Projekt auf GitHub
- „Microservices“ bei YouTube – Galactus FTW!
💡 Link Tipps aus der Open Source Welt
ZincSearch – Elasticsearch Alternative
ZincSearch oder auch Zinc ist eine in Go geschriebene Elasticsearch Alternative, die laut eigenen Aussagen ein Bruchteil der Ressourcen benötigt. Zinc ist ein drop-in replacement für Elasticsearch und kann ES „in 2 Minuten ersetzen“.
Kibana funktioniert nicht mit Zinc, Zinc hat jedoch eine eigene UI.
Vorstellung im kurzen Video hier oder einfach die Demo auf dem Playground Server anschauen (User: Admin, PW: Complexpass#123)
https://github.com/zinclabs/zinc
Cal.com 2.0 released
Cal.com 2.0 ist ein kompletter Relaunch mit neuem Design der Open Source Calendly Alternative.
Du kannst cal.com selbst hosten oder nun komplett kostenlos im neuem „Free forever“ für Individuals Tarif nutzen.
Neu in 2.0 sind außerdem neue Workflows und Routing Formulare, ein neues Design und ein App Store.
Mit „Dynamic Booking Links“ kann man im Team Links für Termine mit mehreren Teilnehmern kalenderweit abstimmen.
Alle neuen Features findest Du im News Eintrag im Blog von cal.com.
https://github.com/calcom/cal.com
Awesome SRE Collection
In dieser sehr umfangreichen, kuratierten Liste findest Du sehr viele Artikel, Videos, Tutorials und Tips rund um das Thema Site Reliability Engineering. Egal ob Kultur, On-Call, Post-Mortem, Performance oder SLA – zu jedem Bereich findest Du eine Vielzahl an Hinweisen und Beiträge. Einfacher anschauen kannst du Dir die Inhalte auf der Website sre.xyz.
https://github.com/dastergon/awesome-sre
❓ 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: