Application servicialisée

• Pas de livraison (téléchargement automatique)
• Pas d'installation, si ce n'est un client pour l'utiilser
• Mises à jours automatiques
• Nécessite une connection internet pour fonctionner
• Le client est dépendant de l'OS, pas l'application
• Exemple : Google Docs

Architectures orientées services

• C'est une représentation logique d'une activité métier avec un résultat attendu.
• Elle est auto-contenue.
• C'est une boite noire pour ses utilisateurs.
• Elle peut être composée de sous-services.

Principes fondateurs

• La valeur métier est plus importante que la stratégie technique.
• L'inter-operabilité intrinsèque est plus importante que les intégrations spécifiques.
• Il vaut mieux avoir des services génériques partagés que des implémentations spécifiques.
• La flexibilité est plus importante que l'optimisation.
• Il vaut mieux rafiner progressivement qu'essayer de faire parfait dès le début.

• Contractualisés
• Autonomes
• Accessibles
• Boîtes noires
• Composables
• Réutilisables
• (Auto-découvrables)
• (Composés de services qui n'etaient pas prévus pour une architecture SOA)

L'architecture mono-service

• Toutes les fonctionnalités sont réalisées dans le même service
• Utilisateurs, documents, évènement, discussions, ...
• Le service peut devenir complexe à maintenir et à faire évoluer

L'architecture micro-services

• Apparue au début de la décénie
• Popularisée par Netflix
• Considérée (a tord) comme un remède miracle

Principe

• La philosophie est identique à celle du monde UNIX : "Faire une seule chose mais bien le faire"
• Les services sont petits et ne font qu'une seule fonction
• Le déploiement et le test automatique sont indispensables
• Durant la conception, il faut vivre avec les erreurs et les pannes, quite à en provoquer
• Chaque service est élastique, résistant, composable, minimal et complet

Intérêt

• Coût de mise en place supérieur
• Maintenance simplifiée et moins coûteuse

Exemple : redimensionnement de miniature

Eviter les nano-services (1)

• Les micro-services trop petits sont un anti-pattern
• Surcharge de code écrit (et donc de bugs)
• Surcharge d'exécution : transformations, trafic réseau
• Logique fragmentée : la fonctionnalité est distribuée sur plusieurs services
• surcoût de conception et de maintenance

Eviter les nano-services (2)

• Packager une fonctionnalité en tant que librairie plutot que service
• Combiner la fonctionnalité avec d'autres pour avoir un service un peu plus conséquent
• Refactoriser le système : refaire son design ou mettre la fonctionnalité dans d'autres services existants

Faire évoluer une architecture mono-service

• Conception initiale ou évolutions qui ont ajouté des fonctionnalité
• Le service devient trop complexe à maintenir
• Evolutions compliquées, difficile d'ajouter de nouveaux composants dans nouveaux langages

Tout rédévelopper en plusieurs services

• On redéveloppe tous les services de la même manière
• Stack homogène
• Mauvaise idée : Big-bang = catastrophe
• Nécessite un investissement conséquent sur une période étalée
• Maintenance en double

Transition progressive

• On identifie bien les briques de fonctionnalités qui peuvent être isolées
• On les servicialise et on les intègre une a une
• On peut aussi s'interfacer avec des services existants
• Stack qui peut être hétérogène
• Le reste du produit peut encore évoluer

Centralisée

• Session centralisée dans le serveur
• Latence aditionnelle
• Single point of failure

Par jeton

• JSON Web Token (JWT)
• Le jeton porte la session
• Il est stocké coté client
• Emis dans chaque requête HTTP (header)
• Il est signé par la clé privée du fournisseur d'authentification
• Les services qui ont la clé publique du fournisseur d'authentification peuvent le vérifier
• La durée du jeton peut être plus longue
• Serveur reste stateless

Architecture Web

Nombre de services

• Il va dépendre du découpage fonctionnel
• Cartographie applicative alignée sur la cartographie métier

Choix de la stack

Bases de données

Rendu coté serveur ou coté client ?

• Coté serveur : SEO, plus léger pour le client, mais plus coûteux en resources
• Coté client : Single Page Application
• Librairies accessibles avec des CDN
• On peut faire les 2 !

API des services backends

• Points d'entrée pour les clients Web et les autres services
• La documentation et la contractualisation sont essentielles
• Bien respecter la modélisation REST et les verbes HTTP
• Un verbe = une action (GET, POST, PUT, DELETE, ...)
• Ne pas mettre d'états dans le service ! (stateless => scalable)
• Peut se concevoir rapidement en wrappant un service existant
• Bien maitriser l'asynchronisme !

Contrat / documentation d'API

Compatibilité ascendante

• Elles sont faites pour être utilisées par d'autres applications
• Compatibilité non assurée => application cassée
• Versionner les API
• Privilégier les ajouts à de la réécriture
• Bien documenter les changements entre les versions

Interface cliente

• HTML (contenu) + CSS (forme) + Javascript (dynamisme + interactions)
• L'utilisateur ne voit que ca, pas tout ce qu'il y a derrière
• Les clients web n'ont plus rien a envier des applications installées
• Belles animations, ergonomies matures
• On peut même faire de la 3D dans le naviagateur (jeux possibles)

Reverse proxy

• Nginx, HA proxy, Traefik, ...

Expérience utilisateur

• Reste le point le plus important
• La latence doit être inférieure à 1 seconde
• L'architecture est construite dans ce but
• Bien maitriser les proxys, les caches, CDN ...

Automatisation

Devops

• Development + Operations
• Objectifs contradictoire : fonctionnalité vs stabilité
• Dévelopements, Déploiements, tests, déploiements, test, ...
• Feedback / amélioration rapide sur des petites itérations
• Mesures, analyses, surveillance

Amélioration continue

Développement

Build

• Objectif : préparer le livrable
• Déclenché au commit
• Peut se décomposer en plusieurs phases
• Si tous les indicateurs sont au vert, un livrable est créé
• Différents types : archive, conteneur, image, tag dans un SCM, ...

Tests

• Les tests unitaires font partie du développement
• Tests d'intégration
• Les tests sont programmés ou enregistrés
• Tests d'API et test d'UI
• Testcomplete, SoapUI, Selenium, ...

Release

• Le livrable a un code (peut être lié a un hash de commit)
• Le livrable est promu
• On peut avoir une étape intermédiaire : release candidate
• Mise a jour dans le gestionnaire de code (tag)

Déploiement

• Le livrable est installé dans un ou plusieurs environnements
• Processus automatisé : Ansible, Docker, ...
• Les configurations de déploiement peuvent être versionnées
• Bien maitriser la configuration des proxys

Exploitation

• Mise en place de contrôles et d'alertes
• Ajustement par rapport à la charge (Load balancing)
• Collecte d'indicateurs (Monitoring)

Avenement du cloud

Outils en ligne

• SCM : Gitlab, Github, ...
• Build : Gitlab, TravisCI, ...
• Registres docker : Gitlab, Dockerhub, ...
• Test, monitoring, ...

Hébergement de machines virtuelles

• Provisionnées en quelques minutes
• Peuvent être conséquentes et supporter beaucoup de machine
• Très facile de composer sa propre architecture / sous-réseau
• On peut s'adapter facilement aux variations et pics de charge
• Il faut des compétences d'opérationel

Hébergement de conteneurs

• Les conteneurs sont plus légers que les VM
• Conteneurs déployés en quelques secondes
• On ne s'occupe plus du matériel
• Très facile de composer sa propre architecture / sous-réseau
• On peut s'adapter encore plus facilement aux variations et pics de charge
• Compétences d'opérationel plus restreintes

La conteneurisation gagne du terrain !