Technologie derrière un SaaS géré par une seule personne

Chaque fois que je vois des ingénieurs écrire sur leur stack, je suis curieux de découvrir de nouveaux outils. Surtout lorsque vous gérez tout seul, vous cherchez toujours à apprendre de l'expérience des autres.

En 2015, j'étais frustré par le niveau des gestionnaires de mots de passe de l'époque, surtout parce qu'il n'y avait rien de décent pour les personnes gérant des serveurs privés. J'ai commencé à travailler sur Psono, un gestionnaire de mots de passe open source avec un bon niveau de cryptage et des options de partage sécurisées. Psono n'a jamais été destiné à fonctionner en tant que SaaS, sinon j'aurais probablement inclus dès le début la prise en charge de plusieurs locataires.

Pour que vous ayez une idée de l'ampleur de Psono : Psono est actuellement installé localement dans environ 70 pays, avec plus de 4000 installations. Psono SaaS est actuellement utilisé par plus de 15 000 personnes, la plupart d'entre elles utilisant notre édition communautaire gratuite de Psono, qui fonctionne sur la même pile technologique que notre produit Enterprise payant.

La stack d'une installation typique de Psono se compose d'une base de données, d'un serveur, de deux clients web (un pour les utilisateurs réguliers et un pour les administrateurs), d'applications pour iOS et Android, d'extensions de navigateur pour Chrome et Firefox. Un client peut installer une passerelle LDAP ou un serveur de fichiers en plus de cela.

En plus de cela, j'ai encore beaucoup plus d'infrastructures en place. En commençant par le site web pour alimenter la page d'accueil de l'entreprise et la page produit, j'ai un serveur de licences pour notre produit Enterprise, un système ERP central pour gérer les devis et les factures, une boutique où les gens peuvent acheter Psono SaaS et gérer leur installation, et un service d'authentification avec OIDC.

Au fil de l'article, vous verrez que je préfère les technologies anciennes et éprouvées.

Langages

• Python : Tout le code backend est écrit en Python. Le plus grand avantage de Python est son écosystème riche. L'absence de types (que beaucoup considèrent comme un inconvénient) rend extrêmement rapide l'écriture de votre service web, ce qui est, en tant que startup, l'un des aspects clés à prendre en compte lors du choix d'un langage de programmation.
• Javascript : Oh non... qui l'aurait cru... Il est tout simplement impossible de créer un site web sans Javascript, déjà en 2015. ;)

Python est mon langage préféré pour les services web. (Je laisse de côté ici mes réflexions sur pourquoi XY n'est pas mieux que Python. Cela remplirait un autre article de blog). Il y a juste un inconvénient auquel vous devez faire face, et c'est la possibilité de livrer du code avec toutes les dépendances de manière fiable, ce qui est particulièrement crucial si les gens installent votre logiciel localement et demandent de l'aide en cas de problème. (En termes de vitesse, ce que d'autres personnes pourraient ajouter ici n'a pas d'importance. Python est suffisamment rapide).

Frameworks

• Django : "C'est comme un super pouvoir pour les développeurs solos" (si je peux citer Anthony N. Simons ici). Avec l'écosystème, il résout presque tous les problèmes que vous pouvez rencontrer. Authentification, modèles, e-mails, migrations de bases de données, TOTP... pour n'en citer que quelques-uns.
• Django Rest Framework : Il alimente actuellement toutes les API et fait un excellent travail. Les différentes couches (sérialisation, authentification, permissions, vues) maintiennent votre code extrêmement propre.
• React : J'ai récemment migré le client web régulier vers React. L'ancien client web (rappelez-vous qu'il a été lancé en 2015) était écrit en AngularJS, et c'était une entreprise assez difficile de rester compatible avec l'ancien client, par exemple, tous les chemins vers l'utilisateur ne doivent pas changer, car ils pourraient avoir des liens enregistrés vers des secrets dans leur documentation ou utiliser des partages de liens. De plus, les gens utilisaient une marque personnalisée avec leurs propres logos, etc., où les chemins dans le système ne devraient pas changer.
• webpack : Je voulais le mentionner ici, car c'est actuellement la seule partie avec laquelle je ne suis pas satisfait. C'est lent, frustrant, difficile à apprendre... le seul avantage est que vous ne restez jamais bloqué. Tout problème que vous pourriez rencontrer a déjà été posé sur Stackoverflow et vous trouverez une solution.
• Gatsby : Alimente nos sites web statiques pour l'entreprise et le produit. Dans le passé, j'utilisais WordPress, mais la surcharge de gestion avec les mises à jour et la peur constante que le site soit compromis (et la potentielle mauvaise publicité) nous ont fait passer à Gatsby. Jusqu'à présent, je n'ai jamais regretté ce choix.
• Vuepress : Le système de gestion de documentation le plus décent que j'ai pu trouver. Il compile en sites web statiques, a un look moderne et alimente actuellement la documentation de Psono.
• Material UI : La principale bibliothèque qui alimente le frontend. Elle est riche en fonctionnalités, s'intègre bien avec React et a un look assez moderne, contrairement aux thèmes plus anciens basés sur Bootstrap.

Il y a certainement d'autres frameworks qui mériteraient d'être mentionnés ici, mais ceux-ci sont les "plus importants" selon mon opinion.

Bases de données

Bien que Django supporte plusieurs bases de données, j'ai très tôt été confronté à la question de savoir si je voulais supporter toutes les bases de données de Django ou seulement une en particulier. La racine de cette question était que je stockais des structures d'arbres imbriqués dans la base de données. Donc des arbres avec plusieurs racines et des branches partagées. Interroger ces structures de manière efficace était crucial, donc après avoir exploré toutes les options disponibles, j'ai décidé d'utiliser l'extension ltree de Postgre.

Si vous prévoyez de développer quelque chose et de le gérer seul, il doit fonctionner de manière fiable dans le cloud, géré par le fournisseur de cloud. Vous ne voulez probablement pas non plus être lié à un fournisseur, donc rien de spécifique au cloud, ce qui limite assez vos choix.

Mon choix :

• Postgres : Il y a deux bases de données open source parmi lesquelles vous pouvez choisir. MariaDB ou Postgres. J'avais toujours prévu d'utiliser Maria (principalement en raison du Galera Cluster de Maria DB, une de ces histoires mal guidées de "jeune développeur qui doit planifier une hyper croissance" ;D), mais en raison des extensions ltree manquantes, mes mains étaient liées. Aujourd'hui, avec tout le développement qui va dans les options de sharding de Postgres, je n'ai jamais regretté cette décision jusqu'à présent.
• Redis : Prévu pour être utilisé comme cache pour les installations plus importantes. Ici aussi, vous pouvez choisir entre Redis ou Memcache. Les deux sont excellents, mais principalement en raison du fait que le protocole Redis est aujourd'hui devenu le standard de facto pour le caching, j'ai opté pour Redis. Le seul inconvénient que j'ai jamais rencontré avec Redis est qu'il est monothread.

Infrastructure

Un petit aperçu de l'infrastructure sur laquelle repose Psono :

• Gitlab : Gitlab alimente toute l'automatisation de Psono. Il est important de noter que tout dans Psono est automatisé, ce qui est l'un des aspects clés de la manière dont je peux gérer les versions et maintenir l'ensemble de l'écosystème de Psono. En 2015, chaque projet open source fonctionnait sur GitHub, mais Gitlab était (et est toujours) si puissant et supérieur en termes de fonctionnalités (à l'exception de la fonctionnalité de recherche de GitHub). Gitlab alimente les builds, les versions, les analyses de vulnérabilités de CHAQUE morceau de logiciel que nous utilisons.
• Cloudflare : Probablement l'entreprise la plus innovante que je connaisse et qui m'a influencé au cours des 10 dernières années. Il est juste de dire que Cloudflare alimente Internet de nos jours. Il me fournit des serveurs de noms fiables, TLS, un CDN décent, et des fonctionnalités avancées comme leur worker edge. La protection DDoS et la fonctionnalité WAF offrent un certain supplément, ce qui est assez important pour un gestionnaire de mots de passe. J'adorerais utiliser leur fonctionnalité SSL en tant que service pour permettre aux clients SaaS de configurer leurs propres domaines, mais le paywall du niveau Enterprise de Cloudflare est tout simplement trop élevé. J'espère toujours qu'ils le publieront quelque part en tant

que plugin indépendant que l'on pourra acheter.

• namecheap : Ma solution préférée pour les domaines et les certificats SSL.
• Google Cloud Run : Tous les serveurs backend fonctionnent sur Google Cloud Run, qui est extrêmement rentable et fiable lorsque vous voulez lancer une flotte de services. Une fois que votre stack est en marche, il fait un excellent travail. Leur intégration API/CLI de premier ordre est un atout absolu ici. Il y a quelques inconvénients, comme le manque de support de Google ou la menace que Google décide à un moment donné que le fait d'être #3 en tant que fournisseur de services cloud pourrait ne pas en valoir la peine et qu'ils annulent le produit.
• Artifactory : Protège ma pipeline de build contre les pannes de npm et stocke mes artefacts de build (qui n'étaient pas intégrés dans Gitlab en 2015).
• Docker Hub : Stocke tous les conteneurs Docker et effectue des analyses de sécurité supplémentaires et la distribution de mes conteneurs.
• Mailgun : Gère tous les e-mails. Contrairement à la plupart des fournisseurs de solutions de messagerie, Mailgun dispose de fonctionnalités de journalisation et d'analyse décentes. Leur support est de premier ordre. Le seul problème est que leurs e-mails sont parfois envoyés dans la boîte de réception de spam (même avec SPF, DMARC, etc.), mais à part cela, ils font un excellent travail.
• Poeditor : Gère toutes les traductions. Ce qui est bien, c'est que les contributeurs peuvent demander l'accès, ce qui est crucial si vous voulez que des externes vous aident à traduire votre projet. Leur support est génial et vous obtenez des réponses extrêmement rapides.
• Docker : L'une des meilleures décisions pour l'ensemble du projet. Surtout que j'utilise Python, et livrer du code Python fonctionnel avec toutes les dépendances Python/OS est difficile. Si les choses doivent fonctionner chez un client sur site et que l'exigence est qu'il puisse mettre à jour et maintenir le système, Docker nous permet de tout faire et me donne un contrôle total sur les paquets installés, ce qui résout au moins 70 % de tous les problèmes de support (tout en introduisant 20 % de nouveaux problèmes car les gens ne sont pas habitués à Docker ;D).

Monitoring

Les choses peuvent mal tourner, et vous devez savoir quand cela se produit et obtenir des informations sur le problème. C'est là que ces outils sont utiles :

• Google Cloud logging : Si vous êtes sur Google, votre solution naturelle.
• Sentry : Ma solution numéro un pour les rapports d'erreurs. Une fois que vous l'avez essayé, vous ne voudrez plus jamais vous en passer. Il me donne les informations nécessaires sur toutes les erreurs.
• Uptimerobot : Appelle le healthcheck de mes différents services et m'alerte si quelque chose tombe en panne. La page de statut public de Psono, d'ailleurs, se trouve ici https://stats.psono.com/, qui n'est qu'une petite fraction des services que ce système surveille pour moi, mais qui, je l'espère, démontre un peu la fiabilité du système.

Infrastructure de développement

Un petit aperçu de la façon dont ma stack de développement locale est configurée :

• Windows avec WSL : Je vais probablement recevoir beaucoup de critiques pour cela, mais oui, je travaille sous Windows. Au cours des dernières années, j'avais toujours une VM Linux quelque part à laquelle je me connectais pour le développement, mais de nos jours, c'est alimenté par WSL. Je profite du meilleur des deux mondes.
• Pycharm / Webstorm : J'utilise les IDE de Jetbrains. La fonctionnalité de développement à distance est cruciale pour mon flux de travail de développement, et cette philosophie "batteries incluses" me convient bien. Parfois, j'ai environ 20 projets ouverts, ce qui nécessite un matériel décent avec suffisamment de RAM. VSCode semble être une bonne alternative de nos jours, mais au fil des années, je me suis habitué à Jetbrains, et apprendre quelque chose de nouveau nécessite toujours une certaine force mentale que je ne suis actuellement pas prêt à investir. Je dirais que chacun devrait utiliser ce à quoi il est habitué.

Support

Il existe bien sûr certains outils nécessaires pour gérer le support des personnes utilisant le produit :

• Freshdesk : Un logiciel de ticket par e-mail typique. Il m'aide à suivre les différentes demandes des clients. À l'époque, il offrait un niveau gratuit décent, ce qui est crucial, surtout au stade de la fondation.
• Discord : Certaines personnes peuvent préférer le chat ou nécessiter une conversation/assistance plus directe. C'est là que Discord est utile.

Autres

Il y a certains autres outils que je voulais mentionner qui peuvent être utiles à d'autres. Surtout les banques pour ceux qui veulent gérer leur entreprise en Allemagne :

• Odoo : Le meilleur système ERP. Son édition open source est gratuite et peut être facilement étendue avec des connaissances en Python et en XML. Ses options de personnalisation et d'intégration avec des API personnalisées sont de premier ordre.
• Holvi : Notre compte bancaire principal. En Allemagne, vous avez besoin d'une banque qui vous permet de créer un compte fondateur, en allemand "Gründerkonto", donc un compte bancaire lié à une entreprise qui n'est pas encore entièrement enregistrée et où vous pouvez transférer les fonds initiaux nécessaires à l'enregistrement de l'entreprise. Un petit problème de "l'œuf ou la poule". Et les grandes banques qui permettent cela coûtent généralement une fortune. Le processus d'inscription a également fonctionné sans problème. Le seul inconvénient est le manque de support pour les paiements internationaux, mais c'est là que le service suivant est pratique.
• Wise : Notre deuxième compte bancaire. Leurs frais sont extrêmement bas (par exemple, pas de frais mensuels), le processus de configuration fonctionne sans problème, ils sont bien connectés et permettent des transferts bancaires internationaux, et les transferts sont effectués rapidement, donc vous n'avez pas à attendre des semaines ou autre.

Sécurité

Je suppose que cela pourrait faire l'objet d'un billet de blog séparé sur la façon dont nous avons structuré les comptes d'utilisateurs, l'infrastructure et les droits d'accès. Comme c'est l'un des aspects les plus cruciaux de la sécurité de Psono, je ne vais pas entrer dans les détails ici et essayer de rester assez vague. Nous utilisons à la fois des services Google Cloud et Azure. Les deux avec des utilisateurs et des groupes complètement séparés. Il y a des utilisateurs dédiés aux tâches d'administration et des comptes d'utilisateurs pour les "activités quotidiennes". Il y a différents systèmes physiques et virtuels que j'utilise pour accéder à / supporter / gérer / administrer Psono. Les tâches d'administration ne sont effectuées que sur un appareil physique séparé, spécialement renforcé, utilisé exclusivement pour ces tâches. Chaque compte est protégé par des tokens matériels. Tous les systèmes sont gérés de manière centralisée et des politiques de sécurité sont en place pour garantir que tous les appareils respectent les normes de sécurité que l'on trouve habituellement dans les banques.

Crédits

Cet article a été fortement inspiré par l'article d'Anthony N. Simon sur Panelbear.