La conférence annuelle re:Invent d'Amazon Web Services (AWS) se tient actuellement. La société y fait comme chaque année de nombreuses annonces, dont le lancement de nouvelles instances. On y trouve des composants de dernière génération, parfois étonnant... comme le Mac mini d'Apple.
AWS est l'un des leaders mondiaux du Cloud, plutôt du genre prolifique. Chaque jour, de petites améliorations de ses nombreux services sont mises en place. Ce qui n'empêche pas la société de se réserver de grands moments de communication, comme sa conférence re:Invent. Et l'édition 2020 ne déçoit pas par son contenu.
Mac mini as-a-service
Outre un partenariat avec Zoom ou encore BlackBerry, on apprend que des instances à base de Mac mini débarquent au sein d'Elastic Compute Cloud (EC2). De quoi donner accès à tout l'écosystème Apple avec une tarification mensuelle, à la demande. Une offre qui vise principalement les développeurs.
Ils peuvent ainsi n'utiliser macOS que lorsqu'ils en ont besoin pour travailler sur la version de leur application pour les appareils de la marque à la pomme, tout en ayant accès à Xcode et les solutions maison : Swift, Metal, CoreML, etc. Ces instances pourront être exploitées avec d'autres services AWS comme Elastic Block Storage (EBS) pour le stockage, Elastic Load Balancer (ELB) et/ou Virtual Private Cloud (VPC) pour la mise en réseau.
Bien entendu des images (AMI) pourront être déployées, AWS ayant sans doute créé son propre système d'orchestration, construit sur la base de Nitro et des outils d'Apple en la matière. La société ne précise par contre pas comment elle opère matériellement ses machines : sous leur forme originelle ou juste leurs cartes mères ?
Pour le moment, seule une déclinaison Intel est proposée. Elle donne accès à macOS Mojave (10.14) et Catalina (10.15), Big Sur (11.0) devant arriver dans un second temps. On imagine que de nouvelles offres à base de SoC Apple M1 pourront alors aussi être disponibles, à moins que des outils de déploiement doivent être spécialement adaptés.
Les Mac mini sont à base de processeur Core de 8e génération (6C/12T), cadencé entre 3,2 et 4,6 GHz, avec 32 Go de mémoire. Il s'agit d'une offre bare metal, donnant accès à la machine complète, puisque l'on a droit à la même quantité de mémoire et 12 vCPU. L'interface réseau est de type 10 Gb/s, le stockage uniquement via EBS (8 000 Mb/s, 80 kIOPS). AWS dit exploiter ici la connectique Thunderbolt 3 de la machine qui permet de tels débits.
L'instance mac1.metal est disponible en Europe (Irlande), Asie Pacifique (Singapour) et aux USA (Ohio, Oregon et Virginie du Nord). D'autres suivront. Le tarif de base est de 1,083 dollar de l'heure, il est de 1,207 dollar en Europe.
L'équipe dit travailler sur le projet depuis plusieurs mois, notamment pour proposer à ses clients qui ne travaillent pas que sous Linux et Windows une solution pour leurs déploiements, leur éviter de maintenir leurs propres dispositifs à base de Mac mini localement et qu'ils optent pour une offre à la demande d'AWS comme pour d'autres systèmes.
Il sera intéressant de voir si d'autres hébergeurs s'essaient à une solution similaire et si Apple se met à pousser volontairement des solutions équivalentes chez d'autres partenaires à travers le monde dans les mois à venir.
Cascade Lake, jusqu'à 4,5 GHz
Si cette annonce est celle qui fera le plus de bruit, elle est loin d'être la seule. Et il y en a pour tous les goûts. Intel est à nouveau l'un des grands gagnants puisque nombre de ses produits trouvent une place dans les nouvelles instances dévoilées à re:Invent, comme les M5zn à base de Xeon Scalable de 2e génération (Cascade Lake).
Leur avantage premier selon les équipes d'AWS et de donner accès à des processeurs hébergés pouvant grimper à 4,5 GHz sur l'ensemble de ses cœurs contre 3,1 GHz sur les M5(n) actuelles, 2,5 GHz sur l'offre AMD EPYC (M5a). Ils sont proposés sous la forme de six instances classiques allant de 2 à 48 vCPU, de 8 à 192 Go de mémoire, de 0,1652 à 3,9641 dollars de l'heure. Une offre dédiée est également proposée, on passe alors à 4,36 dollars.
Le gros de l'offre reste chez Intel...
L'offre Scalable de 3e génération (Ice Lake) ne semble pas encore au programme, son arrivée dans les serveurs ayant progressivement été retardée, on ne devrait pas en voir avant 2021.
C'est donc à nouveau sur la base de Cascade Lake que les instances R5b « optimisées mémoire » évoluent. Elles passent ainsi à un stockage EBS capable de grimper à 60 Gb/s (19 Gb/s précédemment) et 260 kIOPS. Elles varient de 2 à 96 vCPU et de 16 à 768 Go de mémoire. Les tarifs de 0,149 dollar à 7,152 dollars de l'heure.
De nouvelles instances D3(en) sont également de la partie, favorisant cette fois la capacité de stockage. Les D3en proposent un ratio vis-à-vis du nombre de vCPU 3,5 fois plus important selon l'équipe, variant de 28 à 336 To pour 4 à 48 vCPU. Les tarifs vont de 0,609 dollar à 7,69656 dollars de l'heure.
On reste dans tous les cas sous l'énorme serveur annoncé récemment par Scaleway, avec 448 threads, 20 To de stockage et 1,5 + 6 To de mémoire, proposé au sein de son offre bare metal dès... 30 euros de l'heure.
... Habana Gaudi arrive
Mais Intel est particulièrement fière d'annoncer l'intégration de ses accélérateurs IA Habana Gaudi, avec la carte HL-025 pour la première fois proposée au sein d'une instance EC2 d'AWS.
Elle promet un gain de 40 % en ratio performances/prix par rapport à l'offre GPU actuelle et sera disponible dans la première moitié de 2021. Un programme d'accès anticipé est néanmoins proposé, l'inscription se fait par ici. Pour rappel, ces solutions sont le fruit du rachat d'Habana par Intel l'année dernière.
Le géant américain a fait énormément de croissance externe ces dernières années pour se développer dans le domaine des solutions spécifiques à l'IA et renforcer son approche « XPU ». L'objectif de la société est en effet de proposer une couche logicielle unique via sa OneAPI, capable de tirer parti tant des CPU, que des GPU, FPGA et autres accélérateurs, intégrés ou dédiés, sous sa marque ou d'autre.
De quoi faciliter le travail des développeurs qui n'ont pas à produire un code spécifique pour chaque type de composant.
Le HL-205 est la version à 350 watts de TDP de Gaudi, sous la forme d'une carte « mezzanine » respectant le format OAM. Son interface à l'hôte est de type PCIe 4.0 x16, avec 32 Go de mémoire HBM2. Ces cartes peuvent également tirer parti du RDMA over Converged Ethernet (RoCE v2) pour une meilleure interconnexion. Elles embarquent de quoi proposer jusqu'à 10x 100 Gb/s ou 20x 50 Gb/s, et donc s'adapter aux différents besoins.
Un point d'autant plus important que les Gaudi HL-205 sont proposés par la société sous la forme d'une baie HLS-1(H), sans CPU, devant donc être reliée à d'autres serveurs. Il est aussi possible d'opter pour une solution tout-en-un. Amazon ne précise pas pour le moment ce qui sera utilisé pour ses instances EC2.
Elles proposeront par contre bien jusqu'à huit cartes, chacune intégrant une puce et donc huit unités de calcul TPC 2.0 (Tensor Processing Cores). De quoi fournir une puissance de calcul suffisante pour traiter jusqu'à 12 000 images par seconde sur le modèle ResNet-50 via TensorFlow selon les équipes d'Intel et Habana.
Des modèles prêts à l'emploi et des guides de migration seront mis à disposition sur GitHub. Habana propose également des outils de développement spécifiques, tels que sa SynapseAI Software Suite (gérant PyTorch et TensorFlow). Un livre blanc détaillant l'implémentation de la puce actuelle est disponible par ici.
Intel en profite pour annoncer que sa prochaine génération, Gaudi2, arrive et sera gravée en 7 nm par TSMC. De son côté, AWS prépare sa propre solution Trainium attendue aussi l'année prochaine.
AMD : Un petit GPU RDNA à la demande
Du côté de chez AMD, Zen 3 n'est pas encore à l'honneur, puisque les processeurs EPYC l'exploitant n'ont pas encore été officialisés. Ils ne devraient là aussi pas être disponibles avant 2021, tout comme le gros du stock de Ryzen 5000 de l'offre grand public d'ailleurs (ce qui explique les indisponibilités actuelles).
Pour autant, des produits AMD sont utilisés dans de nouvelles instances G4ad qui sont présentées comme des alternatives aux G4dn exploitant un processeur Intel et jusqu'à huit GPU T4 de NVIDIA. Ces derniers disposent d'ailleurs de pilotes GRID pour des usages virtualisés, le traitement vidéo ou des solutions de cloud gaming par exemple.
Les processeurs des nouvelles instances sont des EPYC de 2e génération (Rome) avec 16 à 32 vCPU, accompagnés de 64 à 256 Go de mémoire, de 1 à 4 Radeon Pro V520. Une carte graphique d'entrée de gamme dont AWS précise qu'elle exploite l'architecture RDNA. Elle serait donc dérivée des Radeon RX 5000, mais n'est pas détaillée sur le site d'AMD.
Le stockage est un autre point fort de cette offre, puisque l'on peut grimper à 2 400 Go contre 2x 900 Go auparavant. La bande passante est par contre parfois en retrait, de 3 à 6 Gb/s pour le stockage EBS contre 3,5 à 19 Gb/s pour G4dn. Cette dernière grimpe également à 100 Gb/s pour le réseau contre 10 à 25 Gb/s pour G4ad.
La disponibilité est annoncée pour les prochains jours, les tarifs n'ont pas encore été détaillés. On s'étonne d'ailleurs de ne pas (encore ?) voir un modèle équivalent mais basé sur l'architecture Xe et le nouveau Server GPU d'Intel spécialement pensé pour des usages équivalents, avec des cartes PCIe embarquant directement quatre GPU.
Graviton2 gagne du terrain, l'écosystème AWS se renforce
Bien entendu, les processeurs maison d'Amazon étaient également à l'honneur. Graviton2 intègre ainsi de nouvelles instances C6gn avec du réseau jusqu'à 100 Gb/s et du stockage EBS jusqu'à 38 Gb/s contre 25 Gb/s et 19 Gb/s précédemment (C6g). La société rappelle que leur rapport performances/prix est 40 % supérieur aux solutions x86.
Ainsi, elles seraient idéales pour le traitement de flux réseau, d'où la volonté d'AWS d'augmenter leurs capacités en termes d'E/S. La gamme est plus réduite que C6g, mais va toujours de 1 à 64 vCPU et de 2 à 128 Go de mémoire. Les tarifs n'ont pour le moment pas été dévoilés, la disponibilité étant attendue avant la fin de l'année.
AWS indique également augmenter ses points de présence. 77 zones sont actuellement proposées dans 24 régions, Boston, Houston et Miami ouvrent outre-Atlantique, 12 autres devant suivre dans les mois à venir ainsi que cinq régions : Espagne, Inde, Indonésie, Japon et Suisse. Mais surtout, l'écosystème se renforce.
De nouveaux formats 1U/2U sont proposés pour Outposts, la solution de base de données Aurora Serverless passe en v2 avec une intégration directe de Babelfish et une migration facilitée depuis SQL Server. Les solutions de stockage en bloc (EBS) et objet (S3) gagnent en capacités et en performances, tout comme les outils d'analyse.
Elastic Container Service (ECS) et Elastic Kubernetes Service (EKS) pourront bientôt être exploités dans des datacenters autres que ceux d'Amazon à travers Anywhere. Proton permet le déploiement et la gestion de conteneurs ou d'applications serverless. L'initiative de registre public Elastic Container Registry (ECR) est disponible. Canonical vient d'ailleurs d'annoncer qu'il en était l'un des partenaires.
Monitron vise à permettre aux entreprises de surveiller leurs équipements industriels et prévenir les pannes via Lookout qui fonctionne avec des équipements déjà en place. Panorama repose sur le même principe mais pour une détection plus générale sur des zones plus larges, comme les points chauds en boutique par exemple.
Tant de solutions clé en main et accessibles à tous, qui doivent faire d'AWS un partenaire de choix pour des entreprises qui ne veulent ou ne peuvent pas disposer du savoir-faire nécessaire en interne.
Il en va de même pour le DevOps Guru qui utilise là encore le machine learning, mais pour automatiser des tâches de gestion de l'infrastructure et la détection de problèmes. Et enfin Connect pour un ensemble de solutions de gestion des contacts omnicanal avec analyse des performances.
Le bal des annonces pourrait bien continuer, pas moins de trois semaines de conférences virtuelles étant prévues jusqu'au 18 décembre. Puis cela reprendra du 12 au 14 janvier prochain. Tous les détails se trouvent par ici.
Commentaires (15)
#1
J’ai beau pas être fan d’Amazon en tant qu’entreprise, AWS est quand même un sacré monstre.
Je vois pas trop ce qui pousserai Apple à faire ça d’elle même : ces machines, même le communiqué d’AWS le dit servent en grande partie à lancer des builds Xcode.
L’exclusivité de builder des apps iOS depuis un Mac semble être un choix délibéré d’Apple. Rien ne les empêche de sortir Xcode ou au moins sa toolchain sur d’autres plateformes.
La « M1 » aura peut être un intérêt à être mise en server farm (ça reste à voir mas ça se conçoit pour des usages spécifiques) mais dans ce cas je vois plus Apple proposer son propre service en ligne (quitte à ce que ce soit du rebranding d’AWS puisqu’ils me semble qu’ils s’appuient déjà sur eux).
On a des infos quelques part sur ces procs ? (Je débarque un peu
)
#2
Oui Graviton2 a été annoncé l’année dernière (il est dispo générale depuis septembre)
#3
Mais comment est-il encore possible de s’y retrouver parmi toutes ces appellations… Personnellement, je suis complètement largué depuis un petit moment déjà. Je dois me faire vieux 😅😋
#4
Serverthehome ont fait un article pas mal qui compare le cout d’hébergement sur AWS de leur site par rapport au cout d’hébergement avec leur propre matériel : https://www.servethehome.com/falling-from-the-sky-2020-self-hosting-still-pays/. En hébergeant sur leur propre matériel ils sont gagnants…
#5
En même temps le principe d’AWS c’est de fournir de la puissance pour un besoin ponctuel, pas un hébergement complet sur le long terme.
#6
Nope. AWS fournit bien toute une panoplie complète de services pour héberger 100% d’une appli : stockage, hébergement statique, runners …
#7
C’est un peu découvrir l’eau chaude là.
Dans tous les domaines, quand tu fais toi même c’est “moins cher” (cuisine, hébergement web, travaux allant du bricolage à la construction d’une maison).
Sauf que t’as rarement envie de t’en occuper quand c’est pas ton cœur de métier. Quand tu paies ta maison plus cher pour la faire construire c’est pas les matériaux que tu paies, c’est la garantie que ta maison ne tombera pas au premier coup de vent et le déport de la responsabilité en cas de problème.
Gérer toi même le serveur de ton site perso pour pas cher, oui, bien sûr. En plus t’apprends plein de trucs.
Héberger “soi-même” une appli utilisée par des milliers d’utilisateurs qui paient les salaires de tes employés, c’est avoir une bonne résistance au stress tout de même.
C’est totalement faisable et plein de boites le font hein : tu embauches des gens qualifiés qui assureront des astreintes, des plans de récupération d’urgence, le backup, le hardware en spare, une config qui rend ton infra redondante en cas de panne … mais ça fait tout de suite beaucoup de sous à rajouter dans la balance (dont au moins un salaire d’admin système).
#8
Y’a encore des gens en 2020 qui pensent avoir trouvé LA super info en montrant que le TCO d’une machine physique est moindre que le TCO d’un EC2 qui tourne tout le temps ?
Refaites les mêmes calculs en intégrant :
Et pour jouer un peu, imaginez que votre site web reçoit moins de requête en week-end et que vous resizez EC2 le week-end pour ça. Et bizarrement, le TCO global est plus du tout en faveur de l’hébergement sur sa propre machine à la fin. C’est le problème quand on compare des pommes et des poires.
#9
En usage pro, le serveur en propre il va aussi tourner tout le temps
Donc il faut compter le salaire du type qui va gérer ça aussi le week-end
#10
Faut aussi rappeler que le distinguo est valable pour les services managés (base de donnée, application…) mais pas pour tous les services…
C’est toujours un peu triste le nombre de personnes qui pensent que parce qu’il sont sur une EC2 c’est magique et qu’ils sont dispensé des taches d’administration ou de s’occuper des sauvegardes
#11
C’est mignon mais pas adapté pour 99% des gens.
Le vrai combat c’est AWX versus OVH/Scality et là tu peux avoir de la perf/coût plus avantageux sans les galère du self hosting.
#12
En usage pro et sur un website relativement statique, une bonne part des gens migrent vers des éléments non-serveur et c’est là qu’est le gain de consommation et de scalabilité est le meilleur. Tout comme pour un tout petit site vitrine sans complexité et sans grande consommation, comparer avec EC2 et pas Lightsail est une erreur.
Et pour le week-end, ça s’appelle l’automatisation. Soit au travers d’Auto-Scaling group, soit en mode blue-green.
#13
L’annonce de la disponibilité du Mac Mini dans AWS EC2 m’a vachement intéressé… avant que je me rende compte de ce que ça pourrait coûter.
Je ne suis généralement pas utilisateur de Mac, mais pour un développement qui devait aussi se retrouver sur iPad, j’avais dû “louer” à l’arrache un Mac dans le cloud via MacInCloud, pour compiler le projet. Ca coûte 24€ pour 2 semaines, sans possibilité de “l’éteindre” pour réduire les coûts. A part si je détruit l’instance, évidemment. Mais on perd ce qui est installé, et comme je devais garder mes clés générées pas Xcode, et que j’en avais besoin sur une petite période en quasi-continu, je gardais l’instance en vie. Donc je payais par tranches de 2 semaines.
Avec cette annonce Amazon, je me suis dit “chouette, j’utilise déjà AWS, ça sera plus simple et en plus j’y gagnerai parce que je ne payerai que ce que j’utilise, j’éteindrai la machine quand je n’en ai pas besoin et du coup je ne payerai qu’un éventuel volume EBS et une IP fixe quand la machine ne tourne pas”… sauf que le Mac Mini EC2, si je comprends bien, c’est pas comme une instance avec vCPUs (genre T2), mais c’est plutôt un hôte dédié, non ? Donc on ne peut pas “l’éteindre”, si ? Enfin, peut-être qu’on peut l’éteindre mais on continue à payer la même somme. A moins de détruire l’instance, comme pour MacInCloud. Je comprends bien (je n’ai jamais loué d’hôte dédié sur AWS) ?
Si c’est bien comme ça que ça fonctionne, envolée la réduction des coûts. Et à ce que je vois, ça coûte déjà 28$ pour 24h. Donc ça me reviendrait presque 14x plus cher que MacInCloud si je dois garder la machine 2 semaines. A moins qu’on puisse garder le volume EBS quand on “détruit” la machine, et qu’on puisse en recréer une au besoin, sans perdre ce qui était installé et configuré ?
#14
Si tu as besoin de Mac juste pour compiler, regarde du coter de Bitrise
On utilisais ça a mon précédent boulot, j’ai mis en place les pipelines etc.. même si j’y connais rien en xcode et mac (je suis sysadmin a la base)
Apres pour les besoins ponctuels je sais pas si ça te conviendra, nous on faisait tourner les pipelines pour valider les branches avant merge, build auto et mise a dispo via Testplan, … donc on en avait besoin tout le temps
#15
Merci, j’irai y jeter un oeil.
Après, c’est vrai que si mes “locations” dépassent une certaine somme, je peux dire “tant pis” et (me faire) acheter un Mac pas trop cher juste pour compiler, tester, etc.