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:
Scrum bei Big Tech? Fehlanzeige
Gergely Orosz, der Author des „Pragmatic Engineer“ Newsletters, war früher Mitarbeiter bei Skype und Uber. In diesem Artikel von Ende 2021 beschreibt er den Status Quo von Scrum und den Gründen diverser BigTech Firmen, es nicht einzusetzen.
Bei Skype hatte man zwar 2012 auf Scrum migriert und war damit deutlich schneller, als beispielsweise Microsoft, der spätere Skype Eigentümer. Allerdings lief WhatsApp Skype trotzdem davon, und das obwohl (oder vielleicht gerade weil) das WhatsApp Team deutlich kleiner war?
Der Artikel selbst ist recht lang und ausführlich, deshalb hier eine Übersicht, wie einige der Big Tech Unternehmen aktuell implementieren:
Einige Highlights:
- Meistens leitet ein Engineer das Projekt, entweder jemand aus dem Team oder ein dedizierter Tech Lead
- Teams können die Projekt Management Methode frei wählen
- Es gibt keine dedizierten Projekt Manager für Projekte auf Team Ebene – nur übergreifende Technical Program Managers – bei Uber mit einer 1:50 Rate im Vergleich zu den Engineers
In many cases, Product Managers do not own project management at Big Tech. The team is responsible for the execution, and the team lead – usually the Engineering Manager – is responsible for making this happen.
Gergerly fasst dann Scrum in seinen Worten zusammen und beschreibt eine mögliche Zukunft des Frameworks.
Unter „How Should You Run Teams?“ fasst er seine Empfehlungen zusammen.
Einige davon finde ich recht interessant:
- Iterative changes always work better than ‘big bang’ ones – das kennen wir schon
- It’s more work to teach someone to fish, than it is to catch a fish for them. – der initiale Aufwand für Ausbildung und KnowHow Transfer kann sich mittelfristig ordentlich auszahlen
- Optimizing for reporting is optimizing for a low-trust environment – I look at you Controlling / JIRA Reporting 😉
- The fewer people you need to make decisions, the faster you can make them. – Oh ja, Vertrauen zahlt sich immer aus!
Gebt mir gerne Feedback, wie das bei euch läuft, ich fand den Artikel zwar lang, aber sehr interessant.
How Big Tech Runs Tech Projects and the Curious Absence of Scrum
Shape Up: Softwareentwicklung bei Basecamp/Hey
Die Macher von Basecamp nutzen „Shape Up“ als Softwareentwicklungsprozess:
Shape Up is for product development teams who struggle to ship. If you’ve thought to yourself “Why can’t we ship like we used to?” or “I never have enough time to think about strategy,” then this book can help.
Das Buch zur Methode Shape Up könnt ihr öffentlich lesen, als PDF runterladen oder hier auf Papier kaufen.
Wem das wie mir selbst erstmal zu viel Aufwand ist, dem sei der verlinkte Blog Artikel im Basecamp Blog empfohlen. Am Beispiel einer „Snooze“ Funktion namens „Bubble UP“ für die E-Mail SaaS Software HEY erklärt die Product Designerin Michelle den Entwicklungsprozess. Die Implementierung erfolgt in einem 6 wöchigen Prozess, der sehr transparent stattfindet und Feedback von diversen Stakeholdern. Am Ende der 6 Wochen Implementierung gibt es 2 „Cooldown Weeks“, in denen das Deployment erfolgt, Zeit für Bug Fixing und Support reserviert wird. Im Falle von Basecamp können Features „live“ deployed werden, sind aber nur für Mitarbeiter sichtbar und nutzbar – auch eine interessante Idee.
Am Ende der ersten Cooldown Woche wird der Launch Plan erstellt und in der folgenden Woche erfolgt das Deployment. Das Team erstellt einen Blog Beitrag und schaut sich das Feedback auf Twitter und anderen Kanälen an. Feedback wird dann intern zusammengefasst und für weitere Iterationen verwendet.
HEY Bubble Up: From kickoff to launch
Apple M1 Instanzen bei Amazon AWS EC2
Seit dieser Woche gibt es bei AWS Apple M1EC2 Instanzen. Amazon beschreibt die Instanzen wie folgt:
EC2 Mac instances are dedicated Mac mini computers attached through Thunderbolt to the AWS Nitro System, which lets the Mac mini appear and behave like another EC2 instance.
Entwickler können ihre Apps nun also in der Cloud „nativ“ bauen und benötigen hierfür nicht mehr einen Mac unter dem Schreibtisch. Corey Quinn hat seine Gedanken zum Launch auf Twitter in einem Thread zusammengefasst.
Man benötigt wohl reservierte Instanzen und bezahlt diese dann auch für mindestens 24 Stunden – Gründe sind wohl die Lizenzabrechnung mit Apple. Schön sei an der Lösung, dass sie eben im VPC lebt und beispielsweise auf Daten des Secret Managers zugreifen kann. Wie Mac Minis im Rack aussehen, könnt ihr in diesem Screenshot anschauen – das ist aus dem DataCenter von MacStadium, einem dedizierten „Mac in der Cloud“ Anbieter.
New – Amazon EC2 M1 Mac Instances
Fly.io: Migration der Logs von Graylog nach Elasticsearch
Über Fly.io hatte ich euch schon berichtet. In einem aktuellen Blog Eintrag beschreiben die Entwickler die Migration ihres Logging Stacks von Graylog nach Elasticsearch. Kenner werden jetzt fragen – warum? Graylog nutzt doch auch Elasticsearch?
Graylog ist eine zentrale Lösung, welche nicht nur Logs verwaltet, sondern über Pipelines die Anreicherung und Vorverarbeitung von Log Dateien ermöglicht. Hierbei sind nicht nur einfache Timestamp Änderungen möglich, sondern sehr viele verschiedene Funktionen.
Genau der zentralistische Ansatz wird bei hoher Logging Workload zum Problem. Fly.io berichtet bis zu 30.000 Logs pro Sekunde, welche von der zentralen Graylog Instanz verarbeitet werden müssen. Wir selbst haben eine Instanz betrieben, die über 50.000 Logs pro Sekunde verarbeitet hat. Der Aufwand, ein solches System zentralistisch zu betreiben, ist doch enorm – und man muss ständig optimieren und seine Log Quellen im Griff haben.
Fly.io hat sich deshalb entschieden, die aufwändige Vorverarbeitung der Logs (ETL) auf die Clients auszulagern. Diese haben genug CPU und können den Job verteilt erledigen. Früher verwendete man logstash für die Vorverarbeitung von Elasticsearch und anderen Log Senken. Fly.io hat sich für Vector entschieden. Vector ist eine Open-Source Lösung von DataDog, welche DataDog im letzten Jahr zugekauft hat.
Vector läuft hierbei als Agent/Sidecar, verarbeitet Logs, Metriken und andere Daten und kann diese Daten wiederum an verschiedene Backends bereitstellen, beispielsweise an Elasticsearch, S3 und DataDog.
Insgesamt hat die Migration wohl nur um die 2 Wochen gedauert – schön, wenn man sich auf eine Arbeit konzentrieren kann 🙂
Fly Behind the Scenes: Fresh Logging
ChatOps als Security Risiko
Im verlinkten Artikel bei lastweeekinaws.com schreibt Corey über die Risiken bei der Nutzung von ChatOps. Er schreibt dazu:
ChatOps is “the novel operational practice of expanding your security perimeter to anyone who has access to the right Slack channel or to Slack’s production infrastructure.”
Da ist etwas dran. Viele Firmen integrieren Slack tief in ihre Business und Operations Prozesse, per Webhook können Daten gepulled oder Automatisierungen ausgeführt werden. Monitoring checks und Sentry Alerts können über Integrationen auf Pause gestellt, Finanzielle Daten werden über Bots in Channels geschrieben und manchmal können Services geändert oder gelöscht werden.
In AWS Chatbot können sogar IAM Rollen verwaltet werden. Corey warnt vor allem von der fehlenden Transparenz innerhalb von Unternehmen, die Slack für Operations verwenden.
Wie läuft das bei euch? Gibt es eine Awareness für Möglichen Missbrauch von ChatOps?
The ChatOps Issue That No One’s Chatting About
Technische Schulden und On-Call
Im verlinkten Artikel bei „The New Stack“ findet sich ein interessanter Gedanke und gegensätzlicher Ansatz zum derzeit beliebten Betriebsmodell „You build it, you run it“. Bei PagerDuty, dem Sponsor des Artikel heisst dies Full-Service Ownership – die Details sind hier beschrieben. Der Gedanke lautet wie folgt:
Although developers know the code best, they aren’t as helpful in an incident. While ops teams want a service restored as quickly as possible, development teams want to root out the underlying issue.
Die Gefahr läge also darin, dass der Restore verzögert wird, um die Root-Cause zu finden. Die Autorin vergleicht ein Incident mit einem fehlgeschlagenen Bezahlvorgang an einer Supermarktkasse. Die Kreditkarte wurde abgelehnt, weil die Deckung für die $25 Dollar Rechnung nicht ausreichte. Das eigentliche Problem dahinter sind aber die $25.000 Dollar Schulden, die der Supermarktkunde hat. Die $25 Dollar bekommt er vielleicht kurzfristig woanders her, das Schuldenproblem kann er nicht ad-hoc lösen. Genauso verhalte es sich mit technischen Schulden.
Die Autorin schlägt deshalb vor, die On-Call zeit für die Behebung von „Langläufern“ und technischen Schulden zu nutzen. Arbeiten die Mitarbeiter ansonsten an Features und werden hierbei häufig aufgrund einer Eskalation unterbrochen, so stört dies die Arbeit und sorgt ggf. für neue Bugs und technische Schuld.
Natürlich muss man sich das leisten können, die Mitarbeiter hierfür abzustellen. Alternativ finde ich die Idee gut, zusätzlich zur On-Call Rotation eine „Bug Rotation“ einzuführen, in der Mitarbeiter dediziert an Bugs und technischen Schulden arbeiten.
Tech Debt, Incidents and On Call
OnlineOrNot: 1 Million Uptime Checks pro Woche mit fly.io
OnlineOrNot ist einer der unzähligen Uptime Monitoring SaaS Dienste (und hat nichts mit HotOrNot zu tun). Laut eigenen Angaben führt OnlineOrNot über 1 Mio Uptime Checks pro Woche durch. Diese Uptime Checks wurden in der Vergangenheit mit Hilfe von AWS Lambda und SQS ausgeführt.
Der Entwickler Max Rozen hat diese nun auf fly.io migriert und im verlinkten Blog Eintrag die Migration, Vorteile und die Benefits beschrieben. Eine der Nachteile von Lambda bei der Ausführung sind beispielsweise Timeouts auf Kundenseite – hängt beispielsweise eine Page oder ist „langsam“, so berechnet AWS die vollen 10 Sekunden „Arbeitszeit“ – unschön.
Neben Lambda hat Max auch SQS auf eine Redis VM migriert. Führ ihn ist der Vorteil auch, dass er gut vorhersagen kann, welche Kosten im Monat für seinen Service anfallen. Hat er aufgrund eines viralen Postings exorbitant viele Trial User, so schlug sich das direkt auf seine AWS Kosten durch – nun ist dies nicht mehr der Fall.
Dieser Fall zeigt mal wieder, dass Serverless bei planbaren Workloads Nachteile bei Kosten hat. Natürlich muss man sich um viele Dinge auch nicht kümmern, irgendwann überschreitet man aber den Schwellwert und hat mit klassischen Maschinen deutliche Kostenvorteile.
On moving over a million uptime checks per week onto fly.io
Prometheus Tutorial für den Einstieg
Ein populäres Community Tutorial wurde von Prometheus nun upstream gemerged. Es erklärt grundsätzlich die Funktionalität von Prometheus, verschiedene Metrik Typen, die Implementierung von Metriken in Go, die Visualisierung in Grafana und das Alerting auf Basis von Metriken.
Hierbei wird in kurzen Youtube Videos die funktionsweise erklärt – für den Prometheus Einstieg eine tolle Sache.
Getting Started with Prometheus
Linux, DevOps, Kubernetes und Grafana Workshops
Hier noch ein paar interessante Remote Workshops, bzw. Webinare, die euch vielleicht interessieren.
Bei Kubesimplify startet demnächst eine Workshop Reihe. Los geht es schon in der nächsten Woche, unter anderem mit den folgenden Themen:
Von GrafanaLabs gibt es nächste Woche ein deutsches Webinar zum Thema Lasttests mit Grafana und k6. Sucht ihr ein modernes Tool für Lasttests? dann schaut euch gerne das Webinar zu k6 an – es gibt eine Cloud und Open-Source Variante, die Integration mit Grafana ist sicherlich interessant.
Schmunzelecke
- Was man in der Cloud nicht machen kann? Bier kühlen
- „He was a good tool to download other Browers“ Nach 27 Jahren ist der Internet Explorer Geschichte und erhält in Süd Korea einen Grabstein.
💡 Link Tipps aus der Open Source Welt
Viddy: modernes „watch“
Viddy ist eine Re-implmentierung des CLI Commands watch. Viddy kann hierbei alle Features von Watch, nimmt automatisch Time-Snapshots des Watch commands auf, so dass man in die Vergangenheit blättern kann. Dazu gibt es eine Suche, Keymaps und eine farbige Darstellung für mehr Übersicht.
Schaut euch einfach mal die Demo an.
https://github.com/sachaos/viddy
Awesome Hetzner Cloud Repo
Das Repo awesome-hcloud ist ein weiteres, kuratiertes „awesome“ Repo, welches Tools, Integrationen und Tutorials für die Hetzner Cloud zusammenfasst. Beispielsweise gibt es darin folgende Repos:
- CLI tool für Kubernetes Cluster auf Hetzner: hetzner-kube
- Prometheus Exporter für Hetzner Kosten: hcloud-pricing-exporter
- CLI tool für automatisches Rescaling: hetzner-rescaler
- Prometheus Load Balancer Ressourcen: hetzner-load-balancer-prometheus-exporter
Ziemlich interessant, was sich hier alles findet und verlinkt ist.
https://github.com/hetznercloud/awesome-hcloud
pamspy – eBPF credentials Dumper
pamspy nutzt eBPF Filter um sich an die PAM Bibliotheken zu hängen. pamspy kann somit von pam genutzte Autorisierungen ausspähen, falls ihr mal das Passwort vergessen habt, oder so. Nutzen könnt ihr das dann beispielsweise in Verbindung mit sshd, sudo, passwd, gnome, X11 und allem was eben PAM nutzt.
https://github.com/citronneur/pamspy
❓ 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: