El Monolito Multicloud

Hace tres años, en Happy Scribe, nuestras necesidades de transcodificación habían superado los cómodos límites de Heroku, así que dimos el salto a serverless con AWS Fargate. La promesa era de escalabilidad infinita y rentabilidad. En realidad, sin embargo, nos enfrentamos a un compromiso que no nos convencía del todo: con el ahorro de ancho de banda y cómputo llegó complejidad y un ciclo de desarrollo lento.

Hace solo unos meses, echamos un vistazo exhaustivo a nuestra configuración. Estaba consumiendo una gran parte de nuestro presupuesto y se había convertido en el cuello de botella de toda la cadena de transcripción, ralentizando la mitad de nuestros archivos. No tenía sentido, nuestro reconocimiento de voz de última generación era más rápido y más barato que simplemente convertir formatos de video. ¿El código de transcodificación? Había sido ajustado quizás cinco veces en tres años. No por falta de necesidad, sino porque la perspectiva de atravesar el doloroso proceso de desarrollo era un disuasivo en sí mismo. Claramente, algo tenía que cambiar.

Hoy, hemos dado un paso que algunos pueden considerar poco ortodoxo: hemos adoptado lo que lamamos un Monolito Multinube. No es la historia de una gran revolución, sino de un paso deliberado y práctico hacia la racionalización de nuestras operaciones.

Nuestra transcodificación es ahora cuatro veces más rápida, los costes de procesamiento y transmisión de video han caído a una vigésima parte de lo que eran, y podemos iterar en el código localmente en solo un par de segundos. Todo esto mientras mantenemos el núcleo de nuestra aplicación en Heroku.

Echemos un vistazo a nuestra nueva configuración

Utilizamos Hetzner para las tareas pesadas porque es económico, no cobra por ancho de banda y hace el trabajo. Los trabajadores en Hetzner tienen una copia de todo nuestro código monolítico de Rails y toda la configuración necesaria para conectarse a nuestra infraestructura principal en Heroku.

Para todo lo demás, Heroku es nuestra base de operaciones. Es donde viven nuestros trabajadores web y principales, con Sidekiq y Redis para gestionar los trabajos en segundo plano.

Para desplegar el código, simplemente tenemos dos procesos concurrentes, uno ejecuta la CLI de Heroku y el otro utiliza Kamal para desplegar en Hetzner.

En cuanto a capacidad, Hetzner es tan barato que no necesitamos autoscaling. Estamos simplemente muy sobredimensionados y listo.

Con esta configuración, gracias a Rails y Sidekiq, ejecutar trabajos en la infraestructura de Hetzner es tan simple como:

class TranscodingJob < ApplicationJob
  queue_as :hetzner_video_processing # Just a different queue
  def perform 
    # CPU-intensive work here 
  end 
end 

TranscodingJob.perform_later

Hemos navegado algunos desafíos en el camino. Coordinando despliegues en distintas plataformas, asegurando fiabilidad con alternativas inteligentes, y aislando la ejecución de código para prevenir problemas. Estamos considerando analizar a fondo estas soluciones en una publicación futura si hay interés. ¡Envíame un mensaje a yoel@happyscribe.co si es algo que te gustaría leer!

Mejora progresiva en el lado de la infraestructura

En el ámbito del desarrollo de aplicaciones web, Hotwire destaca por su capacidad para mejorar incrementalmente la interactividad de las aplicaciones. Evita la complejidad de las single page applications, lo que nos permite introducir elementos dinámicos e interactivos manteniendo la facilidad de desarrollo de las páginas tradicionales renderizadas en el servidor. La mejor parte es que para aquellas páginas que no necesitan interactividad, simplemente podemos seguir utilizando el buen y viejo Rails con ERB.

Nos inspiramos en este enfoque y lo tradujimos a nuestra estrategia de infraestructura. Al igual que Hotwire permite mejorar selectivamente las páginas web, el Monolito Multicloud mejora aspectos específicos de nuestra infraestructura según sea necesario. Comenzamos con la simplicidad y la rapidez de desarrollo en Heroku, optimizando la felicidad y la agilidad de nuestros programadores. A medida que ciertos procesos se vuelven más críticos y exigentes, los trasladamos selectivamente a configuraciones más complejas, como Hetzner, para lograr una mayor eficiencia y escalabilidad.

En esencia, nuestro Monolito Multicloud es a microservicios lo que Hotwire es a aplicaciones de una sola página. Ambos enfoques evitan los peligros de sumergirse en arquitecturas excesivamente complejas desde el principio. En cambio, permiten mejoras estratégicas e incrementales. Esta metodología garantiza que no sobrecarguemos nuestro sistema con complejidades innecesarias, manteniendo un equilibrio óptimo entre agilidad y robustez. Es un enfoque pragmático que escala de manera inteligente, mejorando nuestro sistema donde más importa.

Alternativas que hemos descartado por ahora

Un (micro)servicio separado: Casi nunca es solo uno

Transcodificación de videos a mp4, extracción de audios para transcripción, subtitulación codificada... Todo lo relacionado con videos estaba sucediendo en Fargate debido a las limitaciones de ancho de banda de Heroku. Es decir, si nos adentramos en el "rabbithole" de microservicios, pronto tendremos 5-10 servicios. Cosa que suena aún peor que lo que teníamos en Fargate.

Por otro lado, como parte de esta migración, trasladamos nuestro almacenamiento a Cloudflare R2, ya que no podíamos costear los gastos de transferencia de datos de AWS a Hetzner. Sin embargo, algunos de nuestros clientes más importantes aún necesitan que sus archivos se transmitan a través de AWS. Tienen firewalls estrictos, y no vamos a ser nosotros quienes les digamos que hagan "whitelisting" de un proveedor de almacenamiento menos conocido solo para nosotros. Gracias a Active Storage, nuestro monolito de Rails puede encaminar fácilmente diferentes archivos de clientes a través de diferentes rutas de datos, manteniendo toda la lógica empresarial central y accesible. Con microservicios, esto probablemente significaría una configuración de almacenamiento muy complicada.

No estamos completamente en contra de dividir los servicios, sin embargo. La IA es central para nuestra misión y, por lo tanto, tenemos un servicio dedicado escrito en Python y desplegado con Kubernetes en un proveedor de cloud diferente, construido por nuestro equipo de IA. ¿Un equipo de transcodificación, sin embargo? Poco probable. Sin equipo de transcodificación, no hay servicio de transcodificación.

Migración completa a Hetzner: Tentador, pero no para nosotros (¿todavía?)

No podemos evitar rendir homenaje al reciente éxodo a la nube de Basecamp utilizando Kamal—es el tipo de movimiento que hace que el equipo técnico de Happy Scribe se ponga un poco soñador. También tuvimos mucha suerte de que lanzaran a Kamal justo cuando estábamos a punto de comenzar a trabajar en este proyecto.

La idea de seguir esos pasos y trasladar toda nuestra operación a Hetzner ciertamente es tentadora. Pero aquí está el asunto: no somos Basecamp. Ellos tienen alrededor de 30 programadores, y nosotros somos 8. Nuestro equipo de operaciones es, bueno, inexistente. Que un trabajador en segundo plano se caiga no es una crisis—los trabajos son rápidamente retomados por otro trabajador. ¿Pero tiempo de inactividad del servicio web? No, gracias. Por ahora, mantenemos la web donde sabemos que está segura y es sólida—en Heroku. Esto deja a los ocho de nosotros libres para hacer lo que hacemos mejor: entregar valor real a nuestros clientes.

Reflexión final

Nuestro modelo multicloud podría ser tu trampolín fuera de la nube. Reduce los costes sin agregar demasiada complejidad y mantiene a tu equipo enfocado en lo que mejor hace. Si tuviéramos que planear una migración completa, definitivamente empezaríamos así, y luego migraríamos gradualmente todo lo demás (web, base de datos, etc.). Esperamos que nuestra historia te ofrezca ideas, ya optes por una migración parcial o total.

¿Te ha parecido interesante? Estamos contratando. Quién sabe, con un equipo más grande, esa migración completa a la nube podría estar en el horizonte.