(Fast) alle Infrastrukturentscheidungen, die sich nach 4 Jahren Betrieb von Infrastruktur in einem Startup bewährt haben oder die ich bereue

 (cep.dev)
87 Punkte von xguru 2024-02-28 | 4 Kommentare | Auf WhatsApp teilen
  • Jede Entscheidung ist als Endorse (befürwortet) oder Regret (bereut) gekennzeichnet

Wahl von AWS

  • AWS statt Google Cloud: Ich befürworte die Entscheidung für AWS. AWS ist stark auf Kunden fokussiert. Bei Google Cloud fühlt es sich an, als würde man sich auf Roboter und Automatisierung verlassen.
  • EKS: Ich befürworte den Einsatz von EKS. EKS bietet eine tiefe Integration mit AWS-Services, und auch Kubernetes hat in vielerlei Hinsicht aufgeholt (z. B. Integration mit Route53 über externaldns).
  • EKS Managed Add-ons: Ich bereue den Einsatz von EKS Managed Add-ons. Es war nötig, die Installation anzupassen, und nach dem Wechsel zu Helm-Charts war der Betrieb deutlich besser.

Datenbanken und Caching

  • RDS: Ich befürworte den Einsatz von RDS. Daten sind der wichtigste Teil der Infrastruktur, und die Kosten für RDS sind es wert.
  • Redis ElastiCache: Ich befürworte den Einsatz von Redis. Redis ist sowohl als Cache als auch für allgemeine Zwecke sehr effektiv.
  • ECR: Ich befürworte den Umzug von quay.io zu ECR. ECR ist stabiler und die Rechteintegration ist deutlich tiefer.

Netzwerk und Support

  • AWS VPN: Ich befürworte den Einsatz von AWS VPN. Das VPN ist sehr einfach einzurichten und zu verstehen. Für die Verwaltung des VPN-Zugangs wird Okta verwendet, was eine sehr gute Erfahrung bietet.
  • AWS Premium Support: Ich bereue ihn. AWS Premium Support ist sehr teuer und lohnt sich nicht, wenn intern nicht gerade AWS-Wissen fehlt.
  • Control Tower Account Factory for Terraform: Ich befürworte die Integration von AFT. Sie automatisiert die Kontoerstellung und hilft bei der Standardisierung von Tags.

Prozessautomatisierung

  • Automatisierung von Postmortems mit einem Slack-Bot: Ich befürworte die Automatisierung des Postmortem-Prozesses. Sie hilft dabei, Menschen dazu zu bringen, Postmortems auch wirklich zu schreiben.
  • Verwendung von Incident-Templates in PagerDuty: Ich befürworte die Nutzung von Templates bei Incidents. Durch die Flexibilität von Notion ist auch etwas Anpassung möglich.
  • Regelmäßige Überprüfung von PagerDuty-Tickets: Ich befürworte die regelmäßige Überprüfung von Alarmkonfigurationen. So wird sichergestellt, dass auch weniger wichtige Alarme nicht ignoriert werden.
  • Postmortem-Verwaltung in Datadog oder PagerDuty: Ich bereue die Nutzung eines integrierten Verwaltungstools für Postmortems. Bei beiden ist es schwer, den Postmortem-Prozess anzupassen. Ich halte ein leistungsfähiges Tool wie Notion für die bessere Wahl.

Sonstiges

  • Monatliches Meeting zur Kostenverfolgung: Ich befürworte ein monatliches Meeting zur Überprüfung der SaaS-Kosten. So lässt sich prüfen, ob die Kosten angemessen sind und welche Maßnahmen nötig sind. In AWS werden Positionen nach Tags gruppiert und nach Konten getrennt. Die Empfehlung ist, nicht nur auf AWS zu schauen, sondern auf alle großen Ausgabenquellen des Unternehmens.
  • Nicht mehr FaaS genutzt: Ich bereue, FaaS nicht stärker genutzt zu haben. Für GPU-Workloads gab es keine FaaS-Optionen, daher war ein vollständiger Einsatz nicht möglich. Viele CPU-Workloads hätten aber mit FaaS umgesetzt werden können. Ein weiterer versteckter Vorteil von Lambda ist, dass sich Kosten sehr einfach und mit hoher Genauigkeit nachverfolgen lassen.
  • GitOps: Ich befürworte GitOps. Es wird für große Teile der Infrastruktur verwendet, und es wurde in Tooling investiert, das hilft, den Status von Deployments zu verstehen.
  • Team-Effizienz priorisieren: Ich befürworte, die Effizienz des Teams zu priorisieren. Ich habe nie bereut, Zeit in Automatisierung oder Dokumentation investiert zu haben.
  • Mehrere Anwendungen teilen sich eine Datenbank: Ich bereue, dass mehrere Anwendungen sich eine Datenbank teilen. Das hat zu verschiedenen Problemen geführt.

Einführung von SaaS

  • Identity-Plattform spät eingeführt: Früher wurden Berechtigungen über Google Workspace vergeben, aber ich bereue, nicht früher eine Identity-Lösung wie Okta eingeführt zu haben. Okta ist gut integriert und hilft bei Sicherheits- und Compliance-Fragen.
  • Notion: Ich befürworte Notion für Dokumentation. Notion war eine ausgezeichnete Wahl und deutlich einfacher zu nutzen als frühere Werkzeuge wie Wikis, Google Docs oder Confluence. Das Datenbankkonzept zur Organisation von Seiten ist nützlich.
  • Slack: Ich befürworte Slack. Es ist als zentrales Kommunikationstool effektiv.

Entwicklungstools und Services

  • Von JIRA zu Linear gewechselt: Ich befürworte Linear statt JIRA. JIRA ist meiner Meinung nach zu komplex und zu schwergewichtig.
  • Terraform Cloud nicht genutzt: Ich bereue nicht, Terraform Cloud nicht eingesetzt zu haben, weil sich die Kosten nicht rechtfertigen ließen. Stattdessen wurde zu Atlantis gewechselt und die nötige Automatisierung in die CI/CD-Pipeline eingebaut.
  • GitHub Actions für CI/CD: Ich befürworte GitHub Actions mehr oder weniger (Endorse-ish). Die Actions aus dem Marketplace und die Syntax sind einfach zu nutzen. Als Nachteil sehe ich die begrenzte Unterstützung für Self-hosted-Workflows.

Technologiewahl

  • Datadog: Ich bereue den Einsatz von Datadog. Es ist sehr teuer, und das Kostenmodell ist für Kubernetes-Cluster und ein AI-Unternehmen ungeeignet.
  • PagerDuty: Ich befürworte PagerDuty. Das Produkt ist gut und der Preis angemessen.
  • Schema-Migrationen per Diff: Ich befürworte den Einsatz eines Tools für Schema-Migrationen bis zu einem gewissen Grad. Daten sind wichtig, und Schema-Migrationen können riskant sein.
  • Ubuntu for dev servers: Ich befürworte Ubuntu für Entwicklungsserver. Es wird gut unterstützt und enthält die meisten benötigten Pakete.
  • AppSmith: Ich befürworte AppSmith für die Prozessautomatisierung für interne Engineers. Es wird selbst gehostet und ist ausreichend zufriedenstellend. Anfangs wurde retool genutzt, um tiefere Integrationen zu prüfen, aber der Preis ließ sich damals für nur einige wenige Integrationen nicht rechtfertigen.
  • helm: Ich befürworte Helm v3. Es gibt zwar Probleme bei der Bereitstellung von CRDs und bei der Schulung von Entwicklern, aber zum Paketieren und Ausrollen von Kubernetes-Objekten ist es gut genug.
  • helm charts in ECR (oci): Ich befürworte das Speichern von Helm-Charts in einem OCI-Repository. Im Vergleich zur früheren Methode mit S3 und Plugins gibt es weniger Probleme.
  • bazel: Bei bazel bin ich unsicher. Für das Deployment von Go-Services wirkt es überdimensioniert, und GitHub Actions ist für mehr Engineers leichter nutzbar.
  • OpenTelemetry nicht genutzt: Ich bereue, Metriken direkt über die DataDog-API gesendet zu haben. Ich empfehle, von Anfang an OpenTelemetry zu verwenden.
  • renovatebot statt dependencyabot gewählt: Ich bereue, nicht früher darüber nachgedacht zu haben, Abhängigkeiten aktuell zu halten. Renovatebot ist anpassbar, aber Konfiguration und Debugging sind komplex.
  • Kubernetes: Ich befürworte Kubernetes. Es wird eine Möglichkeit gebraucht, langlebige Services zu hosten, und Kubernetes ist populär und funktioniert gut.
  • Eigene IPs gekauft: Ich befürworte den Kauf eigener IP-Blöcke bei der Arbeit mit externen Partnern. Das hilft dabei, externen Partnern größere CIDR-Blöcke zum Whitelisting bereitzustellen.
  • Flux als GitOps-Tool für k8s gewählt: Ich bereue nicht, Flux als GitOps-Tool für Kubernetes gewählt zu haben. Es war nötig, Tooling zu entwickeln, das hilft, den Deployment-Status zu verstehen.
  • Karpenter for node management: Ich befürworte Karpenter bei der Nutzung von EKS. Es ist zuverlässiger und kosteneffizienter als andere Autoscaler.
  • SealedSecrets genutzt: Ich bereue den Einsatz von SealedSecrets. Es ist für Entwickler komplex und man verliert die bestehende automatische Passwortrotation von AWS.
  • ExternalSecrets genutzt: Ich befürworte ExternalSecrets zur Synchronisierung von Secrets von AWS -> Kubernetes. Es ist für Entwickler leichter verständlich und mit Terraform lassen sich Secrets in AWS einfach erzeugen oder aktualisieren.
  • ExternalDNS genutzt: Ich befürworte ExternalDNS. Es synchronisiert DNS-Einträge von Kubernetes -> Route53 und hat in den letzten 4 Jahren kaum Probleme gemacht.
  • cert-manager genutzt: Ich befürworte cert-manager für die Verwaltung von SSL-Zertifikaten. Für die Erstellung von Let's Encrypt-Zertifikaten ist es sehr intuitiv und problemlos.
  • Bottlerocket for EKS: Ich bereue den Betrieb von EKS-Clustern mit Bottlerocket. Es gibt häufig Probleme mit dem Networking-CSI und das Debugging ist schwierig.
  • Terraform statt CloudFormation gewählt: Ich befürworte Terraform. Es lässt sich leichter auf andere SaaS-Anbieter ausweiten und hat eine besser lesbare Syntax als CloudFormation.
  • Keine codebasierte IaC-Lösung verwendet: Ich bereue das nicht. Terraform und CloudFormation nutzen Datendateien, während Pulumi oder CDK Infrastruktur als Code beschreiben. Die eher eingeschränkte Natur von Terraforms HCL hilft dabei, Komplexität zu reduzieren.
  • Kein Service Mesh verwendet: Ich bereue das nicht. Service Meshes sind zwar cool, aber Unternehmen unterschätzen oft die Komplexität. Allgemein gilt für Infrastruktur: „Weniger ist besser“.
  • Nginx-Load-Balancer für EKS Ingress: Ich bereue das nicht und befürworte Nginx. Es ist alt, aber stabil und bewährte Technik.
  • homebrew for company scripts: Ich befürworte homebrew für die Verteilung von Unternehmensskripten. Es ist gut genug, um Skripte und Binärdateien sowohl an Linux- als auch an Mac-Nutzer zu verteilen.
  • Go for services: Ich befürworte Go für Services. Neue Engineers können es leicht lernen und insgesamt ist es eine gute Wahl.

Verwandte Beiträge

4 Kommentare

 
nicewook 2024-02-28

Sowohl der Artikel als auch die Kommentare sind voller wertvoller Inhalte.
 
mhj5730 2024-02-28

Wow … das sind wirklich praktische Informationen, die man kaum irgendwo sonst findet.
 
xguru 2024-02-28

Hacker-News-Kommentare

  • Die Mehrkosten für die Nutzung von RDS sind es wert

    • Die Mehrkosten für RDS wirken fast lächerlich hoch, wann immer man erwägt, es durch einen colocated SQL-Server-Cluster zu ersetzen. Sie übersteigen bei weitem das, was ich zu zahlen bereit wäre, und würden stattdessen Colocation-Racks, AWS Direct Connects, Server, SAN, SQL-Server-Lizenzen, Wartungsverträge und sogar das Gehalt eines internen Vollzeit-DBA abdecken.
    • Gesamtkosten über 12 Monate: 547,441.85 USD
    • Wenn der Aufschlag groß genug wird, um das Gehalt von einer oder mehreren Vollzeitkräften zu bezahlen, sollte man erwägen, stattdessen Leute einzustellen, anstatt RDS blind weiter hochzuskalieren. Bei RDS zahlt man wirklich sehr viel Geld, und man sollte Entscheidungen aus der frühen Gründungsphase noch einmal neu bewerten.

  • Es mag eine unpopuläre Meinung sein, dass Google Cloud besser als AWS ist, aber mit Google Cloud Run lassen sich Docker-Container wie im Traum in der Cloud ausführen. Die Servicenamen sind einfach, es gibt weniger wichtige Services als bei den komplexen Angeboten von AWS, und die UI ist intuitiver. Nachteile sind der Mangel an Community, dadurch weniger Tutorials, Schwierigkeiten, erfahrene Leute zu finden, und weniger Third-Party-Tools. Ich würde empfehlen, es auszuprobieren.

  • Die Nutzung von EC2 + ASG macht sehr viel Freude. Es ist konzeptionell einfach: Man startet ein Image in einer ASG und setzt Auto-Scaling-Richtlinien. Es gibt fast nichts, worüber man sich Sorgen machen muss. Im Gegensatz dazu ist die Nutzung von k8s immer eine große Sache. Man stellt ganze Teams zusammen, um k8s zu verwalten. Man führt Dutzende von k8s-Konzepten ein oder investiert Personenjahre in „Platform Engineering“, um diese Konzepte zu verstecken. Man veröffentlicht Richtlinien, SDKs und allerlei Validatoren, damit k8s „richtig“ genutzt werden kann. Trotzdem schreibt man Zehntausende Zeilen YAML und Code, um Operatoren zu implementieren. Manchmal frage ich mich, ob k8s nicht zu invasiv ist.

  • Meinungen zu SaaS-Produkten

    • Ich verstehe den Wechsel von JIRA zu Linear nicht. Linear ist okay, aber ich stoße oft auf Dinge, die man nicht tun kann oder bei denen ich nicht weiß, wie sie gehen.
    • Ich empfehle Terraform Cloud im Allgemeinen. Das eigene System intern wachsen zu lassen, mag in den ersten Jahren okay sein, kann aber langfristig teuer werden.
    • Ich unterstütze die Nutzung von GitHub Actions für CI/CD einigermaßen. Stattdessen würde ich aber vorschlagen, GitLab zu verwenden.
    • Bei Datadog stimme ich entschieden nicht zu. Es ist das beste Monitoring-/Observability-Tool auf dem Markt. Die häufigste Beschwerde sind die Kosten, aber meistens liegt das daran, dass Datadog falsch konfiguriert wurde und die Kosten deshalb explodieren.
    • Bei Pagerduty stimme ich zu. Pagerduty ist etwa 10-mal teurer als Opsgenie und bietet keine besseren Funktionen. Als wir unseren Vertrag mit Pagerduty verlängerten und den Vertrieb fragten, welche Features es dort gebe, die Opsgenie nicht habe, antworteten sie, dass sie sich als Premium-Marke im Markt positionieren wollten. Deshalb bin ich zufrieden damit, für Incident Reporting die Standardmarke zu verwenden.

  • Ich stelle mir vor, wie Entwickler aus den 90ern/00ern diese Liste lesen und von der Komplexität und den Begriffen verwirrt sind.

  • Interessanter Lesestoff, aber ich bin mir nicht sicher, ob die Person genug bereut, um darüber einen Blogpost zu schreiben.

  • Ich verspüre den Drang, zurückzugehen und damit zu experimentieren, alles auf einem einzigen gigantischen 100k-$-Server in einer Box laufen zu lassen.

  • Ich habe es geschafft, die Grundlagen von Kubernetes / EKS zu lernen, erwäge aber einen Wechsel zu ECS. Kubernetes ist für unsere Anforderungen zu komplex. Es lässt sich mit etwas wie CloudFormation nur schwer steuern. Die durch Add-ons bereitgestellten Load Balancer lassen sich außerhalb von Kubernetes nur schwer referenzieren. Das Logging von EKS Fargate nach Cloudwatch scheint selbst dann nicht zu funktionieren, wenn man der Dokumentation folgt. CPU-/Speichermetriken funktionieren nicht wie bei EKS EC2, und offenbar wird ADOT benötigt. Mit ECS habe ich die Umgebung in einem Zehntel der Zeit neu aufgebaut, und alles funktionierte gut.

  • Mir gefällt, wie dieser Beitrag geschrieben ist und was er enthält. Ich stimme einigen Entscheidungen und Empfehlungen nicht zu, aber selbst dann ist es großartig, die Begründungen zu lesen. Es wäre schön, wenn mehr ähnliche Beiträge veröffentlicht würden und man sie vergleichen könnte. Ich fühle mich inspiriert, selbst einen ähnlichen Beitrag zu schreiben.

  • Die Küchen-Spülbecken-Datenbank, die von allen benutzt wird, ist ein häufiges Problem, das sich aber immer wiederholt. Beim Wachstum wird sie zu erheblicher technischer Schuld und zu einem Performance-Flaschenhals. Mit einer Managed DB wie RDS kann man leicht separate DB-Cluster pro Kernanwendung betreiben.