- Fly.io recaudó alrededor de 25 millones de dólares ($25m) en julio de 2023 de A16Z y de inversionistas existentes como Intel Capital y Dell, y luego aseguró otros 70 millones de dólares ($70m) adicionales liderados por EQT Ventures
- El reto central es que las apps mejoran cuando se ejecutan cerca del usuario, pero para un desarrollador común es difícil entender un despliegue en varias ciudades en menos de 2 horas
- Fly.io considera no solo el despliegue global, sino también las VM on-demand, funciones en tiempo real, presence de usuarios, cifrado y secretos, bases de datos en clúster e inferencia acelerada por hardware como el mismo problema de las 2 horas
- La inversión se usará en su propia flota de hardware, más regiones, soporte y confiabilidad, además de funciones avanzadas de almacenamiento, seguridad y experimentos con nuevo hardware
- Fly.io mantiene la dirección de ser una plataforma amigable para desarrolladores que permite probar rápido tras registrarse en línea y ejecutar apps con uno o dos comandos de
flyctly empaquetado en contenedores
La ronda de inversión de Fly.io
- Fly.io recaudó 25 millones de dólares en julio de 2023 de inversionistas incluyendo a A16Z y a inversionistas existentes como Intel Capital y Dell
- Después aseguró una inversión adicional de 70 millones de dólares liderada por EQT Ventures
- Uno de los objetivos prácticos del anuncio de inversión es captar clientes
- Hay clientes a los que les resulta cómodo trabajar con una Fly.io pequeña, pero también hay clientes que solo se sienten tranquilos con una Fly.io que ha recibido 70 millones de dólares adicionales en una ronda liderada por EQT Ventures
- Durante años, Fly.io ha afinado la visión de plataforma que quiere construir dialogando con usuarios, fans y críticos en la comunidad
El “problema de las 2 horas” y el despliegue global
- En 2020, la creencia básica de Fly.io era que una app funciona mejor cuanto más cerca se ejecuta del usuario
- Las apps como video o presence en tiempo real se clasificaban como tipos difíciles de implementar sin proximidad física
- En el hilo de lanzamiento en HN, esperaban que WebRTC, el edge caching y los servidores de juegos fueran los temas principales, pero en la práctica el interés se fue hacia las bases de datos
- El punto que Fly.io pasó por alto fue asumir que solo ciertas apps “de borde” requerían despliegue global
- En realidad, la mayoría de las apps también quieren ejecutarse en el edge, pero solo lo intentan cuando es lo suficientemente fácil
- Para los servidores de juegos, el despliegue en el edge es indispensable, así que los equipos insisten hasta resolver el problema
- En una app CRUD como una librería en línea, si tras unas 2 horas de intento no aparece un camino claro, se pasa a otra cosa
Límites del modelo actual de despliegue en internet
- Se plantea como problema que gran parte de las apps CRUD del mundo estén alojadas cerca de Ashburn, Virginia, donde está Amazon
us-east-1 - Muchos desarrolladores entienden que es mejor ejecutar cerca del usuario, pero con las herramientas habituales es difícil entender en menos de 2 horas cómo operar una app simultáneamente en varias ciudades
- La apuesta de Fly.io es que, con la plataforma y la cadena de herramientas adecuadas, apps como una librería, una app para calificar sándwiches, un recomendador musical o un administrador de listas de correo de una iglesia también pueden ejecutarse rápido en todo el mundo
- Las regiones objetivo no se limitan al área de Ashburn, sino que incluyen ciudades como Chicago, Sydney, Singapore y São Paulo
- La capacidad de funcionar rápido en varias ciudades al mismo tiempo se considera una característica importante para elevar la calidad de una app
Fly Machines y otras “funciones de las 2 horas”
- El sandboxing, los editores de código con REPL y las aplicaciones de CI/CD necesitan ejecutar código no confiable de clientes
- Todos esos sistemas han ido resolviendo por su cuenta cómo levantar contenedores bloqueados cuando hace falta
- Pero las VM on-demand son una función de gran valor para distintas apps, y aun así la ruta de implementación no queda clara con solo 2 horas de investigación
- Por eso Fly.io creó Fly Machines para hacer que levantar una VM sea tan simple como una llamada de función
- Los objetivos a futuro también siguen ese mismo patrón
- funciones en tiempo real y presence de usuarios
- cifrado y almacenamiento de secretos
- bases de datos en clúster
- inferencia acelerada por hardware
- Otras empresas en bases de datos distribuidas, localización de datos, almacenamiento, IA y frameworks de aplicaciones también intentan resolver el problema de la “ventana de 2 horas” del desarrollador
- Si Fly.io funciona como pretende, esas plataformas podrán crear nuevos bloques base encima, llevar nuevas ideas más rápido a los usuarios y mejorar la calidad de las apps
Por qué necesitan inversión
- Fly.io considera que para construir esta plataforma hacen falta elementos intensivos en capital
-
Su propia flota de hardware
- Fly.io siempre ha corrido sobre su propio hardware
- Hay razones técnicas y de control para instalar directamente el hardware en racks en vez de construir sobre una nube generalista
- La razón principal es la economía
- Si quieren que la gente construya apps sobre la plataforma, tienen que demostrar que probablemente seguirán existiendo dentro de 10 años, y consideran que el hardware permite los márgenes necesarios
-
Más regiones
- Fly.io empezó con 19 regiones y consideraba que era una cantidad suficiente si el objetivo eran solo desarrolladores de aplicaciones individuales
- Pero también quiere que otras plataformas, como bases de datos administradas y herramientas para desarrolladores, se ejecuten sobre Fly.io
- Esas compañías necesitan más regiones
- Fly.io ya creció hasta 33 regiones, y la velocidad para activar nuevas regiones también está aumentando
-
Soporte y confiabilidad
- Fly.io reconoce que los retos de estabilidad de la plataforma son grandes
- No lo ve como un problema que pueda resolverse solo con ingenio
- También quiere apostar más por almacenamiento avanzado, funciones de seguridad y nuevos tipos de hardware
La dirección de plataforma que no cambia
- La dirección de la empresa de plataforma que Fly.io quiere ser no ha cambiado desde 2020
- El objetivo es una plataforma que se pueda probar en menos de 5 minutos después de registrarse en línea
- En el extremo opuesto están las plataformas en las que, tras registrarte en línea, te contacta un representante comercial para darte precio y agendar una demo
- Quieren una plataforma que se pueda entender sin leer manuales
- En el extremo opuesto están las plataformas cuyo uso genera libros enteros y que requieren certificación especializada para levantar una app
- Debe poder ejecutar código Python, Rust y Julia de forma natural
- En contraste con enfoques donde hay que recompilar el código a JavaScript
- En general, las funciones de Fly.io se pueden usar con uno o dos comandos de
flyctl, y cualquier app que pueda empaquetarse como contenedor puede ejecutarse - Si ya tienes un contenedor Docker funcionando, puedes probarlo de inmediato en Fly.io
- Incluso empezando desde cero, debería poder ejecutarse en Fly.io en pocos minutos
- Consideran que ejecutarlo en todos los continentes puede tomar 1 o 2 minutos más a partir de ahí
1 comentarios
Opiniones en Hacker News
La expresión "recaudó mucho dinero" ahora, desde la perspectiva de los clientes de cualquier servicio, primero me genera preocupación.
Se siente como si la empresa funcionara solo con dinero de venture capital, como si el precio que uso o pago no fuera un costo futuro realista, y como si la plataforma siguiera creciendo sin relación con los ingresos.
Como cliente, me da más confianza sobre la estabilidad escuchar que tienen rentabilidad gracias a la operación y a una base de clientes de pago.
No es que esté en contra del artículo en sí, pero ya no es fácil verlo como una señal positiva desde la perspectiva del cliente.
Y luego un día te cambian el precio de forma absurda diciendo que estabas usando gratis una plataforma excelente.
Es como contratar a alguien para cortar el césped y que unos años después llegue con 3 podadoras montables diciendo que tiene que subir el precio para cubrir el costo del servicio que te da.
Fueron ellos quienes hicieron crecer el negocio pensando en clientes con jardines de 10 acres y asumieron que yo también necesitaba ese nivel de servicio; al final, el que termina perdiendo el mantenimiento del jardín soy yo.
Si fuera inversionista, podría preocuparme la dependencia del venture capital, pero como usuario no tenía nada de malo comer barato en servicios como Hello Fresh gracias a subsidios del capital invertido.
Parece muy posible que los vendan pronto para una salida, pero si tienen la resistencia para seguir como empresa independiente sería algo muy bienvenido.
Me hace pensar que el producto ya fue validado, que parece tener más posibilidades de éxito que sus competidores, que no va a desaparecer pronto y que además mejorará más rápido.
El chiste de que “las apps CRUD del mundo están desplegadas en Loudoun County, VA, o sea en Amazon us-east-1 en Ashburn, y hay tantas apps de Rails ahí que una de ellas salió elegida para la junta de supervisores del condado” duele de lo cierto que es.
Pensándolo bien, el paradigma de las regiones en sí ya se ve bastante viejo en términos generales. AWS ha hecho algunos movimientos, pero al final sigue atado al concepto de región en cosas como el control plane, y encima vienen la rareza de VPC, la facturación difícil de entender, los problemas de disponibilidad y todo tipo de hacks, stacks y esfuerzo para manejar múltiples regiones/AZ.
Competidores más recientes como Fly y Cloudflare parecen estar dominando cada vez más el espacio cloud con un enfoque de cómputo en el edge sin el concepto de región, y el enfoque regional de AWS da la impresión de que quedará para aplicaciones legacy atrapadas ahí.
Un enfoque basado en regiones se parece más a un datacenter elástico alojado que a una “nube real”. La nube real debería estar en todas partes hasta el punto de ni siquiera ser algo que haya que considerar.
Como resultado, su marketing de marca es impecable. Todos los textos del blog transmiten las ideas con claridad y con un tono ligeramente sarcástico.
Si quieres convertirte en un hacker famoso, también deberías ser un escritor algo conocido en la industria.
Este tipo de comentario autoconsciente solo funciona cuando se usa rara vez, y en este texto funciona muy bien.
Reconoce la motivación mercenaria, la hipocresía implícita y la autopromoción de este tipo de anuncios, pero aun así transmite toda la información importante y explica de forma concisa el problema real que resuelve la plataforma.
También deja claro cuál es el uso legítimo del dinero recaudado, así que responde a las preguntas de “por qué” y “cuánto”.
Sobre “¿por qué las startups escriben este tipo de anuncios?”, en empresas que ya habían pasado varias veces por rondas de inversión, el motivo era 100% tener una excusa para salir en la prensa.
A menos que sea “arrestaron al CEO al mismo tiempo por malversación y acoso”, si puedes crear un pretexto para que un medio tecnológico publique una nota, obtienes publicidad gratis.
Mejor todavía si tus clientes objetivo leen medios tecnológicos. No tiene nada de malo, pero fue sorprendente reconocer la razón mercenaria y al mismo tiempo omitir la explicación más común que yo veía.
Los periodistas conocían bien a su audiencia y entendían que solo los artículos con un anuncio de inversión conseguían clics.
Así que, después de recaudar dinero, a veces nos quedábamos callados hasta 6 meses y hacíamos el anuncio coincidir con una nueva función o con el lanzamiento de un producto.
Si los artículos tecnológicos sin anuncio de inversión también recibieran más clics, este ciclo podría cambiar, pero ahora parece una especie de dilema del prisionero. No se escriben esos artículos, no generan clics y por eso se dejan de escribir otra vez.
Normalmente, como explica el texto, es por un objetivo mercenario de dejar cierto mensaje e impresión.
Claro que también existe el objetivo de dar a conocer el nombre de la empresa, y ese quizá sea otro motivo mercenario que el artículo trata menos.
Según recuerdo, técnicamente parecía ser información pública. Así me lo explicaron cuando fundé una empresa, aunque fue hace mucho tiempo.
Si no lo anuncias tú directamente, alguien más lo hará, así que es mucho mejor publicarlo primero para que la gente lea tu texto y no el de otro.
Si levantaste 100 millones de dólares, entonces tienes que ir por un exit de 1,000 millones de dólares. Para mantener el impulso actual, los costos de I+D van a aumentar muchísimo
Construir todo el stack por cuenta propia, y al final tener que hacer que todo sea muy sólido, es un trabajo de ingeniería enorme
Como Fly cobra por cómputo y el hardware y el ancho de banda son baratos, en los libros puede parecer rentable
Pero los costos reales son I+D, marketing y compensación basada en acciones, y esos costos pueden impedir la rentabilidad a cualquier escala. No son gastos de una sola vez, sino dinero que hay que seguir gastando, y si no lo haces, los clientes se van
No es solo el caso de Heroku, sino la tragedia de los startups de plataforma/infraestructura
Hay una razón por la que no se ven muchos proveedores de nube pequeños, y es que la economía solo cuadra con escala
Fly parece tener una visión realmente genial y moderna sobre la ingeniería de software, y parecía un buen lugar para trabajar, pero siento que hay una gran desconexión entre marketing y producto
El marketing y la documentación se enfocan en lo fácil que es levantar servidores de aplicaciones distribuidos globalmente, pero los clientes que de verdad necesitan servidores de aplicaciones distribuidos globalmente probablemente ya tengan una plataforma madura con almacenamiento de datos distribuido globalmente también, así que no parece que les preocupe levantar servidores de aplicaciones
Por eso siento que estoy entendiendo mal algo fundamental sobre la arquitectura de aplicaciones de internet
Poder correrlo en varias regiones es útil. La comunidad de Splatoon no está concentrada en un solo lugar, sino repartida por todo el mundo, así que si lo hospedo solo en EE. UU., para los jugadores de Japón va lento, y al revés también
Incluso si el proyecto no despega, siento que más adelante será una experiencia bastante útil cuando salga de la escuela
Ahora mismo lo estoy corriendo en la costa este de EE. UU., Amsterdam y Tokyo por unos 10 dólares al mes
Lo único que cambia es si el objeto son Kubernetes, apps de página única, GraphQL, despliegue en el edge, etc.
En una fiebre del oro, basta con vender palas
La frase “hay empresas de plataforma que te permiten correr bien código Python, Rust y Julia, y empresas de plataforma que te hacen buscar cómo recompilar eso a JavaScript” parece una pulla en broma a Cloudflare y Deno
Sería interesante si Fly además de contenedores Docker terminara ofreciendo hosting de contenedores WASM
Creo que la pulla a Cloudflare fue la parte de “hacer que te llame un vendedor”
Me gustó que reconocieran que esperaban que Fly se usara para juegos, edge caching, etc., pero que en la práctica todos lo usan como el nuevo Heroku para desplegar apps CRUD de Rails+PostgreSQL
Según entendí, el siguiente objetivo es hacer que llevar apps Rails+PostgreSQL al edge sea algo trivial, o sea, un “problema de dos horas”
Es bastante audaz. Históricamente, esto requería acoplamientos específicos de aplicación/framework/dominio, como “cuál es la mejor manera de shardear este modelo de dominio”
Resolverlo como PaaS/IaaS se acerca bastante a escribir y operar un Cloud SQL/Aurora distribuido
Aun así, si se trata de algo como correr de forma fluida un clon de Aurora o algo tipo Neon dentro del stack, parece viable y el valor del producto también podría ser bastante alto
Considerando que los márgenes del cloud para SMB/hobby son relativamente bajos, no me queda claro cómo fly.io va a asegurar rentabilidad
Tal vez puedan poner al mundo entero en el free tier, pero ¿qué va a pasar cuando EQT quiera recuperar?
¿Podrán construir suficientes funciones como para que las empresas lo elijan en serio? En las empresas donde trabajé, salvo que fuera un equipo de menos de 5 personas y sin ninguna necesidad de escalar, parecería difícil usarlo o impulsarlo
Tenemos buena economía unitaria. La decisión más arriesgada y aterradora que tomamos fue empezar con nuestro propio hardware
En infraestructura orientada a desarrolladores, hay que atraer a muchos desarrolladores, lograr que nos lleven a sus trabajos, y luego ayudar a sus empleadores a construir algo mejor a largo plazo
Esto toma mucho tiempo, porque las empresas con procesos de compra están diseñadas para no comprar infraestructura crítica a startups
Aunque todavía no seamos adecuados para todos, hasta ahora nos ha funcionado
[0] https://community.fly.io/t/funding-and-longevity/1957
Me pregunto en qué se diferencia fly.io, o en qué es mejor, de poner la app completa, incluso el contenido dinámico, detrás de CloudFront u otro CDN
Un CDN está más cerca del cliente y ofrece configuración SSL con menor latencia, y esa diferencia puede ser bastante grande
No empuja el servidor de aplicaciones al edge, pero aunque lo haga, igual sigues pagando el costo de latencia de golpear una base de datos en algún búnker de Virginia
Muchas apps hacen varios viajes de ida y vuelta a la base de datos por una sola petición web, así que parece peor. Yo diría que es mejor pagar el costo de latencia en la petición web y que el servidor de aplicaciones acceda rápido a la base de datos
Parece que el cliente objetivo de Fly es mayormente el lado de contenido estático