Développer une app sans SaaS : c'est possible !

Développer en local

Que ce soit pour commencer son projet ou intégrer une nouvelle feature, le développeur devra passer par une phase de code locale. Il voudra accéder à son toolkit favori pour pouvoir intégrer rapidement et efficacement sa nouvelle idée.

Imaginons que notre développeur aimerait mettre à jour son application en NodeJS et installer sa nouvelle librairie préférée. Il voudra sûrement accéder à une API de service extérieur (comme Google Maps par exemple) et intégrer le dernier script JS qu’il a trouvé sur un site de communauté open-source.

Une fois le développeur privé de ses services favoris, ces actions peuvent devenir complexes à mettre en œuvre. Comment accéder à nos ressources et services préférés ? Comment maintenir nos versions à jour simplement ?

Heureusement, des solutions existent ! Vous imaginez que si ce problème arrive à notre développeur, il n’est pas le premier à le rencontrer... Mettre en place des solutions telles qu’un gestionnaire de dépôts d’artefacts, comme le bien connu Artifactory, permettra de stocker et d’indexer des librairies, des scripts, ou même des données brutes qui pourront être utilisés par le développeur de la même manière que les services en ligne. Les différents dépôts doivent être alimentés (par les développeurs, les administrateurs, des scripts automatiques...) afin de maintenir les versions des artefacts ou d’en ajouter de nouveaux.

Cette alternative fonctionnelle et très répandue, permet de palier le besoin d’accéder à de nombreux services du web (dockerHub, npmjs, maven...) et d’avoir un contrôle total sur l’ensemble des données utilisées, mais peut vite devenir gourmande en termes de stockage, car il s’agit tout simplement de dupliquer l’ensemble de nos besoins pour pouvoir y accéder.

Développer en équipe

Un développeur, c'est bien. Plein de développeurs, c’est mieux. Mais qui dit équipe, dit cohésion, harmonie et écosystème à maintenir. Travailler sur une code-base commune implique d’être équipés d’outils adaptés, qui évitera tout conflit de développement et de mises à jour entre les versions de chacun des développeurs.

Aujourd’hui, les réputations de git et des services web qui l’accompagnent (GitHub, GitLab, Bitbucket) ne sont plus à faire. Ces outils permettent à chaque développeur de coder de sib côté tout en gardant une cohérence sur l’ensemble du code applicatif, et ainsi lui permettre d’être plus à l’aise et de faciliter ses contributions sur les différents projets.

Mais la plupart de ces services sont disponibles en tant qu’offre en ligne et ne peuvent donc être utilisés qu’en possédant la sainte connexion internet.

Heureusement, certains de ces services existent en versions autohébergées (Self Hosted pour les bilingues 😉), comme GitLab. Il est possible de monter sa propre instance du service et d’héberger ses projets et ses versions soi-même.

Néanmoins, monter ce type d’instance peut rendre l’infrastructure plus complexe et beaucoup plus difficile à maintenir. La plupart de ces services demandent une grande quantité de stockage ainsi qu’un grand nombre de services annexes pour être totalement opérationnel.

Livrer son application

Maintenant que nos développeurs ont pu réaliser leurs nouvelles features applicatives, ils vont devoir livrer leur application. Ce processus de livraison s’effectue en plusieurs étapes, rassemblées sous le sigle CI / CD / CD (Continuous Integration, Delivery & Deployment).

Il est dans un premier temps nécessaire de vérifier que les développeurs n’aient fait aucune erreur dans leur code et que celui-ci fonctionne comme il le devrait. La bonne pratique veut qu’on effectue différents tests automatisés (unitaires, d’intégration, de sécurité, e2e...). De nombreux services en ligne proposent des solutions pour réaliser ces tests, comme Jenkins ou TravisCI, mais les hébergeurs tels que Gitlab ou Github proposent des solutions intégrées.

Dans un second temps, nous allons vouloir conteneuriser notre application. Devenue une étape indispensable au déploiement d’un projet, cela permettra de transformer le code de nos développeurs en une image unique. Cette image permettra de démarrer l’application sur n’importe quelle plateforme possédant un lecteur d’image conteneurisée. Elle sera stockée sur un service de dépôt en ligne (comme DockerHub, Quay, GCR ...) pour ensuite être téléchargée et lancée par les outils de déploiement continu.

Enfin, une fois l’application déployée, elle sera reliée à de multiples services de supervision qui permettront de suivre son bon fonctionnement ou encore l’activité à laquelle elle fait face. Ces services web, comme Datadog, Kibana ou Grafana sont indispensables pour avoir une bonne visibilité de l’évolution de notre application et permettre une amélioration de celle-ci.

Encore une fois, si ces services web ne sont pas accessibles pour notre projet, il sera nécessaire d’adapter largement notre environnement pour permettre aux développeurs de livrer leurs applications et de les superviser.

Les solutions autohébergées du service Gitlab proposent par exemple de nombreuses fonctionnalités permettant d’effectuer des séries de tests sur notre code. Il est également possible de stocker des images conteneurisées que ce soit à travers Gitlab ou Artifactory. Les solutions comme Grafana ou Kibana proposent aussi des versions autohébergées qui permettront de déployer des services de monitoring d'applications, ses applications sans avoir à dépendre d’une solution externe.

Mais vous imaginez bien qu’à force d’ajouter de nouveaux services, de nouvelles configurations ou de nouveaux plugins à notre infrastructure interne, la complexité de celle-ci augmente considérablement et devient difficile à manager.

Les Forges logicielles

Les exemples précédents nous ont démontré qu’être développeur dans un monde coupé de nos réseaux et de nos services cloud préféré relève du challenge quotidien. Heureusement, beaucoup ont dû faire face à ces problématiques avant nous et divers outils ont été développés pour palier tout ça.

Nous avons pu mettre en avant certains de ces outils au cours de l’article, que ce soit Artifactory, Gitlab, Grafana ou encore Kibana. La mise en place et la configuration de ces outils pour créer un environnement stable, pérenne et résilient pour les développeurs porte le glorieux nom de Forge Logiciel (ou software Factory).

C’est cette forge, et l’ensemble des services et outils qui la composent, qui permettra de faciliter la vie du développeur en environnement offline.

Mais mettre en place une telle infrastructure requiert bien souvent une équipe de SRE dédiée, qui pourra également être chargée d’abonder les dépôts des dernières versions des librairies, ou encore de maintenir à jour l’ensemble des outils et services.

En voulant s’abstraire de la dépendance aux services web publics, on améliore considérablement la sécurité de nos données et de notre développement, mais la complexité de notre infrastructure interne augment fortement.

Conclusion

Les développeurs d’aujourd’hui ont besoin d’accéder à de nombreux services applicatifs différents afin de travailler dans de bonnes conditions. La grande majorité de ces services sont conçus par le web et pour le web. Néanmoins, pour certaines entreprises ou pour certains projets, il est impossible de permettre aux développeurs d’utiliser ces services en ligne et des solutions de contournement doivent être mises en place.

La mise en place d’une forge logicielle donnera l’opportunité aux développeurs d’avoir une expérience de travail au plus proche de celle qu’ils auraient avec un accès à leurs services préférés. Mais la mise en place d’une telle solution représente un investissement, financier comme humain et augmente considérablement la complexité de l’infrastructure déployée.

Il est donc légitime de se poser la question : ne pas utiliser les services du web est-il réellement une nécessité pour vous ? Et si tel est le cas, saurez-vous offrir à vos développeurs un environnement de travail convenable ?