Les principes d’ingénierie logicielle et d’architecture de l’UNIL
L’UNIL a lancé une transformation digitale depuis 2020, tant au niveau logiciel que architectural afin de revoir complétement son SDLC (Software Development Life Cycle)
Les principes de base
- Oriente services (Self Contained Systems)
- Architecture adapative (pattern clean/hexagonal) avec conception logicielle pilotée par le domaine
- Aproche API first
- Applications orientées cloud (containairisées)
- Securité by design
- Logiciel en tant que service (SaaS)
- Aproche agile/produit
- Aproche DevSecOps
- Amélioration continue — Innovation
Oriente services (Self Contained Systems)
Nous préférons les applicatifs (Self Contained Systems) faiblement couplés. Le but principal étant de développer des applications autonomes et isolées qui peuvent être déployés indépendamment, dont voici un résumé des grands principes
- doit être aussi autonome que possible.
- doit fonctionner dans son propre processus et être déployé de manière indépendante.
- doit démarrer et être résilient lorsque ses dépendances ne sont pas disponibles.
- ne doit pas partager son stockage de données ou son dépôt de code avec un autre service, afin que les changements n’affectent pas les autres systèmes.
- ne doit pas partager de bibliothèques avec d’autres services, à moins que ces bibliothèques ne soient open-source.
- ne doit pas fournir de bibliothèque client. L’API de base et son modèle de données sont le moyen de communication de base
Architecture adaptative (pattern clean) avec conception logicielle pilotée par le domaine
Les principes d’une architecture clean sont le pattern choisi dans le cadre de nos développements, ce qui implique qu’un application doit:
- Être indépendante des librairies et outils utilisés
- Être testable indépendamment : les tests doivent pouvoir être réalisés sans éléments externes (interface utilisateur, base de données …)
- Être indépendante de l’interface utilisateur : l’interface utilisateur doit pouvoir changer de forme (console, interface web …)
- Être indépendante de la base de données : il doit être possible de changer de SGBD.
- Être indépendante de tout service ou système externe : en résumé elle ne doit pas avoir conscience de ce qui l’entoure.
En voici un exemple d’implémentation écrit par notre équipe: https://medium.com/unil-ci-software-engineering/clean-domain-driven-design-2236f5430a05
Aproche API first
Une approche API-first signifie que pour tout projet de développement donné, nos API sont traitées comme des “frist class citizens”. Tout ce qui concerne un projet tourne autour de l’idée que le produit final sera consommé par des applications clientes.
Une approche axée sur les API implique le développement d’API cohérentes et réutilisables, ce qui implique d’adopter une stratégie “contract first”. Pour cela nous utilisons le standard Open API.
Ce principe nous amène à:
- définir les API en dehors du code d’abord en utilisant un langage de spécification standard (Open API 3.x) ou en implémentant les interfaces permettant une génération automatique du code sans faire l’implémentation
- obtenir un retour d’information le plus rapidement possible de la part des parties prenantes et des développeurs clients afin d’éviter des développements superflus
Logiciel en tant que service (SaaS)
Nos services sont développés de manière à pouvoir être proposés à des tiers en tant que solution SaaS. Cette stratégie permet de construire un système d’information totalement intégré, sans devoir développer des fonctionnalités à double par les équipes.
Sécurité — Security by design
Dans le cadre de nos développements nous nous efforçons de suivre ces principes de conception “security by design”
Dans une telle aproche, plusieurs éléments doivent être pris en compte dans la conception du système. En voici quelques exemples :
- Minimiser la surface d’attaque. Pour cela, il est notamment important de restreindre aux utilisateurs l’accès à certaines zones, afin de réduire les points d’entrée pour les violations de sécurité. Les tests d’intrusion peuvent dans ce cadre permettre d’identifier des failles de sécurité. Pour toute nouvelle application déployée il est conseillé de demander à notre division Infrastructure de
- Distinguer et restreindre les privilèges. Chaque utilisateur doit avoir un rôle défini et des accès restreints au strict nécessaire. L’administrateur peut, au cas par cas, accorder des accès supplémentaires si la demande se justifie. Cette restriction des privilèges permet de réduire le risque de violation de sécurité des utilisateurs.
- Prendre des précautions et rester vigilant vis-à-vis des services tiers.
Les éléments centraux de cette approche sont:
- Un standard d’authentification OAuth2-OpenID
- Utilisation d’un IAM, dans notre cas Keycloak
- Utilisation d’une plateforme de gestion d’API, dans notre cas KONG
Aproche agile/produit
Nous avons adopté depuis quelques années une approche agile basée sur un mode de fonctionnement où l’équipe en charge de la construction d’un produit prend également les décisions stratégiques sur ce produit. L’équipe responsable du produit gère le cycle de vie complet du service et s’entoure des sponsors et des feedbacks constants des utilisateurs pour continuellement amener de la valeur à ce produit.
Aproche DevSecOps
L’UNIL a décidé dernièrement de prendre une approche DevSecOps nous permettant d’intégrer la sécurité des données dès le début du cycle de développement. La sécurité de celles-ci est considérée comme une condition préalable avant de commencer tout nouveau développement. Ce principe s’applique non seulement aux données directement, mais aussi à leur exposition via des API.
Un gros effort a été réalisé pour automatiser tous les processus d’intégration et de déploiement, afin de garantir le maximum de temps créatif aux développeurs
L’objectif est de pouvoir l’intégrer dans l’ensemble du cycle de vie du produit, du développement à la mise en production, en utilisant des processus automatisés.
Amélioration continue — Innovation
Maintenir la compétitivité au niveau technologique de nos produits sur le le long terme est sans aucun doute l’un des plus grands défis pour nos équipes d’ingénierie. En effet, il est nécessaire de toujours mettre à jour et réviser les solutions en place, car notre industrie évolue très rapidement, et de nouvelles solutions arrivent sur le marché constamment pour résoudre certaines de nos problématiques. De plus cela permet de garder la compétitivité de nos talents au niveau technologique.
Pour suivre et visualiser toutes ces solutions utilisées au sein de notre équipe, nous avons pris la décision d’utiliser un Tech Radar, qui un des standards pour de garder une trace visible des outils utilisés.
Afin de toujours garder la compétitivité technologique et ce Tech Radar à jour, nous avons introduit le concept de sprint d’innovation (3 sprints de deux semaines par année) afin de faire de la veille technologique et toujours suivre les tendances de notre industrie.
Socle technologique supportant ces principes
En résumé le socle technologique est composé:
- Orchestrateur — Kubernetes — Rancher
- Déploiement — ArgoCD
- Intégration et build des atifacts/images — Jenkins pipelines
- Data — Oracle, Talend, DBMaestro
- Securité /Qualité— Jfrog, Sonarqube
- Orchestration — Camunda, Kafka, Debezium
- Logging — ELK
- Monitoring/Obeservabilité — Prometheus, Skywalking, Grafana
- Data source — Postgresql, Redis, MongoDB
- Framework de développement — Spring, ZKoss
- Plateforme API — Kong
- IAM — Keycloak
Et un mot de la fin…
Notre mission de tous les jours est de construire des systèmes simples, efficients et efficaces afin de nous procurer du plaisir, et de ce fait amener de la valeur à nos clients.
Voir ces système utilisés quotidiennement par des milliers d’étudiants et la communauté universitaire nous procure de la fierté.
Nous développons parce que nous aimons cela et si nous n’avions pas à travailler, je suis convaincu que nous le ferions probablement de toute façon ;-).
