Ignacio Arriaga · 01/03/2024

El éxodo del cloud

El éxodo del cloud

Índice

El cloud público –ejemplificado en AWS, Google Cloud, Azure– es uno de los negocios más florecientes de la última década. Pagar por uso por recursos computacionales parece una oferta redonda y, si además esos recursos nos ofrecen servicios adicionales interconectados, la idea es inmejorable. Pero hay compañías que han empezado a cuestionar esto y están abandonando el cloud público.

Hoy vamos a hablar de una tendencia que han iniciado algunas compañías, como Basecamp o Ahrefs. Empecemos por contar sus casos:

  • Basecamp: decidieron abandonar el cloud en 2022 después de gastar 3.2 millones de dólares en su factura de AWS. Pasaron a un entorno en el que compraron máquinas y contrataron a un proveedor que se encargaba de instalarlas en distintos datacenters. Su factura se redujo a 840.000 dólares anuales. Afirman que en cinco años van a ahorrar 7 millones de dólares por haber hecho este cambio. No han tenido necesidad de aumentar su equipo de gestión de máquinas.
  • Ahrefs: el caso de Ahrefs es bastante más loco. Estos tipos nunca estuvieron en un proveedor de cloud grande y siempre tiraron por tener su propia estructura y su propio datacenter. Son un negocio muy intensivo en necesidad computacional, porque todo el tema del crawling y del almacenamiento de los datos de SEO es costoso. Pues bien, ellos afirman que si se hubieran ido a un proveedor de cloud público, en concreto a AWS, habrían pasado de gastarse 16 millones anuales a gastarse 178 millonazos.

El cloud público tiene muchas cosas buenas, pero también muchas cosas bastante grises que vamos a comentar en esta edición.

La sobre optimización es un error que todos cometemos

Todos los fundadores pensamos que vamos a tener un éxito monstruoso, porque si no no pasaríamos por las penurias que se pasan al montar una empresa.

Por eso cometemos el error de preparar a nuestras empresas para ese éxito antes de que suceda. Y esto pasa muchísimo en los perfiles técnicos. Queremos construir algo que escale hasta el infinito y pensamos que necesitamos lo mejor de lo mejor. Y puede parecer que yo, en este post, estoy defendiendo la sobre optimización.

Nada más lejos de la realidad. Si estás empezando, utiliza lo que sepas utilizar y lo que más facilidades te proporcione para llegar a conseguir los primeros clientes. Si quieres usar un VPS cualquiera, úsalo. Si quieres utilizar AWS o Google Cloud o Azure, úsalos. Si quieres utilizar Render o Heroku, tira con ello. Lo que antes te permita poner algo en producción y empezar a vender es lo que debes usar. Esto vale tanto para el cloud como para la arquitectura hexagonal .

Por eso, si estás buscando tu modelo de negocio y estás empezando a tener tus primeros clientes, no intentes optimizar nada. Tristemente es muy posible que nunca jamás llegues a tener un tráfico que necesite más que un VPS básico de Digital Ocean. Invertir tiempo en optimizar en esas fases es, directamente, perder el tiempo.

La competencia desleal y el vendor locking

Hay otro punto de vista sobre utilizar el cloud público y es el componente moral. Para mí, los grandes players del cloud cometen prácticas que, como mínimo, son poco justas con la competencia. Si estás empezando, es muy sencillo conseguir unas decenas de miles de euros de regalo en cualquiera de estos proveedores. Esto es algo con lo que las empresas de hosting que no están dopadas por un gigante tecnológico, no pueden permitirse.

Si eres una startup, es muy probable que tengas poco dinero en caja, y será difícil resistirte a la tentación de coger esa pasta y tirar para adelante. Desde luego, con un tamaño normal, son años de servidores gratuitos. Pero también puedes preguntarte, como startup, ¿querrías que tus competidores te echasen del mercado de esa manera? Seguramente, no. Por eso, si tienes algo de músculo económico, puedes intentar moverte a algún proveedor que no utilice esas prácticas.

Una de las grandes ventajas del cloud es el gran número de servicios que ofrecen y cómo se interconectan entre ellos. Pero esto también es una pequeña –o gran– trampa de estas compañías. Te intentarán contar que la forma en la que más aprovechas sus servicios es la utilización de todas sus productos y servicios nativos. Y esto, seguramente sea cierto, pero provoca un gigantesco vendor lock in. Cuando quieras abandonar ese cloud en el que estás, será muy difícil que salgas de él.

Realmente hay poquísimos servicios que te pueda proporcionar el cloud que no sean fácilmente replicables utilizando software libre u otras APIs independientes. Algunos ejemplos podrían ser Postman en lugar de SES o MySQL en lugar de RDS. Las alternativas son muchísimas. ¿Es más difícil configurar y mantener estas alternativas? Depende, realmente creo que hace falta un equipo para mantener cualquiera de las dos soluciones.

La seguridad y la sencillez de gestionar los servicios cloud es otra de las grandes ventajas que venden estos proveedores. Y son verdades relativas. La seguridad de las aplicaciones suele fallar en la capa de la aplicación, lo que programamos con nuestras manitas, vamos. Y la sencillez de gestión es también cuestionable. No es tan sencillo gestionar AWS o Google Cloud, de hecho por eso existen servicios como Render o Heroku, para facilitar toda esa capa de gestión

El caso de Acumbamail

Nosotros nunca hemos utilizado un cloud público como proveedor principal. Siempre hemos empleado un cloud privado. Primero, porque queríamos un proveedor local. Siempre que podemos los utilizamos. Segundo, porque uno de los cofundadores de Acumba tenía una empresa de cloud privado. Así que la decisión fue sencilla.

El cloud privado funciona parecido al público, la principal diferencia es que nosotros disponemos de ciertos nodos dedicados exclusivamente a nosotros y nosotros nos encargamos de dividirlos en máquinas virtuales y administrarlos.

Existen otras opciones, como la de comprar las propias máquinas y ubicarlas en un datacenter, el llamado collocation por el que ha optado Basecamp o la posibilidad de tener un datacenter propio dedicado, que es por lo que ha optado Ahrefs. La complejidad va aumentando según vamos acercándonos al metal y vamos teniendo que ocuparnos cada vez de más cosas.

Para hacernos una idea de los números reales, con un proyecto real, he calculado más o menos la misma configuración que utilizamos nosotros y la diferencia es bastante importante. Mensualmente ahorramos al mes 16000€ por estar en cloud privado en lugar de en AWS. Nuestra factura se multiplicaría casi por cuatro.

Si sabes lo que significa el número 83333, esta newsletter es para ti *

* Si no lo sabes pero te interesa el mundo del software: debes suscribirte y lo descubrirás inmediatamente.

Lo que dicen algunos de los suscriptores
  • 5 estrellas

    A mí me resulta imposible leerme todas las newsletters a las que estoy suscrito (que no son demasiadas) pero Disaaster es una de las pocas cuya lectura semanal es obligatoria para mí.

    Juan Pablo Tejela, Metricool

  • 5 estrellas

    Ignacio Arriaga en su newsletter te va a contar las verdades del barquero, sin estruendo, a través de ejemplos concretos, explicando el cómo y el por qué.

    Eduardo Manchón, Mailtrack

  • 5 estrellas

    Disaaster es mi newsletter de referencia en el mundo del SaaS. Contenidos muy directos y aplicables, todos los aspectos relacionados con crear y hacer crecer productos digitales y SaaS, desde la experiencia y sentido crítico del gran Ignacio Arriaga.

    Juan Carlos Cortizo, Product Hackers

  • 5 estrellas

    Si te dedicas a crear productos con software en esta newsletter encontrarás contenido super valioso y bien explicado, directo y al grano

    Jose Florido, Freepik