Qu'est-ce que Little Big Cluster ?

Aujourd'hui, nous allons parler des motivations derrière le produit Little Big Cluster

Chez Anybox nous sommes actuellement une petite ESN d'une quinzaine d'employés. Historiquement nous hébergions uniquement des instances Odoo (un ERP) pour nos clients et tous nos outils internes.

Petit à petit les choses évoluent, les personnes changent, le contexte aussi, il est parfois difficile de transmettre pourquoi tel ou tel
outil a été mise en place et surtout pourquoi cela a été fait de telle ou telle manière.

Dans une petite entreprise, innover afin de proposer des offres de produits, en complément de nos offres de services existantes, nécessite de gérer des projets de plus en plus variés. Il est donc important de donner la main à l'ensemble des collaborateurs sur le SI, pour rendre au maximum les équipes autonomes et de ne plus dépendre d'un ou deux administrateurs système pour déployer un nouveau service.

A l'heure où la sécurité et le respect de la vie privée (via la RGPD) sont des enjeux majeurs pour tous, il n'est pas non plus question de laisser quiconque  se débrouiller et maintenir son petit service dans son coin.

Il est important d'accompagner chacun des employés dans des processus maîtrisés, cohérents et uniformes afin d'offrir des services disponibles, stables et maintenus à jour.

Le fait de rendre les collaborateurs plus autonomes ajoute également des challenges complémentaires:

• Les administrateurs de la plateforme ont moins facilement l'information de ce qui est actuellement important, qui travaille sur quoi et quand. Il faut donc permettre aux administrateurs de la plateforme d'intervenir pendant les heures de travail sans générer d’interruptions de service. Pour cela la plateforme et les services se doivent:
• D'être configurés en haute disponibilité à tous les niveaux
• La résilience des services aux pannes doit également être testée en continu, cela est facilité par le mouvement de chaos engineering/Monkey initié par Netflix pour s'assurer en permanence du bon fonctionnement de la résilience. Oui, oui vous avez bien lu nous créons des pannes en production !
• Il devient difficile d'estimer les ressources nécessaires pour dimensionner l'infrastructure, le besoin d’élasticité est très important. Selon les besoins, soit nous rendons abstraite la couche matérielle, ou, nous nous reposons directement sur les offres d'hébergement cloud qui permettent d'avoir une flexibilité vraiment intéressante pour des services régionaux, cela permet par exemple de tourner avec 3 instances répliquées la nuit contre 25 la journée pour un service donné et ajuster les ressources aux besoins.
• Les développeurs ont besoin d’être accompagnés et sensibilisés à comment tourne une application avec des contraintes de haute disponibilité pour comprendre comment est exécutée l’application dans l’environnement cible, également sensibilisés aux pannes opérationnelles afin que le développeur puisse se projeter et anticiper le fonctionnement en production et ainsi produire des applications de plus en plus résilientes.

Le mouvement DevOps a rapidement évolué les 10 dernières années, un grand nombre d'outils Open Source matures sont disponibles permettant de construire une plateforme complète, hébergeant des services de nature et de technologie différentes, à l'instar des transporteurs dans les années 60s, qui ont commencé à transporter les objets dans des conteneurs pour uniformiser les méthodes et les outils de transport et ainsi drastiquement réduire les coûts.

En tant que développeur sur un nouveau projet on a déjà beaucoup à apprendre du domaine fonctionnel, des frameworks utilisés, l'uniformisation des points d'entrée permet de réduire les coûts par des conventions partagées et permettent de collaborer plus rapidement, l'entreprise devient plus flexible, réactive aux besoins de charges de ses clients, les délais de mise en œuvre se réduisent car on se pose moins de questions sur où et comment mettre en œuvre le projet, les temps de montée en compétence sont réduits. Évidemment, Docker a abstrait un grand nombre d'interfaces et ainsi facilité la portabilité des applications développées et la manière de les déployer, il ne faut pas s'arrêter là, des initiatives vont plus loin comme gazr qui normalise comment :

• mettre en œuvre un environnement de développement,
• construire (builder) un projet,
• lancer des tests: unitaires/fonctionnels/d'intégrations...,
• déployer sur une plateforme de qualification, staging, pré-production, production
• mettre à jour un projet
• etc.

L'infrastructure as code (IAC) nous aide et permet :

• De reproduire une plateforme d'hébergement complète rapidement
• De partager l'effort d'infrastructure entre plusieurs entreprises en partageant des éléments de configuration
• De tester la plateforme d'hébergement Docker / l'infrastructure
• De tester des évolutions de la plateforme dans un laboratoire isolé de la production avant de déployer les évolutions.

Nous explorons plusieurs pistes d'architectures, une première reposant sur les services d'AWS qui offre une flexibilité et une réactivité à toute épreuve. Nous publions la configuration en Open Source: https://github.com/littlebigcluster/aws-infra

Une deuxième, basé sur l'utilisation de machines physiques louées chez des hébergeurs par exemple où toute la chaîne est maîtrisée, cette solution est grandement facilitée par l'usage de Proxmox: https://github.com/littlebigcluster/proxmox-infra

Dans les 2 projets les fondamentaux sont similaires. Nous détaillerons les schémas de principe dans des articles à venir. En attendant n'hésitez pas à consulter les dépôts de configurations qui contiennent également plusieurs informations. Ouvrez des issues, créez des pull request, elle seront les bienvenues.

Si vous souhaitez vous aussi que votre entreprise ait la maîtrise sur le workflow de développement de ses projets, profitez de notre expérience pour vous accompagner dans ces démarches, vous pouvez nous contacter par le formulaire de contact.