Les monolithes peuvent fonctionner dans un environnement multicloud

Il y a trois ans, chez Happy Scribe, nos besoins en transcodage avaient dépassé les limites confortables d'Heroku, et nous avons donc fait le saut vers le serverless avec AWS Fargate. La promesse était celle d'une évolutivité infinie et d'un bon rapport coût-efficacité. En réalité, nous avons été confrontés à un compromis qui ne nous convenait pas : les économies de bande passante et de calcul s'accompagnaient d'une complexité et d'un cycle de développement lent.

Il y a quelques mois à peine, nous avons examiné attentivement notre configuration. Cela absorbait une énorme partie de notre budget et était devenu le goulot d'étranglement de l'ensemble du processus de transcription, ralentissant la moitié de nos fichiers. Cela n'avait aucun sens, notre reconnaissance vocale de pointe était plus rapide et moins chère que de simplement convertir des formats vidéo. Le code de transcodage ? Il avait peut-être été ajusté cinq fois en trois ans. Ce n'était pas faute de nécessité, mais parce que la perspective de se frayer un chemin à travers le douloureux processus de développement était en soi un frein. De toute évidence, quelque chose devait changer.

Aujourd'hui, nous avons franchi une étape que certains peuvent considérer comme non conventionnelle : nous avons adopté ce que nous aimons appeler un Monolithe Multicloud. Ce n'est pas l'histoire d'une grande révolution, mais celle d'une démarche délibérée et pratique vers la rationalisation de nos opérations.

Notre transcodage est maintenant quatre fois plus rapide, les coûts de traitement et de diffusion vidéo ont chuté à un vingtième de ce qu'ils étaient, et nous pouvons itérer sur le code localement en seulement quelques secondes. Tout cela en gardant le cœur de notre application sur le bon vieux Heroku.

Jetons un coup d'œil à notre nouveau dispositif

Nous utilisons Hetzner pour le gros oeuvre car c'est bon marché, ne facture pas la bande passante et fait le travail. Les employés de Hetzner ont une copie de tout notre code monolithe Rails et de toute la configuration nécessaire pour se connecter à notre infrastructure principale chez Heroku.

Pour tout le reste, Heroku est notre base principale. C'est là que vivent nos travailleurs web et principaux, avec Sidekiq et Redis pour gérer les tâches en arrière-plan.

Pour déployer le code, nous avons simplement deux processus concurrents, l'un exécute l'interface en ligne de commande Heroku et l'autre utilise Kamal pour déployer sur Hetzner.

En termes de capacité, Hetzner est tellement bon marché que nous n'avons pas besoin d'auto-escalade. Nous sommes juste très sur-approvisionnés et c'est tout.

Avec cette configuration, grâce à Rails et Sidekiq, l'exécution des tâches dans l'infrastructure Hetzner est aussi simple que :

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

TranscodingJob.perform_later

Nous avons navigué à travers quelques défis en cours de route. Coordination des déploiements sur différentes plateformes, garantissant la fiabilité avec des solutions de repli intelligentes, et isolant l'exécution du code pour éviter les problèmes. Nous envisageons une plongée approfondie dans ces solutions dans un futur article s'il y a de l'intérêt. Laissez-moi un message à yoel@happyscribe.co si c'est quelque chose que vous aimeriez lire!

Amélioration progressive du côté de l'infrastructure

Dans le domaine du développement d'applications web, Hotwire se distingue par sa capacité à améliorer de manière progressive l'interactivité des applications. Il évite la complexité des applications monopages, nous permettant d'introduire des éléments dynamiques et interactifs tout en conservant la facilité de développement des pages rendues côté serveur traditionnelles. Le meilleur, c'est que pour les pages qui n'ont pas besoin d'interactivité, nous pouvons simplement nous en tenir au bon vieux Rails et ERB.

Nous avons été vraiment inspirés par cette approche et l'avons traduite dans notre stratégie d'infrastructure. Tout comme Hotwire permet l'amélioration sélective des pages web, le Monolithe Multicloud améliore des aspects spécifiques de notre infrastructure selon les besoins. Nous commençons par la simplicité et la rapidité de développement sur Heroku, en optimisant le bonheur et l'agilité. Lorsque certains processus deviennent plus critiques et exigeants, nous les déplaçons sélectivement vers des configurations plus puissantes, comme Hetzner, pour une plus grande efficacité et évolutivité.

En essence, notre Monolithe Multicloud est aux microservices ce que Hotwire est aux applications monopage. Les deux approches évitent les écueils de se plonger dans des architectures trop complexes dès le départ. Au lieu de cela, elles permettent des améliorations stratégiques et incrémentielles. Cette méthodologie garantit que nous ne surchargeons pas notre système avec des complexités inutiles, maintenant un équilibre délicat entre agilité et robustesse. C'est une approche pragmatique qui évolue intelligemment, en renforçant notre système là où cela compte le plus.

Les alternatives que nous avons écartées pour l'instant

Un service (micro) séparé : Ce n'est presque jamais juste un

Transcoder des vidéos en mp4, extraire les audios pour la transcription, sous-titrer en dur... Tout ce qui touche aux vidéos se passait sur Fargate en raison des limitations de bande passante d'Heroku. Autrement dit, si nous nous engouffrions dans le terrier des microservices, nous aurions bientôt 5 à 10 services. Cela semble même pire que ce que nous avions sur Fargate.

D'autre part, dans le cadre de cette migration, nous avons déplacé notre stockage vers Cloudflare R2 car nous ne pouvions pas nous permettre les coûts de transfert de données d'AWS à Hetzner. Cependant, quelques-uns de nos clients les plus importants ont encore besoin que leurs fichiers soient diffusés via AWS. Ils ont des pare-feu stricts, et nous ne voulons pas être ceux qui leur disent d'autoriser un fournisseur de stockage moins connu juste pour nous. Grâce à Active Storage, notre monolithe Rails peut facilement router les fichiers de différents clients à travers différents chemins de données tout en conservant toute la logique métier centrale et accessible. Avec les microservices, cela signifierait probablement une configuration de stockage très compliquée.

Nous ne sommes pas complètement opposés à la division des services, cependant. L'IA est au centre de notre mission, c'est pourquoi nous avons un service dédié écrit en Python et déployé avec Kubernetes chez un autre fournisseur de cloud, construit par notre équipe d'IA. Une équipe de transcodage, cependant? Peu probable. Pas d'équipe de transcodage, pas de service de transcodage.

Migration complète vers Hetzner : Tentant, mais pas pour nous (pour l'instant ?)

Nous ne pouvons nous empêcher de lever notre chapeau à l'exode récent de Basecamp vers le cloud en utilisant Kamal— c'est le genre de démarche qui fait briller les yeux de l'équipe technique chez Happy Scribe. Nous avons aussi eu énormément de chance qu'ils lancent Kamal juste au moment où nous allions commencer à travailler sur ce projet.

L'idée de suivre ces traces et de déplacer toute notre opération vers Hetzner est certainement tentante. Mais voici la chose: nous ne sommes pas Basecamp. Ils ont environ 30 programmeurs, et nous sommes 8. Notre équipe ops est, eh bien, inexistante. Quand un travailleur de fond tombe en panne, ce n'est pas une crise—les tâches sont rapidement reprises par un autre travailleur. Mais une interruption du service web? Non merci. Pour l'instant, nous gardons le web là où nous savons qu'il est sûr et solide—sur Heroku. Cela laisse les huit d'entre nous libres de faire ce que nous faisons le mieux: offrir une réelle valeur à nos clients.

Pensées d'adieu

Notre modèle multicloud pourrait être votre tremplin loin du cloud. Il réduit les coûts sans ajouter trop de complexité et garde votre équipe concentrée sur ce qu'elle fait de mieux. Si nous devions planifier une migration complète, nous commencerions certainement comme ça, puis migrerions progressivement tout le reste (web, base de données, etc.). Nous espérons que notre parcours vous offre des perspectives, que vous optiez pour une migration complète ou partielle.

Avez-vous trouvé cela intéressant? Nous recrutons. Qui sait, avec une équipe plus importante, cette migration complète vers le cloud pourrait bien être à l'horizon.