SlideShare une entreprise Scribd logo
Continuous	

   (Cloud) Costs Testing
                       	

10h40 - 11h30 - Salle E. Fitzgerald & L. Armstrong
Continuous Cloud Costs Testing	





             Nicolas Fonrose	

 Teevity Cloud Costs Analytics – Founder / CEO	

                      	

          @nfonrose / @teevity	

                                                    27 au 29 mars 2013
Nicolas Fonrose	

 •  Cloud geek, Startuper 	

  •  Pas mal d’années employé d’une boîte de conseil IT. Deux petites
        boites de conseil, créées ensuite.	

  •     Et ensuite, « l’aventure startup » J	

  	

 •  Teevity Cloud Costs Analytics	

  •  Objectif – aider les boites à utiliser le Cloud sans avoir à se soucier des
        complexités liées aux coûts (variables et complexes à optimiser)	

  •     Fonctionne sur AWS/AppEngine/Google BigQuery
(Petit) lexique du cloud	



 •  Instance (une VM)	

 •  Zone (approx. == datacenter)	

 •  Region (1 ensemble de 2 à 5 zones dans une partie du monde)	

  •  Europe, Asie, US-east, US-west	

 •  Web-storage (S3, Google Cloud Storage, Azure Blob Storage)
AVEC LE CLOUD, ESTIMER LES
COÛTS, C’EST COMPLIQUÉ !
Les grilles de prix sont publiques	




     Une grille de prix Cloud, ça
         ressemble à quoi ? 	

      Pas assez de place sur un slide pour montrer celle d’AWS. Loin s’en faut !
                Des 10k de lignes de JSON juste pour les prix AWS !
Estimation	




    Tout bouge. Et tout le temps 	

                                 !
         La grille de prix varie (très souvent – compétition entre CSP)
                     Des nouveaux services apparaissent
                De nouveaux concepts tarifaires apparaissent
             Le comportement du service fourni par le CSP varie
War stories	



QUELQUES HISTOIRES DE COÛTS
Quand la théorie devient réalité …	




     Violent changement de prix
      pour AppEngine en 2011 	

       Largement expliqué et justifié par Google, mais ça fait mal quand même !
     Certains utilisateurs ont vu leur facture faire *20. Il a fallu sacrément optimiser
Des fois, de très bonnes nouvelles	



  AWS S3 price change (-15%, merci Google)	

   AWS Glacier (10* moins cher; enfin presque)	

 AWS DynamoDB price change (-85% !)	

           Super nouvelles ! Mais aussi des hypothèses à revoir !
D’autre fois, des moins bonnes	




     Une région AWS, ça crache
                             	

           Et en entier (toutes les AZ)
                                      	

       On doit faire du multi-région pour avoir une très haute disponibilité
Des services qui changent	




       Le DataStore AppEngine
           passe en HDR 	

    Hello « eventual consistency » on reads
                                          	

           Impact sur l’architecture de certaines applications
Des « non-conformités »	




          Heroku / RapGenius
                           	

     Class action lancée contre Heroku 	

                                       !
      Non seulement pas bon pour les porte-monnaies des clients Heroku
               Mais mauvais de manière générale pour le PaaS
Cloud Costs Savings Tips
LES 4 CATÉGORIES	

Architectes, Développeurs, Devops, vos actions ont
un impact important sur le coût !	





                                                     27 au 29 mars 2013
Categories	




 •  « Software architecture » tips	

 •  « Automation » tips (devops et scripting)	

 •  « Buying strategies »	

 •  « Right-sizing » (allocated vs consumed)
SOFTWARE ARCHITECTURES
COST DRIVEN DESIGN
Architecture logicielle	



     L’élément le plus important !	

      Impossible de profiter des options qui
    rendent « cost-efficient » vos applications
     sans une architecture logicielle adaptée
Les clés du « cost driven » - 1/2	




    Modularité	

    Séparer les problématiques	

    Pour pouvoir allouer les différents traitements à l’endroit le plus pertinent
Les clés du « cost driven » - 2/2	




    Elastic-driven	

    Instances == Resources (!= Serveurs)	

    Compatibilité de l’architecture avec l’apparition/disparition (violente) de hardware
Et le « hardware »	




     Le choix du « Hardware » (virtuel)
     est bien sûr toujours important	

  Mais c’est le software qui prend le lead. Le Hardware est juste là pour servir les besoins du soft.
          Et on peut maintenant changer de « Hardware » comme on change de chemise.
Cost-driven architectures (et auto-scaling driven architectures)	



ARCHITECTURES CLOUD-COSTS
EFFICIENTS : DES EXEMPLES !
Architecture logicielle et coûts cloud	





 Exemple 1	

 Site Web sans serveurs
Ex 1 - Site Web sans aucun serveur !	



   Site Web entièrement hébergés
         sur un Web-Storage	

                                     	

                                     	

                               JS côté Client / 	

                  Des batch qui updatent le contenu (lancés
                             périodiquement) /	

                       Discuss pour les commentaires
Ex 1 - Site Web sans aucun serveur !	




  Le DNS masque totalement le Web storage	

         Compatible avec les CDN	

                                    	

           Aussi applicable à certaines API de ces sites Web
Architecture logicielle et coûts cloud	





 Exemple 2	

 Une application SaaS au régime
Ex 2 - Application SaaS au régime	



      Une application SaaS avec
      beaucoup de requêtes en 
        lecture par les clients	

      Application Web/Destkop/Mobile
Ex 2 - Application SaaS au régime	



                Régime minceur	

      On pousse des copies des données 
        statiques vers un Web store	

                                      	

        Adapter le rythme en fonction de la nature de l’application
Ex 2 - Application SaaS au régime	


                     Compute
                     Instances


                                               on
                                               update




                                 Web Storage




                     Integrated
                     web servers
Ex 2 - Application SaaS au régime	



         Ça marche aussi pas mal pour 
    tout ou partie d’applications « métier » 
     plus classiques (pas que pour les Dropbox like)	

                                        	

                   Ca dépend de leur nature transactionnelle, 
          et de la durée acceptable des copies de données côté client	

                                        	

                       Raisonnement applicable aux API
Ex 2 - Et la sécurité ?	



        Comment on gère les
       autorisations d’accès ?
         S3 Bucket Policy / adresse IP cliente ? Bof … L
         S3 Bucket Policy / headers HTTP ? Mieux J
         Auto-signed URLs ? Fabuleux J
Ex 2 - Et la sécurité ?	


               Auth
                +
               GET signed URL   Compute
                                Instances


                                                          on
                                                          update




                                            Web Storage




                                Integrated
                                web servers
Ex 2 – Cadeau «bonux» orienté Média	




    Amazon S3 supporte Bittorrent !
         Permet de fortement réduire la facture si beaucoup
            de personnes chargent les mêmes données
                Streaming de musique par exemple
Architecture logicielle et coûts cloud	





 Exemple 3	

 Communication B2B au régime
Ex 3 - Application SaaS et upload	




      Application SaaS avec gros
    volume de données en upload	

         Classique en scénario B2B
Ex 3 - Application SaaS et upload
Ex 3 - Application SaaS et upload	



    Donc là aussi, zéro serveur (ou presque),
  c’est possible. Et c’est même mieux (sécurité,
                  scalabilité, …) !	

                                   	

           Il faut quand même souvent des serveurs en batch
                  pour traiter le contenu en asynchrone
Ex 3 - Application SaaS et upload
Ex 3 - Intégration Amazon / IMDB
Architecture logicielle et coûts cloud	




 Exemple 4	

 Application avec des traitements asynchrones
 lourds
Ex 4 – Traitements asynchrones	



      Beaucoup de traitements
        asynchrones lourds ?	

               Des batchs classiques	

        Du processing de photos (vignettes)	

         De l’analyse de données (big data)
Ex 4 – Traitements asynchrones
Ex 4 – Traitements asynchrones	



              Actions périodiques ?	

    Même pas besoin de laisser tourner une
         instance avec un CRON !	

                                         	

   On peut définir des « scheduled-actions » directement dans AWS (CRON interne)
Architecture logicielle et coûts cloud	




 Un contre-exemple maintenant !	

 Malgré l’architecture, dans certains cas, on
 peut quand même arriver à tourner « cheap »
Ex 5 – Le contre-exemple	



  « Web-cache / CDN » en frontal	

        Fonctionne aussi pour les applications
           (quelque soit leur architecture)	

                                              	

 Evidemment pas applicable à toutes les applications (nécessite Web+REST). Ne marche que
                   pour les Reads, pas pour les Writes (pour l’instant)	

      Solution externe à l’application : le cache peut être chez un fournisseur (AWS) et
                           l’application chez un autre (AppEngine) !
Ex 5 – « Web-cache/CDN » frontal
Indispensables pour pouvoir expérimenter les différentes stratégies	



AUTOMATION, SCRIPTING
DEVOPS
Ne pas « pétrifier » son infrastructure	




  Création infra cloud « à la main »
       == infra cloud statique	

       Ça prend du temps, sujet aux erreurs. Donc on la modifie rarement.
Fluide comme du code	



  Scripting == infrastructure fluide	

             Infrastructure As Code	

                        	

          Tester une nouvelle configuration d’infrastructure ==
        Changer des paramètres dans des fichiers de conf / scripts


       Vous êtes libre d’expérimenter car « pas risqué » et « rapide »
Facilite le changement de CSP	




 Important y compris pour pouvoir
    changer/tester d’autres CSP	

      Scripting avec une meta API (Scalr/RightScale par exemple) pour pouvoir
            porter sur un autre fournisseur très rapidement (AWS - GCE)
Corrélations « action-to-cost »	



      Intégration des actions sur
  l’infrastructure dans la boucle de
             cost-feedback	

            Systématise la traçabilité des changements de configuration d’infra
                   Permet de faire des corrélations entre changements
                      dans l’infrastructure et impact sur les coûts
RIGHT-SIZING
« Right-sizer »	



             Ne pas allouer plus que
              ce dont on a besoin	

                         Ça paraît évident …	

    Et pourtant, la source d’économie la plus grosse constatée chez les utilisateurs IaaS.
     Les freins au right-sizing ? Architecture non elastic-driven / Infrastructure statique
                                      = Il faut scripter !
« Right-sizer » avec les PaaS	



       Normalement transparent
           avec les PaaS	

  Finalement pas si trivial que ça même en PaaS	

         Voir les fameuses histoires de coûts du début de la présentation
Les stratégies d’achats de resources Cloud	



BUYING STRATEGIES
Pas encore très développé	





 Disponible pour AWS uniquement	

              Pour l’instant
AWS Reserved Instances (RI)	



        « Acheter les soldes »	

       Pour 150€, vous avez -30% sur les 
    « t-shirts noirs tailles 38 pour femme »
                  pendant 1 an	

                                    	

            Attention ! Ne s’applique pas aux t-shirts gris
Instances réservées – break even	





           6 mois                  16 mois	

           (light)	

   9 mois	

     (heavy)	

                        (medium)
AWS Spot instances	



            « Acheter aux enchères »	

                                 Spot Instances	

                                                	

                        Stratégies proches du trading : Bid, Outbid, …	

                Les machines peuvent être reprises à tout moment par AWS !	

                                                	

                             Pas uniquement réservé aux batchs.	

  Ex : Ajouter des instances derrière un load-balancer pour améliorer les perfs à faible coût
Spot instances
Qui se charge des stratégies d’achat ?	




       Pas vraiment un truc de
     développeur et d’architecte	

                                          	

       Pas encore clair dans les entreprises de savoir à qui revient ce rôle	

                  Equipes DevOps / DSI / Direction financière ?
Comme pour les performances, la qualité, c’est la seule manière de s’améliorer	



COST FEEDBACK
Cost feedback	




    On ne peut améliorer que ce
           qu’on mesure	

     Les Dev/Architectes ont rarement le nez sur la facture (quand ils y ont accès)
                      Pas de feedback == on travaille dans le noir
Cost feedback loop	



   Netflix pousse vers ses équipes
   de Dev leur « consommé de la
       semaine précédente »	

     Pas forcément pour améliorer la « cost efficiency » de l’application au runtime
Cost feedback loop	



   Naturel d’avoir la même chose 
    en prod/integration/qualif/…	

                Surveillance de la marge par tenant, …
                 Notion de ‘cost optimization’ continue
         Surveillance des changements tarifaires non anticipés
                      Surveillance du right-sizing
Le feedback, en continue et de manière industrielle	



CONTINUOUS COST TESTING
Objectif	



   Donner aux équipes du feedback en
    continu sur « l’efficacité coût » du
    système qu’elles créent/déploient	

              Pour éviter les dérives liées aux évolutions du code / de l’archi
       Pour éviter les dérives liées aux évolutions de l’infrastructure du fournisseur
Exemple de dérive – true story	


      Un développeur déplace quelques lignes 
         de code qui implique des boucles	


 è L’application envoie 10.000* plus de
  messages dans une file pour le même
            traitement. Oups !
             Gros changement dans la facture en fin de mois
« Last run » vs « Previous run »	


 Je veux ça dans
 mon inbox tous
 les matins !	



  En bleu : Last run
  En rose : Previous run
  Unité : $ (USD)
  Echelle : peu importe/
Comment on fait ça ?	




       De quelles informations 
           a-t-on-besoin ?
Le coût du dernier « tir »	



   Données sur le coûts et l’usage	

                     Evidemment !

         Comment on les récupère ? Ça dépend du Cloud provider ...
         Pour la méthode d’accès aux données, et pour leur format
GET /costs – AWS Programmatic Billing
GET /costs – AppEngine ‘HTTP headers cost/req’	


 X-AppEngine-Resource-Usage: ms=293 cpu_ms=500 api_cpu_ms=236
 X-AppEngine-Estimated-CPM-US-Dollars: $0.012320




        Présent dans les headers HTTP de retour
          Il faut naviguer sur son application en
         étant connecté en admin sur la console
                   appengine pour les voir
GET /costs – Teevity API – ‘cost snapshot’	

 	

 	

 PUT	

     	

http://api.teevity.com/	

     	

 	

cloudcost/	

     	

 	

costAndUsageSnapshot/	

     	

 	

forCloudServiceId/	

     	

 	

50243203420423	

 ⇒ { snapshotId:582452432342234 }	

 	

 GET	

     	

http://api.teevity.com/
     	

 	

cloudcost/
     	

 	

costAndUsageSnapshot/
     	

 	

582452432342234
GET /costs – Teevity API – ‘cost snapshot diff’	

 	

 	

 GET	

     	

http://api.teevity.com/	

     	

 	

cloudcost/	

     	

 	

costAndUsageSnapshotDifference/	

     	

 	

withInitial/582452432342234/	

     	

 	

and/5915536323421748
Schéma global
Difficulté	



       Décalage temporel entre
     exécution et disponibilité des
          données de coûts 	

               Vous pouvez compter plusieurs heures de décalage.
         Pour l’instant, très difficile d’avoir un feedback quasi temps-réel
Difficulté – le contournement	



   On fait tourner les tests sur des
   périodes de temps bien définies	

         En isolation d’autres activités	

                                     	

       Sur un autre environnement Cloud (autre compte, autre appId)
Le coût ok. Mais la qualité ?	



            Ça ne suffit pas !	

   C’est la « cost efficiency » qui nous
      intéresse, pas le coût absolu
               On a besoin d’autres données
Mesure de cost-efficiency	




 Informations de perf (nb trans/sec)	

    Combien de transactions ont été
      réalisées par unité de coût
Mesure de cost-efficiency (suite)	




                Informations de QoS	

                    Latence notamment
   Point important ! Vous pouvez économiser beaucoup en arrêtant/lançant des instances
                  fréquemment. Mais l’impact sur la latence est important.
Schéma global
Conclusion
Dans le cloud …	



         Vos décisions ont un 
       impact réel sur les coûts  	

    Un nouveau challenge pour les techos 	

                                         !
      Et on commence juste à découvrir les bonnes pratiques pour le relever
Teevity Cloud Costs
     Analytics
d
d
d

Contenu connexe

Tendances

Track 2- Atelier 4 - Architecturez pour de la haute disponibilité
Track 2- Atelier 4 - Architecturez pour de la haute disponibilitéTrack 2- Atelier 4 - Architecturez pour de la haute disponibilité
Track 2- Atelier 4 - Architecturez pour de la haute disponibilité
Amazon Web Services
 
Un Voyage dans le Cloud: Qu'est-ce que AWS?
Un Voyage dans le Cloud: Qu'est-ce que AWS?Un Voyage dans le Cloud: Qu'est-ce que AWS?
Un Voyage dans le Cloud: Qu'est-ce que AWS?
Amazon Web Services
 
Track 2 - Atelier 2 - Introduction à redshift
Track 2 - Atelier 2 - Introduction à redshiftTrack 2 - Atelier 2 - Introduction à redshift
Track 2 - Atelier 2 - Introduction à redshift
Amazon Web Services
 
AWS Summit Paris - Track 3 - Session 1 - IoT Partie 1 - Connectez vos objets ...
AWS Summit Paris - Track 3 - Session 1 - IoT Partie 1 - Connectez vos objets ...AWS Summit Paris - Track 3 - Session 1 - IoT Partie 1 - Connectez vos objets ...
AWS Summit Paris - Track 3 - Session 1 - IoT Partie 1 - Connectez vos objets ...
Amazon Web Services
 
AWS Paris Summit 2014 - T1 - Introduction à Amazon EC2
AWS Paris Summit 2014 - T1 - Introduction à Amazon EC2AWS Paris Summit 2014 - T1 - Introduction à Amazon EC2
AWS Paris Summit 2014 - T1 - Introduction à Amazon EC2
Amazon Web Services
 
AWS Paris Summit 2014 - T1 - Services de bases de données
AWS Paris Summit 2014 - T1 - Services de bases de donnéesAWS Paris Summit 2014 - T1 - Services de bases de données
AWS Paris Summit 2014 - T1 - Services de bases de données
Amazon Web Services
 
4D Summit Europe 2016 - Conférence d'A&C Consulting : "Stocker des données su...
4D Summit Europe 2016 - Conférence d'A&C Consulting : "Stocker des données su...4D Summit Europe 2016 - Conférence d'A&C Consulting : "Stocker des données su...
4D Summit Europe 2016 - Conférence d'A&C Consulting : "Stocker des données su...
Nathalie Richomme
 
AWS Summit Paris - Track 4 - Session 3 - Créez votre SaaS avec AWS
AWS Summit Paris - Track 4 - Session 3 - Créez votre SaaS avec AWSAWS Summit Paris - Track 4 - Session 3 - Créez votre SaaS avec AWS
AWS Summit Paris - Track 4 - Session 3 - Créez votre SaaS avec AWS
Amazon Web Services
 
Gibtalk aws
Gibtalk awsGibtalk aws
Gibtalk aws
meliphen
 
AWS Paris Summit 2014 - T3 - Evolution des architectures VPC
AWS Paris Summit 2014 - T3 - Evolution des architectures VPCAWS Paris Summit 2014 - T3 - Evolution des architectures VPC
AWS Paris Summit 2014 - T3 - Evolution des architectures VPC
Amazon Web Services
 
Présentation des services AWS
Présentation des services AWSPrésentation des services AWS
Présentation des services AWS
Julien SIMON
 
Amazon Web Service par Bertrand Lehurt - 11 mars 2014
Amazon Web Service par Bertrand Lehurt - 11 mars 2014Amazon Web Service par Bertrand Lehurt - 11 mars 2014
Amazon Web Service par Bertrand Lehurt - 11 mars 2014
SOAT
 
AWS Summit Paris - Track 3 - Session 2 - IoT Partie 2 - Mettez en place l'inf...
AWS Summit Paris - Track 3 - Session 2 - IoT Partie 2 - Mettez en place l'inf...AWS Summit Paris - Track 3 - Session 2 - IoT Partie 2 - Mettez en place l'inf...
AWS Summit Paris - Track 3 - Session 2 - IoT Partie 2 - Mettez en place l'inf...
Amazon Web Services
 
Présentation d'Amazon Web Services - Human Talks Grenoble
Présentation d'Amazon Web Services - Human Talks GrenoblePrésentation d'Amazon Web Services - Human Talks Grenoble
Présentation d'Amazon Web Services - Human Talks Grenoble
Bastien Libersa
 
Track 1 - Atelier 3 - Implémentation de cloud d'entreprise par Edifixio
Track 1 - Atelier 3 - Implémentation de cloud d'entreprise par EdifixioTrack 1 - Atelier 3 - Implémentation de cloud d'entreprise par Edifixio
Track 1 - Atelier 3 - Implémentation de cloud d'entreprise par Edifixio
Amazon Web Services
 
Un Voyage dans le Cloud - Dev & Test
Un Voyage dans le Cloud - Dev & Test Un Voyage dans le Cloud - Dev & Test
Un Voyage dans le Cloud - Dev & Test
Amazon Web Services
 
Français Canadien Virtual AWSome Day - 2018
Français Canadien Virtual AWSome Day - 2018Français Canadien Virtual AWSome Day - 2018
Français Canadien Virtual AWSome Day - 2018
Amazon Web Services
 
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Amazon Web Services
 
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
 
Présentation evénement AWS - 13 oct 2015
Présentation evénement AWS  - 13 oct 2015 Présentation evénement AWS  - 13 oct 2015
Présentation evénement AWS - 13 oct 2015
ABC Systemes
 

Tendances (20)

Track 2- Atelier 4 - Architecturez pour de la haute disponibilité
Track 2- Atelier 4 - Architecturez pour de la haute disponibilitéTrack 2- Atelier 4 - Architecturez pour de la haute disponibilité
Track 2- Atelier 4 - Architecturez pour de la haute disponibilité
 
Un Voyage dans le Cloud: Qu'est-ce que AWS?
Un Voyage dans le Cloud: Qu'est-ce que AWS?Un Voyage dans le Cloud: Qu'est-ce que AWS?
Un Voyage dans le Cloud: Qu'est-ce que AWS?
 
Track 2 - Atelier 2 - Introduction à redshift
Track 2 - Atelier 2 - Introduction à redshiftTrack 2 - Atelier 2 - Introduction à redshift
Track 2 - Atelier 2 - Introduction à redshift
 
AWS Summit Paris - Track 3 - Session 1 - IoT Partie 1 - Connectez vos objets ...
AWS Summit Paris - Track 3 - Session 1 - IoT Partie 1 - Connectez vos objets ...AWS Summit Paris - Track 3 - Session 1 - IoT Partie 1 - Connectez vos objets ...
AWS Summit Paris - Track 3 - Session 1 - IoT Partie 1 - Connectez vos objets ...
 
AWS Paris Summit 2014 - T1 - Introduction à Amazon EC2
AWS Paris Summit 2014 - T1 - Introduction à Amazon EC2AWS Paris Summit 2014 - T1 - Introduction à Amazon EC2
AWS Paris Summit 2014 - T1 - Introduction à Amazon EC2
 
AWS Paris Summit 2014 - T1 - Services de bases de données
AWS Paris Summit 2014 - T1 - Services de bases de donnéesAWS Paris Summit 2014 - T1 - Services de bases de données
AWS Paris Summit 2014 - T1 - Services de bases de données
 
4D Summit Europe 2016 - Conférence d'A&C Consulting : "Stocker des données su...
4D Summit Europe 2016 - Conférence d'A&C Consulting : "Stocker des données su...4D Summit Europe 2016 - Conférence d'A&C Consulting : "Stocker des données su...
4D Summit Europe 2016 - Conférence d'A&C Consulting : "Stocker des données su...
 
AWS Summit Paris - Track 4 - Session 3 - Créez votre SaaS avec AWS
AWS Summit Paris - Track 4 - Session 3 - Créez votre SaaS avec AWSAWS Summit Paris - Track 4 - Session 3 - Créez votre SaaS avec AWS
AWS Summit Paris - Track 4 - Session 3 - Créez votre SaaS avec AWS
 
Gibtalk aws
Gibtalk awsGibtalk aws
Gibtalk aws
 
AWS Paris Summit 2014 - T3 - Evolution des architectures VPC
AWS Paris Summit 2014 - T3 - Evolution des architectures VPCAWS Paris Summit 2014 - T3 - Evolution des architectures VPC
AWS Paris Summit 2014 - T3 - Evolution des architectures VPC
 
Présentation des services AWS
Présentation des services AWSPrésentation des services AWS
Présentation des services AWS
 
Amazon Web Service par Bertrand Lehurt - 11 mars 2014
Amazon Web Service par Bertrand Lehurt - 11 mars 2014Amazon Web Service par Bertrand Lehurt - 11 mars 2014
Amazon Web Service par Bertrand Lehurt - 11 mars 2014
 
AWS Summit Paris - Track 3 - Session 2 - IoT Partie 2 - Mettez en place l'inf...
AWS Summit Paris - Track 3 - Session 2 - IoT Partie 2 - Mettez en place l'inf...AWS Summit Paris - Track 3 - Session 2 - IoT Partie 2 - Mettez en place l'inf...
AWS Summit Paris - Track 3 - Session 2 - IoT Partie 2 - Mettez en place l'inf...
 
Présentation d'Amazon Web Services - Human Talks Grenoble
Présentation d'Amazon Web Services - Human Talks GrenoblePrésentation d'Amazon Web Services - Human Talks Grenoble
Présentation d'Amazon Web Services - Human Talks Grenoble
 
Track 1 - Atelier 3 - Implémentation de cloud d'entreprise par Edifixio
Track 1 - Atelier 3 - Implémentation de cloud d'entreprise par EdifixioTrack 1 - Atelier 3 - Implémentation de cloud d'entreprise par Edifixio
Track 1 - Atelier 3 - Implémentation de cloud d'entreprise par Edifixio
 
Un Voyage dans le Cloud - Dev & Test
Un Voyage dans le Cloud - Dev & Test Un Voyage dans le Cloud - Dev & Test
Un Voyage dans le Cloud - Dev & Test
 
Français Canadien Virtual AWSome Day - 2018
Français Canadien Virtual AWSome Day - 2018Français Canadien Virtual AWSome Day - 2018
Français Canadien Virtual AWSome Day - 2018
 
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
 
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...
 
Présentation evénement AWS - 13 oct 2015
Présentation evénement AWS  - 13 oct 2015 Présentation evénement AWS  - 13 oct 2015
Présentation evénement AWS - 13 oct 2015
 

En vedette

2014oct10 : La gestion de projet chez COMPUTERLAND
2014oct10 : La gestion de projet chez COMPUTERLAND2014oct10 : La gestion de projet chez COMPUTERLAND
2014oct10 : La gestion de projet chez COMPUTERLAND
Patricia NENZI
 
Chopra3 ppt ch01
Chopra3 ppt ch01Chopra3 ppt ch01
Chopra3 ppt ch01
Nilesh Jugurnath
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
Ghodhbane Mohamed Amine
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
Mohammed Amine Mostefai
 
Cycle de vie d’un logiciel
Cycle de vie d’un logicielCycle de vie d’un logiciel
Cycle de vie d’un logiciel
Mehdi Abed
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
Rabia AZIZA
 

En vedette (6)

2014oct10 : La gestion de projet chez COMPUTERLAND
2014oct10 : La gestion de projet chez COMPUTERLAND2014oct10 : La gestion de projet chez COMPUTERLAND
2014oct10 : La gestion de projet chez COMPUTERLAND
 
Chopra3 ppt ch01
Chopra3 ppt ch01Chopra3 ppt ch01
Chopra3 ppt ch01
 
Modèle en cascade
Modèle en cascadeModèle en cascade
Modèle en cascade
 
Cours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vieCours Génie Logiciel - Cours 2 - Cycles de vie
Cours Génie Logiciel - Cours 2 - Cycles de vie
 
Cycle de vie d’un logiciel
Cycle de vie d’un logicielCycle de vie d’un logiciel
Cycle de vie d’un logiciel
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 

Similaire à Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03

TechDays 2014 : retour d'expérience Kompass migration Java dans Azure
TechDays 2014 : retour d'expérience Kompass migration Java dans AzureTechDays 2014 : retour d'expérience Kompass migration Java dans Azure
TechDays 2014 : retour d'expérience Kompass migration Java dans Azure
Thomas Conté
 
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
Amazon Web Services
 
Patterns Windows Azure
Patterns Windows AzurePatterns Windows Azure
Patterns Windows Azure
Microsoft
 
JUG Summer Camp (Sep 2011) - Les applications et architectures d’entreprise d...
JUG Summer Camp (Sep 2011) - Les applications et architectures d’entreprise d...JUG Summer Camp (Sep 2011) - Les applications et architectures d’entreprise d...
JUG Summer Camp (Sep 2011) - Les applications et architectures d’entreprise d...
Michaël Figuière
 
"J'ai migré mon SI intégralement en Java dans Windows Azure et je me porte bi...
"J'ai migré mon SI intégralement en Java dans Windows Azure et je me porte bi..."J'ai migré mon SI intégralement en Java dans Windows Azure et je me porte bi...
"J'ai migré mon SI intégralement en Java dans Windows Azure et je me porte bi...
Microsoft
 
Architectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythmeArchitectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythme
Microsoft
 
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Ori Pekelman
 
Presentation mididulibrev2.0
Presentation mididulibrev2.0Presentation mididulibrev2.0
Presentation mididulibrev2.0
robertpluss
 
Serverless avec Azure Functions & Logic Apps
Serverless avec Azure Functions & Logic AppsServerless avec Azure Functions & Logic Apps
Serverless avec Azure Functions & Logic Apps
Samir Arezki ☁
 
Les clouds, du buzz à la vraie science
Les clouds, du buzz à la vraie scienceLes clouds, du buzz à la vraie science
Les clouds, du buzz à la vraie science
Frederic Desprez
 
Devforumfrancois Tonic
Devforumfrancois TonicDevforumfrancois Tonic
Devforumfrancois Tonic
GreenIvory
 
Cloud Computing : enjeux pour les DSI
Cloud Computing : enjeux pour les DSICloud Computing : enjeux pour les DSI
Cloud Computing : enjeux pour les DSI
Stor Solutions
 
Transforming Enterprise IT - French Version - Transformation Day Montreal 2018
Transforming Enterprise IT - French Version - Transformation Day Montreal 2018Transforming Enterprise IT - French Version - Transformation Day Montreal 2018
Transforming Enterprise IT - French Version - Transformation Day Montreal 2018
Amazon Web Services
 
Introduction au cloud computing
Introduction au cloud computingIntroduction au cloud computing
Introduction au cloud computing
Stéphane Traumat
 
XebiCon'17 : Serverless is the new back - Jérémy Pinsolle et Gérôme Egron
XebiCon'17 : Serverless is the new back - Jérémy Pinsolle et Gérôme EgronXebiCon'17 : Serverless is the new back - Jérémy Pinsolle et Gérôme Egron
XebiCon'17 : Serverless is the new back - Jérémy Pinsolle et Gérôme Egron
Publicis Sapient Engineering
 
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir ArezkiGab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Samir Arezki ☁
 
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir ArezkiGab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
AZUG FR
 
20120402 nantes gtug - app engine
20120402   nantes gtug - app engine20120402   nantes gtug - app engine
20120402 nantes gtug - app engine
GDG Nantes
 
[Tuto] Web burst : Débordement Web vers Windows Azure
[Tuto] Web burst : Débordement Web vers Windows Azure[Tuto] Web burst : Débordement Web vers Windows Azure
[Tuto] Web burst : Débordement Web vers Windows Azure
Microsoft Technet France
 

Similaire à Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03 (20)

TechDays 2014 : retour d'expérience Kompass migration Java dans Azure
TechDays 2014 : retour d'expérience Kompass migration Java dans AzureTechDays 2014 : retour d'expérience Kompass migration Java dans Azure
TechDays 2014 : retour d'expérience Kompass migration Java dans Azure
 
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
 
Patterns Windows Azure
Patterns Windows AzurePatterns Windows Azure
Patterns Windows Azure
 
JUG Summer Camp (Sep 2011) - Les applications et architectures d’entreprise d...
JUG Summer Camp (Sep 2011) - Les applications et architectures d’entreprise d...JUG Summer Camp (Sep 2011) - Les applications et architectures d’entreprise d...
JUG Summer Camp (Sep 2011) - Les applications et architectures d’entreprise d...
 
"J'ai migré mon SI intégralement en Java dans Windows Azure et je me porte bi...
"J'ai migré mon SI intégralement en Java dans Windows Azure et je me porte bi..."J'ai migré mon SI intégralement en Java dans Windows Azure et je me porte bi...
"J'ai migré mon SI intégralement en Java dans Windows Azure et je me porte bi...
 
Architectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythmeArchitectures et application hybrides selon vos termes et à votre propre rythme
Architectures et application hybrides selon vos termes et à votre propre rythme
 
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
 
Presentation mididulibrev2.0
Presentation mididulibrev2.0Presentation mididulibrev2.0
Presentation mididulibrev2.0
 
Serverless avec Azure Functions & Logic Apps
Serverless avec Azure Functions & Logic AppsServerless avec Azure Functions & Logic Apps
Serverless avec Azure Functions & Logic Apps
 
Les clouds, du buzz à la vraie science
Les clouds, du buzz à la vraie scienceLes clouds, du buzz à la vraie science
Les clouds, du buzz à la vraie science
 
Devforumfrancois Tonic
Devforumfrancois TonicDevforumfrancois Tonic
Devforumfrancois Tonic
 
Cloud Computing : enjeux pour les DSI
Cloud Computing : enjeux pour les DSICloud Computing : enjeux pour les DSI
Cloud Computing : enjeux pour les DSI
 
Transforming Enterprise IT - French Version - Transformation Day Montreal 2018
Transforming Enterprise IT - French Version - Transformation Day Montreal 2018Transforming Enterprise IT - French Version - Transformation Day Montreal 2018
Transforming Enterprise IT - French Version - Transformation Day Montreal 2018
 
Introduction au cloud computing
Introduction au cloud computingIntroduction au cloud computing
Introduction au cloud computing
 
Kauffmann ec2
Kauffmann ec2Kauffmann ec2
Kauffmann ec2
 
XebiCon'17 : Serverless is the new back - Jérémy Pinsolle et Gérôme Egron
XebiCon'17 : Serverless is the new back - Jérémy Pinsolle et Gérôme EgronXebiCon'17 : Serverless is the new back - Jérémy Pinsolle et Gérôme Egron
XebiCon'17 : Serverless is the new back - Jérémy Pinsolle et Gérôme Egron
 
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir ArezkiGab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
 
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir ArezkiGab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
Gab 2017 Lyon - les strategies d'intégration avec Azure iPaaS - Samir Arezki
 
20120402 nantes gtug - app engine
20120402   nantes gtug - app engine20120402   nantes gtug - app engine
20120402 nantes gtug - app engine
 
[Tuto] Web burst : Débordement Web vers Windows Azure
[Tuto] Web burst : Débordement Web vers Windows Azure[Tuto] Web burst : Débordement Web vers Windows Azure
[Tuto] Web burst : Débordement Web vers Windows Azure
 

Continuous cloud costs testing [Fr] - DevoxxFR - 2013-03

  • 1. Continuous (Cloud) Costs Testing 10h40 - 11h30 - Salle E. Fitzgerald & L. Armstrong
  • 2. Continuous Cloud Costs Testing Nicolas Fonrose Teevity Cloud Costs Analytics – Founder / CEO @nfonrose / @teevity 27 au 29 mars 2013
  • 3. Nicolas Fonrose •  Cloud geek, Startuper •  Pas mal d’années employé d’une boîte de conseil IT. Deux petites boites de conseil, créées ensuite. •  Et ensuite, « l’aventure startup » J •  Teevity Cloud Costs Analytics •  Objectif – aider les boites à utiliser le Cloud sans avoir à se soucier des complexités liées aux coûts (variables et complexes à optimiser) •  Fonctionne sur AWS/AppEngine/Google BigQuery
  • 4. (Petit) lexique du cloud •  Instance (une VM) •  Zone (approx. == datacenter) •  Region (1 ensemble de 2 à 5 zones dans une partie du monde) •  Europe, Asie, US-east, US-west •  Web-storage (S3, Google Cloud Storage, Azure Blob Storage)
  • 5. AVEC LE CLOUD, ESTIMER LES COÛTS, C’EST COMPLIQUÉ !
  • 6. Les grilles de prix sont publiques Une grille de prix Cloud, ça ressemble à quoi ? Pas assez de place sur un slide pour montrer celle d’AWS. Loin s’en faut ! Des 10k de lignes de JSON juste pour les prix AWS !
  • 7. Estimation Tout bouge. Et tout le temps ! La grille de prix varie (très souvent – compétition entre CSP) Des nouveaux services apparaissent De nouveaux concepts tarifaires apparaissent Le comportement du service fourni par le CSP varie
  • 9. Quand la théorie devient réalité … Violent changement de prix pour AppEngine en 2011 Largement expliqué et justifié par Google, mais ça fait mal quand même ! Certains utilisateurs ont vu leur facture faire *20. Il a fallu sacrément optimiser
  • 10. Des fois, de très bonnes nouvelles AWS S3 price change (-15%, merci Google) AWS Glacier (10* moins cher; enfin presque) AWS DynamoDB price change (-85% !) Super nouvelles ! Mais aussi des hypothèses à revoir !
  • 11. D’autre fois, des moins bonnes Une région AWS, ça crache Et en entier (toutes les AZ) On doit faire du multi-région pour avoir une très haute disponibilité
  • 12. Des services qui changent Le DataStore AppEngine passe en HDR Hello « eventual consistency » on reads Impact sur l’architecture de certaines applications
  • 13. Des « non-conformités » Heroku / RapGenius Class action lancée contre Heroku ! Non seulement pas bon pour les porte-monnaies des clients Heroku Mais mauvais de manière générale pour le PaaS
  • 14. Cloud Costs Savings Tips LES 4 CATÉGORIES Architectes, Développeurs, Devops, vos actions ont un impact important sur le coût ! 27 au 29 mars 2013
  • 15. Categories •  « Software architecture » tips •  « Automation » tips (devops et scripting) •  « Buying strategies » •  « Right-sizing » (allocated vs consumed)
  • 17. Architecture logicielle L’élément le plus important ! Impossible de profiter des options qui rendent « cost-efficient » vos applications sans une architecture logicielle adaptée
  • 18. Les clés du « cost driven » - 1/2 Modularité Séparer les problématiques Pour pouvoir allouer les différents traitements à l’endroit le plus pertinent
  • 19. Les clés du « cost driven » - 2/2 Elastic-driven Instances == Resources (!= Serveurs) Compatibilité de l’architecture avec l’apparition/disparition (violente) de hardware
  • 20. Et le « hardware » Le choix du « Hardware » (virtuel) est bien sûr toujours important Mais c’est le software qui prend le lead. Le Hardware est juste là pour servir les besoins du soft. Et on peut maintenant changer de « Hardware » comme on change de chemise.
  • 21. Cost-driven architectures (et auto-scaling driven architectures) ARCHITECTURES CLOUD-COSTS EFFICIENTS : DES EXEMPLES !
  • 22. Architecture logicielle et coûts cloud Exemple 1 Site Web sans serveurs
  • 23. Ex 1 - Site Web sans aucun serveur ! Site Web entièrement hébergés sur un Web-Storage JS côté Client / Des batch qui updatent le contenu (lancés périodiquement) / Discuss pour les commentaires
  • 24. Ex 1 - Site Web sans aucun serveur ! Le DNS masque totalement le Web storage Compatible avec les CDN Aussi applicable à certaines API de ces sites Web
  • 25. Architecture logicielle et coûts cloud Exemple 2 Une application SaaS au régime
  • 26. Ex 2 - Application SaaS au régime Une application SaaS avec beaucoup de requêtes en lecture par les clients Application Web/Destkop/Mobile
  • 27. Ex 2 - Application SaaS au régime Régime minceur On pousse des copies des données statiques vers un Web store Adapter le rythme en fonction de la nature de l’application
  • 28. Ex 2 - Application SaaS au régime Compute Instances on update Web Storage Integrated web servers
  • 29. Ex 2 - Application SaaS au régime Ça marche aussi pas mal pour tout ou partie d’applications « métier » plus classiques (pas que pour les Dropbox like) Ca dépend de leur nature transactionnelle, et de la durée acceptable des copies de données côté client Raisonnement applicable aux API
  • 30. Ex 2 - Et la sécurité ? Comment on gère les autorisations d’accès ? S3 Bucket Policy / adresse IP cliente ? Bof … L S3 Bucket Policy / headers HTTP ? Mieux J Auto-signed URLs ? Fabuleux J
  • 31. Ex 2 - Et la sécurité ? Auth + GET signed URL Compute Instances on update Web Storage Integrated web servers
  • 32. Ex 2 – Cadeau «bonux» orienté Média Amazon S3 supporte Bittorrent ! Permet de fortement réduire la facture si beaucoup de personnes chargent les mêmes données Streaming de musique par exemple
  • 33. Architecture logicielle et coûts cloud Exemple 3 Communication B2B au régime
  • 34. Ex 3 - Application SaaS et upload Application SaaS avec gros volume de données en upload Classique en scénario B2B
  • 35. Ex 3 - Application SaaS et upload
  • 36. Ex 3 - Application SaaS et upload Donc là aussi, zéro serveur (ou presque), c’est possible. Et c’est même mieux (sécurité, scalabilité, …) ! Il faut quand même souvent des serveurs en batch pour traiter le contenu en asynchrone
  • 37. Ex 3 - Application SaaS et upload
  • 38. Ex 3 - Intégration Amazon / IMDB
  • 39. Architecture logicielle et coûts cloud Exemple 4 Application avec des traitements asynchrones lourds
  • 40. Ex 4 – Traitements asynchrones Beaucoup de traitements asynchrones lourds ? Des batchs classiques Du processing de photos (vignettes) De l’analyse de données (big data)
  • 41. Ex 4 – Traitements asynchrones
  • 42. Ex 4 – Traitements asynchrones Actions périodiques ? Même pas besoin de laisser tourner une instance avec un CRON ! On peut définir des « scheduled-actions » directement dans AWS (CRON interne)
  • 43. Architecture logicielle et coûts cloud Un contre-exemple maintenant ! Malgré l’architecture, dans certains cas, on peut quand même arriver à tourner « cheap »
  • 44. Ex 5 – Le contre-exemple « Web-cache / CDN » en frontal Fonctionne aussi pour les applications (quelque soit leur architecture) Evidemment pas applicable à toutes les applications (nécessite Web+REST). Ne marche que pour les Reads, pas pour les Writes (pour l’instant) Solution externe à l’application : le cache peut être chez un fournisseur (AWS) et l’application chez un autre (AppEngine) !
  • 45. Ex 5 – « Web-cache/CDN » frontal
  • 46. Indispensables pour pouvoir expérimenter les différentes stratégies AUTOMATION, SCRIPTING DEVOPS
  • 47. Ne pas « pétrifier » son infrastructure Création infra cloud « à la main » == infra cloud statique Ça prend du temps, sujet aux erreurs. Donc on la modifie rarement.
  • 48. Fluide comme du code Scripting == infrastructure fluide Infrastructure As Code Tester une nouvelle configuration d’infrastructure == Changer des paramètres dans des fichiers de conf / scripts Vous êtes libre d’expérimenter car « pas risqué » et « rapide »
  • 49. Facilite le changement de CSP Important y compris pour pouvoir changer/tester d’autres CSP Scripting avec une meta API (Scalr/RightScale par exemple) pour pouvoir porter sur un autre fournisseur très rapidement (AWS - GCE)
  • 50. Corrélations « action-to-cost » Intégration des actions sur l’infrastructure dans la boucle de cost-feedback Systématise la traçabilité des changements de configuration d’infra Permet de faire des corrélations entre changements dans l’infrastructure et impact sur les coûts
  • 52. « Right-sizer » Ne pas allouer plus que ce dont on a besoin Ça paraît évident … Et pourtant, la source d’économie la plus grosse constatée chez les utilisateurs IaaS. Les freins au right-sizing ? Architecture non elastic-driven / Infrastructure statique = Il faut scripter !
  • 53. « Right-sizer » avec les PaaS Normalement transparent avec les PaaS Finalement pas si trivial que ça même en PaaS Voir les fameuses histoires de coûts du début de la présentation
  • 54. Les stratégies d’achats de resources Cloud BUYING STRATEGIES
  • 55. Pas encore très développé Disponible pour AWS uniquement Pour l’instant
  • 56. AWS Reserved Instances (RI) « Acheter les soldes » Pour 150€, vous avez -30% sur les « t-shirts noirs tailles 38 pour femme » pendant 1 an Attention ! Ne s’applique pas aux t-shirts gris
  • 57. Instances réservées – break even 6 mois 16 mois (light) 9 mois (heavy) (medium)
  • 58. AWS Spot instances « Acheter aux enchères » Spot Instances Stratégies proches du trading : Bid, Outbid, … Les machines peuvent être reprises à tout moment par AWS ! Pas uniquement réservé aux batchs. Ex : Ajouter des instances derrière un load-balancer pour améliorer les perfs à faible coût
  • 60. Qui se charge des stratégies d’achat ? Pas vraiment un truc de développeur et d’architecte Pas encore clair dans les entreprises de savoir à qui revient ce rôle Equipes DevOps / DSI / Direction financière ?
  • 61. Comme pour les performances, la qualité, c’est la seule manière de s’améliorer COST FEEDBACK
  • 62. Cost feedback On ne peut améliorer que ce qu’on mesure Les Dev/Architectes ont rarement le nez sur la facture (quand ils y ont accès) Pas de feedback == on travaille dans le noir
  • 63. Cost feedback loop Netflix pousse vers ses équipes de Dev leur « consommé de la semaine précédente » Pas forcément pour améliorer la « cost efficiency » de l’application au runtime
  • 64. Cost feedback loop Naturel d’avoir la même chose en prod/integration/qualif/… Surveillance de la marge par tenant, … Notion de ‘cost optimization’ continue Surveillance des changements tarifaires non anticipés Surveillance du right-sizing
  • 65. Le feedback, en continue et de manière industrielle CONTINUOUS COST TESTING
  • 66. Objectif Donner aux équipes du feedback en continu sur « l’efficacité coût » du système qu’elles créent/déploient Pour éviter les dérives liées aux évolutions du code / de l’archi Pour éviter les dérives liées aux évolutions de l’infrastructure du fournisseur
  • 67. Exemple de dérive – true story Un développeur déplace quelques lignes de code qui implique des boucles è L’application envoie 10.000* plus de messages dans une file pour le même traitement. Oups ! Gros changement dans la facture en fin de mois
  • 68. « Last run » vs « Previous run » Je veux ça dans mon inbox tous les matins ! En bleu : Last run En rose : Previous run Unité : $ (USD) Echelle : peu importe/
  • 69. Comment on fait ça ? De quelles informations a-t-on-besoin ?
  • 70. Le coût du dernier « tir » Données sur le coûts et l’usage Evidemment ! Comment on les récupère ? Ça dépend du Cloud provider ... Pour la méthode d’accès aux données, et pour leur format
  • 71. GET /costs – AWS Programmatic Billing
  • 72. GET /costs – AppEngine ‘HTTP headers cost/req’ X-AppEngine-Resource-Usage: ms=293 cpu_ms=500 api_cpu_ms=236 X-AppEngine-Estimated-CPM-US-Dollars: $0.012320 Présent dans les headers HTTP de retour Il faut naviguer sur son application en étant connecté en admin sur la console appengine pour les voir
  • 73. GET /costs – Teevity API – ‘cost snapshot’ PUT http://api.teevity.com/ cloudcost/ costAndUsageSnapshot/ forCloudServiceId/ 50243203420423 ⇒ { snapshotId:582452432342234 } GET http://api.teevity.com/ cloudcost/ costAndUsageSnapshot/ 582452432342234
  • 74. GET /costs – Teevity API – ‘cost snapshot diff’ GET http://api.teevity.com/ cloudcost/ costAndUsageSnapshotDifference/ withInitial/582452432342234/ and/5915536323421748
  • 76. Difficulté Décalage temporel entre exécution et disponibilité des données de coûts Vous pouvez compter plusieurs heures de décalage. Pour l’instant, très difficile d’avoir un feedback quasi temps-réel
  • 77. Difficulté – le contournement On fait tourner les tests sur des périodes de temps bien définies En isolation d’autres activités Sur un autre environnement Cloud (autre compte, autre appId)
  • 78. Le coût ok. Mais la qualité ? Ça ne suffit pas ! C’est la « cost efficiency » qui nous intéresse, pas le coût absolu On a besoin d’autres données
  • 79. Mesure de cost-efficiency Informations de perf (nb trans/sec) Combien de transactions ont été réalisées par unité de coût
  • 80. Mesure de cost-efficiency (suite) Informations de QoS Latence notamment Point important ! Vous pouvez économiser beaucoup en arrêtant/lançant des instances fréquemment. Mais l’impact sur la latence est important.
  • 83. Dans le cloud … Vos décisions ont un impact réel sur les coûts Un nouveau challenge pour les techos ! Et on commence juste à découvrir les bonnes pratiques pour le relever
  • 84. Teevity Cloud Costs Analytics
  • 85. d
  • 86. d
  • 87. d