Caractéristiques principales et disponibilité
Lancement et compatibilité
Amazon Web Services (AWS) a récemment introduit une nouvelle API de données conçue pour les instances de base de données Aurora Serverless v2 et Aurora provisioned. Pour l’instant, AWS propose cette API exclusivement pour les clusters PostgreSQL. Cette orientation stratégique sur PostgreSQL correspond à l’adoption généralisée de cette technologie de base de données par les développeurs qui privilégient la fiabilité et l’évolutivité de leurs solutions de base de données.
Fonctionnalité
AWS a conçu la nouvelle API de données pour simplifier le développement d’applications sans serveur. Les développeurs peuvent désormais exécuter des instructions SQL via un point d’accès HTTPS sans avoir à gérer des connexions persistantes à la base de données ou à configurer des pilotes de base de données. Cette fonctionnalité constitue une amélioration majeure dans la simplification des interactions avec les bases de données, en particulier pour les architectures sans serveur où la gestion des connexions peut devenir lourde et inefficace.
Contexte historique et améliorations
Comparaison avec les versions précédentes
À l’origine, AWS a introduit une API de données avec Aurora Serverless v1. Cependant, l’absence d’une API similaire dans Aurora Serverless v2 présentait des limites pour les développeurs exploitant AWS pour des applications sans serveur. Cette lacune obligeait souvent les développeurs à mettre en œuvre des solutions plus complexes pour gérer les interactions avec les bases de données, ce qui pouvait nuire aux avantages de l’informatique sans serveur en termes d’efficacité et d’évolutivité.
Caractéristiques améliorées
AWS a relevé ces défis en reconstruisant l’API de données pour Aurora Serverless v2 et les instances provisionnées. La nouvelle version prend en charge le basculement des bases de données, ce qui favorise la haute disponibilité et la résilience des applications, de sorte que les bases de données peuvent répondre aux exigences des opérations d’entreprise et des applications critiques sans risque d’interruption pendant les pics de charge ou les pannes de serveur.
La possibilité de fonctionner de manière transparente sur des instances sans serveur et provisionnées offre également aux entreprises la flexibilité nécessaire pour faire évoluer leurs opérations en fonction des besoins, sans compromettre les performances ou la disponibilité.
Limites et retour d’information de la part de la communauté
Limites spécifiques
L’API de données ne prend actuellement en charge que les clusters d’écriture des bases de données Aurora, sans étendre ses capacités aux clusters de lecture. Cette restriction spécifique représente un défi pour les applications qui effectuent principalement des opérations de lecture, ce qui est typique dans les scénarios impliquant l’analyse de données à grande échelle et le traitement des requêtes des utilisateurs. Étant donné que la plupart des applications sont plus sollicitées en lecture qu’en écriture, cette limitation pourrait restreindre l’utilité de l’API dans des cas d’utilisation plus larges.
La disponibilité de l’API de données n’est pas encore étendue aux clusters MySQL ou aux classes d’instance polyvalentes à usage multiple. Ces classes sont souvent utilisées pour des charges de travail variables pour lesquelles la capacité d’augmenter ou de diminuer en fonction de la demande est cruciale.
Sans prise en charge de ces instances, les organisations ayant des exigences dynamiques en matière de charge de travail risquent de trouver l’API moins applicable à leurs environnements.
AWS Performance Insights, un service qui offre des capacités de surveillance des bases de données, ne prend pas en charge la surveillance des requêtes exécutées via la nouvelle API de données. L’absence d’intégration peut entraver l’optimisation des performances et le dépannage, car elle limite la visibilité des performances des requêtes et de l’état du système.
Retour d’information des professionnels de l’industrie
Joshua Moore a fait part de ses inquiétudes quant à la conception actuelle de l’API de données, notamment en ce qui concerne l’absence de prise en charge des grappes de lecture. Dans son commentaire sur X (anciennement Twitter), il souligne que cette limitation a un impact significatif sur les applications nécessitant une lecture intensive. Ces commentaires soulignent la nécessité pour AWS d’envisager d’améliorer l’API afin de prendre en charge les opérations de lecture, et de s’aligner ainsi plus étroitement sur les besoins de la communauté élargie des développeurs et des entreprises.
Rétrocompatibilité et migration
AWS a veillé à ce que la nouvelle API de données RDS conserve une compatibilité ascendante avec la version utilisée dans Aurora Serverless v1. Cette compatibilité est essentielle pour les entreprises qui utilisent actuellement la version précédente et qui envisagent une mise à niveau. La rétrocompatibilité signifie que ces organisations peuvent passer à la nouvelle API sans apporter de modifications importantes à leurs bases de code existantes, ce qui est important pour maintenir la continuité des activités et éviter des temps d’arrêt coûteux.
Recommandations en matière de migration
Malgré la rétrocompatibilité, AWS note des différences entre les deux versions de l’API de données et encourage les utilisateurs à migrer vers la dernière version. La version améliorée offre de meilleures performances, une plus grande évolutivité et un ensemble de fonctionnalités plus robuste, y compris l’élimination de la limite de 1 000 requêtes par seconde, qui limitait auparavant les applications à haut débit.
La migration vers la nouvelle version de l’API permet aux entreprises de tirer parti de ces améliorations pour prendre en charge des charges de travail plus importantes et plus gourmandes en ressources sans rencontrer les goulets d’étranglement associés à la limitation du débit de l’API.
La décision de migrer doit tenir compte de la capacité de l’infrastructure actuelle à s’adapter et à s’intégrer aux nouvelles fonctionnalités de l’API, tout en évaluant le temps d’arrêt potentiel ou la courbe d’apprentissage associés à une telle migration.
Améliorations et spécifications techniques
Suppression des limitations
AWS a supprimé la contrainte antérieure de 1 000 requêtes par seconde sur l’API de données pour Aurora Serverless v2. Ce changement répond au besoin pressant d’applications nécessitant un débit plus élevé, en particulier celles qui traitent de grands volumes de transactions ou d’interactions de données.
Le nouveau plafond de requêtes par seconde est désormais directement lié à la taille de l’instance de la base de données et aux ressources dont elle dispose, ce qui introduit une approche évolutive de la gestion des interactions avec la base de données. Les entreprises peuvent désormais ajuster les ressources de leur base de données en fonction de leurs besoins opérationnels, en optimisant à la fois les performances et les coûts.
Intégration et utilisation
L’intégration de l’API de données avec AWS AppSync est un grand pas en avant dans le développement d’applications plus dynamiques et plus flexibles basées sur les données. Facilitant la création d’API GraphQL qui se connectent directement aux bases de données Aurora, AWS AppSync permet aux développeurs d’utiliser des résolveurs JavaScript pour exécuter des instructions SQL.
Cette configuration simplifie le processus de développement et améliore la capacité de l’application à gérer et à récupérer les données de manière efficace. L’API impose une limite de taille de 64 Ko par ligne dans l’ensemble des résultats renvoyés au client afin que les échanges de données restent gérables et performants dans diverses conditions opérationnelles.
Disponibilité régionale et expansion future
Soutien actuel et accès régional
L’API de données prend actuellement en charge les versions Aurora PostgreSQL 15.3+, 14.8+ et 13.11+, couvrant un éventail de versions stables et largement utilisées qui bénéficient des dernières améliorations en matière de performances et de sécurité. La disponibilité dans les régions clés d’AWS – Virginie du Nord, Oregon, Francfort et Tokyo – permet aux entreprises du monde entier d’exploiter la nouvelle API avec une latence réduite et une conformité accrue avec les normes régionales de gouvernance des données.
Projets d’expansion
À l’avenir, AWS prévoit d’étendre la compatibilité de l’API de données aux clusters MySQL. Cette expansion prochaine permettra à un plus grand nombre d’applications, en particulier celles qui utilisent déjà MySQL, de bénéficier des capacités améliorées de l’API de données. Ces développements vont probablement catalyser l’adoption et l’optimisation des architectures sans serveur dans différents secteurs et cas d’utilisation.
Réception et impact sur la communauté serverless
Les retours de la communauté serverless concernant la nouvelle API de données ont été majoritairement positifs. Les développeurs apprécient cette amélioration, notant le potentiel de l’API à simplifier les complexités traditionnellement associées aux déploiements sans serveur.
En gérant plus efficacement les interactions avec les bases de données sans avoir à maintenir des connexions ou à traiter manuellement de gros volumes de requêtes, les développeurs peuvent se concentrer davantage sur l’innovation et moins sur les défis liés à la gestion de l’infrastructure.
