Cómo Figma migró a K8s en menos de 12 meses
(figma.com)- Figma se propuso mover sus servicios centrales ya contenedorizados de ECS a Kubernetes basado en EKS, con el objetivo de reducir limitaciones de plataforma a largo plazo sin tiempo de inactividad
- En ECS, la ausencia de StatefulSets, la dificultad para operar OSS basado en Helm charts y las limitaciones de aislamiento de nodos eran grandes obstáculos; Kubernetes abrió opciones dentro del ecosistema CNCF como Keda, Karpenter e Istio
- La migración acotó el alcance manteniendo las abstracciones de ejecución de servicios, despliegue y herramientas, y cambiando solo la orquestación; la definición de servicios basada en Bazel y la configuración de 3 clústeres EKS sí quedaron dentro del alcance inicial
- Durante la transición, aseguraron la posibilidad de rollback con pruebas de carga, migración gradual de tráfico basada en Weighted DNS, traslado temprano de servicios reales, ocultamiento del YAML crudo y colaboración con los owners de servicio
- Para enero de 2024, la mayoría de los servicios de máxima prioridad ya se había movido a EKS, logrando menor costo por sobreaprovisionamiento, mayor confiabilidad y mejor experiencia de desarrollador, mientras continúan con logging, autoescalado y migración a Graviton
Por qué pasaron de ECS a Kubernetes
- A inicios de 2023, Figma ya ejecutaba todos sus servicios en contenedores y usaba AWS Elastic Container Service (ECS) como plataforma de orquestación
- Al evaluar la siguiente generación de su plataforma de cómputo, concluyeron que seguir construyendo sobre ECS dificultaría a largo plazo crear las capacidades que querían
- Figma no es una empresa que opere miles de microservicios, así que podía gestionar de forma realista el alcance de una migración a Kubernetes
- A veces se necesitan nuevos servicios por aislamiento o rendimiento, pero sus servicios centrales ya proporcionaban modularización básica y aislamiento de tráfico
- En muchos casos, los productos nuevos se soportaban agregando lógica dentro de servicios centrales existentes en vez de crear servicios nuevos
Funciones que faltaban en ECS
- ECS no soportaba StatefulSets de Kubernetes, lo que dificultaba operar almacenes de datos de consenso fuertemente consistente como etcd
- Figma lo resolvía con código personalizado que actualizaba dinámicamente la membresía del clúster al iniciar los contenedores de etcd
- Ese enfoque era frágil y difícil de mantener, mientras que en Kubernetes es común usar la asignación de red con estado de StatefulSets
- En ECS era difícil ejecutar paquetes de servicios definidos con Helm charts
- En ECS sobre EC2, también era engorroso apagar elegantemente una sola máquina EC2 con problemas
- En EKS, al hacer cordon a un nodo defectuoso, el API server puede respetar el proceso de terminación y mover los Pods a otras máquinas
El ecosistema CNCF y la elección de plataforma
- Seguir con ECS dificultaba aprovechar tecnologías open source del ecosistema Cloud Native Computing Foundation (CNCF)
- El autoescalado era una preocupación importante para la siguiente generación de la plataforma de cómputo
- En ese momento, Figma no aplicaba autoescalado a sus servicios contenedorizados
- Aprovisionaban servicios para soportar la carga pico incluso por la noche o los fines de semana, cuando el tráfico era bajo, lo que generaba costos innecesarios
- Keda del ecosistema Kubernetes permite escalar no solo por uso de CPU, sino también con base en la longitud de colas de AWS SQS y métricas personalizadas de Datadog
- También existía la posibilidad de necesitar una service mesh a largo plazo
- El tráfico entre servicios se enrutaba mediante AWS Application Load Balancers (ALB) y Network Load Balancers (NLB)
- Los NLB tardaban varios minutos en registrar targets nuevos y remover los existentes, lo que ralentizaba despliegues urgentes y aumentaba el tiempo medio de recuperación ante incidentes
- Envoy ofrecía mayor capacidad de personalización y ejecución de filtros personalizados
- Figma ya había usado un clúster independiente de máquinas con Envoy como proxy frente a servicios importantes, con filtros personalizados para reducir carga durante incidentes
- En EKS había muchas opciones open source como Istio, mientras que en ECS tendrían que reconstruir capacidades similares por su cuenta
Ventajas operativas de una plataforma popular
- Figma evita convertirse en el usuario más grande de un servicio o software
- Los usuarios más grandes suelen toparse primero con las partes ásperas y los límites de escalabilidad
- Kubernetes es usado por muchas grandes empresas para plataformas de cómputo enormes, así que Figma es un usuario mucho más pequeño en comparación
- Kubernetes ayuda a reducir el vendor lock-in
- EKS ofrece las ventajas de un control plane soportado por el proveedor
- Como los servicios se escriben para ejecutarse en Kubernetes estándar, no sería tan costoso moverlos a otra plataforma Kubernetes soportada por otro proveedor o autohospedada
- También facilita contratar ingenieros con experiencia en Kubernetes
- Los ingenieros con experiencia previa pueden adaptarse rápido y aportar contexto en áreas que podrían representar decisiones nuevas para Figma
Principios para definir el alcance de la migración
- En migraciones grandes, lo más seguro es reemplazar solo el sistema central que se quiere cambiar y mantener tanto como sea posible las abstracciones visibles para los usuarios de la plataforma
- Figma acotó el alcance a mover la ejecución de ECS a EKS sin cambiar la forma de ejecutar servicios, desplegarlos ni usar herramientas de interacción entre servicios
- Incluso trabajos que no parecen cambios de funcionalidad pueden generar efectos de segundo orden, por lo que el cronograma de una migración grande puede crecer con facilidad
- Hubo dos excepciones
- Si hacer que el sistema nuevo se comportara como el anterior requería demasiado trabajo adicional, podían aceptar efectos de segundo orden y adoptar el enfoque nuevo
- Si se trataba de decisiones tipo one-way door, difíciles o costosas de cambiar después, podían aplicar el enfoque nuevo desde el inicio
Mejoras incluidas en el alcance
-
Experiencia de desarrollador
- Las definiciones de servicios en ECS existentes se generaban y modificaban principalmente con Terraform
- Con Terraform creaban una plantilla de task set de ECS con 0 instancias y, luego, en el proceso de despliegue, clonaban esa plantilla, reemplazaban el hash de la imagen y desplegaban en ECS un task set con una cantidad de instancias distinta de 0
- Incluso para agregar una sola variable de entorno había que escribir y aplicar Terraform y luego ejecutar el despliegue; si no se respetaba el orden, podían aparecer bugs porque el código no podía usar la variable de forma segura
- En EKS cambiaron a una definición de servicio unificada que se despliega en un solo paso
- Figma creó una forma interna simple de definir servicios con archivos de configuración de Bazel, y genera automáticamente YAML de definición de servicios y YAML de configuración como Ingress
- El YAML se genera en la herramienta de CI al hacer commit del código y se aplica mediante su sistema interno de despliegue
-
Confiabilidad
- Para cada servicio, configuraron 3 clústeres EKS que ejecutan Pods y reciben tráfico
- Si toda la operación ocurre a nivel de clúster, una caída total puede reducirse a afectar solo un tercio del servicio
- En servicios con reintentos o procesamiento asíncrono, muchas veces esto minimiza la interrupción para el usuario
- Esta configuración aumentó considerablemente la complejidad operativa, por ejemplo en el pipeline de despliegue, pero consideraron que valía la pena implementarla durante la migración en vez de agregarla después
-
Eficiencia de costos
- No incluyeron mucho trabajo complejo de optimización de costos dentro del alcance, pero sí soportaron autoescalado de nodos desde el principio
- En los servicios de ECS sobre EC2 sobreaprovisionaban máquinas para absorber picos durante los despliegues
- En EKS usan Karpenter para escalar nodos dinámicamente hacia arriba o hacia abajo según la demanda
Trabajo excluido del alcance
- El pipeline de logging existente era complejo
- Todos los logs se escribían primero en CloudWatch
- Luego una Lambda leía los logs y hacía transformaciones como borrar ciertos patrones y agregar etiquetas
- Después se escribían en Datadog y Snowflake
- El costo de CloudWatch como almacenamiento intermedio estaba creciendo
- Figma planea introducir Vector, un proyecto CNCF que permite procesar y reenviar logs desde sidecars en el stack de EKS
- Sin embargo, consideraron que no valía la pena asumir los efectos de segundo orden de portar la lógica del reenviador de logs a configuración de Vector, así que lo dejaron fuera del alcance de la migración
- Tampoco incluyeron el autoescalado a nivel de Pod en la migración
- Consideraron que la complejidad era demasiado alta
- Lo vieron como algo que podía agregarse fácilmente después
- Esos trabajos excluidos pasaron luego a ser tareas posteriores y pudieron entregar mejoras en paralelo con la migración de otros servicios a EKS
Cómo ejecutaron el proceso de forma segura
- Como el stack previo en ECS era relativamente estable, el nuevo stack en EKS y el proceso de migración debían ser al menos igual de confiables
-
Pruebas de carga
- Figma creó un servicio “Hello, World” y lo escaló hasta ejecutar la misma cantidad de Pods que su servicio más grande
- Con esta prueba descubrieron que debían ajustar el tamaño y la escala de servicios de cómputo clave que soportaban toda la plataforma
- Kyverno es una herramienta de validación de seguridad del clúster y, si no se configuraba con suficiente capacidad, podía retrasar el arranque de Pods nuevos
-
Rollout gradual
- Usaron entradas de Weighted DNS para mover poco a poco tráfico desde el servicio existente en ECS hacia su equivalente en EKS
- El control fino del cambio de tráfico y del regreso atrás fue clave para una migración segura
- Como los impactos no previstos pueden aparecer en puntos de inflexión desconocidos, era necesario reducir el radio de impacto y poder hacer rollback rápido
-
Ejecutar servicios reales temprano
- Poner cargas reales en el sistema permite aprender muchas cosas que no se detectan solo con staging
- Figma migró un servicio antes incluso de terminar de construir el entorno de staging
- Esa migración temprana ayudó a validar de extremo a extremo la capacidad de ejecutar cargas de trabajo y a encontrar cuellos de botella y bugs
-
Abstracción del YAML
- Hacer que los usuarios definan sus servicios directamente con YAML crudo de Kubernetes podía resultar confuso
- Figma ofreció a los usuarios un golden path y permitió personalización solo en casos especiales
- Al dejar claro qué podían y debían personalizar, mientras imponían consistencia por defecto, simplificaron el mantenimiento y los cambios futuros
-
Colaboración con owners de servicio y asignación de personal
- El equipo de plataforma se encargó de la configuración de nuevos servicios y colaboró estrechamente con los owners de servicio para actualizar monitoreo y alertas, ya que ellos conocían mejor el estado de cada servicio
- Incluso antes de iniciar la migración, discutieron a fondo con los owners las opciones y trade-offs
- Una migración a gran escala puede crear problemas imprevistos, interacciones complejas y bugs comunes, por lo que se necesitaba un equipo con profunda experiencia técnica y capacidad de depuración
Cronograma real de la migración y resultados
- En el primer trimestre de 2023 elaboraron el plan y obtuvieron acuerdo para avanzar con la migración
- En el segundo trimestre de 2023 construyeron el entorno de staging y migraron un solo servicio
- En el tercer trimestre de 2023 se enfocaron en preparar producción, hacer pruebas de carga y alistar la migración de más servicios
- Desde el cuarto trimestre de 2023 hasta la primera semana de enero de 2024, fueron cambiando el tráfico de servicios lentamente
- Para enero de 2024, la mayoría de los servicios de máxima prioridad ya se había migrado al nuevo clúster EKS
- El monolito que contiene la lógica central del negocio
- Un servicio complejo que maneja el aspecto multijugador de la edición de archivos de Figma
- Los servicios que componen Livegraph 100x y empujan actualizaciones en tiempo real a todos los clientes
- Como resultado, redujeron costos por sobreaprovisionamiento para despliegues, mejoraron la confiabilidad con ejecución en 3 clústeres y mejoraron la usabilidad para desarrolladores
- Todo el trabajo avanzó con incidentes menores y bajo impacto en clientes
- Hubo un incidente en el que un operador destruyó y recreó CoreDNS por error en uno de los clústeres de producción
- Con la configuración anterior, eso habría causado una caída total
- Con la configuración de 3 clústeres, el impacto quedó limitado a un tercio de las solicitudes
- La mayoría de los servicios downstream reintentó las solicitudes y finalmente tuvieron éxito
Mejora de herramientas después del lanzamiento
- Figma creó herramientas para que los owners de servicio pudieran depurar lo que ocurre en el clúster
- Ver cuántas instancias están en ejecución
- Abrir un shell del contenedor
- Realizar tareas operativas como escalado de emergencia
- Poco después del lanzamiento, recibieron feedback de que esta herramienta de acceso no era lo suficientemente amigable
- Había dos fuentes de complejidad
- Con la introducción de 3 clústeres, los usuarios debían ejecutar comandos a través de varios clústeres y agregar el nombre del clúster en cada comando
- Al usar roles de Kubernetes RBAC para dar permisos más granulares, los usuarios debían entender qué roles tenían y qué rol requería cada operación específica
- Figma detuvo de inmediato otros trabajos y ajustó la herramienta para que infiriera automáticamente el clúster y el rol adecuados
- Así, los usuarios no tenían que perder tiempo buscando roles, especialmente en emergencias nocturnas
Próximos pasos
- Siguen migrando los servicios restantes mientras mejoran en paralelo la nueva plataforma de cómputo
- Sus áreas de enfoque actuales son las siguientes
- Simplificar el diseño del pipeline de logging
- Soportar autoescalado horizontal de Pods mediante Keda
- Migrar a procesadores Graviton los servicios más costosos de Figma para reducir costos y abrir camino para ejecutar otros servicios sobre Graviton en el futuro
- También planean explorar áreas en las que todavía no han invertido a fondo
- Revisar ofertas de service mesh para mejorar la confiabilidad y observabilidad del stack de networking
- Gestionar más recursos con AWS Controllers for Kubernetes (ACKs) para reducir la dependencia de Terraform y simplificar e integrar el stack
- Colaborar con el equipo de experiencia de desarrollador para unificar cómo se ejecutan los servicios en el entorno de desarrollo y en otros entornos
1 comentarios
Opiniones de Hacker News
Personalmente, me gusta Kubernetes. Opero varias tiendas de comercio electrónico pequeñas pero complejas y hechas a la medida, y además me encargo de marketing, finanzas y atención al cliente.
Antes corrían en servidores dedicados, pero el stack era bastante complejo, así que desplegar era una pesadilla y, al final, la carga de los despliegues estaba frenando la velocidad de una empresa pequeña.
Me tomó un mes aprender Kubernetes y migrar, y opero unos 25 servicios, incluidos frontend, administrador de productos, dashboard de logística, optimización de rutas de entrega, OSRM, ERP, motor de recomendaciones, búsqueda, etc.
Al reunir la configuración del clúster en un solo lugar, pude ordenarla en una estructura repetible y ahora sé exactamente el estado de cada servicio y qué versión está corriendo. También se volvieron posibles los despliegues rolling sin interrupciones; es complejo, sí, pero los programadores justamente lidiamos con cosas complejas. Los archivos de configuración de Nginx también son complejos.
Mientras más profundizas, más entiendes por qué la arquitectura de Kubernetes tiene sentido, y te obliga a seguir estrictamente los 12 factores. Si tus ingresos están directamente ligados a la disponibilidad y estabilidad del stack, la alta disponibilidad es más que algo “deseable”. El costo de hosting ronda los 400 dólares al mes, así que tampoco es tan caro.
Yo tiendo a confiar en Kubernetes, pero realmente es complejo. Es una herramienta que resuelve problemas difíciles. Si estás en multicloud, no hay mucho que pensar; y si quieres una infraestructura compleja que corresponda 1:1 con lo local, encaja bien.
Pero si tienes menos de 100 desarrolladores y solo despliegas contenedores en AWS, en 2024 me parece una locura usar EKS en vez de ECS + Fargate.
La migración en sí para mejorar la base de infraestructura está bien. Pero me sorprendió que una de las motivaciones fuera hacer que los equipos usaran Helm charts en lugar de convertir todo a Terraform.
En la práctica, casi no he visto casos en los que se use un Helm chart cualquiera sin cambios y de forma estable; si fomentas su uso, al final los equipos terminan forkeando y modificando los charts. Helm es una herramienta tan horrible que no quisiera mantener Helm charts propios y personalizados.
Preferiría reescribirlos en Terraform, porque creo que es más fácil mantener una versión local. Me gustaría escuchar contraejemplos. Quizá hoy ya hayan desaparecido la locura de
indent 4en Helm y los problemas de plantillas de strings en múltiples niveles.También puedes gestionar workloads de Kubernetes con Terraform, pero no lo recomiendo. Kubernetes ya tiene su propio estado, y si Terraform también tiene estado, la combinación Terraform + Kubernetes se vuelve dolorosa. Helm fue creado para Kubernetes; Terraform, no.
Eso no significa que me guste Helm. El YAML con plantillas no me agrada, y la locura de
indent 4sigue existiendo. Kustomize está bien cuando todo es simple, pero cuando la app se vuelve compleja me parece peor que Helm. Por ejemplo, si quieres desplegar una app con Ingress, certificados TLS y external-dns en varios entornos, en vez de usar una variable en tres lugares tienes que parchear tres recursos.Tanto Helm como Terraform son muy populares y por eso se mencionan mucho, pero creo que eventualmente aparecerá una herramienta que reemplace a ambos y que todavía no se haya masificado.
El problema de Terraform es que tienes que diseñar los workspaces para no superar el número recomendado de recursos por workspace, unos 100 a 200. De lo contrario, el plan se vuelve muy lento porque revisa incluso bases de datos o redes que no tocaste ni piensas tocar, y eso alarga los tiempos de despliegue.
En la práctica terminas creando una malla de workspaces de Terraform que se disparan entre sí, y hoy no hay una buena herramienta open source que soporte esto adecuadamente.
Por ahora, lo mejor parece ser que Terraform instale una herramienta de despliegue continuo como ArgoCD como parte de la infraestructura, y que los despliegues cotidianos los maneje la herramienta de CD. Y la mayoría de las herramientas de CD te piden empaquetar los despliegues con algo como Helm.
Pero tiene demasiadas trampas, y termino dedicando tiempo a rehacer y depurar trabajo hecho por otros ingenieros.
Espero que una herramienta nueva llamada
timonigane tracción. Resuelve casi todas las quejas que tengo sobre Helm. Si buscas una mejor solución, vale la pena revisar timoni.Optamos por usar los Helm charts públicos tal cual y manejar las personalizaciones con
kustomize —enable-helm.En nuestro caso tenemos un Helm chart base para una sola aplicación/servicio que ofrece valores predeterminados razonables, y todos los despliegues lo extienden. Del lado del uso, la configuración necesaria de Helm values es mínima, y casi nunca tuvimos que meter plantillas propias, porque el chart base expone suficientes puntos de ajuste.
Pudimos desplegar muchos charts de terceros tal cual, y a veces agregamos por PR al upstream las funciones que necesitábamos. En raras ocasiones tuvimos que envolverlos o forkealos, pero fueron muchos más los charts de terceros que desplegamos sin cambios.
Al mantener charts personalizados, helm unittest (https://github.com/helm-unittest/helm-unittest) ayuda mucho a evitar regresiones.
Aunque gestionamos con Terraform algunos recursos de Kubernetes, incluido ArgoCD, en general desplegar Helm charts a través de ArgoCD ha sido mucho más fácil de administrar y más productivo.
Me sorprende que en HN haya tanto sentimiento anti-Kubernetes. Me pregunto si es porque la mayoría de quienes comentan son desarrolladores acostumbrados a servicios como Heroku, fly.io o render.com, o si es porque corren sus apps en VM.
No es un problema limitado a casos específicos, sino algo creado por incentivos muy desalineados en toda la industria y, en cierta medida, por la fiebre del oro de la era de tasas de interés bajas.
Sinceramente, tal como estamos ahora, en otros campos nos verían como artesanos bastante inútiles. Tenemos una obsesión poco sana con las herramientas y el metatrabajo, mientras seguimos tirando por la ventana el uso razonable de recursos con tal de usar cierta herramienta. Es una especie de situación de “ingeniero de FAANG temporalmente en apuros”.
Es difícil explicar cuánto más tiempo toma, cuánta más experiencia requiere, cuánto más frágil se vuelve y cuánto más dinero cuesta construir sobre Kubernetes en lugar de usar los modelos de despliegue que se pueden elegir en AWS, como imágenes de VM en EC2, Elastic Beanstalk, ECS/Fargate o Lambda.
No quiero instalar ni mantener yo mismo un stack ELK o Prometheus. Tampoco quiero pelearme con plugins CNI, Kafka, Postgres de alta disponibilidad, Argo, Helm ni upgrades del plano de control. Con los servicios equivalentes de AWS, puedes arrancar casi de inmediato, casi sin mantenimiento, y los costos suelen empezar de forma lineal desde un punto cercano a 0.
Puedes resolver problemas de negocio de forma mucho más rápida y eficiente. Es la diferencia entre estar en posición de superar ampliamente las expectativas y que todo el equipo se quede varios trimestres atrás.
Dicho eso, si de verdad hay requisitos multi-cloud u on-premise, no querría usar otra cosa que Kubernetes. En una empresa grande con muchos ingenieros expertos que entienden Kubernetes, quizá no sea tan malo. Al menos, los lugares donde trabajé no eran así.
Es bueno ver que las empresas se muevan principalmente hacia infraestructura open source. Una parte importante de eso viene de la CNCF (https://landscape.cncf.io), la ASF y varios proyectos de GitHub.
kata-containers quizá pueda resolver esa inquietud y hacer que disfrute Kubernetes.
En general, personalmente no hay nada en Kubernetes que me parezca genial. Ya vi contenedores, balanceadores de carga y YAML de megabytes; no me resulta lo bastante interesante como para probarlo.
Quizá sea normal en una empresa de este tamaño, pero me cuesta seguir el razonamiento detrás de estas migraciones enormes o proyectos tecnológicos gigantes. No parecen decisiones surgidas de necesidades de los usuarios o de la empresa.
Sentí lo mismo con un artículo parecido que Figma publicó antes sobre bases de datos.
Por ejemplo, si la razón para querer ir a Kubernetes es que en ECS no se puede usar etcd/Helm, primero habría que preguntar por qué quieren usar etcd/Helm. ¿De verdad es tan importante? ¿Realmente esa es la única forma exacta de alcanzar los objetivos de la empresa?
Cuando una decisión se basa en las necesidades de los usuarios, es más fácil validar si las decisiones derivadas tienen sentido; pero cuando se basa en deseos técnicos, aunque las decisiones derivadas parezcan razonables dentro del contexto de ese deseo técnico, sigue siendo incierto si tienen sentido en el contexto del usuario.
Me parece que una de dos: o yo no entiendo las organizaciones de este tamaño, o para una organización de este tamaño es fundamentalmente difícil identificar y razonar sobre trabajo valioso.
Somos, en esencia, un equipo de plataforma, y muchas veces construimos herramientas para otros equipos de plataforma que, a su vez, construyen herramientas para apoyar a los desarrolladores de Figma que crean la experiencia real del producto. Cuanto más te alejas del usuario final, más difícil se vuelve razonar cuál es la decisión correcta, pero al mismo tiempo aparece un gran apalancamiento.
Si construyes bien la plataforma, su efecto impacta en la capacidad de todos los demás ingenieros para trabajar de manera eficiente y efectiva. Gran parte de ese impacto es indirecto.
Claramente existía la opción de decir que no podíamos dar soporte a etcd y Helm y que buscaran otros rodeos. Pero ambos fueron datos adicionales que nos empujaron a concluir que estábamos operando la plataforma de Compute sobre bloques básicos equivocados.
Aunque razonar sea difícil, vale mucho la pena esforzarse en hacerlo bien. Como equipo de plataforma, esa es la forma de asegurarnos de que estamos haciendo lo correcto para llegar a la mejor plataforma. Por eso dedicamos mucho tiempo a tomar esta decisión, y pensé que era un tema interesante para escribir.
Es probable que muchas migraciones a Kubernetes en empresas grandes estén impulsadas por el deseo de multi-cloud o híbrido on-premise, y por mitigar costos, disponibilidad y riesgos de lock-in.
Hay que coordinar upgrades de VM, autenticación, backups, rotación de logs, etc.
En Kubernetes puedes darle a cada quien namespaces, políticas y volúmenes, y gracias a DaemonSet y al stack Kubernetes/cloud native también puedes tener agregación automática de logs.
También está la autorreparación y más; cuesta explicar cuánto mejora todo.
Por ejemplo, no hay muchos almacenes de datos altamente disponibles y consistentes que puedan servir como el equivalente a un archivo
.piden un entorno distribuido. Lo que se me viene a la mente es Zookeeper, pero operarlo es realmente doloroso, exige versiones antiguas de JVM y aun así, en general, es inestable.Cuando se aplica el código de Terraform, se crea un ECS task set con 0 instancias para levantar una plantilla de servicio; luego, cuando el desarrollador despliega el servicio, tiene que clonar ese task set de plantilla y hacer varias tareas manuales. Esa parte suena menos como un problema de ECS y más como que hicieron demasiado complejo el enfoque de gestión de despliegues con Terraform + ECS
Entiendo la parte de crear una plantilla para validarla antes del despliegue real. Pero esto es algo ambiguo
Por eso clasifiqué intencionalmente este punto como una tarea que decidimos incluir en el proceso de migración, y no lo puse entre las razones fundamentales para iniciar la migración
Dicho eso, puedo imaginar algunos escenarios en los que este enfoque se vuelve necesario. Por ejemplo, cuando hay muchos servicios desplegados en ECS y el tamaño del estado de Terraform crece. Entonces
planyapplyse vuelven mucho más lentos, y puede ser mucho más seguro fragmentar el estado de Terraform replicando la configuración tal cual a partir de una plantillaBásicamente era agregar variables de entorno al archivo de Terraform, hacer merge y dejar que CI desplegara. La mayoría de los cambios de configuración que hacíamos se manejaban con ese proceso
“Migrar a Kubernetes puede tomar años”, ¿qué demonios estoy leyendo?
¿Para quién es así? Tampoco entiendo muy bien por qué las empresas se molestan en hacer estas migraciones. ¿Dónde está el valor de negocio y cuál es el beneficio para el cliente? ¿Es como un proyecto de “arte por el arte” que Figma hace porque puede?
En una empresa muy establecida, de unos 30 años y con todo el lastre que eso implica, nosotros nos movimos a Kubernetes en mucho menos tiempo. Eso sí, no intentamos mover todo a Kubernetes; solo movimos lo que podía beneficiarse
Nuestra propuesta era más o menos esta: si se mudan a Kubernetes, durante el traslado de datacenter planeado para fin de año no tendrán que hacer nada más que revisiones. Si no, tendrán que redesplegar las apps en máquinas o VMs nuevas y lidiar con todos los dolores de cabeza asociados. Si todavía no están contenedorizadas, contenedorícenlas ahora y nosotros nos encargamos del resto
La mayoría migró y quedó muy satisfecha con el resultado. En cambio, para los servicios sensibles a la latencia o en áreas de cómputo de alto rendimiento, no había razón para forzarlos a migrar, y tampoco intentamos encajarlos a la fuerza
¿Cuánto tardarán en salirse de esto?
Si la app ya está microserviciada, volver atrás tampoco es sencillo
Cuando leo una entrada de blog que menciona casualmente 6 proyectos de la CNCF con nombres elegantes que nunca había escuchado, solo para obtener una funcionalidad que en apariencia es simple, siento que me quedé atrás
Empiezo a preguntarme en serio si ya es hora de retirarme del desarrollo profesional de software por viejo
Simplemente significa que no estás familiarizado con un enfoque para escalar organizaciones: el de los equipos de plataforma que abstraen hardware, logging, reintentos, etc.
No es el único enfoque, así que quizá estés familiarizado con otros
Me gusta que este artículo explique de forma clara y ordenada los beneficios y las razones para adoptar Kubernetes
Muchos equipos se lanzan sin saber qué van a ganar, ni si siquiera lo necesitan, pero las razones que presentan aquí parecen razonables
Otros comentarios ya señalaron esto: https://news.ycombinator.com/item?id=41194506 https://news.ycombinator.com/item?id=41194420
Por pura curiosidad: ¿qué otro sistema o servicio moderno podría una persona sensata presumir por haberlo migrado en menos de un año?
Un sistema como Kubernetes suele estar en el núcleo de la infraestructura, así que afecta a todo lo que está corriendo. Si además sumas las restricciones de equipo mencionadas en el artículo, un año no suena tan mal
Un ejemplo que se me viene a la mente es cuando Amazon migró por completo de Oracle a bases de datos relacionales de Amazon/open source. Pero recuerdo que eso tomó varios años. Si lo hubieran terminado en menos de un año, seguro lo habrían presumido
Normalmente es más un problema de deuda técnica, complejidad de integración y personal asignado que de la tecnología en sí