- En una startup en etapa inicial, puede ser mejor dedicar tiempo a crear el producto y encontrar el product-market fit que contar desde el primer día con Kubernetes o autoescalado
- Tener logs dispersos entre 20 a 30 funciones Lambda, SQS y CloudWatch dificultaba la depuración, los cambios y los despliegues; había margen para simplificar con un único contenedor NodeJS o una app Flask/FastAPI y Redis
- En un caso donde se separaron el CRUD y la lógica de negocio en 7 microservicios sobre EKS, se dedicaba más tiempo a operar infraestructura que a desarrollar funcionalidades
- Incluso una sola VM puede ofrecer suficiente capacidad de cómputo para un servicio inicial si se aprovechan opciones como EC2, GCP VM, Hetzner o latitude.sh, y servidores con 40GB de RAM y múltiples cores
- Aun con una configuración simple, para usarla en la práctica hacen falta HTTPS, SSH/SSM restringido, CI/CD, DNS, backups de DB, una VM en espera, recuperación ante desastres, reglas de seguridad y políticas de retención de backups
Cómo aparece una infraestructura excesiva en startups iniciales
- Pieter Levels se presenta como un caso de alguien que opera varios micro-SaaS en un solo servidor, evitando la complejidad de la infraestructura cloud y enfocándose en el product-market fit
- Este enfoque no es la respuesta para todos los equipos, pero muestra bien una situación en la que los despliegues y la gestión de infraestructura se vuelven complejos por la complejidad misma
- Un equipo de desarrollo pequeño después del MVP puede tener dificultades con los despliegues y la administración de bases de datos, pero no todos los proyectos necesitan Kubernetes, sistemas distribuidos complejos y autoescalado desde el primer día
- Una infraestructura simple permite que el equipo dedique más tiempo a crear un buen producto y encontrar encaje con el mercado
- Las empresas de escala enterprise tienen problemas aparte, como compliance y grandes dotaciones de personal, pero una startup en etapa inicial no necesita imitar esa complejidad tal cual
Casos reales: la carga operativa creada por la complejidad
-
Sobrecarga de Lambda
- Había entre 20 y 30 funciones Lambda para distintos servicios
- SQS y varias tareas en segundo plano también estaban configuradas sobre Lambda
- Los logs estaban dispersos por CloudWatch, lo que dificultaba rastrear las causas
- La depuración era dolorosa, los cambios eran complicados y, aun con un monorepo, los despliegues se volvían complejos
- Se podría haber simplificado con un único contenedor NodeJS, una app Python Flask/FastAPI y trabajos en segundo plano basados en Redis
-
Exceso de microservicios
- Había 7 microservicios pequeños ejecutándose sobre Kubernetes EKS
- El CRUD y la lógica de negocio estaban separados en servicios distintos
- Kubernetes es potente, pero ese equipo dedicaba más tiempo a infraestructura que a desarrollar funcionalidades
- Quedaba la duda de si esa separación de servicios era realmente necesaria a esa escala
Por qué el enfoque de un solo servidor es realista
- Una configuración de un solo servidor aprovecha activamente el rendimiento de las VM modernas
- En Hetzner y latitude.sh se pueden conseguir VM potentes y económicas
- Las instancias de GCP VMs y EC2 también están en rangos de precio razonables
- Un servidor con 40GB de RAM y varios cores puede ser una mejor opción que varios servicios distribuidos, varias Lambda y varias tareas ECS
- Tener todo en un solo lugar facilita la operación y la administración
- La escalabilidad a millones de QPS puede abordarse cuando ese momento llegue realmente, y para entonces probablemente ya exista un equipo de infraestructura
- Para operar una sola VM de forma estable se necesitan componentes operativos básicos
- Una máquina robusta como EC2, GCP VM o Hetzner
- Acceso seguro, como HTTPS para la web y SSH con IP restringida o SSM para los despliegues
- CI/CD para despliegues sin downtime
- Configuración de DNS
- Backups regulares de la base de datos
- Una VM en espera para redundancia
- Una estrategia sólida de recuperación ante desastres y un tiempo medio de recuperación probado, algo que puede lograrse con una VM de backup
Docker Compose y Docker Compose Anywhere
- Docker Compose es útil en desarrollo local para gestionar varios servicios con un solo comando, pero se usa menos en producción
- Se menciona que Docker Swarm está deprecated
- Docker Compose puede provocar downtime durante las actualizaciones
- Existe una guía de despliegue en producción, y hace falta equilibrar simplicidad con preparación para producción
- Docker Compose Anywhere es un proyecto de fin de semana para simplificar las configuraciones de una sola VM
- Configura un servidor Linux con un clic mediante GitHub Actions
- Usa GitHub Container Registry y Docker Rollout para soportar despliegue continuo sin downtime
- Ofrece gestión de variables de entorno y secrets, y se está considerando age o sops para mejorar la seguridad
- Proporciona backups automáticos de Postgres basados en GitHub Actions
- Soporta varias apps en una sola VM
- Automatiza SSL con Traefik y Let’s Encrypt
- Permite desplegar apps Next.js, Go, Python, Node.js, entre otras
Principios de seguridad y operación que no pueden faltar aunque todo sea simple
- La seguridad y la protección de datos no pueden omitirse ni siquiera en configuraciones simples
- Se necesitan reglas de firewall estrictas que abran solo los puertos necesarios
- Hay que gestionar las claves SSH de forma segura; en AWS se prefiere SSM y en GCP la CLI
- Se puede usar un bastion host para reforzar la seguridad
- Hay que proteger los secrets y considerar el uso de WAF o Cloudflare
- Enviar backups cifrados de la base de datos a S3 o a un almacenamiento cloud seguro equivalente
- Crear snapshots de disco regularmente para redundancia adicional
- Implementar una política de retención para backups y snapshots
- La prioridad de los ingenieros está en preservar la simplicidad de la configuración y enfocarse en el producto principal
- Es fácil distraerse con configuraciones complejas que imitan la ingeniería de Google o los métodos de grandes empresas, o con herramientas nuevas
- Lo más importante, sea una startup o no, es hablar con los usuarios y encontrar el product-market fit
1 comentarios
Opiniones de Hacker News
En varios proyectos me tocó sudar sangre por culpa de tecnologías de moda.
Aunque el equipo era pequeño, terminaban produciendo resultados de una calidad increíblemente baja con el argumento de que necesitaban “escalabilidad infinita”, y también vi equipos inmaduros que ni siquiera entendían bien qué era LTS decidir que necesitaban Kubernetes.
Hoy tengo código Puppet sencillo que permite crear, con cualquier proveedor, una VM endurecida del tamaño que quiera, y ejecutar sobre ella servicios Docker, un backend en Python o servir archivos estáticos.
Ya sea una VM de Hetzner de 2 núcleos o de 48 núcleos, puedo levantar el servicio en menos de 5 minutos, controlar la configuración con manifiestos bajo control de código fuente y vigilar el cumplimiento de la configuración con plugins personalizados de Naemon.
Es un proceso completamente reproducible, pero los equipos de startups crean en la nube configuraciones únicas tipo copo de nieve, gastan miles de euros al mes y aun así obtienen resultados peores que los que lograban los pioneros de DevOps en 2017.
También escribí un artículo sobre este tema llamado The Emperor's New clouds: https://logical.li/blog/emperors-new-clouds/
Nunca entendí la pregunta de “cómo reproduces la configuración sin Docker u otra tecnología”.
Los scripts eran deterministas, las versiones de las dependencias estaban fijadas, la configuración, los argumentos de entrada y el orden de ejecución eran los mismos, y corrían en una máquina de cómputo determinista.
No había razón para que no se pudiera reproducir.
En vez de decir que tienes Docker en una VM endurecida, puedes decir que tienes kubelet, y con un plano de control de k8s de muy bajo costo puedes controlar todas esas VM, en lugar de varios “docker services” improvisados.
No veo por qué ese enfoque sería mejor; de hecho, me parece peor.
Una mala infraestructura cloud es cuando intentas usar todo lo que vende AWS y toda la infraestructura queda atada a capas de abstracción excesivamente altas, al punto de no poder migrarla a otra plataforma.
k8s no tiene nada que ver con eso.
Si respondes a cualquiera de estas cosas con “algo hecho en casa” o “basta con un script”, precisamente por eso k8s tiene valor.
Si es un backend en Python, basta con reproducir el script de build en el VPS:
pip install requirements.txt>python main.py>nano /etc/systemd/system/myservice.service>systemd start myservice> listo.Para escalar instancias, pones esos comandos en un script bash
build_my_app.sh, que cumple el papel de un nuevo Dockerfile y puede instalarse en cualquier servidor en unas decenas de segundos.Usada como IaaS, permite prototipar mucho más rápido que otros enfoques, incluidos los VPS de otros proveedores.
En particular, Google Cloud genera menos lock-in y se ajusta mejor al principio de mínima sorpresa.
Pero después de crear el prototipo, hay que preguntarse si conviene reconstruirlo en un lugar más barato.
Es bueno poder ampliar el disco casi indefinidamente y tener snapshots, y la nube puede permitir escalar el prototipo hasta cargas de producción para medir el tamaño que realmente se necesita.
Pero cuando dependía de la “magia de la nube” como Cloud Run o Lambda, el tiempo de aprendizaje y depuración acababa siendo casi el mismo que hacerlo a la antigua.
En una startup chica estamos haciendo casi exactamente esto.
Hay partes complejas, como el autoescalado de colas de trabajo con GPU mezcladas, pero el núcleo es una sola VM con nginx, la app web, Postgres y Redis.
Como es B2B, casi no hay tráfico.
Los desarrolladores pueden correr la misma configuración tal cual en sus laptops con Linux o en VMs Linux en otras plataformas, y si quieren, cada uno puede tener también su propia VM en la nube para demos o pruebas.
Inicializar un sistema nuevo es básicamente registrar una clave SSH y ejecutar un script de shell.
Es fácil de depurar, no es complejo ni caro, y se puede escalar verticalmente bastante antes de necesitar escalado horizontal.
No es para todos, pero me parece totalmente adecuado antes de la etapa seed.
Es un nivel de indirección sobre el enfoque de “registrar la clave pública”, y permite que el usuario cambie su propia clave sin cambios en Git.
Además, aunque se aleja bastante de la descripción original, el alquiler de claves SSH maneja mucho mejor los casos de offboarding, así que es muy bueno: https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
Mientras buscaba el enlace, también encontré documentación donde Vault afirma ofrecer contraseñas de un solo uso <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
Pero yo estoy firmemente en el bando de “PasswordLogin no”, así que con eso cada quien debería tener cuidado.
Postgres puede hacer de todo.
En una configuración así, ¿cómo llevan el seguimiento de la configuración y las actualizaciones de la VM?
La respuesta es “no, no hace falta”.
Mi SaaS al principio corría en un solo servidor y, después de lograr encaje producto-mercado, lo moví a varios servidores.
Son servidores bare metal de Hetzner, no hay microservicios y no lidiamos con Kubernetes, pero sí operamos una base de datos distribuida.
Estos servidores bare metal son enormemente potentes comparados con las máquinas virtuales de los proveedores cloud.
Hace unos años incluso hice mis propias mediciones: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
En conjunto, este enfoque es absurdamente eficaz.
No hay que lidiar con complejidades como Kubernetes, se evitan las fallas en cascada que inevitablemente aparecen en sistemas complejos, y se ahorra tiempo de desarrollo y mantenimiento, además de costos mensuales de servidores.
La objeción típica es “¿pero cómo escalas?”, cuando todavía no sabemos si hará falta escalar, y con computadoras tan potentes y un diseño razonable se puede llegar muy lejos incluso con 3 a 5 servidores.
Por supuesto, no estoy diciendo que corras el negocio en el clóset de tu casa.
Para administrar servidores sigue haciendo falta automatización, y yo uso ansible y terraform.
Alimenta el optimismo de que el software va a tener un éxito enorme en muy poco tiempo, y la gente quiere creerlo.
No sé si leíste el artículo o solo el título.
Si bajas hasta la sección A few considerations, probablemente ya no te dé tanta risa.
Esas “pocas consideraciones” son un bloque considerable de trabajo de seguridad, sobre todo si almacenas o transmites información muy sensible.
¿Cómo manejas requisitos de cumplimiento como HIPAA en una situación así?
Hay dos tipos de programadores.
Los que creen que ya lo han visto todo, y los que saben que no han visto casi nada.
Por eso estas afirmaciones absolutas cansan.
El 20% central de Kubernetes son cosas como deployments, pods, services, la forma de manejar despliegues blue-green, las definiciones declarativas y la separación por namespaces, y eso está realmente bien.
Si uno se apega a esos fundamentos simples, usa un servicio de Kubernetes administrado en la nube y deja las bases de datos con estado fuera del clúster, la experiencia es buena.
Los problemas empiezan cuando uno cae en la madriguera de “cloud native” y comienza a usar todo tipo de sistemas open source de nicho, operadores, ambassador, patrones de sidecar, etc.
Esas cosas están pensadas para entornos con varios equipos técnicos independientes pero conectados entre sí, y con diversos lenguajes de programación coexistiendo.
En estas discusiones siento que la gente suele hablar de dos cosas distintas.
Para mí no es más que una forma uniforme de despliegue, mejor que Docker Compose.
Pago muy poco por el plano de control, y los workers son VMs comunes con kubelet.
Pero para mucha gente, “Kubernetes” parece significar el segundo párrafo de arriba.
No hay ninguna necesidad de usarlo así.
Puedes configurar un clúster k3s y aprender solo workloads, services e ingress.
Eso es lo que hace falta para reemplazar VMs improvisadas y configuraciones con Docker.
El 99% solo necesita o quiere algo tipo docker-compose++.
Si trae despliegues sin downtime por defecto y un sistema de configuración simple para replica sets u otros mecanismos de replicación y distribución, con eso casi alcanza.
Me gustaría que existiera algo que hiciera exactamente eso.
Kubernetes trae mucho equipaje, y Docker Compose es un poco demasiado básico para requisitos importantes de producción.
Kubernetes tiene como un millón de perillas y diales que puedes ajustar para cualquier caso de uso, pero también puedes ignorarlos y usar solo las funciones centrales para mantenerlo simple.
Puedes armar rápidamente una configuración con despliegues decentes, logs y métricas muy fáciles, y una buena experiencia para desarrolladores.
Como tiene tan mala fama y yo nunca lo había usado antes, me preparé para lo peor cuando pregunté si podía configurar un servidor para herramientas internas.
En la práctica, la persona que lo había configurado me dio un tutorial de 30 minutos, me explicó todos los conceptos, me dio información suficiente para desplegar el servidor, y lo desplegué sin ningún problema.
También terminé muy rápido de dejarlo con despliegue automático mediante
git push.A mí me pareció una elección demasiado obvia.
Es mucho más fácil de usar si no tienes literalmente un solo servicio.
Eso sí, yo no lo instalé personalmente, así que quizá la mala fama venga de esa parte.
Si no tienes k8s en el CV, ¿quién va a conseguir un nuevo trabajo? :)
Hablando en serio, creo que mucha gente elige a propósito el camino difícil para aprender infraestructura a gran escala.
Otro motivo común es “si conseguimos muchísimos clientes, será mucho más fácil” o “podremos escalar dinámicamente según la demanda”.
Todo eso es válido para quien lo construye, pero no lo es tanto para un fundador o un CTO profesional.
Algunas personas queman dinero construyendo cosas vistosas e inútiles, sin preocuparse por las necesidades ni los plazos de los clientes potenciales.
Es parecido a ir al taller a cambiar las llantas y que el mecánico tarde tres semanas porque, por sus propias ganas de crecer, quiere ponerle hidráulica de lowrider y tapacubos giratorios.
Lo peor es que para la siguiente persona se vuelve esencialmente ambiguo.
No se sabe si algo está ahí porque realmente era necesario o si solo es un adorno brillante.
No sé bien si la gente lo hace por interés, porque le gusta la tecnología o, como dijiste, para subir de nivel tecnocráticamente y poner k8s en el CV.
Yo solo pienso: “eso se ve doloroso de administrar”.
Por eso creo que la infraestructura k8s debería ser diseñada y trabajada por un grupo más reducido de personas realmente expertas, o al menos por expertos que guíen a sus mentees.
Y cuando no hace falta, es decir, en la mayoría de startups, pequeñas empresas y compañías de tamaño normal, conviene mantener paradigmas existentes que sean más fáciles de usar.
Están muy satisfechos con su elección y lo han contado en detalle en su blog.
Es un caso en el que “si conseguimos muchísimos clientes, será mucho más fácil” realmente se cumplió.
Es una discusión vieja y a menudo agotadora, pero igual aporto mis dos centavos.
¿Hay que elegir un framework complejo desde el primer día? Probablemente no, a menos que el equipo tenga suficiente experiencia con eso.
Pero a lo que me opongo es a la idea de que administrar infraestructura con procesos a medida y herramientas custom siempre requerirá menos esfuerzo de mantenimiento que usar herramientas probadas.
Es esa actitud obstinada de rechazar el espantapájaros de la “complejidad”, aun cuando los procesos hechos en casa no son nada simples y le quitan mucho tiempo al producto principal.
A todos les gusta la simplicidad de copiar un binario a un VPS y reiniciar el servicio.
Pero pronto se necesita gestionar configuración y secretos, y cuando hay varios servidores por disponibilidad y redundancia, hacen falta despliegues graduales, balanceo de carga, rollbacks, etc.
También vas a querer un entorno de staging, y ese workflow tiene que poder replicarse fácilmente.
Cuando el equipo crece, también se hace evidente que no se puede correr localmente un entorno parecido a producción.
Y así se siguen sumando requisitos.
Al final, para cada requisito nuevo, en vez de apoyarte en soluciones estándar que otros ya resolvieron, tienes que resolverlo a tu manera especial.
Más adelante se convierte en un problema de costos hundidos.
¿Vas a abandonar herramientas custom que conoces y entiendes para pasarte a una “complejidad” que no conoces?
Cuanto más inviertas, más difícil será migrar después.
Mi propuesta es adoptar desde el principio prácticas que faciliten pasarse luego a herramientas estándar.
Es decir, desplegar con contenedores desde el día 1 y adoptar la metodología de 12 factores, por ejemplo.
Y cuando empieces a sufrir por funcionalidades que necesitas, conviene pasarse a herramientas probadas más temprano que tarde.
Es muy probable que descubras que el miedo a lo desconocido no tenía fundamento, y que a largo plazo dedicarás menos tiempo a la infraestructura.
Un enfoque que estuve considerando es empezar desde el primer día con herramientas estándar, es decir k8s + gitops, pero aun así corriéndolo en una sola VM.
¿Qué opinan?
En cambio, sí se encuentran muchos “ingenieros cloud” que entienden estos sistemas cloud “complejos” y pueden desplegarlos y mantenerlos con terraform.
Es un conjunto de habilidades listo para usar.
VM, almacenamiento de bloques/blobs, DNS, IdP, registrador de dominios.
Eso es prácticamente lo único de la nube que he usado con comodidad.
Cuando se entra en FaaS y sus amigos, para mí se vuelve realmente raro.
Me cuesta aceptar no poder mirar dentro de las máquinas donde corre el entorno de producción.
La experiencia de depurar desde un dashboard cloud es pésima.
Creo que el enfoque de Microsoft es lo más cercano a algo que realmente “funciona”, pero aun así es horrible y no quiero volver a tocarlo.
Diez años después, mi arquitectura ideal sigue siendo una base de código monolítica en una sola VM comunicándose con instancias locales de SQLite.
La llegada del almacenamiento NVMe le dio bastante fuerza a este enfoque.
Los backups se manejan con snapshots del dispositivo de bloques, y la durabilidad transaccional, si hace falta, con replicación WAL.
Es ridículamente simple.
Te permite enfocarte en el negocio y en los clientes.
A los clientes no les importa nada de esto, y no van a pagar por ello.
Todo código e infraestructura es un factor netamente negativo, así que hay que tener lo menos posible.
Cuando la gente dice que la nube es más cara que on-premise, muchas veces esta es la razón.
Si vas a tener una VM corriendo 24/7, hay mejores opciones.
Incluso los libros sobre microservicios dicen que primero construyas un monolito.
Antes de obtener reacciones de usuarios reales, no sabes cómo deberías dividir el sistema, y es más fácil partir un monolito que reorganizar servicios.
Puede que nunca necesites dividir el monolito.
Stripe terminó separando algunas partes de su monolito Rails, pero un monolito llega sorprendentemente lejos.
Es difícil que algo sea más fácil de depurar que un monolito tipo Django/Rails.
Dicho eso, ayuda mirar un poco hacia dónde podría ir la infraestructura.
La versión inicial de nuestra empresa se hizo con un contenedor Docker de Django en una sola VM, y el despliegue era manual:
docker pull; docker stop; docker start.Esa configuración aguantó más de lo que esperábamos.
Docker es una buena forma de evitar el problema del empaquetado de dependencias.
Al principio pueden ser molestos problemas como si el servidor tiene los headers C necesarios cuando instalas un nuevo driver de DB, o si la configuración difiere de la de una Mac.
Después de nuestra ronda de extensión seed, nos pasamos a k8s por necesidades de negocio de confiabilidad y escalabilidad, y k8s nos sostuvo bien hasta la Serie B.
Tener todo dockerizado hizo fácil la transición, pero en la etapa inicial redujimos la complejidad de forma agresiva.
Y hay que usar bien el framework, no volver a crear versiones mediocres de las funcionalidades que el framework ya ofrece.
En este aspecto, una persona experimentada logra mejores resultados que diez inexpertas.
Con el tiempo, la diferencia se acumula.
Creo que la mitad de la verdadera razón por la que la gente se cansa de los monolitos es que se trata de monolitos malos y mal operados.
Dicen que los datos deben almacenarse en su propio servicio, y si necesitas un enfoque multiparadigma como relacional y búsqueda de texto completo, pueden terminar siendo varios servicios.
La experiencia de usuario también debería usar su propio servicio.
Como mínimo tiene que haber otro servicio entre medio, y normalmente Django y Rails entran ahí.
Opcionalmente, dicen que también pueden hacer falta servicios adicionales como autenticación y transacciones financieras.
Operé un proyecto durante unos 6 años en un solo VPS de 10 dólares al mes.
En realidad pagaba menos gracias a un descuento permanente que conseguí en lowendtalk, y era un proveedor de VPS enfocado en servidores de juegos.
Salvo una vez que estuvo caído todo un día porque arruiné la configuración y tuve que reinstalar el OS desde cero, y otra vez en que el proveedor cambió la dirección IP con aviso previo, tuvo una estabilidad casi de nivel 99.999.
La tecnología VPS ha avanzado muchísimo y es muy estable.
Los discos de los nodos están configurados en RAID 1, y durante el mantenimiento de nodos la propia VM también puede migrarse en vivo fácilmente a otra máquina.
También se pueden tomar snapshots.
Para mí, elegiría infraestructura cloud no por una mayor estabilidad, sino por funciones de colaboración y gestión operativa como IAM, gestión de secretos e infraestructura como código, o por razones de cumplimiento del centro de datos como HIPAA.
Depende de la situación
Personalmente, me gustan las soluciones basadas en la nube porque ahorran mucho tiempo
Pero hay que ser muy selectivo con lo que se usa, y también hay soluciones tan complejas que claramente terminan siendo contraproducentes
Dirijo una pequeña startup autofinanciada
No nos alcanza ni para pagarnos sueldos, y yo vivo de consultorías como trabajo paralelo
Con presupuesto y tiempo tan limitados, tenemos que ser muy cuidadosos con qué usamos
Por eso me gustan cosas como Google Cloud
Nuestra factura de GCP es bastante baja, de unos cientos de euros al mes
Podríamos mudarnos a un proveedor más barato, pero es difícil justificar esa inversión de tiempo y, comparado con AWS, que usé antes, también me gustan la UI y las herramientas de Google
No tenemos uso para Kubernetes
Solo el costo de mantener un clúster vacío probablemente sería más alto que nuestra factura mensual actual de GCP
Tampoco lo necesitamos porque no caímos en la trampa de los microservicios
Pero sí me gusta Docker
Hace que desplegar software sea ridículamente fácil
Nuestro sitio web es un bucket de Google Storage servido a través de un balanceador de carga y Google CDN
Ese mismo balanceador de carga enruta las llamadas REST a dos VM que ejecutan un monolito
Estas VM se comunican con una DB administrada, Elasticsearch administrado y Redis administrado
La DB y Elasticsearch son caros, pero usarlos como servicios administrados ahorra mucho tiempo y esfuerzo
Eso es prácticamente todo lo que tenemos, y es simple y no tan caro
Si moviéramos todo a un lugar como Hetzner, probablemente podríamos reducir los costos alrededor de un 50%
Puede que valga la pena intentarlo, pero para mí no es algo muy urgente
Perder esos servicios administrados me haría la vida más difícil
Además, algunos clientes parecen preferir AWS, así que quizá algún día tengamos que volver a AWS; también está ese punto