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:
Was können wir von der Facebook Downtime lernen?
Bei Venturebeat gibt es einen interessanten Artikel zur Facebook Downtime vom 4. Oktober 2021.
Technology breaks, people make mistakes, stuff happens.
The right question for every company has always been and remains not whether an outage could occur — of course it could — but what can be done to reduce the risk, duration, and impact.
Soweit die Zusammenfassung, und die kann denke ich, jeder unterschreiben. 100% Uptime ist ein nicht existierender Mythos.
1) Acknowledge human error as a given and aim to compensate for it
Auch hier kann ich nur zustimmen. In einer meiner früheren Firmen hieß es „Fehler gehören dazu“. Arbeiten Tausende Mitarbeiter an der Verbesserung diverser Systeme, schaffen Innovationen und Verbesserungen, so geschieht das nicht ohne Bugs und Fehler.
Die einzige Möglichkeit, keine Fehler zu machen, ist einfach nichts zu tun – auf Dauer ist das dann auch geschäftsgefährdend.
2) Conduct blameless post-mortems
Ein blameless Post-Mortem sollte auch wirklich blameless sein. Alles, was schief gelaufen ist, muss auf den Tisch, diskutiert und erfasst werden. Gemeinsam sollte man dann Wege zur Vermeidung finden und eine Roadmap feststellen: Atlassian hat ein Tutorial für blameless port-motems, welches einen guten Start darstellt.
Wichtig ist auch, nicht noch einen Workaround zu bauen sondern Probleme bei der Wurzel anzupacken.
3) Avoid the “deadly embrace”
Tja, wenn DNS bei Facebook nicht mehr geht, dann geht eigentlich nichts mehr, haben wir aus der Presse gelernt.
Man sollte also vermeiden, Systeme zu bauen, die komplett voneinander gegenseitig abhängig sind.
Und man sollte die Abhängigkeiten seiner Systeme kennen – alleine darin scheitert es häufig schon.
Welchen Traffic Flow hat ein Kunden Request von der Eingabe einer Website bis zur Order in meinem ERP System?
Wie kann ich mich einwählen, wenn DNS Down ist, so dass ich keine Flex benötige, um in mein eigenes Datacenter einzubrechen?
4) Favor decentralized IT architectures
Das Facebook Netzwerk ist scheinbar stark zentralisiert. Die Downtime hat neben Facebook auch Instagram, WhatsApp und sämtliche externen Scripte in Mitleidenschaft gezogen. Nicht mal die Facebook Statusseite war öffentlich erreichbar.
Ziemlich blöd, wenn man dies dann über Twitter mitteilen muss.
Auf der anderen Seite kann ich verstehen, dass man solche Systeme baut. In einer Größenordnung wie Facebook macht es einfach keinen Sinn, BGP, Firewalls, Router und co. separat pro Marke/Produkt zu betreiben.
Abschließend bin ich gespannt, ob es noch weitere, öffentliche Learnings von Facebook zum Vorfall geben wird.
Und die Moral von der Geschicht‘ ? Richtig – „100% Uptime – gibt es nicht“.
Four lessons every company should learn from the back-to-back Facebook outages
Hausdurchsuchung nach Disclosure: Modern Solution
Ein Programmier deckte eine schwerwiegende, ja gar dilettantische Sicherheitslücke in einer Marktplatz Software auf (siehe golem für Details). 3 Monate nach der Meldung an den Betreiber gab es nun anstatt eines Dankeschöns – eine Hausdurchsuchung der Polizei. Sämtliche Arbeitsgeräte wurden beschlagnahmt.
Im Logbuch Netzpolitik Podcast #409 gehen Linus Neumann und Tim Pritlove näher auf die Details ein (Kapitel 11, ca. 23 Minuten).
Scheinbar hatte die App direkt mit MySQL Connections mit einer Server Komponente interagiert. Das sowas überhaupt mal vorkam, ist ja schon selten, dass es im Jahre 2021 noch passiert, ist schon sehr abenteuerlich.
Wer keine Lust auf den Podcast hat, der kann im Blog von Mark Steier Details zum Leak bei Modern Solution einsehen, inkl. Screenshots der MySQL Datenbanken.
Wenn Firmen von Programmier oder Hackern auf Sicherheitslücken aufmerksam gemacht werden, dann sollten Sie diese immer ernst nehmen. Das ist nicht so einfach, häufig bekommt man auch unspezifische Meldungen, die einiges an Aufwand erfordern – trotzdem sollte man jede Meldung für sich betrachten und Ressourcen bereitstellen.
golem.de: Hausdurchsuchung statt Dankeschön
Historie des Domain Erwerbs von HEY.com
Unter HEY.com erreicht man seit Juni 2020 den neusten Service der Basecamp Macher: E-Mail neu gedacht.
Jason Fried, einer der beiden Gründer, beschreibt in einem Blog Eintrag nun ausführlich die Vorgänge hinter der Aquise der Domain Hey.com. Domains mit 3 Buchstaben sind schwer zu bekommen, vor allem, wenn der Besitzer schon ein erfolgreiches Business damit aufgebaut hat.
Jason wollte die Domain aber unbedingt haben, da er festgestellt hatte, dass er 95% seiner Mails mit „Hey there,“ oder „Hey Andy, “ begonnen hatte. Die Aquise zog sich über mehrere Jahre, 60+ Mails und diverse Zoom Calls. Den genauen Preis nennt Jason alledings nicht.
Die ganze Geschichte und Herangehensweise erinnert mich an die Aquise von buffer.com durch die Social Media Sharing App Buffer, die vormals unter bufferapp.com erreichbar. Analysen zur Folge bezahlte Buffer damals $600.000 für buffer.com.
Na, welche Domains schlummern noch in eurem Account?
Die Top 10 GitLab Hacks
Michael Friedrich ist Senior Developer Evangelist bei GitLab. Im GitLab Blog listet er nun seine Top-10 GitLab Hacks auf.
Dazu gehören unter anderem:
- Quick Actions in Tickets/Issues und Keyboard Shortcuts
- Description templates für Issues und Merge Requests helfen bei der Standardisierung von Tickets
- Terraform Integration innerhalb von GitLab
- Prometheus integration in GitLab
- MWPS – „Merge When Pipeline Succeeds“ ist ein Automatismus, der euren Code automatisch merged, wenn die Pipeline erfolgreich ist.
Im verlinkten Artikel findet ihr noch weitere, interessante Tips zu GitLab und dessen Verwendung.
Persönlich spannend finde ich, dass man GitLab mittlerweile als Sentry Backend verwenden kann – und somit keine Sentry-Cloud/self-hosted Umgebung mehr benötigt. Zumindest für kleinere Projekte sollte dies mehr als ausreichend sein.
Noch gibt es ein paar Limitierungen mit diversen Sprachen, aber diese werden sicherlich noch gefixed.
Top ten GitLab hacks for all stages of the DevOps Platform
Multi Cloud Failover ist Unsinn
Lydia Leong schreibt in ihrem Blog CloudPundit und auf Twitter regelmäßig News und Artikel zu Cloud Computing.
In zwei Beiträgen geht Sie nun genauer auf das Thema „Multi-Cloud“ ein, uns dass die Cloud eben nicht nur „der Server eines Anderen ist.„
Auch räumt sie mit dem Mythos Multi-Cloud Failover auf. Im Management denke man sich häufig, dass man Applikationen und Workloads auf einfache Weise zwischen Cloud Providern shiften kann. Das ist vielleicht wahr für Workload innerhalb Kubernetes, oder OpenShift – die großen Provider unterscheiden sich aber fundamental in grundlegenden Dingen, wie Netzwerke, Loadbalancern, Firewall und VPN Konfigurationen und anderen Basisdiensten.
Eine Portabilität zwischen Cloud Providern herzustellen ist daher meist vergeudete Liebesmühe und stiehlt den Entwicklern und DevOps wertvolle Zeit, um Applikationen weiterzuentwickeln und Mehrwerte für Endkunden zu schaffen.
Die Facebook Downtime zeigte jedoch, dass auch Zentral-Komponenten ausfallen können – bei Cloud Providern unterscheidet sich das Netzdesign hierin der Regel – und die Regionen sollten komplett autark sein, um eine Facebook ähnliche Downtime zu verhindern.
Multicloud failover is almost always a terrible idea
Site Reliability Einblick bei Google
Bei The Newstack gibt es einen weiteren Einblick in den SRE Prozess bei Google. Das SRE Team bei Google ist laut Artikel um die 3000 Mitarbeiter groß und folgt einer Mission: „Reliability, velocity, maintainability and efficiency“.
Responsibility for having a reliable service is not off-loaded onto the SRE or thrown over the fence. SRE’s job is to help the dev team meet their reliability and velocity goals and to meet the needs of our users first and foremost
Bei Google ist allerdings nicht das SRE Team für die Verfügbarkeit und Performance von Applikationen verantwortlich – das sind weiterhin die Produktteams selbst. Das SRE Team übernimmt also nicht PagerDuty für die Teams, sondern unterstützt, wo Hilfe benötigt wird.
SRE is not to be the ops team. Our mission is not to handle operations, but to improve inherent reliability of systems through engineering .
Die SRE Teams helfen also durch ihre Erfahrung, durch ihre Community innerhalb der Organisation oder durch Weitergabe von „Production knowledge“ und Wissenstransfer.
In der Praxis können die Dev Teams die Unterstützung durch die SRE Teams anfordern, beide Teams müssen zustimmen und beide Teams können das Engagement wieder beenden. Es gibt 3 verschiedene Ausprägungen von SRE Support: Baseline, Assisted Engagement und Full Support.
Grundsätzlich mache es aber Sinn, früh im Entwicklungsprozess zu unterstützten, denn im „Design Stage“ treffe man bereits Entscheidungen (Architektur, Technology), die man „in Production“ kaum mehr ändern kann.
Google SRE: Site Reliability Engineering at a Global Scale
Hintergründe zu Netflix‘ „Billion Dollar Code“
Die deutsche Netflix Miniserie „The Billion Dollar Code“ ist aktuell in aller Munde. Dass sie auf wahren Begebenheiten beruht, ist vielen mittlerweile klar. Wie genau sich die Geschichte von Terravision um die Berliner Designagentur Art + Com abgespielt hat, welche einen Google Earth ähnlichen Algorithmus entwickelt hat und sich später mit Google vor Gericht darüber stritt, darüber klärt der verlinkte Artikel bei Gründerszene auf.
Wer im Detail an der Entstehungsgeschichte interessiert ist, dem kann ich die Folge 222 des CRE Podcasts von Tim Pritlove empfehlen. Tim interviewt hier Pavel Mayer, einer der 4 Entwickler von Terravision. In über 3,5 Stunden unterhalten die beiden sich über sämtliche Details zu Terravision, dem User Interface „Earth Tracker“ und der folgenden Auseinandersetzung mit Google.
Das ist die echte Firma hinter Netflix‘ „Billion Dollar Code“
roadmap.sh – Leitfaden für Engineer & Developer Ausbildung
Roadmap.sh ist ein Community Bildungs-Projekt für Entwickler und DevOps. Kamran Ahmed und über 50 andere Committer helfen im Open-Source Projekt zu den diversen Roadmaps mit. Folgende Roadmaps gibt es beispielsweise:
und mehr. Mittlerweile hat das Projekt auch einen eigenen YouTube Channel, mit kurzen Tutorial Videos zu „HTTP Caching“ oder auch „YAML„.
Schmunzelecke
Pokemon oder Programmiersprache – Recruiter verirren leicht gemacht – twitter.com/srslyberserk
💡 Link Tipps aus der Open Source Welt
Vigil – Microservice Status Page
Vigil ist eine Open Source Status Page für Microservices, kann aber auch anderweitig verwendet werden. Spätestens der Facebook Incident hat gezeigt, dass man eine Statuspage außerhalb seines normalen „Hosting Angebots“ haben sollte.
Früher populäre Open Source Systeme wie Cachet und statping sind leider nicht mehr aktiv, mit Vigil habt ihr eine schicke Alternative, welche beispielsweise hier bei crisp.chat im Einsatz ist.
Weitere Alternativen findet ihr hier bei GitHub.
https://github.com/valeriansaliou/vigil
Joplin – Open Source Notizen und Todo App
Joplin ist eine Open Source App für Notizen und Todos – quasi ein Evernote zum selber hosten. Screenshots und Features könnt ihr euch auf der Joplin Homepage anschauen. Neben dem Joplin Server gibt es Apps für iOS, Android, macOS, Windows, Linux und einen Web Clipper für Chrome und Firefox.
https://github.com/laurent22/joplin
Ansible Semaphore – Ansible UI
Seit der Übernahme durch RedHat wird die Open-Source Variante des „Ansible Tower“ immer weniger attraktiv. Mit Ansible Semaphore gibt seit längerem eine leichtgewichtige Alternative für die Steuerung und Überwachung eurer Ansible Playbooks. Neben UI bietet euch Semaphore eine minimale Benutzerverwaltung, Task Templates, Logs und Notifications für eure Ansible Umgebung an. Die Demo könnt ihr euch hier anschauen (Login: demo/demo).
https://github.com/ansible-semaphore/semaphore
❓ 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: