SlideShare a Scribd company logo
1 of 105
Download to read offline
CONSTRUIRE DES
APPLICATIONS CLOUD
NATIVES
ou le passage de Lamp à Nvmpsesrrkc
Ori Pekelman, markeuteux en chef chez platform.sh
Mais on me permet de parler ici parce que je fait de l’Erlang.
@oripekelman sur github/twitter/linked-in
CONSTRUIRE DES
APPLICATIONS CLOUD
NATIVES
Préambule
LE CLOUD EN QUOI ET
POURQUOI
• Une application cloud est une
application potentiellement capable:
• de tourner sur des multiples
infrastructures distantes
• de migrer d’une infrastructure à une
autre
• de haute disponibilité
• de montée en échelle horizontale
• d’absorber des pics irréguliers
• de déploiement continu
App-Server
DB
Serveur Web
LAMP
• Linux
• Apache
• MySql
• PHP
LAMP
• Linux
• Apache
• MySql
• PHP
En tout cas on n’utilise plus que
Linux ça sert à rien de le dire… et
l’abstraction de l’OS a été
remplacé par celle des containers.
Plus la dessous plus tard.
NMP
• Linux
• Nginx Apache
• MySql
• PHP
Pas vu un Apache depuis un bail.
NMP
• Linux
• Nginx Apache
• MariaDB MySql
• PHP
Là au moins ça ne change
pas l’acronyme
NMP
• Linux
• Nginx Apache
• MariaDB MySql
• PHP Bon vieux demeure.
App-Server
DB
Serveur Web
MÊME QUAND ON AURA AJOUTÉ PLEIN
DES CASES, LA RÉALITÉ SOUS-JACENTE
RESTE LA MÊME
App-Server
DB
Serveur Web
Et un bout de colle qui est l’OS + une machine pour le faire tourner
Pleins de bouts de colle + plein de
machines pour le faire
tourner
Serveur(s)
Web
App-
Server(s)
DB(s)
Pleins de bouts de colle + plein de
machines pour le faire
tourner
Serveur(s)
Web
App-
Server(s)
DB(s)
J’AIME IMAGINER LA CHOSE EN CERCLES
CONCENTRIQUES QUI RENDENT LA
PLURALITÉ PLUS FACILE À APPRÉHENDER
Pleins de bouts de colle + plein de
machines pour le faire
tourner
Serveur(s)
Web
App-
Server(s)
DB(s)
NOUS ALLONS PASSER DE L’EXTÉRIEUR
VERS L’INTÉRIEUR ETVOIR LE “QUOI” ET
LE “POURQUOI” DE CHAQUE COUCHE
CHAPÎTRE PREMIER, LE CDN
• Pas uniquement pour les “assets” mais en frontal
des toutes les pages
• Même en mode loggué
CHAPÎTRE PREMIER, LE CDN
LE CDN C’EST JUSTE NOTRE
SERVEUR WEB COUPÉ EN DEUX
App-Server
DB
Serveur Web
LE CDN C’EST JUSTE NOTRE
SERVEUR WEB COUPÉ EN DEUX
App-Server
DB
Serveur Web
CDN
IL PARTICIPE ATOUTES CES
“CAPACITÉS” CLOUD.
App-Server
DB
Serveur Web
CDN
de tourner sur des multiples
infrastructures distantes
de migrer d’une infrastructure à
une autre
de haute disponibilité
de montée en échelle
horizontale
d’absorber des pics irréguliers
de déploiement continu
ILVA NOUS PERMETTRE PLUS
FACILEMENT DE PASSER À ÇA:
CDN
Point d’entrée Point d’entrée Point d’entrée
DB
Serveur Web
App
Serveur WebServeur Web
App App
PUIS À ÇA
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE CACHE CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
ET ÇA
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
OU ÇA
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
ET ENCORE, MAIS ONVA RENTRER
DANS LE DÉTAIL PLUSTARD.
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
Si la performance est orthogonale à la scalabilité …
le CDN, pourtant, est la seule manière d’optimiser le
TTFB.
CHAPÎTRE PREMIER, LE CDN
• TTFB =Time to first byte
• Dépend uniquement de la proximité des “Edges”,
vous savez, à cause de c = 299,792,458 m/s
• Rend Google content. Mais aussi vos utilisateurs.
CHAPÎTRE PREMIER, LE CDN
LE CDN IMPOSE DES
CONTRAINTES
• Le “hit ratio” doit être bon
• GEOIP
• Triturages des x-headers à la mano pour faire
quelque chose de charmant
LE CDN IMPOSE DES
CONTRAINTES
• Le “hit ratio” doit être bon
• GEOIP * En tout cas vous devez comprendre l’effet sur le
“hit ratio”. Les CDN vont vous exposer des headers
intéressants à titre d’exemple HTTP_CF_IPCOUNTRY pour
Cloudflare ou CloudFront-Viewer-Country pour le CDN
éponyme. Fastly va vous donner jusqu’à la ville.
• Triturages des x-headers à la mano pour faire quelque chose
de charmant
LE CDN IMPOSE DES
CONTRAINTES
• Le “hit ratio” doit être bon
• GEOIP
• Triturages des x-headers à la mano pour faire
quelque chose de charmant* Certains CDNs vont
vous permettre de triturer à mort. Evitez.
LE CDN, SON IMPLÉMENTATION NOUS
POUSSE À FAIRE DES CHOSES BIEN
• Charger les contenus dynamiques en asynchrone, et si vôtre CDN
le supporte .. en utilisant ESI (Xavier Leune vous en a déjà dit des
choses hier .. ).
/users/me	
• Contrôle de la sémantique cache au niveau de chaque contrôleur /
chaque action de contrôleur.
• D’ailleurs .. cela fait déjà un gros bout de chemin vers les micro-
services
SYMFONY NOUS REND LAVIE
SIMPLE ET BELLE
/**	
	*	@Cache(expires="tomorrow")	
	*/	
class	UserController	extends	Controller	
{	
				/**	
					*	@Cache(lastModified="user.getUpdatedAt()",	ETag="'User'	~	user.getId()	~	
user.getUpdatedAt().getTimestamp()")						
					*/	
				public	function	meAction(User	$user)	
				{	
				}	
}
LE PAR-DÉFAUT EST
RAISONNABLE
Par défaut Cache-Control est no-cache
ESI PERMET LA MISE EN PARTIELLE DE LA PAGE
ESI PERMET LA MISE EN PARTIELLE DE LA PAGE
Toute la
page peut être
en cache
ESI PERMET LA MISE EN PARTIELLE DE LA PAGE
Toute la
page peut être
en cache
Mais des parties
peuvent rester
dynamiques
ESI PERMET LA MISE EN PARTIELLE DE LA PAGE
Toute la
page peut être
en cache
Mais des parties
peuvent rester
dynamiques
Avec desTTLS
différents…
ESI PERMET LA MISE EN PARTIELLE DE LA PAGE
Toute la
page peut être
en cache
Mais des parties
peuvent rester
dynamiques
Avec desTTLS
différents…
Avec même du
ciblage
framework:	
				esi:	true	
				fragments:					{	path:	/_proxy	}	
SYMFONY A DU SUPPORT ESI
INTÉGRÉ
Ouvrez donc app/config/config.yml et dans la partie framework :
{{	render_esi(uri,	options	=	[])	}}	
QUI SAIT FAIRE DU FALLBACK
EN DEV….
• Dans votre template twig il y a un helper pour ça.
{{	render_hinclude(controller('...'),		{	
				'default':	'default/content.html.twig'	
})	}}
VOUS POUVEZ OPTER POUR DU JS ASYNC.
ICI AUSSI SYMFONYVAVOUS AIDER.
Voir http://mnot.github.io/hinclude/
• Dans votre template twig il y a un helper pour ça aussi:
{{	render_hinclude(controller('...'),		{	
				'default':	'default/content.html.twig'	
})	}}
PROBABLEMENT ILVAUT MIEUX FAIRE LE
JS AVEC UN FRAMEWORK COMME IL
FAUT (REACT? ANGULAR?)
• Et servir du JSON de vos magnifiques micro-services avec silex.
• Le choix du CDN est compliqué. Nous avons utilisé CloudFront, CloudFlare et
Fastly
• CloudFront n’est pas cher. Mais regardez bien la latence d’invalidation.
• CloudFlare peut être incroyable pour lutter contre des DDOS et il a des
headers GEO détaillés.
• Fastly peut être cher (surtout en HTTPS) mais il donne du support ESI et
customVCL (même si c’est mal).
• Akamai ont inventé ESI; mais ils sont super chers et j’aime pas traiter avec
eux.
CHAPÎTRE PREMIER, LE CDN
ETVARNISH?
• Le reverse veut être proche du client.
• Implémenter du code applicatif au niveau du
reverse c’est mal.Très mal. C’est intestable et
bricolé.A chaque couche son rôle.
• Fastly supporte desVCLs customs. Mais évitez SVP
(pas fastly, juste lesVCLs customs).
ETVARNISH?
• Par contre c’est pas du tout débile d’avoir un autre
reverse devant votre serveur web.
• Considérez simplement nginx (pas de support ESI
mais SSI est équivalent).Varnish c’est OK mais
souvent superflu.
Pleins de bouts de colle + plein de
machines pour le faire
tourner
Serveur(s)
Web
App-
Server(s)
DB(s)
• On va encore casser notre serveur web en plus petites
parties.
• Cela peut simplement être un load balancer comme ELB sur
AWS. Mais attention au support SNI. Chez nous on utilise ELB
devant notre propre entre-point qui fait aussi le routage SSH.
• Ca peut aussi être un HAProxy ou l’un des dizaines projets en
GoLang qui apparaissent comme des champignons après la
pluie.
CHAPÎTRE DEUXIÈME,TRÈS
COURT, SUR L’ENTRY POINT
• Il peut être assez intelligent et participer au routage
vers vos micro-services.
• Il participe à votre haute-disponibilité. Il isole du
point de vue réseau vos systèmes internes.
CHAPÎTRE DEUXIÈME,TRÈS
COURT, SUR L’ENTRY POINT
ON N’A FAIT QUE ÇA:
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
COMME QUOI, 40 MINUTES POUR
RENDREVOS APPLICATIONS NATIVES
AU CLOUD C’EST STRESS.
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
J’ESPÈRE QUEVOUS AVEZ SUIVI LETALK DE FABIEN MEURILLON
SUR LES MICRO-SERVICES.VOUS AVEZ DÉJÀ COMPRIS LA
RELATION ENTRE CETTE BANDE ET LA COUCHE LA PLUS EN
AMONT (CDN) DONC JUSTE QUELQUE REMARQUES.
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
• Comme on a cassé notre serveur web en plusieurs
parties chacune remplissant un petit rôle sur le chemin
de la requête on comprends l’intérêt de casser notre
serveur d’application aussi;
• On peut ainsi faire monter en échelle chaque partie de
manière autonome ce qui, bizarrement, va nous réduire
la facture d’hébergement. On met pasTOUT à l’échelle
du composant le plus lourd.
CHAPÎTRETROISIÈME, LES
MICRO-SERVICES
Si vôtre graph de services
n’est pas trop profond ça
peut encore aller.
MAIS ATTENTION À LA
LATENCE À LA QUEUE LEU-LEU
• Si vous commencez à faire
des boucles, même avec
du keep-alive ça risque de
non seulement être lent…
mais aussi de consommer
un max de mémoire.
• Deux stratégies pour
mitiger ceci:
MAIS ATTENTION À LA
LATENCE À LA QUEUE LEU-LEU
For	each	image	in	
article	do	an	http	
request
• Designer vos APIs pour que toujours on puisse faire
des appels “bulk”. On ne vend plus au détail.
• Communiquer en profondeur uniquement à travers
une Queue de Messages
• Exposer chaque service avec deux APIs (HTTP
synchrone et MQ Async) est une bonne pratique.
• On commence par HTTP pour aller vite. Puis on
factorise en async.
LA LATENCE À LA QUEUE
LEU-LEU
DONC EN GROS AU LIEU DE
FAIRE
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
VOUS FAÎTES
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
VOUS FAÎTES
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
DOCTEUR, LE MESSAGE QUEUE
C’EST PAS COMPLIQUÉ ?
use	SwarrotProcessorProcessorInterface;	
use	SwarrotBrokerMessage;	
class	Processor	implements	ProcessorInterface	{	
				public	function	process(Message	$message,	array	$options)	{	
								echo	sprintf("Consume	message	#%dn",	$message->getId());	
				}	
}
Chaque queue de message donne des garanties différentes.
Mais de nos jours, Rabbit ou Kafka, ça va vous suffire.
ET POUR LES ÉCRITURES …
CECIVOUS DONNE DU
“BACKPRESSURE
MANAGEMENT”
UN PIC DETRAFIC NEVAS
PLUS RÉSULTER DANSVOS
SYSTÈMES QUI PLANTENT.
MAIS SIMPLEMENT DANS UNE
LATENCE PLUS IMPORTANTE
POUR LA MISE À JOUR DES
DONNÉES.
C’est déjà du CQRS.
Avez vous entendu parler
de CQRS ?
ET ON PEUTTRICHER
ENCORE MIEUX
For	each	image	in	
article	do	an	http	
request
• Désolé, ça, je ne traduis
pas en Français.
CHAPÎTRE QUATRIÈME, COMMAND
AND QUERY RESPONSIBILITY
SEGREGATION
For	each	image	in	
article	do	an	http	
request
• Au lieu d’intermédier
les lectures par vôtre
Queue de Messages
CHAPÎTRE QUATRIÈME, COMMAND
AND QUERY RESPONSIBILITY
SEGREGATION
For	each	image	in	
article	do	an	http	
request
VOUS FAÎTESTOUTESVOS LECTURES
SUR LE MOTEUR DE RECHERCHE
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
VOUS FAÎTESTOUTESVOS LECTURES
SUR LE MOTEUR DE RECHERCHE
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
ECRITURE
VOUS FAÎTESTOUTESVOS LECTURES
SUR LE MOTEUR DE RECHERCHE
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
ECRITURE
VOUS FAÎTESTOUTESVOS LECTURES
SUR LE MOTEUR DE RECHERCHE
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
LECTURE
SIVOUS AVEZ SUIVI HIER LA
PREZ DE LA FOURCHETTE SUR
“L’API FIRST”.. ET CELLE DE
BLABLA SUR ELASTICSEARCH..
VOUSVERREZ. CE N’EST PAS
DE LATHÉORIE.
• Vous faîtes toutes vos lectures “bulk”, les listes, par
le moteur de recherche (et si vous avez suivi la
prez blablacar … vous avez vu. Un ElasticSearch est
très riche).
• Parfois même les lectures unitaires c’est pas mal
par le moteur de recherche (donc un seul lieu dans
lequel vous aller dénormaliser).
QUAND JE DISTOUTES LES
LECTURES JE SIMPLIFIE UN PEU
• Par contre sur un formulaire, tout ce qui est
transactionnel, vous lisez de votre DB principale qui
demeure “la source de vérité”
• L’écriture correspondante va partir souvent sur le
MQ sauf cas super rare ou quelqu’un vous a
convaincu que l’écriture synchrone est un feature.
LAVÉRITÉ A UNE SEULE
SOURCE
ET QUEL MOTEUR DE
RECHERCHE?
ElasticSearch
ET QUEL MOTEUR DE
RECHERCHE?
OK, d’accord SOLR c’est très bien aussi, en tout cas
c’est du Lucene.
ET QUEL MOTEUR DE
RECHERCHE?
OK, d’accord, Xavier, Sphinx existe.
ET QUEL MOTEUR DE
RECHERCHE?
ElasticSearch
ET QUEL MOTEUR DE
RECHERCHE?
• C’est la meilleure traduction que j’ai pu trouver
pour “Staggered Release”. Qui est le contraire du
“Synchronous Release”.
• Si vous pensez faire du micro-service, mais vous
devez mettre en prod tous les services de manière
synchrone, vous ne faites pas de micro-services.
CHAPITRE CINQUIÈME, MISE
EN PROD ÉCHELONNÉE
Car parfois vous voulez pourvoir partager
des modèles entre vos micro-services
DE MANIÈRE PARFAITEMENT
DÉSAGRÉABLE, CECI EST NON-TRIVIAL
• C’est qu’on appelle des “Lazy Migrations” de
migrations à la volée.
• C’est difficile à faire au niveau d’un ORM comme
Doctrine.
CHAPÎTRE CINQ ET DEMI, LA
MIGRATION PROGRESSIVE
• Il y a pourtant un pattern : le membre static, un integer
qui représente en Semver la version du model.A
l’hydratation on regarde la version et on fait jouer la
migration.
• Mais beaucoup plus facile à faire si vous faîtesTOUTES
vos lectures sur le moteur de recherche…. la co-
existence des modèles est assuré par l’indexation.
CHAPÎTRE CINQ ET DEMI, LA
MIGRATION PROGRESSIVE
MAIS, ORI, ON DEVAIT PARLER
DES APPLICATIONS NATIVES
AU CLOUD, N’ESTU PAS EN
TRAIN DETE PERDRE DANS
TES PENSÉES?
• Il y a une cohérence à tout ça. Je pense.
• Ces intermédiations, tout-à-coup, nous résolvent cette question de la vie
de l’application à échelle, et dans la durée
• Mais aussi, tout-à-coup, chacun des éléments de l’infra vient de devenir
horizontalement scalable.
• Ajouter un noeud rabbitmq, puis augmentez le nombre des workers (et
vous venez d’avoir du backpressure management gratos) ajouter quelques
noeuds au cluster elasticsearch .. ou quelques serveurs d’application et
voilà le pic de trafic 10X n’est pas grave du tout.
MERCI POUR LA QUESTION,
MAIS NON.
CE QUI NOUS PERMET AUSSI DE,TOUTE-
DE-SUITE, PASSER AU CHAPITRE SUIVANT
TOUCHANT AUX BASES DE DONNÉES
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
CHAPÎTRE SIXIÈME, OÙ L’ON DÉCOUVRE
QU’ON A UNE FLOPÉE DES SYSTÈMES
DE PERSISTANCE
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
UN RAPIDE SIXIÈME CHAPÎTRE.
LE BÂT BLESSE AU NIVEAU DE LA BD
RELATIONNELLE.
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
NOUS ON FAIT DU ACTIVE MASTER / PASSIVE MASTER EN
REPLICATION SYNCHRONE (GALERA). MAIS ILY A DES
LIMITES À ÇA. SURTOUT SIVOUSVOULEZTRAVAILLER EN
MODE HAUTE-DISPO SUR DES MULTIPLES DATACENTERS.
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
CHAPÎTRE PÉNULTIÈME
Le Cache.
COMMEVOUS AVEZVU PLUSTÔT AVEC NICOLAS GREKAS
SYMFONYVAVOUS ABSTRAIRE BEAUCOUP DES QUESTIONS SUR
CERTAINES DES COUCHES PAR DES SERVICES, DU COUP CELA
DEVIENT UNE QUESTION SIMPLEMENT DES SERVICES FOURNIS PAR
VOTRE INFRA.
CDN
Point d’entrée Point d’entrée Point d’entrée
DB DB
Serveur Web
App1 App2 App3
DB
Serveur Web
CACHE
Serveur Web
App1 App2 App3 App1 App2 App3
Moteur de recherche
Queue de Message
Système de Fichier distribué
RAPPELONS NOUS. CA
N’EXISTE PAS DES
APPLICATIONS STATELESS.
LA QUESTION ESTTOUJOURS :
OÙ EST L’ÉTAT.
ILTRAÎNE SOUVENT DANS LA
DB … ET DANSVOS CACHES.
IMPLÉMENTER DONC LES
BONNES PRATIQUES DE
CACHE (PSR-6) AVEC LES
SERVICES SYMFONYVOUS
LIBÈRE PAS MAL DE DEVOIRY
PENSER.
• On a parlé des la structuration des éléments d’infra et un peu de
l’adhésion code (pas grand chose n’est-ce pas).
• Tout ceci nous prépare pour pouvoir passer pour chaque une de
nos couches de N à N+1
• Mais cela dépend alors de notre capacité à créer à l’identique, et
rapidement des nouveaux noeuds.
• Vous avez deux choix là: le blob que l’on copie (mal) où le build
systématique avec des garanties d’idempotence (bien!).
CHAPÎTRE DERNIER, LE
DÉPLOIEMENT
• Ca implique des contraints mais qui vont vous rendre des fiers
services:
• Le processus de build ne doit pas être dépendant de
l’environnement. Il ne doit pas nécessiter la connexion aux services.
Il ne doit pas connaître l’identité du serveur sur lequel on va
déployer (toute la conf devra arriver de l’environnement).
• La prod est en lecture seule (pour éviter l’émiettement, le
“infrastructure drift). Uniquement les données sont en Lecture/
Ecriture
BUILD HORS INFRA, RUN EN
LECTURE SEULE.
CONCLUSION
UNE APPLICATION CLOUD
NATIVE PEUT ÊTRE DÉPLOYÉE
SUR UN PETIT DÉDIÉ.
de tourner sur des multiples infrastructures distantes
de migrer d’une infrastructure à une autre
de haute disponibilité
de montée en échelle horizontale
d’absorber des pics irréguliers
de déploiement continu
UNE APPLICATION CLOUD EST UNE
APPLICATION POTENTIELLEMENT CAPABLE:
RIEN NEVOUS FORCE DE
PASSER DE
LAMP
• Linux
• Apache
• MySql
• PHP
À
NVMPESRRKCCDX
• Nginx
• Varnish
• MariaDB/Postgres
• PHP-FPM
• Symphony
• NodeJS
• ElasticSearch/Solr
• Redis / RabbitMQ/
Kafka
• Ceph / Gluster
• Docker / LXC
TOUTE DE SUITE.
LE COÛT DE FAIRE LES CHOSES BIEN
DÈS LE DÉPART EST RELATIVEMENT
FAIBLE.
ON N’A PAS OUBLIÉ “OPTIMIZE LAST”
TOUT CECI N’EST PAS LÀ POUR
RENDREVOTRE APPLICATION PLUS
RAPIDE. MAIS PLUS FACILE À MAINTENIR
ET À FAIRE MONTER EN ECHELLE.
JEVAIS QUAND MÊME ME
FAIRE DE LA PUB EN 500MS
CDN (CloudFront, Cloudflare, Fastly)
DNS (Route 53, Dyn, DNSMadeEasy)
ELASTIC LOAD BALANCER SCALE OUT
APP 1 APP 2 APP 3
NGINX / FPM NGINX / FPM NGINX / FPM
REDIS REDIS* REDIS*
DB LOAD BALANCING
GALERA DATABASE CLUSTER
SOLR CLOUD
SSD BASED NETWORK FILE SYSTEM
APP 4
NGINX / FPM
APP 5
NGINX / FPM
S3 BACKUP
1
2
3
5
6
DB LOAD BALANCING4
7
8
1.DNS Alias maps zone apex to CDN distribution.
2.CDN caches popular resources at edge locations.
HTTPS terminates here.
3.ELB performs health check on instances
4.Load Balancer distributes traffic
5.Nginx performs proxy caching, compression and
passes requests to the app running PHP-FPM
6.LB of DB queries pushes writes to the Master,
compensating for optimistic loading. 3
synchronous masters with health check
7.Three discreet Availability Zones datacenters.
8.Platform can scale out the web tier to as many
instances as might be required.
CHEZ MOI, PAR DÉFAUT,VOTRE PROD
RESSEMBLE À ÇA.
CLOUD NATIVE SANS LES SOUCIS.
ET VOUS N’AVEZ RIEN À FAIRE. C’EST UN
PAUVRE PETIT FICHIER YAML PUIS DE
L’AUTOMAGIE.
VENEZ ME PARLER.
QUESTIONS ?
Ori Pekelman, markeuteux en chef chez platform.sh
Mais on me permet de parler ici parce que je fait de l’Haskell.
@oripekelman sur github/twitter/linked-in

More Related Content

What's hot

Le développement web : tour d'horizon
Le développement web : tour d'horizonLe développement web : tour d'horizon
Le développement web : tour d'horizonMicrosoft
 
"What we've learnt from Ember.js developing our new product" by Guillaume Pot...
"What we've learnt from Ember.js developing our new product" by Guillaume Pot..."What we've learnt from Ember.js developing our new product" by Guillaume Pot...
"What we've learnt from Ember.js developing our new product" by Guillaume Pot...TheFamily
 
What we've learnt from Ember.js - The family talk april 2015
What we've learnt from Ember.js - The family talk april 2015What we've learnt from Ember.js - The family talk april 2015
What we've learnt from Ember.js - The family talk april 2015Wisembly
 
03 - [ASP.NET Core] Services RESTful et SPA
03 - [ASP.NET Core] Services RESTful et SPA 03 - [ASP.NET Core] Services RESTful et SPA
03 - [ASP.NET Core] Services RESTful et SPA Cellenza
 
Utiliser le Zend Framework avec Symfony
Utiliser le Zend Framework avec SymfonyUtiliser le Zend Framework avec Symfony
Utiliser le Zend Framework avec SymfonyXavier Gorse
 
04 - [ASP.NET Core] Entity Framework Core
04 - [ASP.NET Core] Entity Framework Core 04 - [ASP.NET Core] Entity Framework Core
04 - [ASP.NET Core] Entity Framework Core Cellenza
 
Intro grpc.net
Intro  grpc.netIntro  grpc.net
Intro grpc.netMSDEVMTL
 
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, LinuxYasmine Amrani
 
Event sourcing avec Kafka, UPEC
Event sourcing avec Kafka, UPECEvent sourcing avec Kafka, UPEC
Event sourcing avec Kafka, UPECSylia Baraka
 
01 - [ASP.NET Core] Plénière
01 - [ASP.NET Core] Plénière 01 - [ASP.NET Core] Plénière
01 - [ASP.NET Core] Plénière Cellenza
 
Synchroniser ses applications plus rapidement avec du low-code
Synchroniser ses applications plus rapidement avec du low-codeSynchroniser ses applications plus rapidement avec du low-code
Synchroniser ses applications plus rapidement avec du low-codegplanchat
 
Introduction à WordPress sous Nginx
Introduction à WordPress sous NginxIntroduction à WordPress sous Nginx
Introduction à WordPress sous NginxMaxime Jobin
 
02 - [ASP.NET Core] ASP.NET Core MVC
02 - [ASP.NET Core] ASP.NET Core MVC 02 - [ASP.NET Core] ASP.NET Core MVC
02 - [ASP.NET Core] ASP.NET Core MVC Cellenza
 
Synchroniser ses applications (plus) simplement
Synchroniser ses applications (plus) simplementSynchroniser ses applications (plus) simplement
Synchroniser ses applications (plus) simplementgplanchat
 
.NET Core - Mug In Clermont
.NET Core - Mug In Clermont.NET Core - Mug In Clermont
.NET Core - Mug In ClermontThomas BAILLY
 
Meteor: you're going to love full-stack JavaScript. At last.
Meteor: you're going to love full-stack JavaScript. At last.Meteor: you're going to love full-stack JavaScript. At last.
Meteor: you're going to love full-stack JavaScript. At last.Arnaud Weil
 
XebiConFr - 15 - Apache Mesos, ou comment exploiter les ressources de votre d...
XebiConFr - 15 - Apache Mesos, ou comment exploiter les ressources de votre d...XebiConFr - 15 - Apache Mesos, ou comment exploiter les ressources de votre d...
XebiConFr - 15 - Apache Mesos, ou comment exploiter les ressources de votre d...Publicis Sapient Engineering
 

What's hot (20)

Le développement web : tour d'horizon
Le développement web : tour d'horizonLe développement web : tour d'horizon
Le développement web : tour d'horizon
 
Dev dev devs
Dev dev devsDev dev devs
Dev dev devs
 
"What we've learnt from Ember.js developing our new product" by Guillaume Pot...
"What we've learnt from Ember.js developing our new product" by Guillaume Pot..."What we've learnt from Ember.js developing our new product" by Guillaume Pot...
"What we've learnt from Ember.js developing our new product" by Guillaume Pot...
 
What we've learnt from Ember.js - The family talk april 2015
What we've learnt from Ember.js - The family talk april 2015What we've learnt from Ember.js - The family talk april 2015
What we've learnt from Ember.js - The family talk april 2015
 
03 - [ASP.NET Core] Services RESTful et SPA
03 - [ASP.NET Core] Services RESTful et SPA 03 - [ASP.NET Core] Services RESTful et SPA
03 - [ASP.NET Core] Services RESTful et SPA
 
Utiliser le Zend Framework avec Symfony
Utiliser le Zend Framework avec SymfonyUtiliser le Zend Framework avec Symfony
Utiliser le Zend Framework avec Symfony
 
04 - [ASP.NET Core] Entity Framework Core
04 - [ASP.NET Core] Entity Framework Core 04 - [ASP.NET Core] Entity Framework Core
04 - [ASP.NET Core] Entity Framework Core
 
Intro grpc.net
Intro  grpc.netIntro  grpc.net
Intro grpc.net
 
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
 
Event sourcing avec Kafka, UPEC
Event sourcing avec Kafka, UPECEvent sourcing avec Kafka, UPEC
Event sourcing avec Kafka, UPEC
 
01 - [ASP.NET Core] Plénière
01 - [ASP.NET Core] Plénière 01 - [ASP.NET Core] Plénière
01 - [ASP.NET Core] Plénière
 
Synchroniser ses applications plus rapidement avec du low-code
Synchroniser ses applications plus rapidement avec du low-codeSynchroniser ses applications plus rapidement avec du low-code
Synchroniser ses applications plus rapidement avec du low-code
 
Introduction à WordPress sous Nginx
Introduction à WordPress sous NginxIntroduction à WordPress sous Nginx
Introduction à WordPress sous Nginx
 
Service Workers
Service WorkersService Workers
Service Workers
 
02 - [ASP.NET Core] ASP.NET Core MVC
02 - [ASP.NET Core] ASP.NET Core MVC 02 - [ASP.NET Core] ASP.NET Core MVC
02 - [ASP.NET Core] ASP.NET Core MVC
 
Synchroniser ses applications (plus) simplement
Synchroniser ses applications (plus) simplementSynchroniser ses applications (plus) simplement
Synchroniser ses applications (plus) simplement
 
.NET Core - Mug In Clermont
.NET Core - Mug In Clermont.NET Core - Mug In Clermont
.NET Core - Mug In Clermont
 
Meetup laravel
Meetup laravelMeetup laravel
Meetup laravel
 
Meteor: you're going to love full-stack JavaScript. At last.
Meteor: you're going to love full-stack JavaScript. At last.Meteor: you're going to love full-stack JavaScript. At last.
Meteor: you're going to love full-stack JavaScript. At last.
 
XebiConFr - 15 - Apache Mesos, ou comment exploiter les ressources de votre d...
XebiConFr - 15 - Apache Mesos, ou comment exploiter les ressources de votre d...XebiConFr - 15 - Apache Mesos, ou comment exploiter les ressources de votre d...
XebiConFr - 15 - Apache Mesos, ou comment exploiter les ressources de votre d...
 

Similar to Construire Des Applications Cloud Natives - SymfonyLive Paris 2016

Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...Christophe Furmaniak
 
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAmazon Web Services
 
Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03
Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03
Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03Nicolas Fonrose
 
Docker, Pierre angulaire du continuous delivery ?
Docker, Pierre angulaire du continuous delivery ?Docker, Pierre angulaire du continuous delivery ?
Docker, Pierre angulaire du continuous delivery ?Adrien Blind
 
La Duck Conf 2018 : "Une infrastructure peut en cacher une autre !"
La Duck Conf 2018 : "Une infrastructure peut en cacher une autre !"La Duck Conf 2018 : "Une infrastructure peut en cacher une autre !"
La Duck Conf 2018 : "Une infrastructure peut en cacher une autre !"OCTO Technology
 
Gab17 lyon-Docker pour quoi faire - Cédric Leblond et Derue
Gab17 lyon-Docker pour quoi faire - Cédric Leblond et DerueGab17 lyon-Docker pour quoi faire - Cédric Leblond et Derue
Gab17 lyon-Docker pour quoi faire - Cédric Leblond et DerueAZUG FR
 
Track 1 - Atelier 2 - Distribution complète d’un site avec le cdn Amazon Clo...
Track 1 - Atelier 2 - Distribution complète d’un site avec le cdn Amazon Clo...Track 1 - Atelier 2 - Distribution complète d’un site avec le cdn Amazon Clo...
Track 1 - Atelier 2 - Distribution complète d’un site avec le cdn Amazon Clo...Amazon Web Services
 
Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !VISEO
 
Presentation sparklane aws
Presentation sparklane awsPresentation sparklane aws
Presentation sparklane awsSparklane
 
AWS Paris Summit 2014 - T2 - Déployer des environnements entreprises hybrides
AWS Paris Summit 2014 - T2 - Déployer des environnements entreprises hybridesAWS Paris Summit 2014 - T2 - Déployer des environnements entreprises hybrides
AWS Paris Summit 2014 - T2 - Déployer des environnements entreprises hybridesAmazon Web Services
 
6 stratégies pour migrer vos données dans AWS
6 stratégies pour migrer vos données dans AWS6 stratégies pour migrer vos données dans AWS
6 stratégies pour migrer vos données dans AWSJulien SIMON
 
Sébastien Coutu: Copy this Meetup Devops - microservices - infrastructure imm...
Sébastien Coutu: Copy this Meetup Devops - microservices - infrastructure imm...Sébastien Coutu: Copy this Meetup Devops - microservices - infrastructure imm...
Sébastien Coutu: Copy this Meetup Devops - microservices - infrastructure imm...MSDEVMTL
 
Orchestrating Docker in production - TIAD Camp Docker
Orchestrating Docker in production - TIAD Camp DockerOrchestrating Docker in production - TIAD Camp Docker
Orchestrating Docker in production - TIAD Camp DockerThe Incredible Automation Day
 
What is Clever Cloud? [French version]
What is Clever Cloud? [French version]What is Clever Cloud? [French version]
What is Clever Cloud? [French version]Quentin Adam
 
PHP dans le cloud
PHP dans le cloudPHP dans le cloud
PHP dans le cloudMicrosoft
 
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...Amazon Web Services
 
Au coeur du framework .net 4.5.1
Au coeur du framework .net 4.5.1Au coeur du framework .net 4.5.1
Au coeur du framework .net 4.5.1Cellenza
 
20151119 Tirer le meilleur parti du Cloud pour ses développements
20151119 Tirer le meilleur parti du Cloud pour ses développements20151119 Tirer le meilleur parti du Cloud pour ses développements
20151119 Tirer le meilleur parti du Cloud pour ses développementsObjectif Libre
 

Similar to Construire Des Applications Cloud Natives - SymfonyLive Paris 2016 (20)

Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
 
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
 
Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03
Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03
Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03
 
Docker, Pierre angulaire du continuous delivery ?
Docker, Pierre angulaire du continuous delivery ?Docker, Pierre angulaire du continuous delivery ?
Docker, Pierre angulaire du continuous delivery ?
 
La Duck Conf 2018 : "Une infrastructure peut en cacher une autre !"
La Duck Conf 2018 : "Une infrastructure peut en cacher une autre !"La Duck Conf 2018 : "Une infrastructure peut en cacher une autre !"
La Duck Conf 2018 : "Une infrastructure peut en cacher une autre !"
 
Gab17 lyon-Docker pour quoi faire - Cédric Leblond et Derue
Gab17 lyon-Docker pour quoi faire - Cédric Leblond et DerueGab17 lyon-Docker pour quoi faire - Cédric Leblond et Derue
Gab17 lyon-Docker pour quoi faire - Cédric Leblond et Derue
 
Track 1 - Atelier 2 - Distribution complète d’un site avec le cdn Amazon Clo...
Track 1 - Atelier 2 - Distribution complète d’un site avec le cdn Amazon Clo...Track 1 - Atelier 2 - Distribution complète d’un site avec le cdn Amazon Clo...
Track 1 - Atelier 2 - Distribution complète d’un site avec le cdn Amazon Clo...
 
Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !
 
Presentation sparklane aws
Presentation sparklane awsPresentation sparklane aws
Presentation sparklane aws
 
AWS Paris Summit 2014 - T2 - Déployer des environnements entreprises hybrides
AWS Paris Summit 2014 - T2 - Déployer des environnements entreprises hybridesAWS Paris Summit 2014 - T2 - Déployer des environnements entreprises hybrides
AWS Paris Summit 2014 - T2 - Déployer des environnements entreprises hybrides
 
6 stratégies pour migrer vos données dans AWS
6 stratégies pour migrer vos données dans AWS6 stratégies pour migrer vos données dans AWS
6 stratégies pour migrer vos données dans AWS
 
Sébastien Coutu: Copy this Meetup Devops - microservices - infrastructure imm...
Sébastien Coutu: Copy this Meetup Devops - microservices - infrastructure imm...Sébastien Coutu: Copy this Meetup Devops - microservices - infrastructure imm...
Sébastien Coutu: Copy this Meetup Devops - microservices - infrastructure imm...
 
Orchestrating Docker in production - TIAD Camp Docker
Orchestrating Docker in production - TIAD Camp DockerOrchestrating Docker in production - TIAD Camp Docker
Orchestrating Docker in production - TIAD Camp Docker
 
Livre blanc docker
Livre blanc docker Livre blanc docker
Livre blanc docker
 
What is Clever Cloud? [French version]
What is Clever Cloud? [French version]What is Clever Cloud? [French version]
What is Clever Cloud? [French version]
 
Php dans le cloud
Php dans le cloudPhp dans le cloud
Php dans le cloud
 
PHP dans le cloud
PHP dans le cloudPHP dans le cloud
PHP dans le cloud
 
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
 
Au coeur du framework .net 4.5.1
Au coeur du framework .net 4.5.1Au coeur du framework .net 4.5.1
Au coeur du framework .net 4.5.1
 
20151119 Tirer le meilleur parti du Cloud pour ses développements
20151119 Tirer le meilleur parti du Cloud pour ses développements20151119 Tirer le meilleur parti du Cloud pour ses développements
20151119 Tirer le meilleur parti du Cloud pour ses développements
 

Construire Des Applications Cloud Natives - SymfonyLive Paris 2016

  • 1. CONSTRUIRE DES APPLICATIONS CLOUD NATIVES ou le passage de Lamp à Nvmpsesrrkc Ori Pekelman, markeuteux en chef chez platform.sh Mais on me permet de parler ici parce que je fait de l’Erlang. @oripekelman sur github/twitter/linked-in
  • 3. LE CLOUD EN QUOI ET POURQUOI • Une application cloud est une application potentiellement capable: • de tourner sur des multiples infrastructures distantes • de migrer d’une infrastructure à une autre • de haute disponibilité • de montée en échelle horizontale • d’absorber des pics irréguliers • de déploiement continu
  • 6. LAMP • Linux • Apache • MySql • PHP En tout cas on n’utilise plus que Linux ça sert à rien de le dire… et l’abstraction de l’OS a été remplacé par celle des containers. Plus la dessous plus tard.
  • 7. NMP • Linux • Nginx Apache • MySql • PHP Pas vu un Apache depuis un bail.
  • 8. NMP • Linux • Nginx Apache • MariaDB MySql • PHP Là au moins ça ne change pas l’acronyme
  • 9. NMP • Linux • Nginx Apache • MariaDB MySql • PHP Bon vieux demeure.
  • 11. MÊME QUAND ON AURA AJOUTÉ PLEIN DES CASES, LA RÉALITÉ SOUS-JACENTE RESTE LA MÊME App-Server DB Serveur Web Et un bout de colle qui est l’OS + une machine pour le faire tourner
  • 12. Pleins de bouts de colle + plein de machines pour le faire tourner Serveur(s) Web App- Server(s) DB(s)
  • 13. Pleins de bouts de colle + plein de machines pour le faire tourner Serveur(s) Web App- Server(s) DB(s) J’AIME IMAGINER LA CHOSE EN CERCLES CONCENTRIQUES QUI RENDENT LA PLURALITÉ PLUS FACILE À APPRÉHENDER
  • 14. Pleins de bouts de colle + plein de machines pour le faire tourner Serveur(s) Web App- Server(s) DB(s) NOUS ALLONS PASSER DE L’EXTÉRIEUR VERS L’INTÉRIEUR ETVOIR LE “QUOI” ET LE “POURQUOI” DE CHAQUE COUCHE
  • 16. • Pas uniquement pour les “assets” mais en frontal des toutes les pages • Même en mode loggué CHAPÎTRE PREMIER, LE CDN
  • 17. LE CDN C’EST JUSTE NOTRE SERVEUR WEB COUPÉ EN DEUX App-Server DB Serveur Web
  • 18. LE CDN C’EST JUSTE NOTRE SERVEUR WEB COUPÉ EN DEUX App-Server DB Serveur Web CDN
  • 19. IL PARTICIPE ATOUTES CES “CAPACITÉS” CLOUD. App-Server DB Serveur Web CDN de tourner sur des multiples infrastructures distantes de migrer d’une infrastructure à une autre de haute disponibilité de montée en échelle horizontale d’absorber des pics irréguliers de déploiement continu
  • 20. ILVA NOUS PERMETTRE PLUS FACILEMENT DE PASSER À ÇA: CDN Point d’entrée Point d’entrée Point d’entrée DB Serveur Web App Serveur WebServeur Web App App
  • 21. PUIS À ÇA CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE CACHE CACHE Serveur Web App1 App2 App3 App1 App2 App3
  • 22. ET ÇA CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche
  • 23. OU ÇA CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message
  • 24. ET ENCORE, MAIS ONVA RENTRER DANS LE DÉTAIL PLUSTARD. CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 25. Si la performance est orthogonale à la scalabilité … le CDN, pourtant, est la seule manière d’optimiser le TTFB. CHAPÎTRE PREMIER, LE CDN
  • 26. • TTFB =Time to first byte • Dépend uniquement de la proximité des “Edges”, vous savez, à cause de c = 299,792,458 m/s • Rend Google content. Mais aussi vos utilisateurs. CHAPÎTRE PREMIER, LE CDN
  • 27. LE CDN IMPOSE DES CONTRAINTES • Le “hit ratio” doit être bon • GEOIP • Triturages des x-headers à la mano pour faire quelque chose de charmant
  • 28. LE CDN IMPOSE DES CONTRAINTES • Le “hit ratio” doit être bon • GEOIP * En tout cas vous devez comprendre l’effet sur le “hit ratio”. Les CDN vont vous exposer des headers intéressants à titre d’exemple HTTP_CF_IPCOUNTRY pour Cloudflare ou CloudFront-Viewer-Country pour le CDN éponyme. Fastly va vous donner jusqu’à la ville. • Triturages des x-headers à la mano pour faire quelque chose de charmant
  • 29. LE CDN IMPOSE DES CONTRAINTES • Le “hit ratio” doit être bon • GEOIP • Triturages des x-headers à la mano pour faire quelque chose de charmant* Certains CDNs vont vous permettre de triturer à mort. Evitez.
  • 30. LE CDN, SON IMPLÉMENTATION NOUS POUSSE À FAIRE DES CHOSES BIEN • Charger les contenus dynamiques en asynchrone, et si vôtre CDN le supporte .. en utilisant ESI (Xavier Leune vous en a déjà dit des choses hier .. ). /users/me • Contrôle de la sémantique cache au niveau de chaque contrôleur / chaque action de contrôleur. • D’ailleurs .. cela fait déjà un gros bout de chemin vers les micro- services
  • 31. SYMFONY NOUS REND LAVIE SIMPLE ET BELLE /** * @Cache(expires="tomorrow") */ class UserController extends Controller { /** * @Cache(lastModified="user.getUpdatedAt()", ETag="'User' ~ user.getId() ~ user.getUpdatedAt().getTimestamp()") */ public function meAction(User $user) { } }
  • 32. LE PAR-DÉFAUT EST RAISONNABLE Par défaut Cache-Control est no-cache
  • 33. ESI PERMET LA MISE EN PARTIELLE DE LA PAGE
  • 34. ESI PERMET LA MISE EN PARTIELLE DE LA PAGE Toute la page peut être en cache
  • 35. ESI PERMET LA MISE EN PARTIELLE DE LA PAGE Toute la page peut être en cache Mais des parties peuvent rester dynamiques
  • 36. ESI PERMET LA MISE EN PARTIELLE DE LA PAGE Toute la page peut être en cache Mais des parties peuvent rester dynamiques Avec desTTLS différents…
  • 37. ESI PERMET LA MISE EN PARTIELLE DE LA PAGE Toute la page peut être en cache Mais des parties peuvent rester dynamiques Avec desTTLS différents… Avec même du ciblage
  • 38. framework: esi: true fragments: { path: /_proxy } SYMFONY A DU SUPPORT ESI INTÉGRÉ Ouvrez donc app/config/config.yml et dans la partie framework :
  • 39. {{ render_esi(uri, options = []) }} QUI SAIT FAIRE DU FALLBACK EN DEV…. • Dans votre template twig il y a un helper pour ça.
  • 40. {{ render_hinclude(controller('...'), { 'default': 'default/content.html.twig' }) }} VOUS POUVEZ OPTER POUR DU JS ASYNC. ICI AUSSI SYMFONYVAVOUS AIDER. Voir http://mnot.github.io/hinclude/ • Dans votre template twig il y a un helper pour ça aussi:
  • 41. {{ render_hinclude(controller('...'), { 'default': 'default/content.html.twig' }) }} PROBABLEMENT ILVAUT MIEUX FAIRE LE JS AVEC UN FRAMEWORK COMME IL FAUT (REACT? ANGULAR?) • Et servir du JSON de vos magnifiques micro-services avec silex.
  • 42. • Le choix du CDN est compliqué. Nous avons utilisé CloudFront, CloudFlare et Fastly • CloudFront n’est pas cher. Mais regardez bien la latence d’invalidation. • CloudFlare peut être incroyable pour lutter contre des DDOS et il a des headers GEO détaillés. • Fastly peut être cher (surtout en HTTPS) mais il donne du support ESI et customVCL (même si c’est mal). • Akamai ont inventé ESI; mais ils sont super chers et j’aime pas traiter avec eux. CHAPÎTRE PREMIER, LE CDN
  • 43. ETVARNISH? • Le reverse veut être proche du client. • Implémenter du code applicatif au niveau du reverse c’est mal.Très mal. C’est intestable et bricolé.A chaque couche son rôle. • Fastly supporte desVCLs customs. Mais évitez SVP (pas fastly, juste lesVCLs customs).
  • 44. ETVARNISH? • Par contre c’est pas du tout débile d’avoir un autre reverse devant votre serveur web. • Considérez simplement nginx (pas de support ESI mais SSI est équivalent).Varnish c’est OK mais souvent superflu.
  • 45. Pleins de bouts de colle + plein de machines pour le faire tourner Serveur(s) Web App- Server(s) DB(s)
  • 46. • On va encore casser notre serveur web en plus petites parties. • Cela peut simplement être un load balancer comme ELB sur AWS. Mais attention au support SNI. Chez nous on utilise ELB devant notre propre entre-point qui fait aussi le routage SSH. • Ca peut aussi être un HAProxy ou l’un des dizaines projets en GoLang qui apparaissent comme des champignons après la pluie. CHAPÎTRE DEUXIÈME,TRÈS COURT, SUR L’ENTRY POINT
  • 47. • Il peut être assez intelligent et participer au routage vers vos micro-services. • Il participe à votre haute-disponibilité. Il isole du point de vue réseau vos systèmes internes. CHAPÎTRE DEUXIÈME,TRÈS COURT, SUR L’ENTRY POINT
  • 48. ON N’A FAIT QUE ÇA: CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 49. COMME QUOI, 40 MINUTES POUR RENDREVOS APPLICATIONS NATIVES AU CLOUD C’EST STRESS. CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 50. J’ESPÈRE QUEVOUS AVEZ SUIVI LETALK DE FABIEN MEURILLON SUR LES MICRO-SERVICES.VOUS AVEZ DÉJÀ COMPRIS LA RELATION ENTRE CETTE BANDE ET LA COUCHE LA PLUS EN AMONT (CDN) DONC JUSTE QUELQUE REMARQUES. CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 51. • Comme on a cassé notre serveur web en plusieurs parties chacune remplissant un petit rôle sur le chemin de la requête on comprends l’intérêt de casser notre serveur d’application aussi; • On peut ainsi faire monter en échelle chaque partie de manière autonome ce qui, bizarrement, va nous réduire la facture d’hébergement. On met pasTOUT à l’échelle du composant le plus lourd. CHAPÎTRETROISIÈME, LES MICRO-SERVICES
  • 52. Si vôtre graph de services n’est pas trop profond ça peut encore aller. MAIS ATTENTION À LA LATENCE À LA QUEUE LEU-LEU
  • 53. • Si vous commencez à faire des boucles, même avec du keep-alive ça risque de non seulement être lent… mais aussi de consommer un max de mémoire. • Deux stratégies pour mitiger ceci: MAIS ATTENTION À LA LATENCE À LA QUEUE LEU-LEU For each image in article do an http request
  • 54. • Designer vos APIs pour que toujours on puisse faire des appels “bulk”. On ne vend plus au détail. • Communiquer en profondeur uniquement à travers une Queue de Messages • Exposer chaque service avec deux APIs (HTTP synchrone et MQ Async) est une bonne pratique. • On commence par HTTP pour aller vite. Puis on factorise en async. LA LATENCE À LA QUEUE LEU-LEU
  • 55. DONC EN GROS AU LIEU DE FAIRE CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 56. VOUS FAÎTES CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 57. VOUS FAÎTES CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 58. DOCTEUR, LE MESSAGE QUEUE C’EST PAS COMPLIQUÉ ?
  • 60. Chaque queue de message donne des garanties différentes. Mais de nos jours, Rabbit ou Kafka, ça va vous suffire.
  • 61. ET POUR LES ÉCRITURES … CECIVOUS DONNE DU “BACKPRESSURE MANAGEMENT”
  • 62. UN PIC DETRAFIC NEVAS PLUS RÉSULTER DANSVOS SYSTÈMES QUI PLANTENT. MAIS SIMPLEMENT DANS UNE LATENCE PLUS IMPORTANTE POUR LA MISE À JOUR DES DONNÉES.
  • 63. C’est déjà du CQRS. Avez vous entendu parler de CQRS ? ET ON PEUTTRICHER ENCORE MIEUX For each image in article do an http request
  • 64. • Désolé, ça, je ne traduis pas en Français. CHAPÎTRE QUATRIÈME, COMMAND AND QUERY RESPONSIBILITY SEGREGATION For each image in article do an http request
  • 65. • Au lieu d’intermédier les lectures par vôtre Queue de Messages CHAPÎTRE QUATRIÈME, COMMAND AND QUERY RESPONSIBILITY SEGREGATION For each image in article do an http request
  • 66. VOUS FAÎTESTOUTESVOS LECTURES SUR LE MOTEUR DE RECHERCHE CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 67. VOUS FAÎTESTOUTESVOS LECTURES SUR LE MOTEUR DE RECHERCHE CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué ECRITURE
  • 68. VOUS FAÎTESTOUTESVOS LECTURES SUR LE MOTEUR DE RECHERCHE CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué ECRITURE
  • 69. VOUS FAÎTESTOUTESVOS LECTURES SUR LE MOTEUR DE RECHERCHE CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué LECTURE
  • 70. SIVOUS AVEZ SUIVI HIER LA PREZ DE LA FOURCHETTE SUR “L’API FIRST”.. ET CELLE DE BLABLA SUR ELASTICSEARCH.. VOUSVERREZ. CE N’EST PAS DE LATHÉORIE.
  • 71. • Vous faîtes toutes vos lectures “bulk”, les listes, par le moteur de recherche (et si vous avez suivi la prez blablacar … vous avez vu. Un ElasticSearch est très riche). • Parfois même les lectures unitaires c’est pas mal par le moteur de recherche (donc un seul lieu dans lequel vous aller dénormaliser). QUAND JE DISTOUTES LES LECTURES JE SIMPLIFIE UN PEU
  • 72. • Par contre sur un formulaire, tout ce qui est transactionnel, vous lisez de votre DB principale qui demeure “la source de vérité” • L’écriture correspondante va partir souvent sur le MQ sauf cas super rare ou quelqu’un vous a convaincu que l’écriture synchrone est un feature. LAVÉRITÉ A UNE SEULE SOURCE
  • 73. ET QUEL MOTEUR DE RECHERCHE?
  • 75. OK, d’accord SOLR c’est très bien aussi, en tout cas c’est du Lucene. ET QUEL MOTEUR DE RECHERCHE?
  • 76. OK, d’accord, Xavier, Sphinx existe. ET QUEL MOTEUR DE RECHERCHE?
  • 78. • C’est la meilleure traduction que j’ai pu trouver pour “Staggered Release”. Qui est le contraire du “Synchronous Release”. • Si vous pensez faire du micro-service, mais vous devez mettre en prod tous les services de manière synchrone, vous ne faites pas de micro-services. CHAPITRE CINQUIÈME, MISE EN PROD ÉCHELONNÉE
  • 79. Car parfois vous voulez pourvoir partager des modèles entre vos micro-services DE MANIÈRE PARFAITEMENT DÉSAGRÉABLE, CECI EST NON-TRIVIAL
  • 80. • C’est qu’on appelle des “Lazy Migrations” de migrations à la volée. • C’est difficile à faire au niveau d’un ORM comme Doctrine. CHAPÎTRE CINQ ET DEMI, LA MIGRATION PROGRESSIVE
  • 81. • Il y a pourtant un pattern : le membre static, un integer qui représente en Semver la version du model.A l’hydratation on regarde la version et on fait jouer la migration. • Mais beaucoup plus facile à faire si vous faîtesTOUTES vos lectures sur le moteur de recherche…. la co- existence des modèles est assuré par l’indexation. CHAPÎTRE CINQ ET DEMI, LA MIGRATION PROGRESSIVE
  • 82. MAIS, ORI, ON DEVAIT PARLER DES APPLICATIONS NATIVES AU CLOUD, N’ESTU PAS EN TRAIN DETE PERDRE DANS TES PENSÉES?
  • 83. • Il y a une cohérence à tout ça. Je pense. • Ces intermédiations, tout-à-coup, nous résolvent cette question de la vie de l’application à échelle, et dans la durée • Mais aussi, tout-à-coup, chacun des éléments de l’infra vient de devenir horizontalement scalable. • Ajouter un noeud rabbitmq, puis augmentez le nombre des workers (et vous venez d’avoir du backpressure management gratos) ajouter quelques noeuds au cluster elasticsearch .. ou quelques serveurs d’application et voilà le pic de trafic 10X n’est pas grave du tout. MERCI POUR LA QUESTION, MAIS NON.
  • 84. CE QUI NOUS PERMET AUSSI DE,TOUTE- DE-SUITE, PASSER AU CHAPITRE SUIVANT TOUCHANT AUX BASES DE DONNÉES CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 85. CHAPÎTRE SIXIÈME, OÙ L’ON DÉCOUVRE QU’ON A UNE FLOPÉE DES SYSTÈMES DE PERSISTANCE CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 86. UN RAPIDE SIXIÈME CHAPÎTRE. LE BÂT BLESSE AU NIVEAU DE LA BD RELATIONNELLE. CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 87. NOUS ON FAIT DU ACTIVE MASTER / PASSIVE MASTER EN REPLICATION SYNCHRONE (GALERA). MAIS ILY A DES LIMITES À ÇA. SURTOUT SIVOUSVOULEZTRAVAILLER EN MODE HAUTE-DISPO SUR DES MULTIPLES DATACENTERS. CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 89. COMMEVOUS AVEZVU PLUSTÔT AVEC NICOLAS GREKAS SYMFONYVAVOUS ABSTRAIRE BEAUCOUP DES QUESTIONS SUR CERTAINES DES COUCHES PAR DES SERVICES, DU COUP CELA DEVIENT UNE QUESTION SIMPLEMENT DES SERVICES FOURNIS PAR VOTRE INFRA. CDN Point d’entrée Point d’entrée Point d’entrée DB DB Serveur Web App1 App2 App3 DB Serveur Web CACHE Serveur Web App1 App2 App3 App1 App2 App3 Moteur de recherche Queue de Message Système de Fichier distribué
  • 90. RAPPELONS NOUS. CA N’EXISTE PAS DES APPLICATIONS STATELESS. LA QUESTION ESTTOUJOURS : OÙ EST L’ÉTAT. ILTRAÎNE SOUVENT DANS LA DB … ET DANSVOS CACHES.
  • 91. IMPLÉMENTER DONC LES BONNES PRATIQUES DE CACHE (PSR-6) AVEC LES SERVICES SYMFONYVOUS LIBÈRE PAS MAL DE DEVOIRY PENSER.
  • 92. • On a parlé des la structuration des éléments d’infra et un peu de l’adhésion code (pas grand chose n’est-ce pas). • Tout ceci nous prépare pour pouvoir passer pour chaque une de nos couches de N à N+1 • Mais cela dépend alors de notre capacité à créer à l’identique, et rapidement des nouveaux noeuds. • Vous avez deux choix là: le blob que l’on copie (mal) où le build systématique avec des garanties d’idempotence (bien!). CHAPÎTRE DERNIER, LE DÉPLOIEMENT
  • 93. • Ca implique des contraints mais qui vont vous rendre des fiers services: • Le processus de build ne doit pas être dépendant de l’environnement. Il ne doit pas nécessiter la connexion aux services. Il ne doit pas connaître l’identité du serveur sur lequel on va déployer (toute la conf devra arriver de l’environnement). • La prod est en lecture seule (pour éviter l’émiettement, le “infrastructure drift). Uniquement les données sont en Lecture/ Ecriture BUILD HORS INFRA, RUN EN LECTURE SEULE.
  • 95. UNE APPLICATION CLOUD NATIVE PEUT ÊTRE DÉPLOYÉE SUR UN PETIT DÉDIÉ.
  • 96. de tourner sur des multiples infrastructures distantes de migrer d’une infrastructure à une autre de haute disponibilité de montée en échelle horizontale d’absorber des pics irréguliers de déploiement continu UNE APPLICATION CLOUD EST UNE APPLICATION POTENTIELLEMENT CAPABLE:
  • 97. RIEN NEVOUS FORCE DE PASSER DE
  • 99. À
  • 100. NVMPESRRKCCDX • Nginx • Varnish • MariaDB/Postgres • PHP-FPM • Symphony • NodeJS • ElasticSearch/Solr • Redis / RabbitMQ/ Kafka • Ceph / Gluster • Docker / LXC
  • 102. LE COÛT DE FAIRE LES CHOSES BIEN DÈS LE DÉPART EST RELATIVEMENT FAIBLE. ON N’A PAS OUBLIÉ “OPTIMIZE LAST” TOUT CECI N’EST PAS LÀ POUR RENDREVOTRE APPLICATION PLUS RAPIDE. MAIS PLUS FACILE À MAINTENIR ET À FAIRE MONTER EN ECHELLE.
  • 103. JEVAIS QUAND MÊME ME FAIRE DE LA PUB EN 500MS
  • 104. CDN (CloudFront, Cloudflare, Fastly) DNS (Route 53, Dyn, DNSMadeEasy) ELASTIC LOAD BALANCER SCALE OUT APP 1 APP 2 APP 3 NGINX / FPM NGINX / FPM NGINX / FPM REDIS REDIS* REDIS* DB LOAD BALANCING GALERA DATABASE CLUSTER SOLR CLOUD SSD BASED NETWORK FILE SYSTEM APP 4 NGINX / FPM APP 5 NGINX / FPM S3 BACKUP 1 2 3 5 6 DB LOAD BALANCING4 7 8 1.DNS Alias maps zone apex to CDN distribution. 2.CDN caches popular resources at edge locations. HTTPS terminates here. 3.ELB performs health check on instances 4.Load Balancer distributes traffic 5.Nginx performs proxy caching, compression and passes requests to the app running PHP-FPM 6.LB of DB queries pushes writes to the Master, compensating for optimistic loading. 3 synchronous masters with health check 7.Three discreet Availability Zones datacenters. 8.Platform can scale out the web tier to as many instances as might be required. CHEZ MOI, PAR DÉFAUT,VOTRE PROD RESSEMBLE À ÇA. CLOUD NATIVE SANS LES SOUCIS. ET VOUS N’AVEZ RIEN À FAIRE. C’EST UN PAUVRE PETIT FICHIER YAML PUIS DE L’AUTOMAGIE. VENEZ ME PARLER.
  • 105. QUESTIONS ? Ori Pekelman, markeuteux en chef chez platform.sh Mais on me permet de parler ici parce que je fait de l’Haskell. @oripekelman sur github/twitter/linked-in