Back-end story
Celui qui ne sait pas d'où il vient
ne peut savoir où il va.
Antonio Gramsci
{firstname:'Stéphane' ,
lastname : 'Michel',
job: 'Software Craftsman'}
© Stéphane Michel
Sommaire / Concepts clés
SOMMAIRE
Backend vs Frontend
Définition
backend : Partie serveur d'une architecture logicielle
Opposée à frontend (partie cliente / interface graphique)
Y sont déportés les traitements lourds / métiers et les données
Serveur
Qu'en attend-t-on ?
Performances
Capacité de montée en charge (scalability)
Stockage
Gros volumes (To, Po)
Tolérence aux pannes (disques RAID 2 et +)
Clusterisation
Load balancing
Sauvegarde centralisée
Bref, un truc 100% disponible !
Préhistoire
Le premier ordinateur : ENIAC en 1945
30 tonnes, 167 m2
Système centralisé (mainframe) et terminaux passifs
Avant les années 80
Avantages
Utilisation des ressources optimale (1 serveur unique, très cher et très volumineux)
Inconvénients
Terminaux passifs : ergonomie /possibilités faibles
Nombreux clients simultanés (jusqu'à plusieurs milliers pour les plus performants)
A partir des année 80
Normalisation des OS (UNIX) et des architectures et des langages (C)
Amélioration considérable de l'ergonomie (interfaces graphiques, fenêtres, etc.)
Montée en puissance des ordinateurs personnels
C'était bien, mais surtout pour travailler dans son coin (architecture 1 tiers)
Pour travailler à plusieurs on reste sur du mainframe
Années 90
Et on a eu envie d'interconnecter tout ça...
Des serveurs puissants, des clients avec des interfaces graphiques.
Surtout qu'on disposait d'une technologie réseau déjà efficace : TCP/IP
Ainsi est né le client / serveur !
Architecture 2-tiers
Et pourquoi mettrais-je du code métier côté serveur ?
En local, connecté à une base distante ce serait plus simple ? non ?
Client
Client
Client
BDD
2-tiers
Présentation et traitements
Données voire traitements (procédures stockées, argh !)
Inconvénients
- Performances : Les BDD s'écroulent à partir de quelques dizaines d'utilisateurs...
- Utilisation réseau importante (verbosité du SQLNet)
- Acteurs uniques -> coût importants : Oracle / IBM
- Code propriétaires côté serveur, quand on choisit une BDD c'est pour longtemps...
- Pas encouragé à faire de la séparation en couche -> maintenabilité faible
- Problème de lock en base (mises à jour transactionnelles)
Avantages 2-tiers vs 1-tier
Partage de l'information : 1 seule BDD (éventuellement en cluster)
Stockage centralisé et transactionnel (ACID)
Obsolète depuis la fin des années 90
Cas d'utilisation du 2-tiers
Architecture 3-tiers
Par extension n-tiers
3-tiers
Présentation
Traitements métiers
Données
...
Client Web
Client Mobile
Client Desktop
Mail Server
Client Web
Client Mobile
Client Desktop
Par extension n-tiers
Frontal / Gateway / ESB
Mail Server
...
Avantages
- Décomposition/séparation en couche / les liens entre couches sont définis par des interfaces (API REST, SOAP, etc.)
- Modularité et indépendance technologique de chaque niveau : possibilité de changer une couche sans impacts sur les autres, possibilité de répartir les travaux entre plusieurs équipes.
- Performances : technologie optimale adaptée à chaque couche
- Testabilité : les couches sont testables indépendamment
- Ouvre la porte à la "scalability" (capacité à supporter des montée en charge) et la Tolérance aux pannes
Inconvénients
- Complexité
- Technologies parfois hétérogènes
- Déploiement / test / installation nécessitent d'être outillés
-> nécessite du personnel bien formés
(alors va pas falloir dormir...)
Cas d'utilisations
Tout est possible à partir du moment où il y a du réseau...
Vous en connaissez plein...
YouTube, instagram, Amazon,... bref la quasi totalité du web...
Architecture
µ service
(avant goût)
Gateway / Frontal
BDD Order
µ-services (avant goût)
Mail Server
...
Client Web
Client Mobile
Client Desktop
Order µservice
BDD Products
Products µservice
BDD Users
Users µservice
C'est un avant goût, pour le détail il faudra attendre le cours de Benoît...
Zoom sur les couches
Vue globale
Couche présentation
1 - Client natif
Java (JavaFX/OpenJFX, Swing (commence à dater...), Eclipse RCP), .Net (WPF, Windows Forms, UWP), MacOS/XCode (Cocoa, Objective-C/Swift), Android SDK, Unity, QT...
2 écoles
Avantages :
Performances
On peut quasi tout faire
Inconvénients :
Rarement multi-plateforme
Complexité
Coût (temps et parfois argent)
Ecosystème monolithique (difficile d'en sortir)
Le livrable est un exécutable
2 - Client basé sur les technologies du web
Couche présentation
HTML5/CSS/JavaScript
(React.js, Angular, Vue.js, Progressive WebApp)
2 écoles
Avantages :
Basé sur des standards
Libertés des outils
Suffit dans 80% des cas
Si backend node.js on a une fullstack Javascript (moins de techno à maîtriser)...
Inconvénients :
Souvent moins veloce que du natif (mais ca se rapproche (WebAssembly))
Compliqué d'intégrer des composants externes non web.
Interfaçage avec le poste local
Difficultés de validation (multi browser)
Objectifs : le graal (le multi plateforme)
Couche présentation
Solutions émergeantes...
Grosse activité depuis 3/4 ans poussée par des gros acteurs (Microsoft, Google) et le monde open source.
Deux ou trois solutions devraient émerger (lesquelles ?)
(Google)
(.net)
là c'est simple, 1 choix s'impose :
HTTP(s)
Avec parfois en complément
WebSocket : pour les aspects push du serveur vers les clients (mais plutôt en intranet, car ne passe pas tous les firewall).
Pour des architectures plus exotiques (matériel embarqué, absence de pile HTTP), communications
basées sur TCP : RPC, RMI (Java), CORBA, DCOM (Microsoft, on n'en parle plus), socket directe...
Couche réseau
Couche n°5 (session) du modèle OSI
IIS / ASP.Net Core
Couche serveur
Liste non exhaustive et on se limite aux serveurs Web
File system : le niveau 0 du stockage ! Mais peut suffire si les besoins sont simple et en lecture seule
SGBDr (Oracle, MySQL, PostgreSQL, SQL Server, SQLite3, etc.) : transactionnel, ACID.
SGBD no SQL (CouchDB, MongoDB, Cassandra, Redis, ElasticSearch et des dizaines d'autres...) en plein boom...
SGBD objets (le buzz il y a 15 ans)
Couche données
Exemples d'architectures
.net
Source ici
Java / J2EE
Node.js
Et du coup ?
Que choisit-on ?
Objectifs d'une architecture
The architecture of a software system is the shape given to that system by those who build it.
The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in wish those components communicates with each other.
The purpose of that shape is to facilitate the development, deployment, operations, and maintenance of the software system contained within it.
Robert C. Martin "Clean Architecture"
LA solution n'existe pas
Tout est affaire de compromis
C'est le job de l'architecte logiciel
Éléments de réflexion
And so I learned that great architecture sometimes lead to great failures.
Architecture must be flexible enough to adapt to the size of the problem.
Architecting for the enterprise, when all you really need is a cute little desktop tool, is a recipe of failure.
Robert C. Martin "Clean Architecture" (p 374)
Un peu d'humilité
Critères non techniques
Non exhaustifs et pas nécessairement impartiaux
L'existant : quelles technos sont déjà utilisées / maîtrisées
L'équipe : expérience, profil (moteur / suiveur), motivation, aspirations, taille (on ne fait pas la même archi pour une équipe de 5 et une équipe de 20)
humains
Critères non techniques
Non exhaustifs et pas nécessairement impartiaux
Type de projet : Prototype, R&D ou production
Délais : pour dans 2 mois ou pour dans 2 ans...
Budget : en temps et en argent...
projet
Méthode : en V, agile...
Critères non techniques
Non exhaustifs et pas nécessairement impartiaux
Futur : vers où on a envie d'aller, en quelles techno on croit
Expérience: retours sur R&D ou prototypes ou projets passés.
stratégie d'entreprise
Réutilisation : souhait de réutiliser des briques déjà existantes dans l'entreprise
Critères non techniques
Non exhaustifs et pas nécessairement impartiaux
Confidentialité : niveau de sensibilité des données (adapté au cloud ou pas ?)
contraintes de sécurité
Criticité : domaine militaire ou pas, critique dès la phase de développement (réseau confidentiel défense par exemple).
Critères techniques
Non exhaustifs et pas nécessairement impartiaux
Outillage: IDE, facilité à mettre en place l'environnement de développement
Productivité: facilité de développement
développement
Technologie: richesse de l'ecosystème, langage, frameworks, adéquation avec le besoin
Communauté: facilité à trouver de l'aide, de la doc, des exemples, etc.
Critères techniques
Non exhaustifs et pas nécessairement impartiaux
Architecture d'ébergement : Cloud, Docker, serveur intranet, etc.
deploiement
Automatique ou piloté : Direct depuis l'intégration continue ou processus de validation préalable.
Critères techniques
Non exhaustifs et pas nécessairement impartiaux
Performances : nombre de clients simultanés, volumes échangés, performances réseau
Tolérance aux pannes : capacité à supporter des crash
Scalabilité : capacité à supporter les montées en charge
opérationnel
Critères techniques
Non exhaustifs et pas nécessairement impartiaux
Maintenabilité : intégration continue, facilité de réalisation des tests
maintenance
Feedback : log, retours sur l'utilisation et sur les crashs
Quelques éléments sur les performances
| Language | Threads vs. Processes | Non-blocking I/O | Ease of Use |
|---|---|---|---|
| PHP | Processes | No | |
| Java | Threads | Available | Requires Callbacks |
| Node.js | Threads | Yes | Requires Callbacks |
| Go | Threads (Goroutines) | Yes | No Callbacks Needed |
Quelques conseils
Non exhaustifs et pas nécessairement impartiaux non plus
Se documenter : rester toujours curieux sur tous les sujets (livres, site technologiques, blog, salons/conférences, etc.)
Mais lors du choix : rester dans le mainstream : trop de techno disparaissent faute d'avoir trouver un public. Pensez à ceux (peut être vous) qui devront maintenir l'appli dans les années à venir
Rester critique : toujours vérifier une info, testez, faite vous votre propre opinion
Prototyper : avant de se lancer vers l'inconnu, on teste à petite échelle
Savoir se remettre en cause : les choix d'hier ne sont pas nécessairement adaptés à demain
Scénarios
Scénario 1
Le client souhaite faire une appli métier de gestion dans son intranet. Cette appli sous Windows doit pouvoir intégrer des composants graphiques "maison" faits en C++. Le tout sera utilisé par une dizaine de personnes. Ils ont déjà des compétences backend en J2EE. Il stocke actuellement ses données dans une BDD PostgreSQL. Le budget est limité...
On ne fait pas la révolution :
On conserve la BDD
On propose quand même du node.js côté backend au cas où car ce serait moins coûteux
Côté client, les techno web ne vont pas aller (composant C++) ca sent le client lourd en WPF / ou UWP ou QT...
Le client souhaite faire une appli métier de gestion dans son intranet. Cette appli sous Windows doit pouvoir intégrer des composants graphiques "maison" faits en C++. Le tout sera utilisé par une dizaine de personnes. Ils ont déjà des compétences backend en J2EE. Il stocke actuellement ses données dans une BDD PostgreSQL. Le budget est limité...
Scénario 2
Le client souhaite refaire une appli métier de gestion pour ses collaborateurs répartis dans le monde entier car la version actuelle ne tient plus la charge. Cette appli pourra être utilisée par des milliers de personnes. Les données ne sont pas "sensibles". Ils ont déjà des compétences backend IIS. Il stocke actuellement ses données dans une BDD SQL Server sur leur site principal. Le budget est important...
Là on peut faire la révolution (au moins la proposer...)
On ne conserve rien (de toute manière ça ne fonctionne pas bien)
Répartition mondiale -> le cloud peut être un bon candidat (AWS, Azure, etc.).
Par contre le choix est impactant (coût, pérennité...)
Nécessite de faire un premier prototypage.
Le client souhaite refaire une appli métier de gestion pour ses collaborateurs répartis dans le monde entier car la version actuelle ne tient plus la charge. Cette appli pourra être utilisée par des milliers de personnes. Les données ne sont pas "sensibles". Ils ont déjà des compétences backend IIS. Il stocke actuellement ses données dans une BDD SQL Server sur leur site principal. Le budget est important...
Scénario 3
Le client souhaite refaire une appli métier de gestion dans un browser en intranet pour son personnel. Cette appli pourra être utilisée par des centaines de salariés. Ils ont peu de compétence backend mais souhaitent pouvoir reprendre le projet à terminaison. Ils stockent actuellement leurs données dans une BDD Oracle (qui leur coûte un bras) sur leur site principal. Le budget est confortable...
Là on peut se faire plaisir et faire plaisir au client en même temps :
Client : React / Angular ou Vue.js
Serveur node.js Stateless
Etude du remplaçement de la BDD Oracle par une BDD PostgreSQL (si on reste en relationnel) voire suivant les cas une BDD nosql (analyse approfondie à faire)
Le client souhaite refaire une appli métier de gestion dans un browser en intranet pour son personnel. Cette appli pourra être utilisée par des centaines de salariés. Ils ont peu de compétence backend mais souhaitent pouvoir reprendre le projet à terminaison. Ils stockent actuellement leurs données dans une BDD Oracle (qui leur coûte un bras) sur leur site principal. Le budget est confortable...
On choisit sa technologie front-end en fonction de la technologie back-end ?
Word est une application avec une architecture 2 tiers !
Skype est une application avec une architecture n-tier !
Le back-end est la partie visible de l'application ?
Une appli est scalable si elle supporte le crash d'un de ses composant
Une appli tolérante aux panne supporte les montées en charge !
Faire un test de montée en charge sur une appli consiste à simuler un grand nombre de requêtes et de clients !
C'est uniquement l'expertise technique qui drive les choix d'architecture !