AWS change | InfoMonde

Après ce qui m’a semblé être une période relativement sèche d’annonces de produits en 2021, AWS a dépensé re:Invent 2022 lancement d’une foule de nouveaux services. AWS Chief Evangelist Jeff Barr, avec l’aide de certains défenseurs des développeurs AWS, a résumé les annonces les plus percutantes parce qu’« il y a tout simplement trop de choses formidables à couvrir pour l’équipe », mais ils ont ensuite dépensé plus de 2 700 mots pour souligner leurs annonces préférées, qui semblaient inclure… tout. En gros, ils ont remis des trophées de participation à chaque équipe de service AWS. Pas particulièrement utile.

Ils auraient pu souligner préparation automatisée des données pour Amazon QuickSight Q, compte tenu de la complexité de la préparation des données pour l’apprentissage automatique. Ou qu’en est-il Lac de sécurité Amazon, qui centralise automatiquement les données de sécurité d’une entreprise à partir de sources cloud et sur site dans un lac de données. Très cool. Qu’en est-il d’Amazon CodeCatalyst, que James Governor, analyste de RedMonk, a raison caractérise comme “un exercice d’emballage” conçu pour améliorer le développement et la livraison de logiciels et conduire à une plus grande commodité (“l’application qui tue”). Aussi, très cool.

Si nous regardons au-delà des milliards de nouveaux services et mises à jour des services existants annoncés par AWS, un thème émergent laisse présager un AWS radicalement différent (et meilleur). Oui, je parle de l’intégration en tant que fonctionnalité essentielle du produit.

Moins d’assemblage requis

AWS avait l’habitude de vanter ses plus de 200 services. Plus maintenant. En fait, il existe probablement près de 400 services AWS actuellement, mais à un moment donné au cours des deux dernières années, AWS s’est rendu compte que le fait d’avoir autant de services compliquait les décisions informatiques des clients au lieu de les simplifier.

Pour ceux qui ne connaissent pas le fonctionnement d’AWS, chaque service (produit) l’équipe fonctionne de manière autonome. Il existe une certaine direction descendante, mais en règle générale, les équipes de service individuelles construisent ce qu’elles pensent que les clients veulent le plus, même si cela conduit à une concurrence inter-équipes. Il s’agit à la fois d’une fonctionnalité (les équipes autonomes peuvent construire plus rapidement) et d’un bogue (les équipes autonomes ne se coordonnent pas nécessairement pour faciliter l’utilisation harmonieuse de plusieurs services AWS). Les clients doivent souvent bricoler des services disparates sans intégration étroite de la manière dont Microsoft pourrait le fournir, par exemple.

Tout cela rend l’introduction de Intégration Amazon Aurora sans ETL avec Amazon Redshift un tel compte-gouttes.

Soyons clairs : en substance, AWS a annoncé que deux de ses services fonctionnent désormais bien ensemble. C’est plus que ça, bien sûr. La suppression du coût et de la complexité de l’ETL est un excellent moyen de supprimer le besoin de créer des pipelines de données. Au fond, il s’agit de faire en sorte que deux services AWS fonctionnent exceptionnellement bien ensemble. Pour une autre entreprise, cela pourrait être considéré comme des enjeux de table, mais pour AWS, c’est relativement nouveau et incroyablement bienvenu.

C’est également un signe de la direction qu’AWS pourrait prendre : une intégration plus étroite entre ses propres services afin que les clients n’aient pas à assumer le poids indifférencié de l’intégration des services AWS.

Faire de la place aux tiers

Cette annonce zéro ETL, aussi puissante soit-elle, aurait été encore meilleure si AWS avait également mis en évidence des intégrations transparentes avec des services tiers tels que Databricks ou DataStax. AWS n’aime peut-être pas utiliser le mot « P » (« plate-forme »), mais cela ne change pas la réalité. AWS est la plus grande plate-forme cloud au monde, et les clients d’AWS s’attendent à juste titre à pouvoir intégrer leur logiciel préféré à AWS.

C’est ce qui fait Zone de données Amazon si intéressant.

Amazon DataZone est un “service de gestion des données qui vous aide à cataloguer, découvrir, analyser, partager et gérer les données dans l’ensemble de l’organisation”. écrit Swami Sivasubramanian, vice-président AWS chargé des données et de l’apprentissage automatique. Ce serait cool si tout ce qu’il faisait était de rassembler toutes les données stockées dans les référentiels de divers services AWS, ce qu’il fait avec des intégrations aux services AWS comme Redshift, Athena, QuickSight, et plus encore. DataZone va au-delà en proposant des API à intégrer à des sources de données tierces de partenaires ou autres.

D’une part, il est évident qu’AWS ont à fournir de telles API, car bien sûr, toutes les données client (ou même la plupart) ne se trouvent pas dans AWS. Dans la FAQ accompagnant l’annonce, AWS a même mentionné que DataZone peut suivre les données de fournisseurs de cloud concurrents tels que Google Cloud et Microsoft Azure. Mais ce n’est pas non plus évident. Après tout, l’industrie technologique a passé des décennies à regarder Apple, Microsoft et d’autres ignorer les produits concurrents en dehors de leurs propres jardins clos. En mettant l’accent sur la nécessité d’accéder à des sources de données non AWS, DataZone pourrait bien être un indicateur avancé du fait qu’AWS va au-delà de l’acceptation à contrecœur de sources de données ou de services tiers pour une adoption emphatique.

Ouverture

Puis il y a eu l’annonce qui n’en était pas du tout une. AWS a annoncé Extensions de langage de confiance pour PostgreSQL sur Amazon Aurora et Amazon RDS. PG.TLE est un kit de développement open source pour la création d’extensions PostgreSQL. Il “donne aux administrateurs de base de données le contrôle sur qui peut installer des extensions et un modèle d’autorisations pour les exécuter, permettant aux développeurs d’applications de fournir de nouvelles fonctionnalités dès qu’ils déterminent qu’une extension répond à leurs besoins”.

Bonne droite?

Ce qui n’a pas été annoncé et ne le sera jamais, c’est le fait qu’AWS est sans doute le deuxième employeur de Contributeurs PostgreSQLjuste derrière CrunchyData. J’ai suggéré avant qu’AWS a de plus en plus ressenti le besoin de contribuer aux projets open source dont dépendent ses services gérés (et ses clients). Les contributions des employés d’AWS à PostgreSQL en sont un bon exemple.

Tout cela suggère qu’AWS devient chaque jour moins insulaire. L’entreprise a toujours considéré « l’obsession du client » comme sa mesure de réussite la plus importante, et parfois les équipes de service ont estimé que la bonne façon d’y parvenir était de créer le meilleur service possible indépendamment des investissements informatiques existants du client, y compris d’autres services AWS. Cela a également conduit certaines équipes à limiter leur implication dans des projets open source en amont et à essayer de livrer une version autonome de ce projet afin de mieux contrôler l’expérience client.

Comme le suggèrent ces annonces et d’autres annonces de re:Invent, AWS intègre de plus en plus la communauté – qu’il s’agisse de partenaires, de projets open source ou même d’autres produits concurrents – dans ses services. C’est très bien pour les clients et très bien pour AWS.