Devoxx france-2013-lecons-cloud

Le Cloud en pratique?
çà change vraiment tout …
©2012 Ifeelgoods, All rights reserved.

Le Cloud – Une Passion
Dali Kilani, VP Engineering @ IFeelGoods

Personnellement
Passionné de Cloud depuis le lancement de Amazon EC2 en 2006
Utilisateur régulier, Conseiller et Béta testeur de plusieurs services tels que
Azure, CloudFoundry, HP Cloud, Heroku, appFog, DotCloud, Parse, etc

Professionnellement
Ex-Zynga (CTO Farmville, 2010-11, Directeur Backend-aaS Jeux HTML5, 2012)
Ex-eBay (Product Manager du Programme Cloud, 2009)
Ex-Panologic (Directeur Technique, Solution Virtualization de Desktops dans
le Cloud, 2007-2009)

Tous les produits sur lesquels j’ai travaillé depuis 6 ans
n’existeraient pas sans le Cloud!
2

Le Cloud est réellement révolutionnaire
Ce n’est pas que du slogan Marketing …

Mais il faut s’assurer d’avoir :

Des Objectifs Business
Une Méthodologie
Des Technologies/Outils
Un Capital Humain
Une Organisation

Compatibles avec le Cloud!
3

Quelques (Fausses) Idées reçues sur le Cloud
« Je peux migrer mon infrastructure existante vers le Cloud en
lançant quelques machines chez Amazon » - FAUX

« Mon Admin Système qui a toujours géré mes serveurs me fera
migrer vers le cloud » - FAUX

« Mon Process de Mise en Production n’a pas besoin d’etre
revisité, ca fait 10 ans qu’on l’utilise avec succès! » - FAUX

« Le Cloud baissera le cout des serveurs d’Hébergement de mon
application » - FAUX

4

Etude de Cas - Farmville™


Farmville™ == Jeux Sociaux sur Facebook™ (en 2010)
Le plus gros jeu social sur Facebook de tous les temps
Le jeu qui a validé l’existence d’un marché lucratif du « jeu social »

6

Farmville™ - Quelques Chiffres …

•  32M de joueurs uniques/jour (DAU) au sommet de sa
popularité (3x la région parisienne!)
•  70M de joueurs uniques/mois (Toute la France et plus!)
•  200+M de joueurs ont essayé le jeu a un moment ou un autre
•  Croissance fulgurante : 0-32M joueurs/jour en 6 mois
•  Phase d’hyper-croissance : 1M de DAU en plus chaque semaine
en Février-Mars 2010

Impossible de prévoir un succès
aussi franc d’un jeu avant de le lancer!

Sans le Cloud, le jeu n’aurait jamais pu
servir autant de joueurs
7

Objectifs Business

•  Maintenir une qualité de service acceptable pour les joueurs
« coute que coute »
•  Faire en sorte que le contenu soit aussi « frais » que possible
•  Agilité maximum
•  Gérer les risques technologiques mais rester agressif
•  Minimiser l’impact de la fragilité de la plateforme Facebook

Des objectifs largement contradictoires …
à première vue

8

En pratique …
•  Le prix n’est pas important du moment qu’un joueur joue à tout
moment malgré l’affluence record

•  Mise en production aussi souvent que possible – idéalement
tous les jours

•  Le contenu d’une « release » peut changer le jour de la mise en
production

•  Faut faire un changement radical sur l’architecture d’un
module? On identifie les risques et les stratégies de repli mais
on le fait quand même

•  On adapte l’architecture pour que l’application continue a
tourner quand l’API Facebook a des problèmes
9

Comment s’organiser pour tenir ces objectifs?

Infrastructure
Méthodologie
Capital Humain
Organisation d’Equipe

10

Infrastructure – Tour d’Horizon

100% Amazon EC2
Stack :
PHP + MySQL + MemCache (Backend)
Flash + JS (Frontend)

Chiffres :
•  5000+ Serveurs Web
•  1000+ Serveurs MySQL
•  1000+ Serveurs Memcache
•  Des Centaines de serveurs pour des Queues/Workers/etc
•  10000 Volumes EBS pour les Bases de Données

11

Infrastructure – Leçons
Une instance est plus fragile qu’une machine physique

Une instance est (beaucoup) moins performante qu’une machine
physique au même prix

Redondance a tous les niveaux

Automatisation des opérations de maintenance

Les IOPS coutent cher, éviter d’écrire sur Disque autant que
possible

La mémoire est chère aussi

12

Méthodologies
4+ mises en production par semaine

Mise en production entre 15h et 17h pour les changements
routiniers, a 10h du matin pour les gros changements

Possibilité de changer ce qui va en production jusqu’à 4h avant
la release

Un cycle de QA complet tous les jours

QA manuelle au début mais largement automatisée depuis

Une branche de « release » peut devenir un « master »
temporaire de secours
13

Méthodologies - Leçons

La QA doit commencer tôt dans le cycle de développement

Plusieurs branches de développement simultanées

Automatiser la QA est un facteur clé

Une branche de « release » peut devenir un « master »
temporaire de secours

Toujours préparer la procédure de « rollback » et ne pas hésiter a
le faire

14

Equipe

Plutôt jeune avec quelques vétérans J

Les profils embauchés sont surtout des ingénieurs

polyvalents technologiquement.

Peu ont fait du PHP avant de rejoindre l’équipe.

Beaucoup n’avait jamais fait de développement Web.

12 Développeurs, 5 membres Equipe Opérationnelle + quelques
Admins Systèmes/ Admin Base de Donnée au niveau de la
compagnie

15

Equipe - Leçons

Donner de la liberté à l’équipe de lancer des instances sans
permission préalable

Tous les ingénieurs font un passage dans l’équipe Ops

Privilégier la polyvalence plutôt que la spécialisation

Privilégier la rigueur plutôt que l’expérience

Encourager la créativité (Hackathon thématique ou libre, etc)

Mettre physiquement les ingénieurs et les autres membres de
l ’équipe cote a cote. Encourager l’interaction entre les
fonctions.
16

Mais…

Je ne serais (probablement) pas confronté
à ces problématiques dans ma carrière…


Si!

Ces leçons s’appliquent a toutes les
organisations …


Etude de Cas - Ifeelgoods


Le slide Marketing obligatoire J


Flexible, Instant Digital Promotions

Consumers see Shares the
iTunes offer on iAd
successful offer

Completes Friends are clicking
a purchase
to get the offer

22

FIN

(de la parenthèse Marketing)


Objectifs Business

Itérations rapides

Agilité

Minimiser le cout humain de maintenance de l’infrastructure

Minimum de CAPEX

Tenir la charge si une campagne promotionnelle attire les foules

Objectifs alignés avec ce que le Cloud peut offrir
24

Décisions - Infrastructure

100% SaaS (Email/Productivité, Bug Tracking, Wiki, Source Control,
Gestion de Projet, Collection de Logs, Monitoring de
Performance, etc)

100% AWS (15 instances EC2, EBS, S3, Cloudfront, RDS)

Toutes nos instances peuvent être recréé en 10-15 mins, ajuster la
capacité du système prendrait 15 mins aussi.

Pas d’administrateur système, pas d’Administrateur de Base de
donné, pas d’IT

« EC2 Reserved Instances » achetées au bout de 18 mois pour les
instances statiques (Test&Dev, Base de Donnée, etc)
25

Décisions - Equipe

Partagée entre Paris, New York et San Francisco

Un mix de spécialistes et de généralistes

Une dizaine d’ingénieurs

Collaboration quotidienne entre Designer, Ingénieur et Product
Manager

Tous les métriques business sont partagés avec l’équipe

26

Décisions - Méthodologie

Mise en production aussi souvent que possible (~3 fois/semaine)

Large investissement dans l’automatisation de Tests

Un Sprint est planifié pour une semaine

Monitoring de performance et alertes en cas de problème sur
toutes les instances, les logs et dans l’application

Tout membre de l’équipe technique peut faire une mise en
production en un click

27

Merci


Devoxx france-2013-lecons-cloud

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Devoxx france-2013-lecons-cloud

Ähnlich wie Devoxx france-2013-lecons-cloud (20)

Devoxx france-2013-lecons-cloud