2016 Octo WP Readyapp

CONCEVOIR VOS APPLICATIONS
POUR TIRER PARTI DU CLOUD
www.octo.com - blog.octo.com
Table des
ma+ires
O1 Scaler naturellement ________________________________________________ 08-15
2
O2 Assurer sur la qualit de service ________________________ 16-25
O3 99,99% de disponibilit ________________________________________ 26-33
O4 Garantir intgrit et scurit ________________________________ 34-39
O5 Dployer frquemment et facilement ___________ 40-46

Cloud Ready
Applications
Les applications daujourdhui et leurs futures volutions

doivent tre un avantage concurrentiel. Elles doivent sadapter
un environnement changeant et offrir une qualit de service
toujours plus leve. Le cloud offre des opportunits pour
rpondre ces nouveaux challenges.
Pour en tirer profit et concevoir une application cloud ready,

nous avons dcel cinq enjeux fondateurs pour les applications
de demain.
Pour chacun, nous vous proposons un chapitre pour comprendre

comment concevoir larchitecture de ces applications avec des
3 patterns*, des pistes de rflexion, des services manags et
des exemples dimplmentations destins rpondre cet
enjeu. Par souci dhomognit, tous les exemples se basent
sur Amazon Web Services, mais restent transposables sur toute
autre plateforme de cloud.
Que vous conceviez, dveloppiez ou exploitiez des applications

sur le cloud, ces lments vous aideront comprendre quelles
librairies, quels services, quelles architectures utiliser en
fonction de vos besoins.
Ces fiches se veulent des pistes de rflexion et non des

solutions prtes lusage; en effet, lensemble des patterns*
applicatifs dcrits sur un schma ne sont certainement pas
tous ncessaires dans votre contexte, De plus les solutions
techniques ne sont rien sans lorganisation humaine adapte.
Enfin, parce que les pratiques Cloud Ready Applications sont
complmentaires avec dautres pratiques que nous dfendons
galement chez OCTO pour construire des applications :
Software Craftsmanship et DevOps notamment.
* Un pattern est une solution rptable et rutilisable un problme identifi.

OCTO > CLOUD READY APPS
XaaS (Anything As A Service) :

o vos applications peuvent-elles
tre dployes ?
En fonction du type de XaaS choisi, votre application dispose de plus ou
moins de services sous-jacents :
IaaS : Infrastructure as a Service
Dsigne les fondations du cloud computing. Il sagit doffres de capacit de calcul,
de stockage et de rseau sous une forme comparable celle dune machine virtuelle.
4 CaaS : Container as a Service

Dsigne les offres permettant dhberger des conteneurs de type Docker. Un
conteneur de type Docker est, de faon trs schmatique, une application package
pour tre opre de faon totalement isole. Un conteneur est implment en isolant
des ressources au sein dun mme systme dexploitation.
PaaS : Platform as a Service

Dsigne des offres permettant dhberger des applications, doffrir un stockage
structur et requtable (SQL ou NoSQL), de fournir un MOM (Message Oriented
Middleware) sous forme de service Le nombre de stacks prises en charge et
labstraction vis--vis des ressources matrielles sont variables selon les offres.
SaaS : Software as a Service

Dsigne le fait de distribuer un logiciel en ligne. Le concept est utilis depuis trs
longtemps pour les clients mails. Il a t dmocratis avec la suite bureautique en
ligne Google Documents et le logiciel de CRM en ligne SalesForces.
BaaS : Back-end as a Service

Dsigne un service sur tagre offrant des fonctionnalits back-end en particulier
pour une application mobile.
Les principes suivants sont utiles en tout cas pour rpondre aux diffrents enjeux de
vos applications.
IaaS CaaS PaaS BaaS SaaS
Front-end Front-end Front-end Front-end Front-end

Applicatif Applicatif Applicatif Applicatif Applicatif
Back-end Back-end Back-end Back-end Back-end

Applicatif Applicatif Applicatif Applicatif Applicatif
Services (OS, Services (OS, Services (OS, Services (OS, Services (OS,
middleware, middleware, middleware, middleware, middleware,
conteneur) conteneur) conteneur) conteneur) conteneur)
Serveur Serveur Serveur Serveur Serveur

Physique Physique Physique Physique Physique
Stockage Stockage Stockage Stockage Stockage
Rseau Rseau Rseau Rseau Rseau

DataCenter DataCenter DataCenter DataCenter DataCenter
Dveloppement interne
Fourni dans loffre de cloud
Scaler
na+urel-
lement
10 1000 10M
100 1M 100M
OCTO > CLOUD READY APPS > SCALER
Scaler
Naturellement
SAPPUYER INTELLIGEMMENT
SUR LE CLOUD
nvisager en priorit lutilisation des services manags, nativement rsilients et scalables fournis
E
par les plateformes cloud: PaaS, services de persistance et de cache, BaaS
Patterns: SaaS (Ex. Salesforce, AWS RDS, AWS ElastiCache), PaaS (Ex. Heroku, AWS Lambda),
BaaS (Ex. Parse, Kumulos).
CHOISIR LE BON NIVEAU DABSTRACTION :

8
SERVEUR, CONTENEUR, RUNTIME
C oncevoir en faisant abstraction de la localisation physique pour lexcution, le dploiement en
cloud noffrant pas de garantie sur cet aspect afin dallouer les ressources l o elles sont le plus
rapidement disponibles.
Adapter la conception au niveau dabstraction de la plateforme : certaines peuvent imposer des
contraintes fortes (temps dexcution limit, mono-thread).
Envisager des produits (systme dexploitation, logiciels, services) ayant des politiques de
facturation lusage plutt quau nombre de machines.
Patterns : Location Transparency, Fast Startup and Graceful Shutdown, Service Discovery.
CONCEVOIR
POUR LA SCALABILIT
P our simplifier llasticit et ladaptation rapide la charge, lapplication doit embarquer des
mcanismes facilitant sa scalabilit.
L a scalabilit horizontale offre une approche plus extensible tout en contribuant viter les SPOF,
mme si elle est plus complexe mettre en uvre que la scalabilit verticale.
Il est prfrable de dplacer le traitement plutt que les donnes lorsquelles sont volumineuses.
Le cloud offre en effet la possibilit dallouer aisment des capacits de traitement en diffrentes
zones.
Patterns : Load balancer, sharding, shared nothing, microservices.
Pattern
Microservices
Approche darchitecture de SI visant modulariser le SI en privilgiant des services plus petits,
ports chacun par une quipe ddie. Par opposition une approche plus intgre/monolithique,
une architecture en microservices :
C
larifie les responsabilits par la matrialisation des frontires.
L imite la complexit locale et ainsi fiabilise les dveloppements.
R
end les couplages plus faibles, ce qui facilite les changements et donc linnovation.
P
ermet dutiliser des technologies diffrentes.
A
utorise grer la scalabilit en permettant de la grer un niveau plus fin.
9 A
utorise grer la haute disponibilit un niveau plus fin.
Cette approche est toutefois plus exigeante en termes dorganisation, du fait de la ncessit de
coordonner les changements et les dploiements. Par ailleurs, les liens entre services augmentent
la complexit globale et leur mise en place peut tre coteuse.
Microservice Microservice Microservice Microservice

Autocompltion Catalogue Tunnel de vente Gestion de compte
EXEMPLE
Services offerts
par AWS
pour la scalabilit
1. Route 53 : Service de DNS qui peut tre 7. ElasticCache : Service de cache
utilis pour router le trafic au niveau DNS compatible avec les protocoles Redis et
entre plusieurs rgions, en dtectant au Memcached.
besoin si une rgion est indisponible.
10
8. S3 : Single Storage Service. Service de
2. ELB : Service permettant de rpartir stockage objet illimit grant des fichiers
la charge entre plusieurs instances AWS, dune taille allant jusqu 5TB (en septembre
en dtectant au besoin si lune delles est 2016).
indisponible.
9. CloudFront : Service de CDN (Content
3. Cloud Watch : Service de surveillance Delivery Network) proposant des points
des instances et applications qui permet de prsence sur toute la surface du globe
notamment de donner des alertes lAuto ce qui permet de diminuer la latence et
Scaling Group. de rduire les cots en servant un cache
HTTP depuis une localisation plus proche
4. Auto Scaling Group : Service permettant de lutilisateur.
daugmenter ou de rduire le nombre
dinstances AWS en fonction de mtriques
CloudWatch. Remarque:
La haute disponibilit et la scalablit
5. RDS : Relation Data Service. Service de ces services sont assures par la
manag de bases de donnes relationnelles. plateforme AWS.
6. DynamoDB : Service manag de base

de donnes NoSQL Cl/Valeur.
Amazon CloudFront
1 9
Amazon Web / API
Route 53
shorturl web/core
web /
shorturl user /
data data transfer
4 7
11
CACHE
Auto Scaling Group Auto Scaling Group
Amazon
Elasticache
Business
logic
download managers
statistics
5
Amazon RDS
Auto Scaling Group Auto Scaling Group
3
App-generated
File Transfer data
stats for
Auto Scaling
8 workers Amazon
6
CloudWatch
App health
monitoring
Amazon S3
Auto Scaling Group
Amazon
DynamoDB Health Status
Notifications
EXEMPLE
Implmentation
scalable
Au niveau du stockage de donnes vous les utiliser au mieux vous permet de choisir
concevez votre application en tenant la ressource la moins chre disponible
compte du sharding des donnes (1). Il ce moment prcis. Pour cela, vous devez
sagit du premier prrequis la scalabilit. penser votre application pour quelle soit
Les systmes de stockage actuels NoSQL capable dtre arrte et redmarre en
qui abstraient ce concept restent trs rares. plein traitement. AWS offre par exemple un
Leur optimisation ncessite dans tous les mcanisme denchres avec ses instances
cas de matriser ds la conception les choix Spot qui autorisent consommer de la
12
faits au niveau du sharding des donnes. puissance supplmentaire tant que son
prix est infrieur un seuil fix. Lorsque le
Supporter du load balancing (2) permet prix remonte, la machine est arrte sous
quune requte soit traite par une instance 2 minutes. La capacit de fast startup &
de lapplication, la requte suivante par graceful shutdown (5) est ici indispensable.
une seconde instance. De cette faon, vous
pourrez augmenter le nombre dinstances
pour grer plus de trafic. Cela impose une
gestion trs stricte des tats dans le code.
Pouvoir sexcuter sans faire dhypothse
sur son emplacement physique permet
enfin daller un cran plus loin en excutant
potentiellement linstance sur une autre
machine, voire dans un autre data-
center. Cest ce quon appelle la location
transparency (3). Je veux accder mon
fichier local, je veux lire les logs de cette
instance, ces rflexes doivent tre perdus.
Enfin, une application qui peut sexcuter
sur une machine de faible puissance, avec
de multiples curs disponibles, et qui sait
1. Sharding :
Le sharding dcrit ainsi un ensemble
de techniques qui permettent de
rpartir les donnes sur plusieurs
machines pour assurer la scalabilit de
larchitecture.
2. Load balancer :
Composant rseau ou applicatif qui 2
rpartit les requtes sur diffrentes
instances de faon quilibrer la charge.
Amazon ELB est par exemple un service
de load balancing fourni par AWS.
3. Location transparency : 3 5
Mcanisme de dcouplage permettant A A
13
lmetteur de ne pas connatre la
localisation du rcepteur. Par exemple
DNS, reverse proxy
4. Shared Nothing :
Pattern darchitecture dans lequel A
les nuds dun systme distribu ne
partagent ni disque, ni mmoire et qui
ne prsente aucun point unique de
dfaillance (Single Point of Failure).
5. Fast startup and graceful 1

4
shutdown:
Capacit de lapplication servir rapi- A1 A2
dement des requtes aprs le dmar-
rage et raliser automatiquement les
oprations ncessaires pour son arrt
(sauvegarder les rsultats intermdiaires,
diffuser un tat partag). En effet
dans le cloud, une instance peut tre
dmarre ou arrte tout moment.
Voir http://12factor.net/
OCTO > CLOUD READY APPS > QUALIT DE SERVICE
Assurer
sur la
14
quali+
de service
15
Assurer
sur la qualit de service
MESURER, APPRENDRE,
AMLIORER
ollecter des mesures dtailles tous les niveaux (systme, middleware, application) pour
C
connatre lexprience client (UX), lanalyser et lamliorer.
endre la performance visible et accessible tous les acteurs, dans le cadre dun programme de
R
performance en continu aux objectifs partags et explicites.
Patterns: Centralized monitoring, Correlation ID, Continuous performance.
16 CONCEVOIR
POUR LE SERVICE
R
echercher la simplicit et la maintenabilit : volutivit, exploitabilit, dployabilit.
A
ppliquer les patterns en fonction de besoins avrs.
T
enir compte des forces et faiblesses de lenvironnement (infrastructure, middlewares, services
cloud).
P
enser lutilisateur : soigner lUX en sattachant au ressenti du client, prvoir un mode dgrad
en cas dimprvu.
Patterns : KISS, Graceful degradation, Microservices.
SE HISSER SUR LES PAULES

DES GANTS
S
imprgner de ltat de lart, pour savoir sappuyer sur les nombreux patterns labors par la
communaut notamment sur la concurrence, le stockage et laccs aux donnes, la rduction de
la latence et la robustesse.
Patterns : lambda architecture, request queuing, request collapsing, request redundancy,
timeouts, circuit breakers, bulkheads, idempotence.
Patterns
Centralized monitoring
Avec la possibilit dajouter et de retirer une instance de serveur tout moment, il est difficile de
consulter les logs locaux sur un grand nombre de machines. De plus, ces fichiers locaux peuvent
disparatre tout moment avec les instances associes, rendant la tche totalement impossible.
Il est donc ncessaire dsormais de centraliser lensemble des logs. Par exemple dans une stack
Elastic (Elasticsearch, Logstash et Kibana).
Log/mtriques Log/mtriques Log/mtriques Log/mtriques
17
Attention : certains patterns induisent de la complexit,

il convient donc den peser le pour et le contre.
Continuous performance
Processus visant tester et mesurer la performance du systme de manire continue, du
dveloppement la production.
Cycles ditrations agiles
Itration 1 Itration 2 Itration 3 Itration 4 Itration 5 Itration 6
Test Test Test Test

de performance de performance de performance de performance
18
Graceful degradation
Adaptation automatique de lapplication une situation dgrade (perte dune partie de
linfrastructure, taille dcran de lutilisateur rduite, fonctionnalit non supporte par le navigateur
cible, bande passante rduite, etc.).
Gestion derreur standard Graceful degradation
CATALOGUE COMMANDE COMPTE CATALOGUE COMMANDE COMPTE
ERREUR
Lambda architecture
Une architecture lambda combine deux types de traitements sur les donnes :
T
raitements batch , gnrant intervalles rguliers des rsultats prcalculs.
T
raitements temps rel , gnrant des rsultats la demande.
Cette combinaison permet de fournir des rsultats actualiss malgr des calculs potentiellement
coteux et des donnes dentre changeant rapidement.
Donnes Traitement
de prcalcul temps rel
Rsultat
temps rel
19
Batch Vue
de prcalcul prcalcule
Bulkhead
La dfaillance dun systme externe peut rapidement mettre en pril lensemble du service. Pour
lutter contre cela, le pattern bulkhead permet disoler les appels. la manire des caissons tanches
de bateau, il permet de protger le systme dune dfaillance localise qui se transformera en
dfaillance globale.
Un exemple dimplmentation de ce pattern est lutilisation de deux pools de connexions pour
quune saturation de lun nimpacte pas lautre.
(https://github.com/Netflix/Hystrix/wiki/How-it-Works#isolation)
Service 1 Service 2 Service 3 Service 4
Bulkhead 1
Bulkhead 2
Bulkhead 3
Request collapsing
20 Pattern applicatif permettant de limiter le nombre dappels distants en regroupant plusieurs
requtes pour nen faire quune. Netflix Hystrix implmente ce pattern par exemple. Cela peut
servir limiter :
la charge rseau,
limpact dune latence rseau leve,
les cots dans le cadre de licences la requte.
Request 1
Response 1
Request 1+2+3
COLLAPSER
BACKEND
CLIENT
Request 2
Response 1+2+3
Response 2
Request 3
Response 3
Request redundancy
Pattern qui consiste envoyer une mme requte plusieurs systmes distincts afin dutiliser le
rsultat de la rponse la plus rapide. Le but est doptimiser le temps de rponse. Google lutilise
par exemple pour son moteur de recherche.
Request 1
x BACKEND
"REDUNDER"
Request 1
CLIENT
Request 1 Backends
Response 1 BACKEND identiques
x
Request 1
BACKEND
x
21
Request queuing
Pattern applicatif consistant mettre les requtes en attente afin dviter une surcharge du systme.
Netflix Hystrix, par exemple, le permet ct client. Ce pattern permet un couplage asynchrone, donc
plus faible, des deux parties. Ainsi, les deux parties sont moins couples en termes de disponibilit,
ce qui peut permettre dabsorber des dfaillances ou de faciliter le dploiement de mises jour.
Request 1 Request 1
Request 2 Response 1
BACKEND
CLIENT
QUEUE
Response 1 Request 2
Response 2 Response 2
Circuit breaker
En fonction dun certain nombre de critres derreur (timeout, nombre derreurs), ce pattern
permet de dsactiver lenvoi de requtes au Service 2 et de renvoyer immdiatement une rponse
alternative.
Il agit comme un proxy implmentant une machine tats (Ouvert, Passant (ferm), Semi-ouvert)
pour lapprentissage de ltat du service.
Service 1 Service 2
Rponse alternative
Rponse alternative
22 Rponse attendue
Seuil dchecs atteint

OUVERT
Lve une exception
Service 1 Service 2
Seuil temps
Un appel
dattente PASSANT
atteint Ajoute 23 aauchou
compte A A +=23 mais une exception
Si rsultat appel = OK
survient par la suite
Nombre checs = 0
SEMI-OUVERT
Si rsultat appel = KO
Si rsultat appel = OK Nombre checs ++
NombreAjoute
succs
23 ++
au compte A Message dj trait,
Lve une exception
Si rsultat appel = KO le traitement nest pas rappliqu
Nombre succs = 0
Appel a chou = vrai

Seuil de succs atteint
Service 1 Service 2
Rponse alternative
Rponse alternative
Idempotence
Une fois le service rtabli, la requte en chec peut potentiellement tre relance. Ceci nest
possible que Rponse attendue
si le Service 2 est capable dtre idempotent : n envois successifs de la mme
commande conduiront toujours au mme tat.
Il peut par exemple tre implment en conservant un identifiant unique pour chaque requte et
en ignorant les futures occurrences des requtes avec le mme identifiant.
Service 1 Service 2
Ajoute 23 au compte A A +=23 mais une exception

survient par la suite
23
Ajoute 23 au compte A Message dj trait,
le traitement nest pas rappliqu
Kiss (Keep it simple, stupid)

Principe qui prconise la simplicit dans la conception, notamment pour rduire les cots, faciliter
la comprhension, augmenter la fiabilit et limiter la maintenance.
Attention : certains patterns induisent de la complexit,

il convient donc den peser le pour et le contre.
OCTO > CLOUD READY APPS > DISPONIBLIT
99,99%
24
de dispo-
nibili+
25
99,99%
de disponibilit
CONCEVOIR
POUR LA DISPONIBILIT
viter les points uniques de dfaillance SPOF (Single Point Of Failure).

D
iviser lapplication en composants faiblement coupls.
C
oncentrer les tats persistants dans quelques composants scalables.
P
rvoir et grer les erreurs pour matriser leur propagation tout en conservant les traces
pour analyse.
Patterns: APIs, Microservices, Asynchronous data exchanges, Bulkheads, Idempotence,
Health check.
26
COMPOSER
AVEC LES DFAILLANCES
A
ccepter quen environnement fortement distribu, la probabilit derreur ne soit plus ngligeable.

tre capable de dtecter un composant dfaillant, et instancier tout moment le ou les composants
de lapplication pour rpondre aux pannes et retrouver un comportement nominal ou un niveau
dgrad acceptable.
Patterns : Pets vs. Cattle, Timeouts, Circuit Breakers, Fast Startup and Graceful Shutdown, Design
For Failure.
TESTER, TESTER, TESTER
prouver et entraner sa capacit grer les diffrents incidents de production pour une meilleure
ractivit lors des vritables incidents : crash dun processus, erreur systme, perte de serveur,
indisponibilit dune zone gographique du cloud, perte de lien rseau...
Patterns : Simian Army, Test dendurance, Test de robustesse.
Patterns
Design for failure

Les traitements applicatifs doivent, ds leur conception, prvoir le cas o les composants quils
appellent pourraient tomber en erreur. leur charge de grer au mieux ce cas en fournissant si
possible un service dgrad leur client.
Service 1 Service 2
Dtection des erreurs
27
Timeout
Temps dattente maximal pour chaque appel.
Ce principe gnral peut tre implment en utilisant les patterns des chapitres prcdents.
Service 1 Service 2
Pets versus Cattle

(lit. animaux de compagnie vs. btail). Les serveurs ne sont plus nomms Violette ou Anmone
mais par un identifiant unique (cow-xxx). Cette approche industrielle de gestion denvironnements
consiste ne plus nommer, rparer un serveur et le garder longtemps (Pet), mais systmatiquement
le dtruire et le recrer en cas de problme (Cattle).
ANMONE COW-346368
COW-670445
COW-543251
COW-104028
COW-418575
28 COW-546793
VS
VIOLETTE
Test dendurance
Test avec la charge cible du systme sur une longue dure afin didentifier les fuites de ressources
(ex. fuite mmoire).
Test de robustesse
Test avec la charge cible du systme durant lequel on dgrade volontairement une ressource afin
dprouver la robustesse du systme.
29
EXEMPLE
Exemple
dimplmentation
haute disponibilit
Votre application est dcoupe en micro- continent o un dploiement similaire
services, exposant chacun des API que peut tre ralis.
vous avez pris soin de rendre stateless et
en adquation avec les principes REST. Votre base de donnes est dploye sur
Ceci vous permet de pouvoir profiter sans RDS (2), une plateforme de Database
limites des outils de load balancing, de as a Service, qui offre nativement un
30
cache mcanisme de rplication.
Vous dployez votre application sur la Afin de garantir le dcouplage avec votre
plateforme IaaS Amazon EC2. Pour application, vous choisissez dimplmenter
atteindre une disponibilit de 99,99%: un pattern de communication asynchrone
au moyen de Amazon SQS. Celui-ci offre
Vous choisissez de dployer votre applica- une dcorrlation parfaite au prix dune
tion sur deux Availability Zones (AZ), qui plus grande complexit.
correspondent deux zones dun ou
plusieurs datacenters raisonnablement Aprs avoir tir profit au maximum des
espacs gographiquement pour quun possibilits des services AWS, limplmen-
incident ne les impacte pas simultanment. tation de patterns sera ncessaire pour
atteindre une disponibilit comme 99,99%.
Le composant ELB (3) vous permet Timeout et Circuit Breaker seront deux
de rpartir vos requtes vers les deux autres patterns applicatifs de haute dispo-
datacenters. La haute disponibilit de nibilit de type quick win.
ce service est directement assure par
AWS. Afin de lutiliser pleinement, votre Enfin, vous testez la robustesse de votre
application doit cependant exposer une systme en lanant un test grandeur nature
URL de health check (4). En fonction du (par exemple avec Simian Army (5)) qui va
retour de cette URL, le load balancer alatoirement supprimer vos instances
pourra bannir lune de vos instances. et sassurer que lapplication est toujours
fonctionnelle.
Le composant Route 53 permet doffrir
une garantie supplmentaire en tant
capable de rediriger le DNS sur un autre
4
your-app.com
Availibility zone 1 (route 53) Availibility zone 2
Instances Instances
API API
1
Autre 3
Microservice Amazon
SQS
5
2
Chaos
RDS Monkey
Multi-AZ RDS Multi-AZ RDS
Simian Army
31 1. API : 4. URL de health check :

Limiter le couplage entre services via une Un appel sur une URL de health check
API REST stateless est une bonne pratique va excuter un test pour sassurer quun
car cela permet de tirer parti facilement des composant rend correctement le service
outils de haute disponibilit dvelopps au- quil est cens remplir. Une erreur
dessus de HTTP (load balancing, cache). retourne par une URL de health check
sera notamment utilise pour indiquer
2. Database as a Service : un load balancer de ne plus envoyer
Les offres de cloud savent dsormais proposer de requtes sur ce composant. Metrics
des services de haut niveau comme une propose une implmentation en Java
base de donnes (service de type PaaS). En https://dropwizard.github.io/metrics/,
matire de haute disponibilit, la rplication healthchecks propose une implmentation
des donnes et les sauvegardes peuvent pour Express en Node.js https://github.
tre prises en charge par le service ce qui com/broadly/node-healthchecks
vite de devoir les r-implmenter.
5. Simian Army:
3. Asynchronous Data Exchanges : Ensemble doutils open source de Netflix
Lorsque la smantique mtier lautorise, pour prouver la stabilit de leur plate-
reposer sur des changes asynchrones forme sur AWS. Le plus connu est Chaos
permet de dcorrler les deux services. Monkey qui permet de tuer des serveurs
Ces changes asynchrones permettent par de manire alatoire. https://github.com/
exemple un mcanisme de reprise sur Netflix/SimianArmy
erreur. Ce type de dcouplage peut tre
implment en sappuyant sur un service
de message queuing tel que AWS SQS.
Garan+ir
lin+grit
et la
32
scuri+
33
OCTO > CLOUD READY APPS > INTGRIT ET SCURIT
Garantir
lintgrit et la scurit
PLACER LA SCURIT
AU BON NIVEAU
amener la scurit au plus proche du service et sappuyer sur des systmes de fdration pour
R
pouvoir garantir la scurit en environnement ouvert.
rivilgier la propagation du commettant (principal propagation) ou la dlgation dautorisation
P
lutilisation de comptes de services gnriques.
Patterns: Delegated authorization, principal propagation.
CONSERVER
34
TOUTES LES INTERACTIONS

F
aire de la traabilit mtier et technique une fonctionnalit de premier ordre du systme. Enrichir
les logs, les normaliser pour faciliter leur analyse.
P
rvoir par exemple des IDs de corrlation dans les changes pour pouvoir retracer des interactions
travers plusieurs systmes.
Patterns : Event sourcing, Correlation ID.
PENSER FIABILIT, INTGRIT

ET SCURIT
Utiliser bon escient les techniques de chiffrement au niveau du transport, des donnes et des
cls.
tre flexible sur les entres et strict sur les sorties (loi de Postel).
Si un modle de cohrence terme doit tre prfr aux transactions, veiller en matriser les
impacts sur lintgrit.
Patterns : Eventual consistency, Read Your Write consistency.
Patterns
Loi de Postel ou principe de robustesse

Citation de Jon Postel lun des pionniers dInternet. [Les implmentations de TCP] doivent suivre
un principe gnral : tre conservateur dans leurs implmentations, tre librale dans ce quelles
acceptent. Cela signifie que mme si certains messages ne sont pas strictement conformes la
spcification, tant quil ny a pas dambigut ils doivent pouvoir tre traits. Dans le monde du
cloud o les services utiliss sont trs nombreux, cela rduit le risque derreur.
Principal propagation
Mcanisme scuris permettant une application qui a authentifi un utilisateur de transmettre son
identit (le principal) un autre service.
35 1. Authentification.
2. Propagation du principal.
3. Validation du principal (ici il sagit dune dlgation dautorisation, le service 2 valide le principal
sur lidentity provider).
Service 1 Service 2
Principal
Principal
3
Identity provider
Delegated authorization (ou dlgation de droit daccs)

Mcanisme de dlgation de droits (par exemple le droit daccder vos emails) un service tiers
(offrant un nouveau type dinterface) par un mandant (celui qui dtient les droits, en loccurrence
vous pour votre compte email). Par exemple, une application de blog propose un bouton pour
tweeter sous votre nom. OAuth2 est une spcification permettant dimplmenter ce mcanisme.
Event sourcing
Pattern applicatif dans lequel lensemble des modifications du systme sont stockes sous forme
dvnements qui, une fois agrgs, donnent une vision consolide. Conserver les vnements
permet leur rejeu et leur analyse.
36
WRITE READ
A kind of business layer

(command, Domain Driver Design...)
STOCK
Mapping Layer
Events Dispatcher STOCK
Events Log
(list of events)
...
Correlation ID
Ajout dun identifiant dans chaque requte pour suivre une transaction de bout en bout dans le SI.
ID=42 ID=42 ID=42
20160614T17:47:50ID=42WARNING
37
Eventual consistency
En franais cohrence terme, dsigne un modle dans lequel la cohrence nest garantie
qu la fin la fin tant relative votre cas dutilisation. Lexemple dimplmentation le
plus connu de ce modle est le protocole DNS dans lequel les adresses sont jour une fois
toutes les propagations termines. Ce modle est particulirement important pour un stockage
distribu dans lequel la cohrence ne peut pas tre dfinie en permanence du fait des dlais de
propagation et des potentielles indisponibilits dun nud.
Read Your Write Consistency

Modle de cohrence dans lequel les modifications ne sont visibles qu terme globalement, mais
qui garantit que lapplication lorigine de la modification en voit les effets immdiatement.
Cohrence Read your write consistency
Lit 0 Ecrit+1 Lit 3 Lit 0 Ecrit+1 Lit 1 Lit 3
Lit 0 Ecrit+2 Lit 3 Lit 0 Ecrit+2 Lit 2 Lit 3

Dpl yer
facilemen+
frquem-
38
men+
39
RELEASE
OCTO > CLOUD READY APPS > DPLOYER
Dployer
facilement frquemment
AUTOMATISER POUR ALLER
PLUS VITE, SEREINEMENT
arantir la reproductibilit du dploiement en limitant lintervention humaine et en prouvant les
G
processus sur des environnements comparables la production, ds le dveloppement.
Patterns: Infrastructure as code, service discovery, containers.
DPLOYER
40
SANS ACCROC
G
arantir des changements de version plus transparents, jusquau Zero Downtime Deployment
au besoin, pour limiter au maximum les impacts nfastes sur les utilisateurs finaux tout en
apportant de la valeur.
P
artager les mmes mthodes, outils et objectifs du dveloppement la production.
Patterns : Tolerant reader, consumer driven contracts, multiversions services & backward
compatibility, feature flipping.
DPLOYER
TOUT LE TEMPS
Rduire le Time To Market et maximiser lagilit en livrant les fonctionnalits par petites itrations
frquentes.
Dsacraliser les mises en production.
Patterns : Infrastructure as code, strict separation of build and run stages, service discovery.
Patterns
Infrastructure as code
Code dcrivant linfrastructure cible de manire rptable et automatiquement sans intervention
humaine. Cette pratique offre une approche centralise, raliste et versionnable de linfrastructure.
Les fournisseurs de cloud proposent gnralement leurs propres outils linstar de CloudFormation
pour Amazon, qui viennent largir un panel doutils open source tels Ansible, Chef, Puppet ou
encore Terraform.
41
Service discovery
Mcanisme denregistrement et de dcouverte des services. Dans une infrastructure dynamique o
les services naissent et meurent pour rpondre la charge, il est important de leur permettre de
senregistrer dynamiquement pour tre connus de tous. Plusieurs solutions sont rpandues dans
ce domaine telles que Consul, Zookeeper, ETCD ou encore Eureka qui est intgre au framework
Spring Cloud Netflix.
Tolerant reader & consumer driven contract

Le principe est de veiller ce que le consommateur dun quelconque systme externe soit tolrant
lvolution du schma de donnes qui lui est expos. Ceci consiste prvoir des solutions
palliatives en cas de valeur non prvue, de valeur absente ou encore ne respectant pas le format
attendu (voir loi de Postel). Les navigateurs web par exemple sont trs tolrants par rapport des
carts la norme HTML.
Consumer Message accept Consumer Driven implementation

contract par un tolerant reader contract Implmentation adapte
au plus prs
42
Feature Flipping
Pattern applicatif permettant dactiver et de dsactiver une fonctionnalit chaud sans interruption
de service. Cela permet de dployer en production un composant sans en activer les nouvelles
fonctionnalits (pour des raisons lgales, pour les tester sur une population rduite, parce quelles
ne sont pas finalises, ). Des librairies permettent de faciliter la mise en uvre telle que FF4J en
Java qui apporte notamment une API et IHM pour contrler lactivation des fonctionnalits.
http://blog.octo.com/feature-flipping/
FEATURE 1 FEATURE 2 FEATURE 3 FEATURE 4
ON ON ON OFF
Backward compatibility
Gestion de version consistant viter toute modification qui empcherait lancien client de
fonctionner. Par exemple, les API utilises par des clients mobiles natifs doivent souvent maintenir
plusieurs versions car les diffrents devices ne se mettent pas tous jour simultanment.
Multiversion Service
Lenjeu dun service est dtre capable dvoluer sans entraner de rgression pour les consommateurs
existants. La mise en place dun versioning sur lAPI permet, lors dvolutions majeures, dexposer
un nouveau service tout en maintenant lexistant. Ce pattern est lourd en termes dimplmentation
et il faut veiller ce que notamment les schmas de donnes restent compatibles pour les deux
API. Attention prvoir galement un dcommissionnement des versions au fur et mesure pour
pousser les consommateurs voluer et rduire la charge de dveloppement associe.
43
Backward compatibility Multiversion services
API API V1 API V2
V1 V2 V1 V2
Zero-Downtime Deployment
Dploiement dune application sans interruption de service
http://blog.octo.com/zero-downtime-deployment/.
Exemple de procd permettant le Zero downtime deployment
Load balancer Load balancer Load balancer Load balancer
Appli Appli Appli Appli Appli Appli Appli Appli

V1 V1 V1 V2 V2 V2 V2 V2
44
Conteneur
Un conteneur est une image dune application et de ses dpendances. Un conteneur est plus lger
quune machine virtuelle tout en permettant une isolation entre applications et une faon simple de
dployer lapplication avec toutes ses dpendances.
Conteneur Docker
SERVICE SERVICE SERVICE
Userland (OS) Userland (OS) Userland (OS)
Init System
Userland (OS)
HOST KERNEL
SERVER
Docker Containerisation
Index des Patterns
Backward compatibility 43
Bulkhead 19, 20
Centralized monitoring 17
Circuit breaker 22
Continuous performance 18
Conteneur 44
Correlation ID 37
Delegated authorization 36
Design for failure 27
Event sourcing 36
Eventual consistency 37
Feature Flipping 42
Graceful degradation 18
45
Idempotence 23
Infrastructure as code 41
Kiss (Keep it simple, stupid) 23
Lambda architecture 19
Loi de Postel ou principe de robustesse 35
Microservices 09
Multiversion Service 43
Pets versus Cattle 28
Principal propagation 35
Read Your Write Consistency 37
Request collapsing 20
Request queuing 21
Request redundancy 21
Service discovery 41
Test dendurance 29
Test de robustesse 29
Timeout 27
Tolerant reader & consumer driven contract 42
Zero-Downtime Deployment 44
NOUS APPORTONS mthode
et expertise POUR, ENSEMBLE,
concevoir et repenser
LES APPLICA+IONS
SUR LE CLOUD
DU CODE A LA PRODUCTION.
NOUS GARANTISSONS AINSI,
srnit et excellence
PAR DES APPLICATIONS FIABLES,
PERFORMAN+ES
ET CONUES POUR tirer parti
des opportunits du cloud.
TRIBU CLOUD READY APP CHEZ OCTO

TECHNOLOGY
OCTO Technology
CABINET DE CONSEIL ET DE RALISATION IT
Nous croyons que linformatique transforme

nos socits. Nous savons que les ralisations
marquantes sont le fruit du partage des savoirs et
du plaisir travailler ensemble. Nous recherchons
en permanence de meilleures faons de faire.
THERE IS A BETTER WAY!
Manifeste OCTO Technology
310
2 FILIALES
PRODUITS
COLLABORATEURS
38M de CA
2015 (+39%)
5 IMPLANTATIONS OCTO EN TTE DU PALMARS CONFRENCE
> Paris 1er 2011

4X
1er 2012
> Rabat 2e 2013
2e 2015
> Lausanne
> So Paulo
ORGANISME DE FORMATION
> Sydney
Merci aux contributeurs :
Youri Antenor Habazac, Arnaud Btrmieux,
Marc Bojoly, Benjamin Brabant, Antonio Gomes
Rodrigues, Edouard Perret, Bormi Toch.
Merci aux relecteurs :

Laurent Brisse, Laurent Dutheil, Christian Faure,
Eric Fredj, Damien Joguet, Benjamin Joyen-Conseil,
Benot Lafontaine, Arnaud Mazin, Alexandre Raoul,
Franois-Xavier Vende.
Merci lquipe communication :

Caroline Bretagne, Joy Boswell, Nelly Grellier.
Dpot lgal : juin 2016

Conu, ralis et dit par OCTO Technology.
Imprim par IMPRO
98 Rue Alexis Pesnon, 93100 Montreuil
OCTO Technology 2016

Les informations contenues dans ce document prsentent le point de vue actuel
d'OCTO Technology sur les sujets voqus, la date de publication. Tout extrait
ou diffusion partielle est interdit sans l'autorisation pralable d'OCTO
Technology.
Les noms de produits ou de socits cits dans ce document peuvent tre les
marques dposes par leurs propritaires respectifs.
www.octo.com - blog.octo.com
PARIS I RABAT I LAUSANNE I SO PAULO I SYDNEY

2016 Octo WP Readyapp

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2016 Octo WP Readyapp

Загружено:

Авторское право:

Доступные форматы

CONCEVOIR VOS APPLICATIONS

POUR TIRER PARTI DU CLOUD

O2 Assurer sur la qualit de service ________________________ 16-25

O3 99,99% de disponibilit ________________________________________ 26-33

O4 Garantir intgrit et scurit ________________________________ 34-39

O5 Dployer frquemment et facilement ___________ 40-46

Les applications daujourdhui et leurs futures volutions

Pour en tirer profit et concevoir une application cloud ready,

Pour chacun, nous vous proposons un chapitre pour comprendre

Que vous conceviez, dveloppiez ou exploitiez des applications

Ces fiches se veulent des pistes de rflexion et non des

* Un pattern est une solution rptable et rutilisable un problme identifi.

XaaS (Anything As A Service) :

4 CaaS : Container as a Service

PaaS : Platform as a Service

SaaS : Software as a Service

BaaS : Back-end as a Service

Front-end Front-end Front-end Front-end Front-end

Back-end Back-end Back-end Back-end Back-end

Serveur Serveur Serveur Serveur Serveur

Stockage Stockage Stockage Stockage Stockage

Rseau Rseau Rseau Rseau Rseau

CHOISIR LE BON NIVEAU DABSTRACTION :

Microservice Microservice Microservice Microservice

6. DynamoDB : Service manag de base

5. Fast startup and graceful 1

SE HISSER SUR LES PAULES

Log/mtriques Log/mtriques Log/mtriques Log/mtriques

Attention : certains patterns induisent de la complexit,

Cycles ditrations agiles

Itration 1 Itration 2 Itration 3 Itration 4 Itration 5 Itration 6

Test Test Test Test

Gestion derreur standard Graceful degradation

CATALOGUE COMMANDE COMPTE CATALOGUE COMMANDE COMPTE

Service 1 Service 2 Service 3 Service 4

Seuil dchecs atteint

Appel a chou = vrai

Ajoute 23 au compte A A +=23 mais une exception

Kiss (Keep it simple, stupid)

Attention : certains patterns induisent de la complexit,

TESTER, TESTER, TESTER

Design for failure

Dtection des erreurs

Pets versus Cattle

31 1. API : 4. URL de health check :

TOUTES LES INTERACTIONS

PENSER FIABILIT, INTGRIT

Loi de Postel ou principe de robustesse

Delegated authorization (ou dlgation de droit daccs)

A kind of business layer

Events Dispatcher STOCK

ID=42 ID=42 ID=42

Read Your Write Consistency

Cohrence Read your write consistency

Lit 0 Ecrit+1 Lit 3 Lit 0 Ecrit+1 Lit 1 Lit 3

Lit 0 Ecrit+2 Lit 3 Lit 0 Ecrit+2 Lit 2 Lit 3

Tolerant reader & consumer driven contract

Consumer Message accept Consumer Driven implementation

FEATURE 1 FEATURE 2 FEATURE 3 FEATURE 4

Backward compatibility Multiversion services

API API V1 API V2

Exemple de procd permettant le Zero downtime deployment

Load balancer Load balancer Load balancer Load balancer