Keynote de cloture de l AWS Summit de Paris 2017

Transcript

MUSICAL INTRO Thank you. Toujours vivant ? Non, ça suffit pas, on va la refaire. Toujours vivant ? Non, ça crie trop fort. Plus fort, encore ? Allez. Alors, c'était une bonne journée ? Ok. Bon, alors on va commencer par remercier tous les speakers précédents de la track technique et des autres tracks, tous les clients, tous les partenaires, tous les clients, les gens qui ont bossé et qu'on a harcelé pour avoir de bonnes sessions, de bons slides, de bonnes démos. Vraiment, je vous demande de les applaudir. On a été dur avec eux. Merci beaucoup. Merci beaucoup. Et donc, j'ai le plaisir de clore ce summit. Et comme Boris l'a dit il y a quelques instants, effectivement, on va soulever un Voilà, avant de ça, je voulais vous donner une information, je voulais donner la date de disponibilité de la région. Donc ça sera en 2017. Voilà. Ne tweetez pas, ne tweetez pas. Je viens de faire transpirer beaucoup de gens chez moi, là. Hein ? Sophie ! Ok. Allez, arrêtons un peu les conneries, on va travailler. Ça marche ? Alors j'espère que vous avez un site web ou une plateforme dont la courbe de trafic ressemble à ça. J'espère que vous êtes confronté à ce genre de problème, à ces croissances ininterrompues, à ces pics de trafic permanents. C'est une expérience incroyable. J'ai eu l'occasion de vivre ça dans d'autres vies. C'est une expérience qui est fatigante, mais c'est une expérience intéressante et on apprend beaucoup. Le problème, c'est comment est-ce qu'on survit à ce genre de choses. Donc ici, on voit la courbe de trafic d'Amazon Retail et on voit que non seulement la courbe est plutôt vers le haut à droite, elle a des pics qui sont d'une violence inouïe. Vous voyez le pic du Prime Day, qui est un jour important pour Amazon en 2015, qui était déjà impressionnant à l'époque, et puis vous voyez la taille du même pic. Alors, ce n'est même plus un pic, c'est une espèce de... je ne sais pas... Ouais, c'est l'Everest, quoi ! En 2016. Alors, imaginez-vous à la place des équipes infra d'Amazon, comment est-ce qu'on vit à ça. Avec de l'infra physique on ne peut pas, c'est la bonne ou la mauvaise nouvelle, je ne sais pas. Personne n'est en mesure, ni techniquement, ni opérationnellement, ni financièrement, d'encaisser des pics comme ça en se disant bon alors donc on est en janvier, on va essayer de prévoir le pic de mi-juillet, alors l'année dernière on a fait plus de 20%, bon cette année elle est on va essayer de faire plus 30, on va commander des serveurs, on va les préparer, on va les installer, on va les raquer, on va les câbler, on va aller bla bla bla bla. Et puis le mini machin de juillet 2015 devient un énorme truc en 2016 et vous êtes mort. Vous avez entendu ce matin Radio France, pendant la keynote, qui vous a expliqué que leur décision finalement de rebâtir leur plateforme et d'aller vers AWS, c'était suite à une catastrophe. infras, doublé d'une vraie catastrophe, suite aux attentats et suite aux pics de trafic engendrés par l'événementiel autour de tout ça. Donc il n'y a pas d'autre solution quand on est confronté à des croissances et à des pics de ce style et même à des croissances plus faibles que d'utiliser une infrastructure cloud, une infrastructure élastique qui va vous permettre à la fois d'encaisser des pics extrêmement violents, et le reste du temps, lorsque les choses sont un petit peu plus calmes, si on peut dire, de février à mai, même si la croissance est quand même robuste, finalement d'adapter la voilure, d'adapter l'infrastructure au trafic, là qui est relativement linéaire, d'optimiser vos coûts, et puis lorsque les gros événements, le gros trafic déboule, vous pouvez scaler. Et vous ne vous inquiétez pas plus que ça finalement, parce que l'autre tactique, c'est de se mettre en boule comme un hérisson et puis de dire « ça va passer, ça va passer, ça va passer ». Bon, ça ne passe pas, on est tombé, on est par terre, on perd des ventes, on perd du fric, on reçoit des SMS à 2h du matin, on se fait engueuler par son CEO, on passe une mauvaise semaine, un mauvais mois et voire plus. Donc l'élasticité est essentielle. Et pour vous permettre de bâtir vos plateformes de manière robuste et élastique partout dans le monde, l'infrastructure de AWS au fil du temps s'est étendue dans différentes zones géographiques. Aujourd'hui on a 16 régions, ça a été déjà mentionné plusieurs fois aujourd'hui, et donc on va ouvrir quatre régions supplémentaires, donc Paris en 2017 et Stockholm, une région en Chine et une région à Hong Kong. On continuera d'ouvrir des régions aussi nombreuses que nécessaire lorsque le business le justifie. Ces régions vous permettent d'utiliser nos services et d'utiliser notre infrastructure à l'identique partout dans le monde. Il y a plein de clients aujourd'hui qui sont déployés dans plusieurs zones de manière identique. En complément des régions, on a bâti au fil du temps un CDN qui aujourd'hui vous propose 77 points de présence un peu partout dans le monde y compris dans des pays où vous n'avez pas de région disponible. Donc ce CDN, il va vous permettre tout simplement de servir votre contenu avec une latence plus faible au plus près de vos utilisateurs. Il va avoir aussi plein d'avantages en termes de sécurité, en termes de protection contre les attaques type DDoS, etc. 77 points, ça c'est le slide qui n'est jamais à jour. Il l'est aujourd'hui, mais je suis prêt à parier que dans les jours qui viennent, il ne le sera plus parce qu'on ouvrira un point de présence dans une nouvelle ville. Alors la question qu'on pourrait se poser c'est « Ok, tout ça c'est bien, on met des points, on met des trucs là un peu partout dans le monde. Qu'est-ce qui se passe entre les points ? » Beaucoup de choses. Donc entre ces points, entre les régions, entre les points de présence de CloudFront, là aussi, on a bâti un réseau global qui est opéré par les équipes d'Amazon et d'AWS et qui vous permet d'acheminer du contenu entre les régions ou vers les pop cloud front avec un niveau de qualité, un niveau de latence prévisible, constant, sensibilisé. Avoir à subir les vicissitudes de l'internet public qui marche bien la plupart du temps et généralement pas le jour où on en a vraiment besoin. Donc grâce à ce réseau finalement nos équipes peuvent contrôler plus finement les performances globales de notre cloud et donc de vos plateformes. Ce réseau est composé de fibres à 100 gigas redondantes qui font à peu près le tour du monde. Donc évidemment il y a des liaisons terrestres mais il y a aussi des liaisons océaniques, donc à travers l'Atlantique, à travers l'océan Indien, à travers la Méditerranée, etc. Et donc évidemment l'importance de la redondance ici est vitale puisqu'il ne faudrait pas qu'en cas de tremblement de terre, et ça arrive un peu souvent dans les régions asiatiques, ou en cas d'un chalutier qui passe, qui accroche un câble, ça fait sourire, mais ce sont des incidents qui arrivent. Mais il ne faut pas que ce genre de choses fassent tomber nos clients, donc on a insisté très fortement sur la redondance. Le dernier projet en date, c'est la construction d'un câble transpacifique qui part de Hawaï et qui va en Australie, en Nouvelle-Zélande, jusqu'aux Etats-Unis. Qui est là aussi basé sur de la technologie 100 gigas. Et donc on a 100 longueurs d'onde, 100 fois 100 gigas. Je renonce à faire le calcul, ça fait quoi ? 10 terabits ? Si je sais compter, c'est ça ? Il y a 10 terabits de capacité sur ce câble. Ça permet de transférer des données d'une région, d'un S3 dans une région vers un S3 dans une autre région. Ça permet de déplacer vos backups. Ça permet de faire des snapshots ou de la réplication de bases de données. Tous les services cross-région que vous utilisez, ils vont s'appuyer sur ces différents câbles et en particulier sur ce câble transpacifique donc qui a atteint la Nouvelle-Zélande en décembre en fin d'année dernière. Donc voilà, vous avez ce réseau qui relie les régions qui relient CloudFront et dont vous bénéficiez finalement lorsque vous utilisez nos services. Alors imaginez que vous soyez dans l'obligation de, alors évidemment pas de construire, mais de souscrire ce genre de choses, pour les personnes qui ont pu faire ça, d'acheter ou de louer de la connectivité privée entre, je vais prendre mon exemple favori, ça fera sourire des gens dans la salle, entre le Japon et les Pays-Bas par exemple. C'est relativement loin, ça passe à travers la Sibérie, voilà, c'est cher, donc vous en louez un, et puis quand il tombe, bon, il tombe, un coup de pelleteuse quelque part en Sibérie, et vous êtes embêté, vous êtes obligé soit de passer par l'Internet public et de rajouter de la latence, soit de faire le tour de la Terre de l'autre côté, comme dirait Werner, on n'a pas encore battu la vitesse de la lumière, mais on y travaille, et donc votre latence et votre expérience utilisateur et votre plateforme en général fonctionnera moins bien. Donc tout ça c'est caché, tout ça c'est opéré par les équipes AWS et ça fait partie du service, ça fait partie de l'utilisation de nos services et de nos régions. Alors parlons des régions justement. Donc aujourd'hui on a 16 régions. Les régions sont découpées en zones de disponibilité. On l'a entendu mille fois, vous savez tous ça par cœur, mais je veux insister là-dessus un instant parce qu'il semblerait que tout le monde n'ait pas la même définition de la région. Donc je pense que c'est important d'être transparent et c'est important de comprendre ce que AWS entend par région. Et je laisserai les autres expliquer ce qu'eux entendent par région, et puis vous ferez votre propre avis. Donc une région, c'est un ensemble de zones de disponibilité. Au moins deux, et à partir de désormais, comme dirait l'autre, trois. Donc toutes les nouvelles régions maintenant auront trois zones de disponibilité, et toutes les régions qui n'en avaient que deux sont upgradées à trois. Ce qui est le cas par exemple de la région de Francfort, qui initialement a été lancée avec 2 AZ et qui passe à 3. Donc la région française qui sera lancée en 2017 aura 3 zones de disponibilité. Ces zones de disponibilité, on peut en avoir jusqu'à 5 dans les plus grandes régions, et pourquoi pas plus au fur et à mesure de la croissance des régions. Dans une région, on va avoir des data centers, on va y revenir dans deux secondes, mais il faut, vous l'avez vu, il faut de la connectivité. Ce fameux réseau mondial 100 gigabits, il faut qu'il alimente les régions et les zones de dispo. Et évidemment, il faut que cette alimentation soit redondante. Donc dans chaque région, on va avoir deux centres de transit qui sont séparés physiquement, qui sont des bâtiments différents, qui sont complètement différents, isolés les uns des autres et qui sont par ailleurs connectés à des points de peering et à un grand nombre d'opérateurs. L'objectif c'est évidemment de fournir des points d'échange de trafic et d'amener le maximum de connectivité, le maximum de présence aux clients qui sont hébergés dans la région. Ensuite, à l'intérieur d'une zone de disponibilité, évidemment on va avoir, qui peut être composé de plusieurs bâtiments, de plusieurs data centers, on va avoir une fibre métropolitaine, on va dire, puisque les différents bâtiments qui constituent une zone de disponibilité sont suffisamment proches pour être à faible latence, mais suffisamment proches pour être à faible latence. éloigné pour qu'un incident, un incendie, une explosion, que sais-je, qui détruirait ou qui incapaciterait l'un des bâtiments, n'ait pas d'impact sur les autres. Donc c'est du métropolitain, mais ce n'est pas des distances extrêmement éloignées. Ensuite, on va avoir entre les zones de disponibilité, on va avoir là aussi des connexions, qui vont servir à votre plateforme, si vous lancez des instances C2 dans différentes zones de dispo, évidemment il faut qu'elles puissent communiquer. Il faut que des services managés comme Dynamo, S3, Aurora, etc., qui vous masquent complètement la complexité de l'infrastructure et qui s'exécutent dans les différentes AZ puissent eux aussi communiquer. Donc on a du réseau à haute capacité aussi entre les AZ. Donc voilà, ça commence à faire beaucoup de traits de toutes les couleurs. Donc vous imaginez un peu la complexité de la configuration réseau, le nombre de fibres, et la complexité de ces configurations-là. Et tout ça, une fois de plus, fait partie du service. Donc quand vous déployez des instances dans EC2, dans plusieurs AZ, eh bien vous avez tout ça à disposition. Donc une région AWS, c'est aussi compliqué que ça. Pour information, c'est une question qu'on me pose souvent, quelle est la latence entre les zones de disponibilité ? Bon, on va dire qu'elle est aux alentours d'une milliseconde, voire moins. Donc suffisamment près pour qu'on puisse faire de la réplication suffisamment loin pour que, une fois de plus, un incendie ou une explosion n'ait pas trop d'impact. Alors qu'est-ce que c'est qu'une zone de disponibilité ? Une zone de disponibilité, c'est évidemment au moins un data center. Je sais bien qu'on passe notre temps à parler de serverless, mais je vous rassure, il y a quand même des serveurs. On n'a pas encore inventé, on n'a pas battu la vitesse de la lumière, et on n'a pas encore réussi à exécuter du code en l'absence de serveur. Je suis bien sûr qu'il y a quelqu'un qui travaille quelque part dans un coin chez nous, mais ce n'est pas pour tout de suite. Donc au moins un data center, et dans certains cas jusqu'à 8, et là aussi on pourrait avoir plus si nécessaire. Donc ces bâtiments, évidemment on l'a vu, ils ont une connexion réseau extrêmement redondante. Et quelle est la taille d'une zone de disponibilité ? On va dire qu'elle est de l'ordre de quelques centaines de milliers de serveurs. On dit toujours qu'on a 16 régions et 43 Z. Je vous laisse faire une estimation du nombre total de serveurs qui tournent chez AWS. On ne peut pas vraiment faire 43 x 300. Je vous laisserai jouer avec la feuille Excel, puis vous me direz sur Twitter. Chacun des data centers qui composent une AZ va héberger entre 50 à 80 000 serveurs. Donc une puissance aux alentours entre 25 et 30 mégawatts. Alors ça ne vous parle peut-être pas, bon c'est pas énorme, c'est un choix. On aurait pu construire des data centers beaucoup plus gros. On pourrait aller à plus de 100 MW si on voulait. Il n'y a pas de limitation particulière. Pourquoi se restreindre à des data centers de taille intermédiaire ? C'est pour deux raisons. La première, c'est qu'il n'y a pas vraiment d'économie d'échelle au-delà de cette taille-là. On n'économiserait pas beaucoup en faisant beaucoup plus gros. Par contre, on prendrait un risque accru en cas d'incident sur un datacenter. C'est-à-dire qu'évidemment, quand un datacenter se casse la figure, s'il est complètement coupé et que c'était le seul datacenter de votre AZ et qu'il avait, je ne sais pas, 500 000 serveurs, et que l'AZ est par terre, c'est embêtant. Donc on préfère avoir une approche plus distribuée, où on va avoir plus de data centers de taille moyenne, avec des capacités raisonnables, pour effectivement éviter, en tout cas limiter, l'impact global d'un gros problème sur un data center. Donc là aussi, vous ferez vos calculs, et puis vous me direz combien on a de data centers. Alors, qu'est-ce qu'il y a dans les data centers ? C'est ça la question maintenant. Alors il y a plein de choses. D'abord il y a du réseau, on l'a vu tout à l'heure. On a eu une adduction réseau sur les AZ, les data centers. Donc effectivement il va falloir du matériel réseau. Alors on va faire un petit test. Qui gère des équipements réseau dans la salle, dans son data center ? Pas tant que ça. Quelques-uns. Bon voilà. Ça vous est déjà arrivé d'avoir un bug sur un routeur core ? Ou un switch d'agrégation ? Le truc qui relie vos 24 racks ? Jamais, on est d'accord ? Salut ! Je sais que tu mens. Ça arrive finalement, le réseau maintenant, c'est depuis des années, de plus en plus c'est du soft. Je ne citerai pas de constructeurs, ils sont à peu près tous logés à la même enseigne, et quand on a un bug sur un équipement comme ça, et que vous contactez le support, le premier truc qu'ils vous disent c'est « Ah, il faut mettre à jour ». Ça vous dit quelque chose ? Alors, quand c'est un petit switch top of rack, on peut dire « Ok, on va faire ça en loose day ». Moi je faisais ça pendant les incidents, je profitais des incidents pour faire mes upgrades, je peux le dire maintenant il ya prescription entre cassé est complètement cassé il n'y a pas une grosse différence ouais je vous donne tous mes secrets mais de temps en temps il faut patcher le switch d'agrégation il faut pas de chez le routeur de tête il faut pas de chez un truc comme ça et là là c'est pas la même limonade il faut prévoir une intervention si vous aviez un set up redondant, il faut faire les deux, vous espérez que le failover va marcher. Moi j'ai souvent vu le fail, j'ai pas souvent vu le over. Bon ça a rendu ma vie intéressante. Mais vous voyez ce que je veux dire, c'est compliqué. Et puis dans certains cas vous pouvez pas patcher, dans certains cas le patch n'est pas disponible, donc vous vivez avec des bugs, enfin c'est voilà. Et puis généralement la release d'après amène de nouveaux bugs et c'est reparti pour un tour. Et puis le cycle de correction est long parce que c'est compliqué. Un OS de routeur, c'est énorme, il y a des milliers de fonctionnalités, et là aussi, toutes les marques sont logées à la même enseigne, donc vous attendez les correctifs pendant des mois et des mois et des mois. Et vous imaginez bien que pour AWS, à l'échelle où on est, et même à l'échelle où on était il y a des années, c'est pas possible. On ne peut pas vivre avec ça, on ne peut pas vivre avec des équipements qui provoquent des incidents, qui font tomber des instances, etc. Donc, AWS construit ses propres routeurs avec du hardware qu'on a spécifié et avec un soft, avec une pile de protocole qui est développée par AWS. Ça paraît un choix incroyable, mais finalement, au moins, ça nous donne le contrôle et on peut implémenter les fonctionnalités dont on a besoin et pas plus. Donc, si certaines fonctionnalités sont du constructeur X, Y ou Z, dites interopérables, mais qui ne le sont pas en réalité, sont inutiles pour nous, on ne les implémente pas, on minimise le risque, et puis quand vraiment on a un bug dans nos protocoles, on les fixe nous-mêmes, et ça ne met pas 6 mois. Très tôt, on a déployé du réseau 25 gigas, alors que les standards de l'époque étaient plutôt 10, qui étaient assez répandus, puis 40, qui l'étaient beaucoup moins. Et donc, ce choix de 25 a été un choix gagnant pour nous, puisque le choix des 40 gigabits, finalement, c'est 4 fois 10, et donc ça ne permettait pas d'amener vraiment un lien supérieur à 10 gigas sur un équipement donné. Donc on est assez content d'avoir fait ce choix de 25, il a payé pour nous en termes de performance. Donc ces équipements... Ils utilisent, on l'a dit, du matériel qui est propriétaire, qui est spécifié par AWS. Donc on a notre propre ASIC, qui a des milliards de transistors, une consommation électrique maîtrisée. Et on a un écosystème de partenaires qui peuvent fabriquer cet ASIC pour nous. Il n'y a pas de problème particulier lié à ça. Voilà. Nos propres équipements, nos propres protocoles et même nos propres chips. Mais finalement le matériel, j'ai dit tout à l'heure, le matériel dans ce qu'on parle de réseau, c'est... Je n'ose pas dire que c'est secondaire, je vais me faire insulter, mais c'est rien, j'ai l'habitude. Le point important maintenant, c'est le soft. C'est là que ça se passe, y compris pour le réseau. Et depuis le début de ces deux, on a utilisé du SDN, du Software Defined Networking, où finalement le hardware n'est qu'un châssis. Il y a des ports, on branche et c'est tout. C'est un réceptacle pour le câble et puis un circuit de commutation. Et toute l'intelligence est en soft. Très tôt aussi, en 2012, on a déplacé pour les instances EC2, on a déchargé les instances, le CPU des serveurs qui font tourner les instances EC2, on les a déchargées du traitement réseau. Donc ça c'est quelque chose qui existe depuis longtemps sur les interfaces réseau, mais nous on l'a aussi en production depuis des années. Donc sur nos interfaces réseau qui sont dans les serveurs, les châssis EC2, on a un processeur spécifique codé avec du logiciel codé par AWS qui va nous permettre de décharger le CPU de l'instance du traitement réseau et de gérer toute la stack TCPIP, enfin une grosse partie de la stack TCPIP en Word. Ça nous permet de limiter l'impact de la virtualisation sur les performances réseau. Ça permet d'avoir une latence réduite, ça permet d'avoir un jitter, une gig, donc une imprévisibilité du trafic réduite, donc des performances plus linéaires, plus stables dans le temps. Et pour ceux qui ont suivi les webinars, et en particulier le Deep Dive EC2, vous vous souvenez qu'on a parlé des mécanismes de SRIOV et d'Enhanced Networking, qui maintenant sont à peu près standards sur la plupart de nos instances, sauf si vous avez vraiment une très très vieille AMI, et qui permettent de bypasser la couche de virtualisation pour tout le trafic réseau, et d'aller attaquer directement l'interface matérielle, et du coup d'avoir des performances extrêmement élevées. Donc ça c'était la situation... Et donc en 2016, à la fin de l'année dernière, on a commencé à déployer une nouvelle génération de composants qui s'appelle Anapurna, qui va encore plus loin que les générations précédentes, qui permet d'avoir deux liens 25 gigas. Vous commencez à imaginer les débits que ça peut donner. Et là on contrôle tout, la conception du silicium, la conception du hardware qui est autour, la réalisation du soft. Est-ce qu'on peut dire qu'AWS est une société qui fait du semi-conducteur ? Je ne sais pas si on va aller jusque là, mais je crois qu'on pourrait. Et donc vous voyez, Werner parlait ce matin de l'innovation continue, et vraiment de notre engagement à aller toujours plus loin dans les services qu'on met à votre disposition. Et voilà, il y a ce qu'on annonce, il y a ce que vous voyez passer dans les flux Twitter, etc. à peu près tous les jours, ce que vous voyez sur le blog de Jeff Barr, ce que vous voyez sur le blog de Werner, etc. Les nouveaux features S3, RDS, EC2, lambda, on ne va pas tous les faire, je crois qu'il y en a 91 ou 92 maintenant. Ce déluge de features, et puis il y a le reste. Il y a l'innovation, on va dire infrastructure, l'innovation réseau, qui est finalement au moins aussi importante et sur laquelle on communique un petit peu moins. Et donc cette nouvelle génération de chips, elle nous permet d'avoir des instances EC2, qui ont 20 gigabits de débit réseau. Donc en particulier, la plupart, pour ne pas dire toutes les instances qui sont des 16 X-large, les R3, les I2, etc., les C4, me semble-t-il, ces instances-là supportent un débit réseau de 20 gigabits par instance. La famille X1 aussi, la famille X1. des monstres pour faire tourner SAP, les gros jobs Spark et tout ça. Non, promis, je ne recommence pas sur Spark, mais j'en ai assez fait ce matin. Mais voilà, donc on peut avoir, il y a de nombreuses instances qui vont vous permettre d'avoir du 10 gigabits par seconde, voire même du 20 gigabits par seconde par instance. Et pour ceux qui disent « oui, non mais ça, ce n'est pas vraiment vrai, la cap est pas vraiment là, il y a de la mutualisation, etc. Je vous incite à faire des benchmarks. Prenez les spécifications hardware des instances, faites des tests, vous verrez, vous avez le nombre de cœurs qui est indiqué, vous avez la mémoire qui est indiquée, vous avez le débit réseau qui est indiqué, vous avez tout. Donc il n'y a pas de mutualisation entre instances. Donc les caractéristiques CPU, RAM, réseau, stockage d'une instance, c'est ce que vous avez pour l'instance. Il n'y a pas d'ambiguïté là-dessus, contrairement à ce que je peux lire ou entendre parfois. Donc voilà pour la partie réseau. Vous voyez, c'est relativement avancé. Dans les data centers, c'est... C'est bien d'avoir du réseau, c'est bien d'avoir de l'électricité aussi. Parce que dans la série des trucs qu'on n'a pas réussi à faire, donc il y a battre la vitesse de la lumière, faire du serverless sans serveur, et puis faire des serveurs qui marchent sans électricité. Mais on y travaille, je suis sûr. Donc les gens qui opèrent leurs propres data centers ou qui sont hébergés dans des data centers en colocation, enfin des data centers publics, Redoute une chose par-dessus tout, c'est la panne électrique. C'est ce qu'il y a de pire. Moi, ça a été mon cauchemar, je l'ai vécu un certain nombre de fois. La coupure, alors la coupure franche, la coupure intermittente, le truc qui fait on, off, on, off, jour, nuit, jour, nuit, jour, nuit. Ça, généralement, ça casse beaucoup de choses. Voilà, il y a toute une variété de panne électrique tout à fait sympathique. qui ont tendance à détruire vos serveurs. Même quand le courant revient, vous êtes par terre parce que les SSD de votre routeur a cramé, les cartes réseau ont pris un coup dans la tête, vous avez des disques qui ont brûlé à droite à gauche, des alignes qui ont claqué. L'hébergeur vous dit « Ouais, c'est revenu ! » « Ouais, c'est revenu, oui, il y a du jus. Si je mets les droits dans la prise, ok, il y a 16 ampères. » quand je regarde mon monitoring, il est encore bien rouge. Ça rappelle des souvenirs à quelqu'un ? Ah, ils n'osent pas le dire, là. Bon, moi, oui, ça m'en rappelle plein. Et l'année dernière, il y a eu un incident de ce style dans une grande compagnie aérienne américaine. Par pudeur, on ne va pas citer son nom, et puis j'ai peur qu'elle m'enlève mes miles, alors on ne va pas le faire. Et souvenez-vous, il y a eu cet énorme incident qui a empêché et chez tous leurs vols au niveau national et probablement même international de décoller pendant un certain temps. Et tout ça a été lié à une panne électrique chez eux. Il y en a eu une autre en Europe plus récemment, de l'autre côté de la Manche. Là, je n'ai pas de miles, on pourrait les citer, mais de l'autre côté de la Manche, c'était facile à trouver. Ça arrive. On ne connaît pas bien les causes de celles-là, mais probablement c'est du même ordre. Donc une panne électrique, des saveurs qui tombent, qui ont du mal à remonter. Imaginez des vols cloués au sol, des passagers pas contents, Twitter qui s'enflamme, enfin Internet qui s'enflamme, un bad buzz extraordinaire. L'impact va bien au-delà des retards d'avion, c'est une catastrophe. Mais on ne peut pas vraiment leur en vouloir. Le job d'une compagnie aérienne et même le job des équipes IT d'une compagnie aérienne, ce n'est pas d'être des experts des tableaux de distribution électrique et des UPS et des générateurs diesel. Bien sûr, il faut comprendre. Mais au jour le jour, ce n'est pas ça leur boulot. Et certainement, dans ces équipes-là, il n'y a pas cette expertise. Et utilise souvent cette phrase, vous l'avez déjà entendu plusieurs fois j'imagine, qui est qu'il n'y a pas de courbe de compression pour l'expérience. Ce qui est une façon extrêmement élégante de dire que, bon, on apprend de ses erreurs quoi, et je reste poli, il est impossible de tout prévoir quand on opère des plateformes, quand on est à l'échelle, d'autant De temps en temps, un truc surgit, vous ne l'aviez pas vu, c'était imprévisible, ça vous tombe sur la tête, et c'est la catastrophe, et vous vous dites « Qu'est-ce qu'on a fait ? Pourquoi nous ? Pourquoi moi ? » Surtout quand je suis en astreinte. « Pourquoi moi ? Pourquoi ça m'arrive à moi ? » C'est comme ça. La prod, vous le savez, c'est ça. Et donc, tant qu'on n'a pas eu ces problèmes-là, On ne sait pas comment les résoudre. Le truc, c'est que ce problème-là, le problème qui est arrivé à cette compagnie aérienne américaine dont le nom commence par D et finit par A, et que j'emprunte bientôt... Allez, mettez-moi des miles et je ne dis pas de nom. En fait, ce problème-là, il s'était déjà produit pendant le Super Bowl 2013. Alors nous, on n'est pas très foot américain, je vous l'accorde, mais vous avez déjà entendu parler du Super Bowl, c'est le plus gros événement sportif et sans doute le plus gros événement tout court aux Etats-Unis tous les ans. Et le même problème s'était produit pendant le Super Bowl 2013 et avait impacté la diffusion et les opérations. Et donc c'est toujours la même histoire, c'est un panneau électrique. Alors pour ceux qui ne sont jamais allés dans des data centers, ce n'est pas très sexy, c'est rigolo mais c'est pas très sexy. Donc voilà il y a des panneaux électriques comme ça, c'est plein de disjoncteurs un peu comme à la maison c'est juste qu'il y a plus de courant dedans donc c'est encore, ne mettez pas les doigts, ne touchez pas, vous risquez de faire des bêtises. Et donc ce truc là tombe en panne et bypass les systèmes d'UPS, de batterie etc. Et au lieu de tomber en panne proprement et de dire je suis en panne on va basculer sur batterie, il dit je suis en panne et puis on va pas mettre du tout de courant donc ça se passe pas très bien et puis le data center tombe et quand il se rallume il se rallume plus ou moins et donc vos équipements sont dans un état compliqué donc ce problème là il se produit mais voyez il se produit de manière rare à des endroits différents chez les prestataires différents avec des clients différents et c'est donc on dit ouais c'est la faute à pas de chance ah oui bon d'accord c'est la faute à pas de chance chance, peut-être. Néanmoins, à l'échelle d'Amazon et d'AWS, il n'y a pas la place pour la faute à pas de chance. Et à notre échelle, ces problèmes pourraient se produire régulièrement. Donc si tous les trois mois, on vous faisait le coup du tableau de distribution qui tombe en panne en disant « c'est la faute à pas de chance », bon, la première fois, ok, la deuxième, bof, la troisième, non. Puis ça Vous auriez furieux et vous auriez raison. Donc, pour régler ce genre de problème, on a donc évidemment nous des équipements électriques, mais le firmware qui tourne sur ces équipements, il est custom pour nous, il est revu par nous et spécifié par nous. Parce que nos équipes infra apprennent de tous les incidents qui se passent partout chez AWS et de manière générale partout dans le monde. Et donc à chaque fois qu'un scénario comme ça se produit chez Delta, ça y est, voilà mes miles, ou au Super Bowl, ou chez British Airways, oh zut, non mais je vole sur Air France, bon en fait, et je veux bien des miles aussi, maintenant que je leur ai fait de la pub, et bien à chaque fois qu'un problème se produit quelque part, nos équipes l'observent, apprennent et améliorent. Et donc il n'y a pas de courbe de compétence, compression pour l'expérience et c'est ça qui nous permet en permanence de continuer à abattre une plateforme de plus en plus solide, de plus en plus robuste. Alors dans les data centers, il y a du stockage aussi pour mettre tous vos logs, toutes vos bases de données, tous vos snapshots, toutes vos images, tout ce que vous mettez dans vos plateformes. Et donc en 2014, on avait révélé un premier une première génération de baie de stockage qui avait 880 disques par rack. Et donc aujourd'hui, on a un nouveau design avec plus de 1000 disques par rack qui a une capacité à peu près de un peu moins de 9 pétas. Bon maintenant un peu plus parce que évidemment la densité des disques augmente. Donc on est très certainement au-delà des 10 pétas par baie. aujourd'hui. 10 péta octets par b. Non, c'est pas mal. Imaginez une salle remplie de baies de stockage, cela ferait de quoi remplir quelques buckets. Nous faisons du serverless, mais il y a quand même des serveurs. Nous avons aussi des serveurs personnalisés. Chez AWS, les serveurs sont jetables. Nous en mettons beaucoup et vous donnons tous les moyens de faire du scale-out et de l'auto-scaling. Ce sont des serveurs simples, avec une emphase sur l'efficacité énergétique plutôt que sur des disques massifs, car nous avons des baies de disques dédiées. Nous essayons d'avoir des serveurs économes en électricité, avec une alimentation et une conversion de voltage optimisées. Lorsque l'électricité entre dans un équipement, une partie est dissipée en chaleur, ce qui est inefficace et réchauffe inutilement l'environnement. Nous visons donc des serveurs optimisés en termes de consommation électrique. Notre objectif est d'avoir 100% d'énergie renouvelable consommée par les data centers d'AWS. En 2015, nous étions à 25%, et en fin 2016, à 40%. Aujourd'hui, nous devrions être entre 45 et 50%, voire plus. Nous investissons massivement dans l'éolien et le solaire, dans la même logique que ce qui a été expliqué par Engie ce matin. Depuis plusieurs années, nous lançons, construisons et opérons des fermes éoliennes et solaires avec des capacités non négligeables. Nous continuons à ouvrir de nouveaux projets tous les quelques mois, augmentant progressivement notre capacité de production d'énergie propre. Aujourd'hui, nous dépassons 900 MW d'énergie propre, ce qui est équivalent à un réacteur nucléaire en France. Ces projets génèrent environ 2,6 millions de mégawatts-heures, soit suffisamment d'énergie pour alimenter 240 000 foyers américains, ou environ 600 000 foyers français. C'est suffisamment d'énergie propre pour alimenter une ville de la taille de Portland. Nous avons 16 régions, 43 zones de disponibilité, et plusieurs régions à venir, dont la France. Vous voyez une innovation qui ne se limite pas au service de la plateforme, mais qui s'étend au réseau, au stockage, aux serveurs, et à l'efficacité énergétique, tout cela pour vous proposer la meilleure plateforme possible. Je voulais remercier tous ceux qui ont contribué à l'organisation du Summit, ainsi que James Hamilton, l'auteur de ces slides et le père de l'infrastructure d'AWS, pour m'avoir permis de les utiliser. Pour ceux qui auraient raté l'information, nous avons annoncé l'embauche de James Gosling, le père de Java. James avait une particularité : il jetait des t-shirts lors de ses présentations. En hommage à nos grands leaders techniques, James Hamilton, Werner, et en particulier James Gosling, je vais relancer cette tradition, mais avec des polos. Ne vous battez pas, on ne veut pas finir sur une mauvaise note. Merci beaucoup, j'espère que vous vous êtes bien amusés aujourd'hui. À bientôt.