⏱️ Lectura: 13 min
David Crawshaw, cofundador y ex CTO de Tailscale, anunció esta semana el levantamiento de capital para exe.dev, una nueva plataforma cloud construida desde cero para arreglar lo que, según él, los hyperscalers hicieron mal hace 15 años y nadie se atrevió a repensar. La tesis es directa: las máquinas virtuales, el almacenamiento en bloque remoto y el networking que vende AWS, Google Cloud y Azure tienen la forma equivocada para la realidad de hardware del 2026. Y esa forma equivocada es lo que hace que Kubernetes exista tal como lo conocemos.
📑 En este artículo
La carta personal que publicó Crawshaw en su blog el 22 de abril de 2026 acompaña al anuncio oficial de exe.dev y deja una frase que resume el espíritu del proyecto: “me gustan las computadoras”. Detrás de ese tono casi ingenuo hay una crítica técnica muy concreta contra la abstracción cloud moderna, con números que duelen y que cualquier ingeniero que haya pagado una factura de AWS puede reconocer de inmediato.
Qué pasó: el anuncio de exe.dev
Crawshaw formalizó el fundraising de exe.dev con un mensaje doble. Por un lado, el comunicado corporativo —seguro, medido, diseñado para inversionistas y prensa técnica—. Por otro, un post personal titulado “I am building a cloud” en el que explica por qué, después de construir Tailscale y verla convertirse en una de las piezas de red más queridas por desarrolladores, decide lanzarse de nuevo al dolor de arrancar una empresa desde cero.
La respuesta corta del autor es que los clouds actuales no lo dejan hacer lo que quiere con las computadoras. Quiere comprar CPU, memoria y disco, y correr encima tantas máquinas virtuales como le dé la gana. Quiere SSD local con las latencias reales de un SSD. Quiere salir a internet sin pagar diez veces el precio de un rack en un datacenter normal. Y quiere hacer todo eso con APIs que no parezcan diseñadas por un comité.
Contexto: quién es Crawshaw y por qué esto importa
Crawshaw no es un outsider haciendo ruido desde afuera. Fue cofundador y CTO de Tailscale, la empresa que tomó WireGuard y lo convirtió en una mesh VPN que funciona sin que el usuario tenga que pensar en puertos, NAT ni firewalls. Antes trabajó en Go durante años en Google, donde se involucró directamente en el diseño del runtime y las herramientas del lenguaje. Es, en otras palabras, alguien con credibilidad técnica suficiente para que la industria lo escuche cuando dice que la capa fundamental del cloud está rota.
Su historia con el tema tiene raíces profundas. Tailscale nació en parte porque el networking moderno es una jaula. Las VPCs cerradas, los peering acuerdos costosos y el egress caro empujan a los equipos a soluciones complicadas para algo que debería ser simple: conectar dos computadoras. Con exe.dev, Crawshaw extiende esa misma crítica a la capa de cómputo y almacenamiento.
La incomodidad con el status quo
Quien haya intentado armar una arquitectura medianamente seria en AWS o GCP conoce la sensación. Todo empieza bien —una VM, un bucket, un load balancer— y de repente estás escribiendo Terraform para configurar IAM roles, políticas de KMS, VPC endpoints, gateway NAT, y mil detalles que no tienen nada que ver con el producto que quieres construir. Cada cloud te obliga a aprender su propio lenguaje de abstracción, y cuando cambias de proveedor descubres que ninguna de tus decisiones es portable. Crawshaw lo resume sin piedad: “cada producto cloud que pruebo está mal”.
Datos y cifras: la aritmética que mata
La parte más contundente del manifiesto es cuando Crawshaw baja al detalle numérico. Tres frentes quedan expuestos: VMs, disco y red.
VMs atadas a CPU y memoria
En los clouds actuales, cuando compras una VM compras un tamaño fijo de CPU y memoria. Si quieres correr varias VMs dentro de esa VM —por ejemplo, para aislar workloads de clientes distintos—, tienes que recurrir a gVisor o virtualización anidada, que introducen una penalización de rendimiento y te obligan a implementar tu propio reverse proxy para exponerlas. El argumento de Crawshaw es que esa estructura no tiene sentido: una VM Linux es simplemente un proceso corriendo en un cgroup de otro Linux, y debería poder correr tantas como permita el hardware real, no lo que diga el menú del proveedor.
Disco remoto: el costo oculto del SSD
Aquí están los números más llamativos. Cuando los clouds introdujeron almacenamiento en bloque remoto, tenía sentido: los discos eran HDDs con seek times de 10 milisegundos. Pagar un RTT de red de 1 ms extra era aceptable, un overhead del 10%. Hoy los SSDs tienen seek times de 20 microsegundos. El mismo 1 ms de red ahora es un overhead de más de 10x.
Crawshaw compara: configurar una instancia EC2 con 200.000 IOPS cuesta alrededor de USD 10.000 al mes. Una MacBook común tiene 500.000 IOPS de fábrica. La infraestructura cloud está, literalmente, más lenta que el laptop del desarrollador, y se cobra una fortuna por ello.
⚠️ Ojo: esto no es un detalle de optimización. Bases de datos, colas, motores de búsqueda y cualquier sistema I/O-intensive que corra en cloud está pagando un peaje gigante contra SSD local. Si alguna vez te preguntaste por qué Postgres en RDS se siente lento, ya tienes la respuesta.
Networking: 10x el precio del rack
El precio estándar de un GB de egress desde un hyperscaler es aproximadamente 10 veces lo que cuesta en un datacenter normal con un rack propio. A volúmenes medios, el múltiplo es peor. Solo cuando firmas contratos de millones de dólares al mes los precios se vuelven razonables, lo cual excluye al 99% de los proyectos reales. Crawshaw es claro: la tecnología subyacente funciona bien; los límites son artificiales y diseñados para que nada de lo que construyas pueda ser barato.
Impacto y análisis: por qué Kubernetes es un síntoma
La crítica de Crawshaw a Kubernetes es interesante porque no lo tacha de estafa. Lo que dice es peor: K8s es un producto real, con valor real, que existe para parchar el dolor que los clouds infligen. Las VMs son difíciles en Kubernetes porque el cloud no te deja correrlas fácil. El disco es difícil porque cuando se diseñó K8s, Google ni siquiera tenía block storage remoto usable. El networking es difícil porque, si fuera fácil, armarías un private link a un datacenter vecino y le quitarías un cero a tu factura cloud.
Dicho de otro modo: el 90% de la complejidad de Kubernetes existe porque los primitives del cloud están rotos. En un mundo donde las VMs no estén atadas a CPU, el disco sea local y rápido, y el egress no cueste una fortuna, la superficie de K8s se simplifica radicalmente.
graph LR
A["Hardware real"] --> B["Abstracción cloud tradicional"]
B --> C["VMs atadas a CPU/mem"]
B --> D["Block storage remoto"]
B --> E["Egress 10x"]
C --> F["Kubernetes tapa fugas"]
D --> F
E --> F
A --> G["exe.dev"]
G --> H["VMs como procesos"]
G --> I["SSD local 500k IOPS"]
G --> J["Red a precio de rack"]Qué significa para LATAM
Para los equipos de desarrollo en América Latina, este debate no es académico. El costo de una factura AWS en dólares pega directo contra presupuestos en pesos, colones, soles o quetzales. Muchos proyectos regionales mueren no porque falle la idea, sino porque la unit economics se rompe contra el egress y el storage premium. Una propuesta como exe.dev, si entrega lo que promete, cambia el cálculo de viabilidad para startups, agencias y equipos internos que hoy no pueden justificar el gasto de los hyperscalers.
Hay una lección adicional: las migraciones de hyperscalers a proveedores más baratos, como Hetzner, OVH o bare metal con coloc local, ya están pasando. Artículos recientes documentan casos de equipos que bajaron facturas de USD 1.400 a USD 230 al mes sin perder capacidades. exe.dev apunta a un espacio entre el bare metal manual y la experiencia API del cloud moderno —un lugar que hoy, en la práctica, está vacío.
💭 Clave: el cloud ganó la narrativa de “ops fácil”, pero en 2026 el dolor real para muchos equipos no es operar, es pagar. Quien resuelva la fricción API sin el sobreprecio, tiene mercado.
Qué sigue para exe.dev
Crawshaw no publicó un roadmap público detallado con el anuncio. Lo que sí dejó claro es qué va a tratar como primitives fundamentales: VMs desacopladas del shape del hardware, SSD local expuesto al workload, networking a costo realista, y APIs diseñadas para que un ingeniero no tenga que aprender un DSL nuevo por cada proveedor. El plan, según se desprende del post, es no hacer otro PaaS. Los PaaS, escribe, son “abstracciones inherentemente menos potentes que una computadora”, y cada vez que prometió a un equipo que “este sí es el indicado” terminó descubriendo un límite obscuro a mitad de proyecto.
La apuesta es vender una experiencia cloud sobre la forma correcta de las cosas: Linux real, procesos reales, disco real, red real. La gran pregunta comercial es si exe.dev va a ofrecer esto como un servicio hosteado propio, como una capa que corre sobre hardware del cliente, o alguna combinación. Los próximos meses deberían aclararlo.
Un ejemplo práctico de la diferencia
Para dar una idea concreta, comparemos cómo se siente hoy levantar un stack típico en un cloud tradicional versus la promesa de exe.dev.
# Hoy en AWS: para correr 5 VMs aisladas con SSD rápido
# 1. Lanzar una VM grande (m5d.8xlarge, ~USD 1.7/hr)
# 2. Instalar Firecracker o gVisor para anidar
# 3. Configurar NAT interno y reverse proxy (nginx/traefik)
# 4. Conectar EBS gp3 provisioned IOPS (200k IOPS ~USD 10k/mes)
# 5. Armar IAM roles, VPC, security groups, ENIs, route tables
# Resultado: semanas de trabajo y una factura de 5 cifras
# Promesa de exe.dev (pseudocódigo especulativo):
exe vm create --cpu 2 --mem 4g --disk 100g --image debian-12
exe vm create --cpu 2 --mem 4g --disk 100g --image debian-12
# ...cinco veces, sobre el mismo pool de hardware comprado
# Disco local a 500k IOPS incluido. Egress a precio de rack.La diferencia no es solo operativa. Es una diferencia de modelo mental: el cloud deja de ser un catálogo de productos con sus reglas arcanas y vuelve a ser lo que siempre debió ser —una forma remota de usar computadoras.
💡 Tip: si estás diseñando un sistema que depende fuertemente de I/O (bases de datos, búsqueda, analytics), mide tus IOPS reales hoy. Muchos equipos descubren que están pagando precios premium por rendimiento peor que una laptop de gama media.
Las preguntas abiertas
El anuncio tiene aristas que los próximos meses van a resolver. ¿Cómo maneja exe.dev la redundancia y la alta disponibilidad si el disco es local? ¿Qué garantías de vecino ruidoso ofrece si comparte hardware? ¿Qué regiones arranca cubriendo y cómo piensa el networking entre ellas? ¿Cuál es el modelo de facturación real? Son preguntas a las que Crawshaw todavía no respondió públicamente, y la respuesta marcará si exe.dev termina siendo una alternativa viable a los hyperscalers para workloads serios, o un laboratorio de ideas para proyectos pequeños.
Lo que ya es evidente, con o sin respuesta, es que el debate está abierto. Cuando alguien con el track record de Crawshaw cuestiona los primitives del cloud y pone dinero de inversionistas detrás, la industria tiene que escuchar. Y los equipos técnicos —desde startups en San José de Costa Rica hasta bancos en Buenos Aires— van a mirar si realmente llega una alternativa que no los haga elegir entre pagar el peaje hyperscaler o volver al bare metal artesanal.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es exe.dev y quién lo fundó?
exe.dev es una nueva plataforma cloud anunciada en abril de 2026 por David Crawshaw, cofundador y ex CTO de Tailscale. Su tesis es que los primitives de los hyperscalers —VMs atadas a CPU/memoria, block storage remoto y egress sobrevaluado— son la forma equivocada para el hardware moderno, y propone construir un cloud que respete mejor lo que las computadoras reales pueden hacer.
¿Por qué Crawshaw critica tanto el block storage remoto?
Porque los tiempos de seek de los HDDs eran de 10 milisegundos, y el RTT de red de 1 ms era un overhead del 10%. Con SSDs modernos los seek times bajan a 20 microsegundos, y el mismo 1 ms de red ahora es más de 10x de overhead. Pagar USD 10.000 al mes por 200k IOPS en EC2 cuando una MacBook tiene 500k IOPS gratis es un síntoma de que el modelo no escaló con el hardware.
¿Kubernetes deja de ser útil si los clouds se arreglan?
Kubernetes sigue siendo útil para orquestar aplicaciones distribuidas, pero mucha de su complejidad actual existe para tapar fugas de los clouds: virtualización anidada, abstracciones sobre block storage, workarounds de networking. Con primitives mejores, K8s debería simplificarse o ceder espacio a herramientas más delgadas.
¿Qué impacto puede tener exe.dev en LATAM?
El impacto directo es económico: las facturas cloud se pagan en dólares y golpean fuerte en presupuestos regionales. Un cloud con API moderna pero sin el sobreprecio de egress y storage premium abre la puerta a arquitecturas viables para startups y equipos internos que hoy no pueden justificar los números de AWS, GCP o Azure.
¿Cuándo estará disponible exe.dev?
Al momento del anuncio, exe.dev está en etapa de fundraising y construcción. No hay fecha pública de disponibilidad general ni detalles de regiones, pricing ni SLAs. Crawshaw dejó claro el porqué; el cuándo vendrá en próximas comunicaciones.
¿Es exe.dev otro PaaS tipo Heroku o Vercel?
No. El propio Crawshaw rechaza explícitamente el modelo PaaS en su post, llamándolo “abstracciones inherentemente menos potentes que una computadora”. La apuesta de exe.dev es ofrecer Linux real, VMs reales y disco local, con APIs limpias —no un runtime propietario con límites arbitrarios.
Referencias
- crawshaw.io — I am building a cloud — post personal de David Crawshaw anunciando la tesis detrás de exe.dev.
- tailscale.com — la empresa previa de Crawshaw, referencia para entender su visión de networking simple.
- Wikipedia — Kubernetes — contexto histórico sobre por qué K8s tomó la forma que tiene.
- Wikipedia — Solid-state drive — fundamentos técnicos del cambio de HDD a SSD que enmarca la crítica al block storage remoto.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios