Qu'aimez-vous le plus à propos de Aiven for PostgreSQL?
Le service est simple et facile à utiliser. Il est facile de lancer une instance Postgres dans le service cloud d'Aiven via l'interface utilisateur ou des outils d'infrastructure en tant que code (comme Terraform) et de l'exploiter aux côtés de notre infrastructure cloud existante dans un VPC privé sans accès partagé à Internet.
La fonctionnalité pour l'utilisation des services par les entreprises s'est nettement améliorée ces derniers mois, avec des installations pour le contrôle de groupe partagé d'un compte et des comptes de facturation centralisés, tout comme les trois grands fournisseurs de cloud. J'ai confiance que mes données sont hébergées dans une installation sécurisée par une équipe d'experts qui comprennent profondément les systèmes avec lesquels ils sont intégrés. La console me surprend également avec des fonctionnalités dont je ne connaissais pas l'existence ; aujourd'hui, j'ai découvert qu'Aiven est en avance sur son temps en offrant l'authentification SAML en standard. Bravo pour ne pas exiger un plan tarifaire "entreprise" pour une fonctionnalité aussi essentielle !
Exploiter des services via Aiven n'est en aucun cas l'option la moins chère lorsqu'on considère les coûts bruts du matériel/instance cloud, mais après avoir pris en compte les coûts opérationnels et d'opportunité de l'exploitation de nos propres services de base de données, c'est compétitif. Avis collecté par et hébergé sur G2.com.
Que n’aimez-vous pas à propos de Aiven for PostgreSQL?
Il y a des domaines dans lesquels Aiven pourrait s'améliorer en matière de résidence/gouvernance des données et le sentiment que j'ai concernant la sécurité de mes données lors de l'utilisation des services d'Aiven. J'aimerais également voir des développements dans l'approche technique d'Aiven pour gérer les services afin d'instaurer plus de confiance que ce service protégera adéquatement mes données.
1. Actuellement, les services d'Aiven sont hébergés dans le compte du fournisseur de cloud d'Aiven, et non dans un compte cloud qui m'appartient. Cependant, je ne comprends pas comment nos données sont protégées dans le cas où Aiven cesserait ses activités ou si un acteur compromis à l'intérieur d'Aiven accédait à nos données et/ou les manipulait. Bien qu'Aiven dispose des attestations ISO et SoC auditées appropriées, ces contrôles basés sur des processus ne sont pas les mêmes que des limites strictes sur la capacité d'un acteur malveillant à se déplacer latéralement dans le cas où il accédait malicieusement en tant qu'utilisateur privilégié à votre compte cloud. Cela me laisse une inquiétude résiduelle concernant l'utilisation des services d'Aiven et la considération de protéger les données en faisant mes propres sauvegardes en dehors d'Aiven.
2. J'aimerais avoir la possibilité de "apporter votre propre cloud" comme standard, pour tous les services d'Aiven. Cela prendrait la forme de partager l'accès via les identifiants IAM natifs d'un fournisseur de cloud à un projet et de lier les autorisations IAM appropriées pour permettre à Aiven de lancer et de gérer ses propres instances dans le projet. Bien que cette fonction soit disponible une fois que l'utilisation dépasse un engagement mensuel plus élevé avec Aiven, Postgres est en fait très efficace et il faudra donc beaucoup de temps pour qu'un service largement utilisé et hautement évolutif atteigne ce seuil.
Offrir un service "apportez votre propre cloud" comme standard résoudrait de nombreuses préoccupations autour du point n°1 concernant la propriété des données, car j'aurais l'assurance que mes données sont stockées dans une infrastructure cloud attachée à mon propre compte de facturation. Cette assurance est essentielle dans tous les cas, mais surtout dans les industries réglementées.
En tant que fonctionnalité de produit, Aiven pourrait ensuite offrir une "protection de sécurité du fournisseur de cloud" en proposant à ses services gérés de faire une sauvegarde des instances de production de l'utilisateur dans leur propre cloud vers des compartiments de stockage dans les comptes cloud d'Aiven (tenus sous une facturation séparée d'Aiven). Cela offrirait aux clients la tranquillité d'esprit que leurs données sont transmises en toute sécurité à un compte cloud d'une autre organisation et qu'il y a donc une redondance dans le cas où leur propre compte cloud serait accidentellement compromis ou perdu pour une raison quelconque.
De plus, Aiven devrait fournir un accès direct aux journaux de transactions.
3. En plus des sauvegardes de données, il y a très peu de visibilité sur les contrôles qu'Aiven a mis en place à ce sujet. Aiven dispose d'une excellente fonctionnalité de sauvegarde, y compris des restaurations à un moment donné, mais pour avoir confiance qu'elles sont utilisables, je dois savoir qu'elles sont résilientes à diverses conditions erronées (même byzantines) dans lesquelles un utilisateur pourrait avoir besoin d'y recourir. Encore une fois, les contrôles basés sur des processus sont utiles pour gérer le risque, mais il y a toujours un risque résiduel qui ne peut être éliminé dans le fait qu'Aiven héberge de grandes quantités de données utilisateur et est donc une cible unique à attaquer avec des ramifications potentiellement étendues pour plus que le seul business d'Aiven.
4. La topologie d'Aiven pour Google Cloud Platform semble placer toutes les instances et VPC dans un seul projet du côté d'Aiven. Est-ce évolutif ? Comment les risques sont-ils gérés ici ?
5. La console présente un certain nombre de bugs qui introduisent des dangers opérationnels. Par exemple, le bug lors de la tentative d'activation d'un projet dans le sélecteur de projet que l'utilisateur peut voir (il fait partie d'un compte centralisé) mais pour lequel les autorisations n'ont pas été propagées, donc ils n'ont pas la permission d'inspecter à l'intérieur du projet. Plutôt que de présenter une erreur "Permission refusée" appropriée qui interrompt le flux de travail de l'utilisateur, le sélecteur de projet passera silencieusement au projet suivant auquel l'utilisateur a la permission d'accéder. C'est très dangereux car cela signifie qu'un utilisateur qui croyait accéder à un projet de développement, peut-être pour supprimer une infrastructure, peut être connecté à la place à un projet de production et supprimer par inadvertance la mauvaise instance ! De bonnes pratiques opérationnelles pour vérifier le projet avant des opérations destructrices sont bonnes ici, mais de tels bugs n'instaurent pas la confiance quant à d'autres bugs qui pourraient exister dans la console. J'ai signalé cela au support produit, donc j'espère que cela pourra être rectifié bientôt.
6. Le personnel de support d'Aiven est excellent ! Vous devriez certainement les contacter. Cependant, il n'est pas clair quel est le SLA autour du support, ou comment je pourrais l'améliorer si j'avais besoin d'un SLA plus strict sur les services que je prends d'eux. Avis collecté par et hébergé sur G2.com.
