(Casi) todas las decisiones de infraestructura que apoyé o de las que me arrepiento tras 4 años operando infraestructura en una startup

 (cep.dev)
87 puntos por xguru 2024-02-28 | 4 comentarios | Compartir por WhatsApp
  • Todas las decisiones están marcadas como Endorse (apoyo) o Regret (arrepentimiento)

Elección de AWS

  • Elegir AWS en lugar de Google Cloud: Apoyo esta decisión. AWS está más enfocado en el cliente. Google Cloud da la impresión de depender de robots y automatización.
  • EKS: Apoyo usar EKS. EKS ofrece una integración profunda con los servicios de AWS, y Kubernetes también se ha puesto al día en muchos aspectos (por ejemplo, integrándose con Route53 mediante externaldns).
  • Add-ons administrados de EKS: Me arrepiento de usar los add-ons administrados de EKS. Necesitábamos personalizar la instalación, y después de cambiar a charts de Helm la operación mejoró.

Bases de datos y caché

  • RDS: Apoyo usar RDS. Los datos son la parte más importante de la infraestructura, y el costo de usar RDS vale la pena.
  • Redis ElastiCache: Apoyo usar Redis. Redis es muy efectivo tanto para caché como para usos más generales.
  • ECR: Apoyo haber migrado de quay.io a ECR. ECR es más estable y tiene una integración de permisos más profunda.

Red y soporte

  • AWS VPN: Apoyo usar AWS VPN. La VPN es muy simple de configurar y entender. Usamos Okta para administrar el acceso VPN y la experiencia ha sido muy buena.
  • Soporte premium de AWS: Me arrepiento. El soporte premium de AWS es muy caro y, si no te falta conocimiento interno de AWS, no vale la pena.
  • Control Tower Account Factory for Terraform: Apoyo la integración con AFT. Automatiza la creación de cuentas y ayuda a estandarizar etiquetas.

Automatización de procesos

  • Automatización de postmortems con bots de Slack: Apoyo automatizar el proceso de postmortem. Ayuda a impulsar que la gente los escriba.
  • Uso de plantillas de incidentes de PagerDuty: Apoyo usar plantillas cuando ocurre un incidente. Aprovechan la flexibilidad de Notion y permiten cierto nivel de personalización.
  • Revisión periódica de tickets de PagerDuty: Apoyo revisar regularmente la configuración de alertas. Ayuda a asegurar que incluso las alertas menos importantes no sean ignoradas.
  • Gestionar postmortems en Datadog o PagerDuty: Me arrepiento de usar una herramienta integrada para gestionar postmortems. En ambos casos es difícil personalizar el proceso posterior al incidente. Creo que es mejor usar una herramienta potente como Notion.

Otros

  • Reunión mensual de seguimiento de costos: Apoyo una reunión mensual para revisar costos de SaaS. Sirve para verificar si los costos son razonables y tomar acciones cuando haga falta. En AWS agrupamos los rubros por etiquetas y los separamos por cuenta. Recomiendo no quedarse solo en AWS y revisar todas las fuentes principales de gasto de la empresa.
  • No usar más FaaS: Me arrepiento de no haber podido adoptar FaaS por completo, ya que no había opciones FaaS para cargas con GPU. Muchas tareas de CPU sí se podrían haber resuelto con FaaS. Otra ventaja oculta de Lambda es que facilita mucho rastrear costos con gran precisión.
  • GitOps: Apoyo usar GitOps. Lo usamos en gran parte de la infraestructura e invertimos en desarrollar herramientas para entender el estado de los despliegues.
  • Priorizar la eficiencia del equipo: Apoyo priorizar mejorar la eficiencia del equipo. Nunca me he arrepentido de invertir tiempo en automatización o documentación.
  • Múltiples aplicaciones compartiendo una sola base de datos: Me arrepiento de que varias aplicaciones compartan una sola base de datos. Eso causó varios problemas.

Adopción de SaaS

  • Adoptar tarde una plataforma de identidad: Usábamos Google Workspace para asignar permisos, pero me arrepiento de no haber adoptado antes una solución de identidad como Okta. Okta se integra bien y resuelve temas de seguridad y cumplimiento.
  • Notion: Apoyo usar Notion para documentación. Fue una excelente elección y funciona mucho mejor que lo que había usado antes (wikis, Google Docs, Confluence, etc.). El concepto de bases de datos para organizar páginas es útil.
  • Slack: Apoyo usar Slack. Es efectivo como herramienta principal de comunicación.

Herramientas y servicios de desarrollo

  • Migrar de JIRA a Linear: Apoyo usar Linear en vez de JIRA. Me parece que JIRA es demasiado complejo y pesado.
  • No usar Terraform Cloud: No me arrepiento de no usar Terraform Cloud porque no podía justificar su costo. Migramos a Atlantis y agregamos la automatización necesaria al pipeline de CI/CD.
  • GitHub Actions para CI/CD: Lo apoyo hasta cierto punto (Endorse-ish). Las actions del marketplace y la sintaxis son fáciles de usar. Considero una desventaja el soporte limitado para workflows self-hosted.

Elecciones tecnológicas

  • Datadog: Me arrepiento de usar Datadog. Es muy caro y su modelo de costos no encaja bien con clusters de Kubernetes y una empresa de IA.
  • PagerDuty: Apoyo usar PagerDuty. El producto es bueno y el precio es razonable.
  • Migraciones de esquema por diff: Lo apoyo hasta cierto punto usar herramientas para migraciones de esquema. Los datos son importantes y las migraciones de esquema pueden ser riesgosas.
  • Ubuntu para servidores de desarrollo: Apoyo usar Ubuntu para servidores de desarrollo. Tiene buen soporte y la mayoría de los paquetes necesarios.
  • AppSmith: Apoyo usar AppSmith para automatizar procesos internos de ingeniería. Lo alojamos nosotros mismos y ha sido suficientemente satisfactorio. Al principio exploramos integraciones más profundas usando retool, pero en ese momento no podíamos justificar el precio por apenas unas cuantas integraciones.
  • helm: Apoyo usar Helm v3. Tiene problemas con despliegue de CRD y capacitación de desarrolladores, pero es suficientemente bueno para empaquetar y desplegar objetos de Kubernetes.
  • helm charts en ECR (oci): Apoyo guardar charts de helm en un repositorio OCI. Ha dado menos problemas que el método anterior usando S3 y plugins.
  • bazel: No estoy seguro sobre bazel. Parece excesivo para desplegar servicios en Go, y GitHub Actions es más fácil de usar para más ingenieros.
  • No usar OpenTelemetry: Me arrepiento de enviar métricas usando directamente la API de DataDog. Recomiendo usar OpenTelemetry desde el inicio.
  • Elegir renovatebot en lugar de dependencyabot: Me arrepiento de no haber pensado antes en mantener las dependencias actualizadas. Renovatebot permite personalización, pero configurarlo y depurarlo es complicado.
  • Kubernetes: Apoyo usar Kubernetes. Se necesita una forma de alojar servicios de larga duración, y Kubernetes es popular y funciona bien.
  • Comprar IP propias: Apoyo comprar bloques de IP propios al trabajar con socios externos. Esto ayuda a darles un bloque CIDR más grande para whitelist.
  • Elegir Flux para GitOps en k8s: No me arrepiento de haber elegido Flux como herramienta GitOps para Kubernetes. Hace falta desarrollar herramientas para entender el estado de los despliegues.
  • Karpenter para gestión de nodos: Apoyo usar Karpenter con EKS. Es más confiable y más eficiente en costos que otros autoscalers.
  • Usar SealedSecrets: Me arrepiento de usar SealedSecrets. Es complejo para los desarrolladores y se pierde la automatización existente de AWS para la rotación de secretos.
  • Usar ExternalSecrets: Apoyo usar ExternalSecrets para sincronizar secretos de AWS -> Kubernetes. Es fácil de entender para los desarrolladores y permite crear/actualizar secretos fácilmente dentro de AWS usando terraform.
  • Usar ExternalDNS: Apoyo usar ExternalDNS. Sincroniza entradas DNS de Kubernetes -> Route53 y casi no ha dado problemas en los últimos 4 años.
  • Usar cert-manager: Apoyo usar cert-manager para gestionar certificados SSL. Es muy intuitivo para generar certificados de Let's Encrypt y no ha dado problemas.
  • Bottlerocket para EKS: Me arrepiento de operar clusters de EKS con Bottlerocket. Había problemas frecuentes con el CSI de red y era difícil depurarlos.
  • Elegir Terraform en lugar de CloudFormation: Apoyo usar Terraform. Facilita expandirse a otros proveedores SaaS y tiene una sintaxis más legible que CloudFormation.
  • No usar una solución IaC basada en código: No me arrepiento. Mientras Terraform y CloudFormation usan archivos de datos, Pulumi o CDK describen la infraestructura como código. La naturaleza limitada de HCL en Terraform ayuda a reducir la complejidad.
  • No usar service mesh: No me arrepiento. Los service mesh son atractivos, pero las empresas tienden a subestimar su complejidad. Un consejo general sobre infraestructura es: “menos es mejor”.
  • Balanceador Nginx para ingress de EKS: No me arrepiento y apoyo usar Nginx. Es una tecnología antigua, pero estable y probada.
  • homebrew para scripts de la empresa: Apoyo usar homebrew para distribuir scripts de la empresa. Es suficientemente bueno para distribuir scripts y binarios tanto a usuarios de Linux como de Mac.
  • Go para servicios: Apoyo usar Go para servicios. Es fácil de aprender para ingenieros nuevos y, en general, es una muy buena elección.

Lecturas relacionadas

4 comentarios

 
nicewook 2024-02-28

Tanto el artículo como los comentarios están llenos de contenido valioso.
 
mhj5730 2024-02-28

Vaya... esto es información práctica que cuesta muchísimo encontrar en cualquier lado.
 
xguru 2024-02-28

Opiniones de Hacker News

  • El costo adicional de usar RDS vale la pena

    • El costo extra de usar RDS resulta tan ridículamente caro cada vez que se considera reemplazarlo por un clúster de servidores SQL en colocation, que solo da risa. Supera por mucho lo que estaría dispuesto a pagar, al punto de que alcanzaría para cubrir racks en colocation, AWS Direct Connects, servidores, SAN, licencias de SQL Server, contratos de mantenimiento e incluso el salario de un DBA interno de tiempo completo.
    • Costo total de 12 meses: 547,441.85 USD
    • Cuando el sobreprecio se vuelve lo bastante grande como para pagar el salario de uno o más empleados de tiempo completo, hay que considerar contratar gente en vez de simplemente seguir escalando RDS. Con RDS realmente se está pagando muchísimo, y vale la pena reevaluar las decisiones tomadas al inicio de la empresa.

  • Puede que sea una opinión impopular decir que Google Cloud es mejor que AWS, pero con Google Cloud Run se pueden ejecutar contenedores Docker en la nube como un sueño. Los nombres de los servicios son simples, hay menos servicios importantes que en el ecosistema enredado de AWS, y la UI es más intuitiva. Las desventajas son la falta de tutoriales por una comunidad más pequeña, la dificultad de encontrar gente con experiencia y la menor cantidad de herramientas de terceros. Lo recomiendo.

  • Usar EC2 + ASG es muy agradable. Es conceptualmente simple: lanzas una imagen en el ASG y configuras políticas de autoescalado. Casi no hay nada de qué preocuparse. En cambio, usar k8s siempre es una gran empresa. Se arma un equipo completo para administrar k8s. Se introducen decenas de conceptos de k8s o se invierten años-persona en "platform engineering" para ocultarlos. Se publican lineamientos, SDKs y varios validadores para poder usar k8s "correctamente". Aun así, se terminan escribiendo decenas de miles de líneas de YAML y código para implementar operadores. A veces uno se pregunta si k8s no es demasiado intrusivo.

  • Opiniones sobre productos SaaS

    • No entiendo el cambio de JIRA a Linear. Linear está bien, pero con frecuencia encuentro cosas que no puede hacer o formas de uso que no conozco.
    • En general recomiendo usar Terraform Cloud. Hacer crecer un sistema propio en casa puede estar bien durante los primeros años, pero a largo plazo puede salir caro.
    • Apoyo en cierta medida usar GitHub Actions para CI/CD. Aun así, sugeriría usar GitLab en su lugar.
    • No estoy fuertemente en desacuerdo con Datadog. Es la mejor herramienta de monitoreo/observabilidad del mercado. El costo es la queja más común, pero en la mayoría de los casos los costos se disparan porque Datadog está mal configurado.
    • Estoy de acuerdo con lo de Pagerduty. Pagerduty cuesta unas 10 veces más que Opsgenie y no ofrece mejores funciones. Cuando llegó el momento de renovar contrato con Pagerduty y le pregunté al vendedor qué funciones tenía que Opsgenie no tuviera, respondió que estaban tratando de posicionarse como una marca premium en el mercado. Así que estoy perfectamente conforme con usar una marca genérica para reportes de incidentes.

  • Me imagino a desarrolladores de los 90/00 leyendo esta lista y quedando confundidos por la complejidad y la terminología.

  • Es una lectura interesante, pero no estoy seguro de que sea alguien que realmente se arrepienta lo suficiente como para escribir un blog.

  • Siento el impulso de experimentar con volver a un único servidor gigantesco de $100k y ejecutar todo dentro de una sola caja.

  • Logré aprender lo básico de Kubernetes / EKS, pero estoy considerando cambiarme a ECS. Kubernetes es demasiado complejo para nuestras necesidades. Es difícil de controlar con algo como CloudFormation. Los load balancers aprovisionados por los add-ons son difíciles de referenciar desde fuera de Kubernetes. En EKS Fargate, el logging hacia Cloudwatch parece no funcionar incluso siguiendo la documentación. Las métricas de CPU/memoria no funcionan como sí lo hacen en EKS EC2, y parece que se necesita ADOT. En ECS pude reconfigurar el entorno en una décima parte del tiempo y todo funcionó bien.

  • Me gusta la forma en que está escrito este artículo y su contenido. No estoy de acuerdo con algunas decisiones y recomendaciones, pero incluso en esos casos es excelente leer las razones. Ojalá hubiera más publicaciones similares y una forma de compararlas. Me inspiró a escribir algo parecido.

  • La base de datos tipo kitchen sink que todo el mundo usa es un problema común, pero se sigue repitiendo. Cuando el sistema crece, se convierte en una deuda técnica considerable y en un cuello de botella de rendimiento. Con una base de datos administrada como RDS, es fácil operar clústeres de base de datos individuales para cada aplicación principal.