Estoy construyendo una nube
(crawshaw.io)- Las abstracciones de nube existentes dificultan combinar y usar CPU, memoria y disco de la forma deseada, y tanto las VM como el PaaS imponen más restricciones que una computadora común
- El almacenamiento en bloques remoto y los altos costos de egress mantienen una estructura atada a supuestos de la era de los HDD, agravando los problemas de rendimiento y costo en entornos de SSD y redes modernas
- Kubernetes cubre las API de nube difíciles de manejar, pero no puede cambiar la abstracción base equivocada, así que sigue cargando con los límites de las VM, el disco y la red
- A medida que los agents aumentan la demanda de software y de ejecución, se vuelven más importantes los espacios de ejecución privados, el uso compartido fácil y el bajo overhead operativo, y al mismo tiempo crecen los cuellos de botella estructurales de la nube actual
- exe.dev busca acercarse a la nube que realmente se quiere usar asegurando primero CPU y memoria, ejecutando VM directamente encima, y combinando TLS proxy, proxy de autenticación, NVMe local, replicación asíncrona y despliegue basado en anycast
Por qué volver a construir una nueva nube
- Las abstracciones de nube existentes dificultan usar las computadoras de la forma deseada, y esa fue la razón directa para iniciar una nueva empresa
- Las computadoras en sí son buenas, pero en la nube actual las restricciones se repiten en casi todos los productos, y el núcleo del problema se parece más a la forma de las unidades básicas de construcción que a simples fallas de UX o diseño de API
- Las VM se ofrecen como instancias individuales atadas a CPU y memoria, pero lo deseable sería una estructura donde primero se reserven recursos de CPU, memoria y disco, y encima de eso se levanten tantas VM como hagan falta
- Una VM de Linux es un proceso que corre dentro del cgroup de otro Linux, y aun así en la nube actual no es fácil manejar eso
- Para esquivarlo hay que montar gVisor o virtualización anidada sobre una sola VM de nube, asumiendo una pérdida de rendimiento y además la operación de al menos un reverse proxy
- El PaaS tampoco resuelve este problema, y más bien obliga a usar abstracciones dependientes del proveedor menos poderosas que una computadora normal
- Hay que aprender una nueva forma de desarrollar para cada proveedor de cómputo
- A veces solo cuando el proyecto ya avanzó bastante se descubre que tareas sencillas en una computadora normal son casi imposibles por limitaciones profundas de la plataforma
- Se repite una y otra vez la sensación de “ahora sí se puede”, hasta volver a chocar con abstracciones implementadas a medias
Límites estructurales visibles en disco y red
- En disco, los proveedores de nube prefieren el almacenamiento en bloques remoto o métodos aún más restringidos y lentos como S3, algo que en la era de los HDD era relativamente razonable
- El almacenamiento remoto no sufría una gran desventaja en lecturas y escrituras secuenciales, y como el random seek de los HDD estaba alrededor de 10 ms, un RTT de 1 ms por Ethernet era un costo aceptable
- Desde la perspectiva del proveedor, eso facilitaba la operación al eliminar un eje de los tipos de instancia estándar
- Pero con la transición a SSD, ese supuesto dejó de ser válido
- El tiempo de seek bajó de 10 ms a 20 microsegundos
- El RTT de red de los sistemas remotos por bloques mejoró, pero el overhead de IOPS pasó de alrededor de 10% en la era HDD a más de 10 veces en la era SSD
- En EC2, configurar 200k IOPS es complejo y cuesta 10 mil dólares al mes, mientras que una MacBook ofrece 500k IOPS
- La tecnología de red en sí es suficientemente buena, pero los costos de egress y la estructura del negocio terminan bloqueando la usabilidad
- Las redes de los hyperscalers son excelentes, pero muy caras y además dificultan la interoperabilidad con otros vendors
- La tarifa de egress de los proveedores de nube se presenta como aproximadamente 10 veces el costo por GB de rackear servidores en un datacenter común
- Cuando el uso sube un poco, ese múltiplo empeora todavía más
- Los clientes que gastan decenas de millones de dólares al mes pueden obtener mejores precios, pero eso no sirve para proyectos de decenas o cientos de dólares mensuales
- En ese rango, sin importar lo que se construya, se vuelve difícil operar barato
Kubernetes y las API tapan el problema, pero no lo resuelven
- Las API de nube son dolorosas de manejar, y Kubernetes apareció para cubrirlas y reducir ese dolor para los ingenieros
- Pero las VM siguen siendo difíciles de manejar incluso sobre Kubernetes, porque la nube simplemente traslada encima la virtualización anidada
- Con el disco pasa algo parecido: cuando se diseñó Kubernetes, del lado de Google prácticamente no había un dispositivo remoto por bloques realmente útil, y aun hoy, incluso si se logra ajustar un patrón común, se termina atado con facilidad a almacenamiento lento
- En red ocurre lo mismo: si se abriera esto con facilidad, sería posible conectar parte de sistemas en datacenters abiertos cercanos mediante private link y borrar un cero del costo de nube, así que no hay mucho incentivo para facilitarlo
- Más que descartar Kubernetes como trabajo artificial, se lo ve como el resultado de enfrentarse a un problema imposible: construir una nube portable y usable
- En el fondo, no se puede resolver montando una nueva abstracción sobre una abstracción de nube equivocada, y hasta mejorar Kubernetes tiene límites muy claros
- Ya van 15 años conviviendo con esta nube incómoda, y durante ese tiempo la estrategia fue soportarla como otras partes desagradables del stack de software y minimizar el contacto
Este es el momento de corregirlo
- El motivo por el que ahora es un punto de inflexión es la aparición de los agents
- Como en la paradoja de Jevons, cuanto más fácil se vuelve escribir código, más aumenta la cantidad total de software, y cada persona termina usando más programas tanto en el trabajo como en sus hobbies
- Para ejecutar esa cantidad creciente de programas se necesitan espacios de ejecución privados, uso compartido sencillo y poco overhead operativo
- Cuanto más crece el volumen total de software, más se transforman en un gran cuello de botella problemas de nube que antes solo eran molestos
- Se necesita más cómputo y además que sea más fácil de administrar
- Los agents ayudan a manipular la API de AWS, pero requieren entregar credenciales y a veces podrían borrar la base de datos de producción
- Sobre todo, los agents también chocan contra las mismas limitaciones fundamentales de las abstracciones de nube actuales
- Se terminan gastando más tokens de los necesarios y los resultados son peores de lo esperado
- Cuanto más se gasta la context window de un agent en forzar la nube clásica, menos margen queda para resolver el problema real
Lo primero que empezó a corregir exe.dev
- Lo primero que lanzó exe.dev fue una solución al problema del aislamiento de recursos para VM
- En lugar de aprovisionar VM individuales, ofrece una estructura en la que primero se reciben CPU y memoria, y encima de eso se ejecutan directamente las VM que uno quiera
- Partiendo de la idea de que no se quiere exponer una VM nueva directamente a internet, maneja en conjunto un TLS proxy y un proxy de autenticación
- Para disco usa NVMe local y replica los bloques fuera de la máquina de forma asíncrona
- Permite tener máquinas en varias regiones del mundo para que se ejecuten cerca de la ubicación del usuario
- Las máquinas se despliegan detrás de una red anycast para ofrecer puntos de entrada de baja latencia a usuarios de todo el mundo
- Sobre esta base está diseñado para poder agregar pronto nuevas funciones
- Todavía queda mucho por construir
- Quedan elementos relativamente claros, como una IP estática
- También quedan retos como la UX para acceder a snapshots históricos de disco generados automáticamente
- Al mismo tiempo, se está volviendo a la etapa de rackear computadoras directamente en datacenters y reconsiderando todas las capas del stack de software, incluida la forma de conectividad de red
- El objetivo final es construir la nube que realmente se quiera usar
6 comentarios
Al principio pensé: “¿por qué ahora?”..
Pero al ver que el autor es cofundador de Tailscale, de alguna manera me dieron ganas de apoyarlo.
¡Por favor, hagan un buen producto!
La tabla de precios es muy confusa, porque dice cosas como 2 núcleos, 8 GB, 50 VM, etc. Creo que hay que entenderlo como que te dan una VM y puedes ejecutar 50 contenedores en ella.
La nube es compleja por una razón.
No veo la opción para darse de baja, ¿alguien la encontró?
Estaría bueno poder conectar servicios entre sí con solo arrastrar y soltar.
Comentarios en Hacker News
Kubernetes al principio puede parecer bien para correr unos cuantos contenedores de una webapp, pero pronto le terminan montando SDN y toda clase de servicios, y se vuelve incontrolablemente enorme
Cuanto más “optimizaban” y “endurecían” el clúster, más se multiplicaban por 2 o 3 los costos de cloud, las fallas, el downtime y el esfuerzo de depuración
Al final dejaron esa inercia de DevOps, eliminaron el clúster y desplegaron Docker con Kamal en una VM única con Debian y firewall activado; con eso lograron la mejor estabilidad y confiabilidad de infraestructura, además de bajar mucho el costo
La mayoría de las apps de negocio tienen cientos o miles de usuarios, así que muchas veces basta una VM grande; además, clouds como Google ya resuelven las fallas de hardware, así que solo hace falta levantar una segunda VM cuando sea necesario y cambiar la IP en Cloudflare
Es muy común meter k8s en escalas demasiado pequeñas, y en esos casos probablemente desde el inicio no era una escala que necesitara k8s
Por eso hace falta una capa superior que simplifique los patrones de despliegue más comunes, y Knative es un ejemplo de eso
Cualquier solución que intente exponer todos los primitives base inevitablemente termina siendo tan compleja como Kubernetes
Lo que hice en https://github.com/openrundev/openrun es manejar de forma declarativa los despliegues internos de webapps para equipos, con SAML/OAuth y RBAC, y soporte tanto para Docker en una sola máquina como para Kubernetes
Esa forma de pensar, excesivamente compleja, difícil de depurar y cara, puede reproducirse igual en VMs
Solo que ahora la VM única con Debian quizá está fuera del radar de sus políticas y por eso sigue libre
Cuando alguien se meta, probablemente intentará agregar HA, rollout/rollback, 3 a 5 VMs, políticas de red virtual, 4 escáneres de seguridad, 2 procesadores de logs, watchdog, monitoreo de red, mTLS y herramientas de visibilidad de tráfico
Tener una más reduce la ansiedad si algo falla durante upgrades o cambios
Lo que estoy construyendo en https://github.com/psviderski/uncloud, inspirado en Kamal, busca hacer que una configuración de múltiples máquinas sea tan simple como una VM única, usando un overlay WireGuard sin configuración y Docker Compose estándar para desplegar en varias VMs
Se puede empezar con 1 sola máquina, sin complejidad de orquestador ni control plane, y escalar cuando haga falta mezclando VMs de cloud y on-prem
Lo usé en producción y me encantó en todo momento; me pareció casi una redefinición de la computación misma
Por eso siento que quizá me estoy perdiendo la perspectiva del lado que lo odia tanto
El OP es uno de los cofundadores de Tailscale, así que por contexto resulta todavía más interesante
Parece acertado señalar que las empresas tradicionales de Cloud 1.0 te dan por defecto algo así como 3000 IOPS en una VM, mientras una laptop puede dar 500 mil IOPS
La visión me parece muy buena, e incluso siento que soy exactamente el cliente objetivo, pero me preocupa que mientras más éxito tenga, más termine siguiendo el camino conocido donde la presión por ingresos supera al ideal
Muchas veces los precios de cloud no están basados en costos, y suelen diseñarse para dejar márgenes fuertes sobre todo en rubros como bandwidth o NAT gateway, que suben fuerte una vez que el cliente ya quedó profundamente amarrado
No creo que OP desconozca esa estructura
El problema es que ese storage es básicamente ephemeral y tampoco tiene suficiente redundancia
Se puede reducir el riesgo de falla de hardware con RAID1, pero eso limita cuántos NVMe puedes conectar, y tampoco hay una forma limpia de mover la VM si hay otros problemas del host como RAM o CPU
Al final esas VMs casi tienen que tratarse como bare metal y hace falta redundancia a nivel de aplicación, como replicación de base de datos
En Azure hay que asumir que ellos pueden mover la VM cuando quieran y borrar los datos ephemeral, pero en OpenStack podíamos apagar la VM si hacía falta y copiar también los datos NVMe a otro host con migración local a nivel de bloques
Aun así, si el host crasheaba, esa VM quedaba caída hasta que el host volviera, así que la redundancia a nivel de app era un requisito
Pero la latencia percentil 99.9 era de unos 5ms en Hetzner y 18ms en DO, y la latencia máxima era de 7ms en Hetzner contra 85ms en DO, así que sí había una diferencia importante
En dd secuencial, Hetzner dio 1.9GB/s y DO 850MB/s
Y en precio también hay mucha diferencia: Hetzner cuesta 4 euros y la instancia de DO 18 dólares
Lo escribí antes de terminar el texto, y justo OP también estaba señalando exactamente esas dos cosas
Incluso un servidor simple queda mal parado para usar una base de datos local a la máquina, lo que puede ser una forma de impulsar el lock-in
Esa idea de “hacer una unidad cuesta X, así que el precio es 1.y*X” está bastante lejos de cómo se fija precio en el mercado real
Un enfoque top-down suele ser más realista que uno bottom-up
Así como el debate alrededor de la AI se va a extremos, con Kubernetes parece pasar exactamente lo mismo
He operado clústeres de distintos tamaños durante años, y nunca tuve una falla cuya causa fuera k8s en sí
Una vez sí hubo una caída de una hora, casi como un apagón total, y todo el grupo que odiaba k8s quiso culpar de inmediato a ese “maldito sistema k8s”
La causa real fue que el servicio, en cierta situación, abrió decenas de miles de puertos casi instantáneamente y se hizo un DOS a sí mismo
No creo que k8s sea el futuro absoluto ni que sea basura; me parece un buen sistema cuando de verdad se necesita
Uno es que es demasiado complejo de aprender, no hace falta para mi problema y con el despliegue tradicional alcanza; el otro es que frente a bare metal tiene peor eficiencia de costo/energía
Por lo general ambos van juntos
Las posturas moderadamente neutrales o indiferentes se están volviendo raras, y también hace pensar de inmediato en la política de Estados Unidos
Yo tampoco entiendo mucho de k8s y cuando un staff engineer empieza a hablar de pods y clústeres se me pierde la mirada, pero a nuestro equipo le sirve y realmente funciona
Para quien solo tiene martillo, todo parece un clavo; y quien trae un hacha se pregunta por qué todos quieren partir madera con martillo
Incluso cuando el trabajo sí requiere hacha, si el del martillo te quita el puesto, se vuelve fácil odiar al martillo
En muchos casos de uso de k8s ya hay best practices relativamente claras, pero en el mundo de los LLM todavía ni siquiera está claro qué cuenta como best practice
Me identifico mucho con la crítica de que las VMs están atadas a CPU/memoria y que terminas pagando por tiempo, no por trabajo
Por eso compré un servidor de subasta barato de Hetzner y lo corro sobre un orquestador self-hostable de Firecracker que hice yo
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
Lo que quería era comprar hardware, dividirlo en VMs libremente y olvidarme del provisioning y del ciclo de vida
Las VMs inactivas guardan su estado de memoria en disco y devuelven toda la RAM, así que el hardware es mío, las VMs son desechables y cuando no están haciendo nada casi no cuestan nada
En especial, descubrir que con memory-state snapshot todo se vuelve reanudable fue muchísimo más poderoso de lo que esperaba
Puedo dejar snapshot de un Chromium con sesión iniciada y levantar al instante clones de esa sesión cuando haga falta; los agentes trabajan dentro del sandbox y también corro ahí docker compose para entornos de preview
Cuando no corre nada, el servidor está prácticamente idle, y una sola caja de 100 dólares al mes maneja todo esto
Lo explican con más detalle en https://shellbox.dev/blog/race-to-the-bottom.html
La documentación es completa y útil, pero en buena parte se nota el toque de texto escrito por AI, y me gustaría que fuera un poco más concisa
Aun así, la sección de “design decisions” me gustó especialmente y aprendí cosas nuevas ahí
Si todavía no lo hiciste, podría valer la pena subirlo a Show HN
Ya hay demasiado software que nadie usa, así que no termino de entender por qué tanta obsesión con producir todavía más código
Basta ver el app store para encontrar montones de software que nadie usa
Me parece que el uso más evidente de los LLM no debería ser crear más software, sino crear mejor software
Ojalá el foco deje de estar solo en generar código y se mueva en otras direcciones; hay muchas formas en que los LLM pueden ayudar a escribir mejor código
La imagen del sistema determinista, cuidadosamente construido, mantenido y actualizado va a seguir existiendo, pero la AI ya está cambiando la forma en que los usuarios interactúan con la computadora
Como resultado, probablemente veremos mucho más software casi desechable
Ahora mismo seguimos en la etapa de “¿cómo ayuda la AI a que un ingeniero escriba software?”, pero creo que poco a poco estamos pasando a “¿qué puede hacer un ingeniero para que la AI escriba mejor software?”
Eso traerá una nueva generación de ingenieros con una visión completamente distinta de qué es el software y cómo hay que construir la interacción con las computadoras
Probablemente veremos muchísimo software hecho a medida que nunca llegará al app store
Para que aplique, tendría que bajar el costo unitario de producir software pero subir el gasto total porque el aumento de demanda supera por mucho ese ahorro
El concepto se cumple en mercados donde la cantidad demandada responde fuertemente a cambios de precio, es decir, donde hay alta elasticidad de la demanda
Salvo en juegos, algún día quizá miraremos hacia atrás y veremos lo raro que era intentar crear un solo software para cientos de millones o miles de millones de personas
Ahora la gente podrá depender menos de prioridades cruzadas o modelos de negocio distorsionados, y hacer software que haga exactamente lo que realmente quiere
Por definición, ese software también podría considerarse de mayor calidad
Eso facilitaba prever costos e ingresos para ambas partes, pero el punto central era construir software lo más genérico posible
Como resultado, se seguían descartando UX o funciones importantes solo para ciertos usuarios
El vibe coding y el desarrollo acelerado por LLM podrían darle la vuelta a eso
Ahora todos podrían costear software adaptado a sus necesidades y preferencias, y se puede imaginar un mundo donde, en vez de que 150 mil clientes de Salesforce usen el mismo CRM, existan 150 mil CRMs personalizados
El margen de expansión del software ahora es enorme
Si no entiendes el ciclo de engordamiento del software, vas a seguir repitiendo los mismos errores
Se empieza con software lean, se van acumulando funciones pedidas por usuarios, termina en un desastre bloated, luego hace falta un rewrite más pequeño, y se vuelve otra vez a software lean
Los reinicios suelen fracasar, o si no, aciertan algo fundamental y avanzan lo suficiente como para amenazar al incumbente
Esa visión que reduce DevOps a adornar el currículum o a ser la fuente de complejidad excesiva me suena más a mentalidad de startup
En empresas pequeñas tal vez una sola persona de DevOps se encargue de toda la infraestructura, pero especialmente en finanzas, quienes realmente llevan la dirección suelen ser los MD de platform engineering
Ellos dividen a los ingenieros de software en muchos grupitos pequeños y quieren que cada equipo controle su propio repo, su propio despliegue y todo lo suyo, y creen que los microservices les dan ese poder
Te aseguro que al lado de DevOps no le gusta la complejidad
Son ellos a quienes llaman de noche y en fines de semana, y casi siempre todo empieza bajo la suposición de que “es un problema de infraestructura”
Aunque los logs de despliegue están todos en el sistema de agregación de logs, rara vez el desarrollador revisa esos logs y resuelve por sí mismo su problema de despliegue; enseguida se convierte en un Incident
Ya va siendo hora de considerar a los microservicios como una moda pasada
exe.dev me pareció bueno, y sí veo una oportunidad clara en suavizar el flujo de desarrollo con LLM mientras se ofrece la flexibilidad de una máquina Linux con root
Pero cuando leí la frase “me traicionaron una y otra vez abstracciones medio implementadas y medio pensadas”, irónicamente sentí que eso mismo describe mi experiencia con Tailscale
Se supone que simplifica la red, pero entonces la batería se drena demasiado rápido, las reglas de firewall quedan modificadas y chocan con otras herramientas, el bug tracker está silencioso, y al final termino teniendo que entender yo mismo la implementación interna
Y eso me hace decir “No thank you”
El servicio en sí se ve realmente genial
Lo que intento no es escribir ACLs de router, sino definir una capa de red peer-to-peer, y ahí es donde siento la carencia
Yo simplemente uso Hetzner
Todo lo que ofrecen las empresas de cloud me parece demasiado caro, y mi Postgres HA con backups autogestionados ha funcionado sin interrupciones durante 10 años costando más o menos una décima parte de lo que costaría RDS o CloudSQL en producción
Hago autoscaling de instancias yo mismo con métricas recolectadas en Grafana, y un autoscaler basado en webhooks también funciona de manera muy simple y nunca ha dado problemas
Así que ya no tengo muy claro por qué debería usar GCP o AWS
Todos los servicios están en HA y los backups diarios salen muy bien
En ese momento la meta era recrear de manera barata la experiencia de un dedicated server, que era la más flexible de todas, y UML hacía eso posible
Pero durante toda la década de 2010 me equivoqué por completo al pensar que la mayoría de los desarrolladores no elegiría, por un poco de conveniencia, una pila donde cada pieza se cobra por separado según uso
Me pregunto si los ingenieros de software veinteañeros de hoy todavía saben montar una plataforma de webapps de alto tráfico con servidores y routers comprados en eBay
Yo hice exactamente eso el año pasado para un datastore de más de 50PiB, y de verdad me intriga cuánto se usa este enfoque en proyectos medianos o grandes
Hetzner elimina gran parte de la molestia física pero conserva casi toda la ventaja económica, así que me desconcierta que no sea el rey absoluto del mundo del hosting y que en 2021 apenas estuviera en ingresos de 367 millones de euros
También me cuesta creer que el conocimiento necesario para manejar un lote de dedicated servers se haya vuelto tan especializado como para que la gente ignore un ahorro de este tamaño
Aun así, es cierto que si puedes conseguir a la gente correcta, operar por tu cuenta puede salir muchísimo más barato
Cada minuto cron hace
docker pullde la imagen más reciente, y solo cuando hay nueva versión hacedocker up -dpara reemplazarlaAdelante uso caddy para HTTPS, y así lleva años funcionando de forma muy barata y estable
Parecía una empresa del Reino Unido con una filosofía parecida; todavía no la he usado, pero ya me abrí cuenta como posible candidata para mi próximo VPS
Muchas veces ni siquiera hace falta autoscaling si desde el inicio puedes pagar un servidor 5 veces más rápido
Ya existen muchas alternativas, y yo hice https://shellbox.dev
A diferencia de exe, cobra solo por lo que usas, puede hacer scale-to-zero y te deja levantar una VM al instante por SSH
Como es Linux normal, también soporta VSCode remote y Zed remote, y permite nested virtualization
Si alguien quiere invertir, con 5 millones de dólares también me sirve
No hay puertos expuestos hacia afuera, y todos los frontends web están protegidos con contraseña
No pienso publicarlo; es mi entorno de desarrollo aislado corriendo en una Raspberry Pi personal detrás de la TV
El costo es prácticamente cero
Ojalá al servicio le vaya bien
No queda claro dónde corre realmente la infraestructura base ni qué garantías de seguridad ofrece, así que cuesta entregarle workloads