Oui j’ai encore besoin d’un service !
Mais cette fois d’un tout petit service ^^
Un Micro-Service.
Tu vas comprendre en lisant cet email.
Dans l’email de lundi, je t’ai parlé d’architectures monolithiques.
Prenons l’exemple d’un site WordPress en PHP.
C’est une architecture monolithique qui ressemble à ça.
Toutes les fonctionnalités sont codées en PHP dans le même projet.
Toutes les fonctionnalités sont dépendantes entre elles.
Le problème de ce type d’architecture.
Le code back-end et front-end sont mélangés.
Soit tout fonctionne, soit rien fonctionne. (tout est hébergé au même endroit).
D’autres problèmes se posent également mais je vais pas t’en parler ici.
Et puis il y a eu les Architectures Orientées Services (SOA).
Pour simplifier le code front est back est découpé.
Il peut y avoir un ou plusieurs back-end découpés par domaine (gestions des utilisateurs, comptabilité, facturation …).
Et un ou plusieurs front-end (site web frontal, un backoffice, une application mobile etc …).
Le tout communiquant via des API
Un autre exemple de schéma :
SOA : Une énorme avancée, mais encore avec des problèmes.
Ce type architecture a résolu de nombreux problèmes par rapport aux architectures monolithiques.
Mais d’autres problèmes subsistent toujours.
Des services par domaine complexes et difficiles à maintenir.
Si tu prends par exemple le service Facturation :
C’est probablement une application codé dans un langage (par exemple Java).
Avec énormément de règles métiers complexes.
Et de nombreuses API exposées (génération de : Devis / Factures / Validation / Mis à jour / Remboursement).
Si un service tombe tout le domaine tombe.
Si l’application contenant le service des utilisateurs tombe (panne électrique, coupure réseau, serveur en panne ou autre).
Tout le domaine des utilisateurs tombe.
Impossible par exemple de créer des nouveaux utilisateurs.
Mais surtout impossible aux utilisateurs existant de se connecter.
Pour limiter tout ces problèmes il y a les architectures Micro service (MSA).
L’idée est de découper encore plus finement les domaines.
Par exemple notre domaine Utilisateurs pourrait être découpé en micro-services comme cela :
Le client à gauche du schéma est le navigateur (ou application mobile).
Il fait appel à des services.
Quatre micro services.
Un micro-service d’authentification.
Un micro-service de création / suppression / mise à jour d’utilisateurs.
Un micro-service de gestion des rôles utilisateurs.
Un micro-service de tracking d’activités d’utilisateurs.
Chaque micro-service est hébergé sur un serveur différent.
Quels sont les avantages d’un découpage en micro-services ?
Contrairement aux applications monolithiques.
Si un serveur tombe ce n’est pas tout le système qui tombe.
Par exemple si le micro-service d’ajout des utilisateurs tombe, il ne sera plus possible d’ajouter des utilisateurs.
Le système pourra afficher un message du type : Nous ne pouvons pas ajouter d’utilisateurs pour le moment, merci de ressayer dans quelques minutes.
MAIS le système d’authentification fonctionnera toujours, les utilisateurs existants pourront continuer d’utiliser le système.
En monolithique, si par exemple ton site WordPress tombe, tout est arrêté ! Et tu as ça :
Il y a également d’autres avantages :
L’agilité : Il est possible de développer des micro-services de manière agile et rapide.
Déploiement facile : Il est facile de faire évoluer, tester et déployer des micro-services rapidement.
Liberté technologique : Il est possible de créer des micro-services indépendants avec des langages différents : Java, en Javascript Python …
Scalabilité : Si il y a un pic de trafic, il est possible de dupliquer et de dimensionner chaque micro-service indépendamment.
C’est la coupe du monde ? Il faut générer beaucoup de billets pour les matchs. On redimensionne (on loue un énorme serveur) le micro-service de génération de billets.
Bref les micro-services sont partout et les offres se multiplient.
De plus en plus de projets, de start-up utilisent ce type d’architecture.
Mais les profils sont rares …
Les boites qui utilisent ce genre d’architectures ne veulent pas de développeurs généralistes.
Elles ne veulent pas de profils types : « Développeur Javascript Html PHP » .
Elles veulent des profils spécialisés comme par exemple : « Développeur Back-End Micro services API REST » .
Les profils back-end maîtrisant les API REST avec les nouvelles technologies : Javascript / Node JS / Express … sont rares.
Tu es intéressé par l’aventure des micro-services ?
Sache que plusieurs dizaines de personnes ont déjà rejoins ma toute dernière formation.
DEVENIR DÉVELOPPEUR BACK-END API REST : Maîtrise les API REST coté back-end en Javascript.
Une formation qui à pour but de te lancer dans le développement de micro services (API REST) en Javascript.
Grâce à cette formation tu vas être capable :
- d’analyser une demande client (exemple concret).
- de la traduire en code fonctionnel.
- de préparer la structure de données (quelles données en entrées / en sorties et quel format).
- d’organiser ton code en couches (fini le code spaghettis).
- de comprendre les architectures N-TIERS.
- de monter une stack applicative Node JS / Express / API REST.
- de créer des micro services.
- d’utiliser tout les outils récents pour utiliser, décoder, debugger, manipuler les API.
- d’implémenter les tests unitaires.
Tu auras également accès au Slack développeur ou tous les membres de la formation échangent.
Tu pourras également me poser tes questions en cas de blocage.
La promo se termine dimanche
Clique pour en profiter à temps
Tu as la choix :
Tu peux continuer à apprendre des choses généralistes : PHP / HTML / JS et accumuler toutes ces technos pour être un généraliste.
Ou tu peux te spécialiser.
Et devenir un développeur back-end spécialiste des API REST et micro-services en Javascript / Node.
A toi de voir.
Tout est là, seulement pour quelques jours : formations.mikecodeur.com/api-back?coupon=SEPT19
À demain,
Mike
