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:
Für die Einführung von AWS wurde noch niemand gefeuert.
Geschichte wiederholt sich. In den 70er und 80er Jahren gab es das Mantra „nobody ever got fired for buying IBM“.
Dies wiederholte sich, vor allem im DACH Markt, mit „für die Einführung von SAP wurde noch niemand gefeuert“.
Beides hatte sich so als Standard etabliert, dass niemand am Sinn und den nötigen finanziellen Aufwänden zweifelte.
Aktuell scheint sich die Geschichte mit AWS zu wiederholen.
AWS hat sich so als Standard etabliert, dass es häufig keine Zweifel daran gibt, Applikationen oder ganze Datacenter nach AWS zu migrieren. AWS hat sich als das „Typo3 der Infrastruktur“ etabliert – Firmen können auf eine Vielzahl externer Dienstleister, Zertifizierungen und Services zurückgreifen.
Im verlinkten Blog Artikel vergleicht Wille Faler die Kosten für das Hosting einer E-Commerce Applikation auf AWS (mit Serverless und PaaS Komponenten wie Datenbanken) mit den Kosten in einem Hetzner / Cloudflare Setup.
Bei AWS sind die Kosten je nach Setup um Faktor 6 bis 9,7 höher, als im Hetzner Setup.
Natürlich muss man aufpassen, dass man hier nicht Äpfel mit Birnen vergleicht – ein Managed Service kann Geld sparen – birgt aber auch diverse Nachteile. Und ab einer gewissen Größe sind PaaS Dienste einfach nicht mehr rentabel. Zusätzlich darf man nicht vergessen, dass man trotzdem jemanden benötigt, der „langsame DB Queries“ identifiziert – der Cloud Provider hat daran ja kein Interesse – er schickt einfach eine CPU Warnung und die Empfehlung, die Datenbank Instanz zu vergrößern – oder skaliert die Instanz einfach direkt.
Ein großer Kostentreiber bei AWS (und anderen großen Anbietern) sind Traffic Kosten – diese sind einfach unverschämt teuer und schwer vorherzusehen. Es gibt zahlreichere, andere Anbieter mit einfacherem Traffic Kosten Modell – häufig lohnt sich hierbei der Vergleich.
Bei Der Nutzung von Serverless Diensten ist ebenfalls Vorsicht geboten, Wille hierzu:
While AWS Serverless brings many benefits, I suspect its main strategic purpose for Amazon is to lock in cloud customers into their eco-system. Once you are on Serverless, it’s difficult to get out, unless you took proactive precautions (which is possible!).
Hier verfolgen die 3 großen Cloud Provider ebenfalls eine ähnliche Strategie, AWS ist hier keine Ausnahme.
Was wird die Zukunft bringen?
Wille hat hierzu eine Vision:
The most likely scenario is where Open Source catches up. It becomes trivial to deploy your own PaaS with a few open source components. Yes, it will run on servers (just as Serverless!), but it will be self-healing and mostly self-managing, to the extent the lines to cloud provider Serverless offerings will be blurred.
Das wäre natürlich super, gibt es doch mehr und mehr Funding für Firmen mit einem Open Source Geschäftsmodell.
Nobody ever got fired for buying AWS
Die Verbreitung von Cloud steht noch am Anfang
Konträr zu den oben genannten Warnungen bezüglich AWS Kosten ist eines trotzdem sicher: Die Implementierung von Software in der Cloud, oder Cloud ähnlichen Strukturen steht noch am Anfang und weiter zunehmen.
Im Earnings Call zu den beachtlichen Q2/2022 AWS Zahlen erläuterte der Amazon CFO Brian Olsavsky, warum eine Rezession einen positiven Effekt auf das AWS Wachstum haben könnte:
..“because, again, when you’re trying to launch a new product or service and you have to face building your own data center and getting capital for a data center and building it yourself or moving to the cloud and essentially buying incremental infrastructure capacity, cloud computing really shows its value..“
Jetzt können sicherlich die wenigsten Firmen sich mal kurz ein Datacenter bauen, aber Cloud Kosten vereinfachen ein „Leasing“, die Umstellung von hohen initialen Investment Kosten auf inkrementelle und planbare Ausgaben doch sehr.
Natürlich ist dies für ein an der Börse notiertes Unternehmen ein großer Vorteil – mit den monatlichen Einnahmen kann man fest rechnen, ob man die gleiche Hardware/Lizenz in 2,3 Jahren erneut verkauft, ist ungewiss.
Dennoch hat sich bei allen 3 großen Cloud Providern das Wachstum verlangsamt:
- AWS um 33% gegenüber dem vorherigen Quartal (zuvor 37%)
- Azure wuchs um 40% (zuvor 46%)
- Google wächst um 36% (zuvor 44%)
Der Marktanteil des aktuell $200 Millionen Dollar großen Cloud Markts verteilt sich daher auf:
- AWS mit 34%
- Azure mit 21%
- Google mit 10%
- Alibaba Cloud 5%
- IBM Cloud mit 4%
Quelle: twitter.com/@pip_net (Statista)
Cloud spending can’t stop, won’t stop
Einfacher Stack auf einem großen Server
Nach den „Cloud Gedanken“ oben setze ich jetzt noch einen drauf 😉
Für ziemliches Aufsehen auf HackerNews sorgte vergangene Woche der verlinkte Blog-Artikel „one Big Server“.
Um was geht es?
A lot of ink is spent on the “monoliths vs. microservices” debate, but the real issue behind this debate is about whether distributed system architecture is worth the developer time and cost overheads
Wieviel Overhead bezahlen wir für Cloud und Co.?
Der Author vergleicht die Kosten für ein größeres Stück Hardware mit selbigen Kosten in der Cloud (sind schwierig zu berechnen, siehe oben). Hierfür gibt es ein paar öffentliche Besipiele:
- 1 million IOPS on a NoSQL database
- 70k IOPS in PostgreSQL
- 500k requests per second to nginx
- Compiling the linux kernel in 20 seconds
Natürlich macht es aus diversen Themen keinen Sinn, solche Hardware zu kaufen, auch wenn der Autor die Kosten dafür beispielhaft anführt. Auch ist ein Server nicht gerade für seine Hochverfügbarkeit bekannt, auch hierfür gibt es Lösungen und bei Cloud Providern in der zweiten Reihe ebenfalls sehr gute Angebote in mehreren AZs und Regionen.
Interessant finde ich die Kostenberechnung zu Serverless/AWS Lambda – im Beispiel wird aufgeführt, dass Serverless ungefähr 5,5 mal so teuer ist, wie ein Server selbst – je nach Auslastung. Ist der Server im Schnitt über 20% ausgelastet, so ist ein Server – selbst im Modell „on-demand“ – immer günstiger. 20% Auslastung ist jetzt nicht wirklich viel, oder?
Nima räumt mit den üblichen Vorurteilen gegenüber „Servern vs. Cloud“ auf, beispielsweise, dass man ja keinen Sysadmins mehr brauche, sich nicht um Security Updates kümmern muss, und dass die Cloud ja immer „up“ sei.
Jedenfalls macht es immer Sinn, beide Seiten zu beleuchten. Cloud und Serverless sind grundsätzlich erstmal super für den Schnellstart. Wenn eine App keine große Last hat, dann sind die Kosten häufig „free“ oder die „PDF Rechnung“ nicht wert.
Sobald die Applikation aber Last bekommt, sollte man die Architektur überdenken, damit man nicht von „Skalierungs-Kosten“ überrascht wird.
Oder andersrum: Cloud Architekturen sind nie fertig und ständig in Bewegung.
Danke Michi für den Link.
Remote, Hybrid oder Persönlich?
Das Thema „Future of Work“ interessiert aktuell viele Firmen und deren Mitarbeitende.
Nachdem in der letzten Woche schon Ben Horowitz (Mitgründer des VCs Andreessen Horowitz) angekündigt hatte, die Firma in Zukunft „hybrid“ zu betreiben, ist das Thema „Remote & Hybrid“ nun auch Thema im Blog von Fred Wilson.
Ben Horowitz schrieb dazu:
It’s not perfect, but mitigating the cultural issues associated with remote work turns out to be easier than mitigating the employee satisfaction issues associated with forcing everyone into the office 5 days/week.
Fred sieht dies genauso, gerade für konzentriertes Arbeiten sei ein „ruhiges Home Office“ in der Regel besser als der Trubel im „Open Space“ Büro. Fred selbst sieht als Einwohner von New York City aber den größten Vorteil in der steigenden Zufriedenheit aufgrund dem Wegfall der Pendelei – Na gut, mit einer einfachen Büro-Anreise Dauer von einer Stunde kann ich das gut nachvollziehen.
Das größte Problem sieht er wie Ben auch bei „Cultural Issues“ mit dem Wegfall der persönlichen Kommunikation. Es gäbe Wege, dem effektiv entgegenzutreten – beispielsweise mit „festen Tagen mit Mehrwert“ im Büro, beispielsweise einer „CEO Hour“, „after work“ Events oder gemeinsame Sport Aktivitäten.
Führungskräfte, Teams und auch Mitarbeitende sollten zusätzliche Möglichkeiten haben, sich regelmäßig und unabhängig vom Büro zu sehen. Gut, das mag in einem VC, welcher 130 Portfolio Firmen hat, sowieso mit Reise Tätigkeiten verbunden sein.
Persönlich finde ich, dass hiervon auch alle anderen Firmen lernen können, beispielsweise mit regelmäßigen Company oder Team Retreats – wie das funktionieren kann, beschreibt Buffer in einem Blog Artikel bei Surfoffice.
GitLab: Reduzierung der On-Call Alarmierungen
Im GitLab Blog finden sich häufiger spannende Beiträge zu den Themen SLI/SLO. In einem aktuellen Artikel beschreibt man die Probleme, die mit einem „System-weiten GitLab.com“ Ausfall auftreten – die On-Call Pager stehen nicht mehr still und nerven die Mitarbeiter. Dies verursacht Streß und trägt nicht wirklich zu einer schnellen und konzentrierten Behebung der Probleme bei.
Sind 50+ Services betroffen und damit mindestens so viele SLIs gestört, so bekommt man eben auch 50+ Alerts.
Erste Abhilfe brachte die Gruppierung von Services im Alertmanager, welcher für die Notifizierung bei GitLab übernimmt.
Die endgültige Verbesserung brachte allerdings die korrekte Abbildung von Service Abhängigkeiten, die eine Alarmierung von voneinander abhängigen Systemen verhindern (Beispiel: Ist die DB Down, muss man nicht alle abhängigen Services eskalieren).
Ein Teil der Diskussion ist bei GitLab im Runbooks Projekt öffentlich, so dass jeder von den Erfahrungen profitiert.
How we improved on-call life by reducing pager noise
Stolpersteine bei Post-Mortems
In diesem kurzen, aber interessanten Artikel geht das Incident.io Team auf Stolpersteine bei der Erstellung von Post-Mortems ein.
Beispielsweise sei es bei kleineren Incidents überhaupt nicht nötig, eine exakte Zeitfolge eines Incidents abzubilden – viel mehr sei wichtig, ob man was daraus gelernt hat – falls ja, was? Wie kann man es in Zukunft verhindern? Gab es einen ähnlichen Incident zuvor schon einmal?
Manchmal sei ein Post-Mortem auch überflüssig und die investierte Zeit nicht wert. Und nur, weil ein Post-Mortem Template gewisse Felder erwartet, so sollen diese auch nur beffüllt werden, wenn dies sinnvoll ist (Note-no-self!).
Post-Mortems sind zwar häufig als „Blameless“ tituliert, trotzdem müsse man immer aufpassen, dass man nicht in „Was wäre wen“ Diskussionen abdriftet.
3 common pitfalls of post-mortems
Solana Hack war doch kein Hack!
In den letzten Wochen verloren über 10.000 Wallet Inhaber der Crytpo Coins Solana ihr Wallet. In Summe ist der Schaden über 10 Millionen. Anfangs wurden vermutet, dass die Crypto Währung selbst ein Problem haben könnte.
Sicherheitsforscher von Slope haben nun das Problem analysiert und herausgefunden, dass der Wallet Anbieter „Slope“ die zu den User gehörenden Mnemonics (Password Merk-Hilfen) im Klartext gespeichert und an eine Sentry Instanz übermittelt hat.
Ein Angreifer habe scheinbar zugriff auf diese Logging-Daten erhalten und konnte sich über den Recovery Mechanismus in die Wallets einloggen und das Geld abziehen – so die aktuelle Vermutung.
Ob die Sentry Instanz eine SaaS Instanz oder eine self-hosted Instanz war, ist unklar. Jedenfalls kann man Sentry auch durch 2FA schützen – oder besser – man übermittelt sicherheitsrelevante Daten gar nicht, oder Deaktiviert die Übertragung solcher Daten schon in den Sentry SDKs oder entfernt die Daten spätestens, wenn sie fälschlicherweise nach Sentry transferiert wurden (Advanced Data Scrubbing).
Spätestens jetzt sollte jeder von euch schauen, ob er/sie Tokens, „Passwort Vergessen“ Hilfen oder gar Passwörter in seinem Debugging/Logging Dienst verarbeitet.
Twitter Thread: How thousands of Slope wallets were hacked and how other wallets can avoid this
Log4j Attacken noch immer aktiv
Selbst ein halbes Jahr nach dem Bekanntwerden von CVE-2021-44228, der Log4j Lücke im November 2021, wird die Lücke noch immer aktiv angegriffen und ausgenutzt.
Der WordPress Firewall Anbieter Wordfence sieht noch immer über 100.000 Attacken am Tag.
Die meisten Attacken kommen au sden Netzten von CDNext, DigitalOcean, Amazon und Microsoft – und kommen aus den USA, Belgien und der Schweiz.
Analyzing Attack Data and Trends Targeting Log4J
Asahi Linux – Linux für Apple M2
Asahi Linux ist ein Linux für Apple Silicon, welches mit dem Juli Release nun auch Apple M2 supported.
Mir war bis dahin unbekannt, dass es sowas überhaupt gibt, hat dies jemand von euch schon mal ausprobiert?
M2 is here! July 2022 Release & Progress Report
Schmunzelecke
- And then you have your first Kubernetes Deployment – Twitter @rothgar
- Paying 50k for a Pentest vs. Paying 500k Ransom – da ist was Wahres dran – Twitter @LitMoose
💡 Link Tipps aus der Open Source Welt
Hacker-News Slack Bot
Darauf hat die Welt lange gewartet, es gibt nun einen Hacker News Bot, welcher euch in Slack informiert, sobald eure Marke, Produkt oder sonstige Keywords erwähnt werden.
Das Ganze ist auch ein Showcase für Vercel und Vercel Function und vielleicht auch daher interessant für euch.
Funktionsweise und Announcement hier auf Twitter, wie man das Ganze für sich selber einsetzt hier als Tutorial.
https://github.com/vercel-labs/hacker-news-slack-bot
Baserow: Open Source Airtable Alternative
Baserow ist eine no-code Datenbank und Open Source Alternative zu Airtable. Mit Baserow könnt ihr einfach und ohne technische Expertise Datenbanken erstellen, mit Formularen befüllen und an 3rd Party Tools anbinden.
Wie häufig gibt es eine SaaS Variante und seine self-hosted Variante, die mit Docker & Docker-Compose betrieben werden kann.
https://gitlab.com/bramw/baserow
Open source SAML SSO mit SAML Jackson
Neben dem coolen Produktnamen „SAML Jackson“ ist auch das Produkt selbst ein Highlight.
Kürzlich von BoxyHQ auf Product Hunt angekündigt, gibt es das Open Source Projekt „SAML Jackson“ dazu schon länger.
Hiermit könnt ihr einfach „Enterprise Grade“ SAML single sign-on Authentifizierung in euer Produkt einbauen.
❓ 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: