Introduction

Dans les flux de travail précédents, de nombreuses équipes s'appuyaient sur Amazon DataZone pour partager des données à travers AWS. Il aidait à configurer des domaines, à publier des données et à gérer les accès. Récemment, AWS a lancé SageMaker Unified Studio (SMUS).

Il ne s'agit pas seulement d'un nouveau nom. C'est une évolution majeure. SMUS combine l'analytique, l'apprentissage automatique (machine learning) et le catalogage de données dans un espace de travail unique. Ce changement modifie la façon dont les projets, les environnements et les autorisations sont structurés.

Alors que je façonne mon propre parcours professionnel pour devenir chef de projet, je considère ces changements non seulement comme des mises à jour techniques, mais comme des changements fondamentaux dans la façon dont les équipes produit et données collaborent. Dans cet article, nous explorerons ces différences structurelles à un niveau global. Dans nos prochains articles, nous plongerons plus en détail dans la mise en œuvre technique.

La valeur fondamentale du catalogage

Amazon DataZone fournissait un catalogue central de données métier. Les producteurs y publiaient des actifs, et les consommateurs s'y abonnaient en toute sécurité. Le système gérait une grande partie de la gouvernance et des autorisations automatisées à travers les différents périmètres.

SMUS reprend ces fondations et les élargit. Au lieu de cataloguer les données dans un outil et de construire des modèles d'apprentissage automatique dans un autre, SMUS permet aux équipes de faire les deux au même endroit. Les ingénieurs de données et les praticiens du ML partagent désormais le même contexte de projet.

Principales différences architecturales

Si votre organisation prévoit de passer d'une configuration DataZone à SMUS, il y a cinq changements structurels majeurs que les propriétaires de produits (Product Owners) et les décideurs techniques doivent comprendre :

1. Structure de projet et espaces de travail flexibles

Le concept d'environnement a changé. Dans SMUS, un environnement est essentiellement un livre de recettes pour une capacité dédiée. Un projet peut toujours avoir plusieurs environnements, mais la définition d'un environnement n'est plus restreinte au projet lui-même. Il n'est également plus verrouillé à un espace de travail fixe. Cela donne aux équipes beaucoup plus de flexibilité pour faire évoluer et organiser leur infrastructure.

2. Gestion des autorisations et accès externe

DataZone s'appuyait fortement sur la gestion automatique des autorisations. SMUS introduit un transfert de responsabilité. Les utilisateurs doivent désormais s'accorder eux-mêmes les autorisations pour accéder aux actifs de données. De plus, il y a un changement significatif dans la stratégie « Bring Your Own » (BYO - Apportez le vôtre). Cela modifie spécifiquement la façon dont les équipes configurent et gèrent l'accès aux services externes.

3. Base de données de catalogage unifiée

Par le passé, vous pouviez maintenir des bases de données distinctes pour la publication d'actifs et l'abonnement aux actifs. SMUS simplifie cette approche. Les actifs utilisés à la fois pour la publication et l'abonnement sont désormais fusionnés dans une seule base de données. Cependant, si votre logique métier nécessite l'ancienne séparation, vous pouvez toujours implémenter des flux de travail personnalisés pour reproduire les propriétés de DataZone.

4. Le nouveau modèle d'outillage (Blueprint "Tooling")

SMUS introduit un nouveau modèle de base appelé blueprint « Tooling » (Outillage). Cette couche de base est commune à tous les projets. Elle standardise la façon dont les outils de développement et les intégrations sont provisionnés à l'échelle de l'organisation, facilitant ainsi la gestion des exigences logicielles standards par les équipes de plateforme.

5. Fonctionnalités prêtes à l'emploi

Les projets intègrent désormais de multiples fonctionnalités prêtes à l'emploi. Vous avez la flexibilité de sélectionner des fonctionnalités spécifiques en fonction des besoins de l'équipe produit. Vous avez également la possibilité d'activer toutes les fonctionnalités disponibles pour un projet unique en une seule fois, réduisant ainsi le temps nécessaire à l'intégration d'une nouvelle équipe.

Perspectives d'avenir

Ce sont là les changements structurels de haut niveau entre DataZone et SMUS. L'abstraction de l'environnement est différente, les modèles d'autorisation nécessitent une nouvelle approche et les bases de données sont davantage consolidées. Dans ma prochaine série d'articles, je détaillerai chacun de ces cinq points. Je partagerai les détails techniques et les configurations exactes nécessaires pour construire et gérer ces nouvelles architectures.