Construire Des Applications Cloud Natives - SymfonyLive Paris 2016

CONSTRUIRE DES APPLICATIONS CLOUD

NATIVESou le passage de Lamp à Nvmpsesrrkc

Ori Pekelman, markeuteux en chef chez platform.shMais on me permet de parler ici parce que je fait de l’Erlang.

@oripekelman sur github/twitter/linked-in

CONSTRUIRE DES APPLICATIONS CLOUD

NATIVESPré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 ET VOIR 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 A TOUTES 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

IL VA 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 À ÇACDN

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 ÇACDN

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 ÇACDN

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 ON VA RENTRER DANS LE DÉTAIL PLUS TARD.

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 LA VIE SIMPLE ET BELLE

/**

*@Cache(expires="tomorrow")

*/

classUserControllerextendsController

{

/**

*@Cache(lastModified="user.getUpdatedAt()",ETag="'User'~user.getId()~user.getUpdatedAt().getTimestamp()")

*/

publicfunctionmeAction(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 cacheMais des parties peuvent rester dynamiques

ESI PERMET LA MISE EN PARTIELLE DE LA PAGE

Toute la page peut être

en cacheMais des parties peuvent rester dynamiques

Avec des TTLS différents…

ESI PERMET LA MISE EN PARTIELLE DE LA PAGE

Toute la page peut être

en cacheMais des parties peuvent rester dynamiques

Avec des TTLS différents…

Avec même du ciblage

framework:esi:truefragments:{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 SYMFONY VA VOUS 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 IL VAUT 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 custom VCL (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

ET VARNISH?

• 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 des VCLs customs. Mais évitez SVP (pas fastly, juste les VCLs customs).

ET VARNISH?

• 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 RENDRE VOS 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 QUE VOUS AVEZ SUIVI LE TALK 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 pas TOUT à l’échelle du composant le plus lourd.

CHAPÎTRE TROISIÈ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

Foreachimageinarticledoanhttp

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ÎTESCDN

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ÎTESCDN

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É ?

useSwarrot\Processor\ProcessorInterface;useSwarrot\Broker\Message;

classProcessorimplementsProcessorInterface{publicfunctionprocess(Message$message,array$options){echosprintf("Consumemessage#%d\n",$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 … CECI VOUS DONNE DU

“BACKPRESSURE MANAGEMENT”

UN PIC DE TRAFIC NE VAS PLUS RÉSULTER DANS VOS 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 PEUT TRICHER ENCORE MIEUX

Foreachimageinarticledoanhttp

request

• Désolé, ça, je ne traduis pas en Français.

CHAPÎTRE QUATRIÈME, COMMAND AND QUERY RESPONSIBILITY

SEGREGATION

Foreachimageinarticledoanhttp

request

• Au lieu d’intermédier les lectures par vôtre Queue de Messages

CHAPÎTRE QUATRIÈME, COMMAND AND QUERY RESPONSIBILITY

SEGREGATION

Foreachimageinarticledoanhttp

request

VOUS FAÎTES TOUTES VOS 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ÎTES TOUTES VOS 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ÎTES TOUTES VOS 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ÎTES TOUTES VOS 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

SI VOUS AVEZ SUIVI HIER LA PREZ DE LA FOURCHETTE SUR

“L’API FIRST”.. ET CELLE DE BLABLA SUR ELASTICSEARCH.. VOUS VERREZ. CE N’EST PAS

DE LA THÉ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 DIS TOUTES 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.

LA VÉ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îtes TOUTES 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’ES TU PAS EN TRAIN DE TE 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 PERSISTANCECDN

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 rechercheQueue de Message

Système de Fichier distribué

NOUS ON FAIT DU ACTIVE MASTER / PASSIVE MASTER EN REPLICATION SYNCHRONE (GALERA). MAIS IL Y A DES

LIMITES À ÇA. SURTOUT SI VOUS VOULEZ TRAVAILLER 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 rechercheQueue de Message

Système de Fichier distribué

CHAPÎTRE PÉNULTIÈME

Le Cache.

COMME VOUS AVEZ VU PLUS TÔT AVEC NICOLAS GREKAS SYMFONY VA VOUS 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 rechercheQueue de Message

Système de Fichier distribué

RAPPELONS NOUS. CA N’EXISTE PAS DES

APPLICATIONS STATELESS.

LA QUESTION EST TOUJOURS : OÙ EST L’ÉTAT.

IL TRAÎNE SOUVENT DANS LA DB … ET DANS VOS CACHES.

IMPLÉMENTER DONC LES BONNES PRATIQUES DE CACHE (PSR-6) AVEC LES SERVICES SYMFONY VOUS

LIBÈRE PAS MAL DE DEVOIR Y 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 NE VOUS 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 RENDRE VOTRE APPLICATION PLUS

RAPIDE. MAIS PLUS FACILE À MAINTENIR ET À FAIRE MONTER EN ECHELLE.

JE VAIS 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.shMais on me permet de parler ici parce que je fait de l’Haskell.

@oripekelman sur github/twitter/linked-in