Dans l’épisode précédent, nous avions parlé de MySQL sur Google Cloud Platform, aujourd’hui nous allons comparer avec la solution proposée par Microsoft sur Azure.
MySQL et MariaDB dans le PaaS Azure
Si on rassemble toutes les bases de données dans le PaaS Azure pour une photo de famille, on obtient ceci :
– La partie de gauche regroupe les solutions basées sur le moteur maison SQL Server. Nous ne manquerons pas de vous parler en détail de ces solutions lors de prochains posts.
– En bas à droite, les bases non relationnelles type MongoDB / CosmosDB, dont on parlera aussi plus tard.
– Et enfin en haut à droite, ce qui nous intéresse, les solutions open-source, avec MySQL et PostgreSQL, mais aussi MariaDB qui fait son entrée dans la liste et qui est en public preview depuis octobre 2018.
Cette offre MySQL / MariaDB reste encore très jeune, MySQL n’étant disponible en General Availability que depuis mars 2018, et MariaDB en preview donc depuis cet automne. Elle couvre les versions 5.6 et 5.7, ainsi que la version 10.2 pour MariaDB.
Les deux solutions sont très similaires sur le plan des fonctionnalités cloud donc je ne ferai pas d’étude séparée. Il reste bien sûr les différences intrinsèques : par exemple les histogrammes de stats sur MariaDB qui n’existent pas dans la version communautaire, etc…
MySQL comme MariaDB ne sont pas déployables dans toutes les régions actuellement, notamment en France où seule la région France Central dispose d’Availability Zones, France South n’étant utilisée qu’en disaster recovery et pour des demandes clientes spécifiques :
Caractéristiques
– Versions 5.6, 5.7, MariaDB 10.2 comme déjà évoqué
– Moteurs InnoDB et MEMORY supportés.
– Mise à jour des releases mineures appliquées en automatique.
– Backups automatiques et restauration à un point dans le temps.
– 4×9% de disponibilité (99.99%) annoncée.
– Scaling dans les 2 sens mais avec des limitations.
Les tiers disponibles
Quelques explications concernant les générations 4 et 5 de processeurs:
– CPU génération 4 : Intel E5-2673 v3 (Haswell) 2.4 GHz
– CPU génération 5 : Intel E5-2673 v4 (Broadwell) 2.3 GHz
Sachant que seuls les gen 5 sont disponible en France.
Attention plusieurs fonctionnalités ne seront disponibles qu’en General Purpose (GP) ou Memory Optimized (MO):
– La géo redondance des backups et la possibilité de repartir sur une autre région en cas de blackout régional.
– Le scale-down : on ne peut pas redescendre en Basic une fois passé en GP ou MO.
– Réplication avec master externe seulement en GP ou MO.
– Des read replicas peuvent être créés seulement en GP ou MO.
On comprend donc que la survivabilité d’une instance en Basic sera très limitée, restreinte à la région dans laquelle elle aura été créée, et dépendra essentiellement des backups automatiques et la capacité à restaurer à un point dans le temps. Si la criticité est élevée , ce ne sera pas le tier à choisir dans le cas d’un déploiement en production.
Le stockage
Là encore, la performance disque va dépendre de la volumétrie choisie, on retrouve la même problématique de sur-dimensionnement du stockage qu’avec GCP.
Le stockage de type Standard ne garantit rien en termes d’IOPS, et quant au stockage Premium, 3 IOPS/Gb sont garantis avec un plafond à 6000 IOPS atteint avec 2Tb de stockage, ce qui reste très en dessous de ce que propose GCP (les 6000 IOPS sont possibles avec seulement 200Gb provisionnés). Mais là encore, en fonction du workload, cela peut suffire. Le problème est que si le plafond est atteint vous n’aurez pas d’autre choix que de travailler à l’optimisation de vos requêtes car il n’y aura plus de levier en termes de stockage.
Autre différence par rapport à GCP, pas d’autoscaling du stockage en cas de dépassement de capacité. En gros si le stockage arrive à 5% d’espace libre restant, l’instance va passer en lecture-seule et plus aucune transaction ne sera acceptée. D’où l’importance de bien mettre en place des alertes pour le suivi de cette partie volumétrie.
Enfin, comme sur GCP le stockage peut être augmenté mais jamais réduit.
Autres limitations
– 5000 connexions simultanées maximum en fonction du tier choisi.
– Privilège SUPER indisponible, sans surprise.
– Chargements via LOAD DATA INFILE ou extraction via SELECT INTO OUTFILE non supporté. Seul LOAD DATA LOCAL INFILE via un chemin UNC Azure est supporté.
– Pas possible de redescendre de tier vers Basic.
– Pas possible de réserver une instance : par exemple 1 an ou 3 ans avec paiement upfront à l’avance. Tout est en pay-as-you-go avec MySQL / MariaDB. Comme la réservation est possible depuis août avec Azure SQL Databases (SQL Server monobase), on peut toujours espérer que ça arrive un jour pour les bases open source …
– Autre surprise en testant MariaDB, pas possible de créer des fonctions ou triggers car les instances sont toutes créées avec le log binaire activé pour assurer la restauration PITR, et cela nécessite d’activer le paramètre log_bin_trust_function_creators qui est disponible pour Azure MySQL mais pas Azure MariaDB. Un oubli ? En tous cas un feedback a été créé espérons qu’il soit pris en compte par les équipes de dev, merci de voter pour appuyer cette demande.
Les coûts
Si on reprend la même configuration quelle celle utilisée lors du premier test sur GCP, on obtient en utilisant la calculette Azure le résultat suivant:
– Région France Central
– General Purpose 16vCores Gen 5 démarrée 24/7
– 80Gb de RAM (5Gb/vCore)
– 200Gb stockage Premium (SSD 600 IOPS …)
– Volume snapshot de 1Tb (backups)
– Redondance Géographique du stockage (GRS, 16×9’s de durabilité)
Le prix pour GCP était de 1670€ / mois pour une config à peu près similaire en dehors de la RAM qui dans le cas d’Azure a un format imposé, et on peut être tenté de se dire que finalement Azure est moins cher de presque 4400€/an…
Mais je vous arrête tout de suite:
– Dans le cas de GCP, il est inclus un failover replica qui est facturé au même prix que l’instance principale. Dans Azure, il n’y a pas de failover replica, comme on va le voir un peu plus loin… Et sans le failover replica, la facture GCP s’élèverait à … 870€/mois.
– 3 IOPS pour 200Gb ça fait 600 IOPS maximum, contre 4500 IOPS dans le cas de GCP.
– Et bien d’autres inconvénients mais je ne veux pas spoiler, il va falloir lire la suite 🙂
Connectivité et outils d’administration
Le déploiement ne prend que quelques minutes. Ensuite pour se connecter il va falloir ouvrir des règles dans le pare-feu, notamment une qui autorise l’accès au port 3306 à l’IP du client. Si le client se trouve sur votre PC, vous pouvez ouvrir votre IP publique en cliquant sur Securité de la connexion -> Ajouter une adresse IP cliente:
Il est aussi possible de mettre des ranges d’adresses.
Ensuite il faudra évaluer l’activation ou non de SSL pour encrypter la connexion, ce qui est évidemment recommandé et activé par défaut:
Pour pouvoir vous connecter il faudra alors récupérer un certificat et le déployer sur le ou les postes clients.
$ mysql --host=mariadb-azr.mariadb.database.azure.com --port=3306 \
--user="capdata@mariadb-azr" --password="********" \
--ssl-ca=c:\ssh\BaltimoreCyberTrustRoot.crt.pem --execute="select version() ;"
+---------------------+
| version() |
+---------------------+
| 10.2.17-MariaDB-log |
+---------------------+
L’accès à l’instance peut donc se faire soit via les outils de commande en ligne (mysql, mysqladmin, etc…) soit via les GUI type SQLYOG ou MySQL Workbench, mais aussi via les API disponibles dans plusieurs langages : ADO.NET, JDBC, Node.js, ODBC, PHP, Python, Ruby, Go, Java….
Quant aux outils d’administration, comme pour GCP, il y a le portal azure bien sûr mais aussi le CLI Az déjà utilisé pour toutes les autres ressources dans Azure. Az permet de piloter les ressources Azure mais pas de s’y connecter à la différence de gcloud. Les 3 branches principales permettent de gérer le niveau instance (server), base (base) et de pouvoir télécharger les logs de requêtes lentes (server-logs):
PS > az mysql server configuration show --name='tx_isolation'
--resource-group='ResGroup_Test'
--server='mysql-azr'
--query='{TXISOL:value}'
--output=table
TXISOL
---------------
REPEATABLE-READ
Accès aux journaux
Seul le log de requêtes lentes est accessible au format fichier. Il est conservé 7 jours et renouvelé chaque jour ou lorsqu’il atteint 7Gb. Le fichier est ensuite téléchargeable via la console :
Ou via Azure CLI :
PS> az mysql server-logs download
--name=mysql-slow-mysql-azr-2018122007.log
--resource-group=ResGroup_Test
--server-name=mysql-azr
Ensuite il sera possible de passer le fichier à la moulinette mysqldumpslow ou pt-query-digest pour avoir une version agrégée. Sachant que le paramètre @@performance_schema est à 1 par défaut sur Azure quel que soit le tier, les requêtes pourront aussi être agrégées manuellement à partir de performance_schema.
Configuration de l’instance MySQL
On trouve en tout 105 paramètres modifiables depuis la console ou Az CLI, contre 54 paramètres sur GCP.
PS > az mariadb server configuration show --name='innodb_adaptive_hash_index'
--resource-group='ResGroup_Test' --server='mariadb-azr'
--query='{VALUE:value}'
{
"VALUE": "ON"
}
Là c’est plutôt une bonne surprise, d’autant que l’event_scheduler est disponible et que performance_schema, certes inaccessible, est bloqué à 1 par défaut. Les paramètres mémoire eux sont sans surprise inaccessibles puisque dépendants du tier choisi.
Parmi les paramètres intéressants on peut noter event_scheduler, histogram_size et histogram_type sur MariaDB, innodb_change_buffering, innodb_fill_factor, join_buffer_size, sort_buffer_size … query_cache_size n’est pas disponible mais il est coincé à 0 donc pas de query cache sur Azure MySQL ou MariaDB, ce qui n’est pas forcément un problème on le sait déjà.
Sauvegarde et Restauration
Les sauvegardes sont gérées en automatique sur Azure, elles ne sont même pas visibles, et on ne peut pas en faire manuellement, ni via la console ni via Az CLI. La politique est la suivante :
– Un backup complet par semaine.
– Un backup différentiel deux fois par jour
– Des backups de logs binaires toutes les 5 minutes.
La rétention des backups est paramétrable de 7 à 35 jours, et le coût du stockage des backups est nul tant qu’il reste égal au volume disque provisionné.
Par exemple si je provisionne 500Gb de stockage, je pourrai utiliser jusqu’à 500Gb d’espace de sauvegarde sans frais additionnels, mais l’allongement de la rétention des sauvegardes utilisera davantage de stockage et donc potentiellement peut ajouter des frais supplémentaires.
Avec un tier General Purpose / Memory Optimized, les backups peuvent être stockés dans plusieurs régions différentes. Mais il faut le spécifier à la création de l’instance, on ne pourra plus revenir dessus ensuite:
Ce backup redondé géographiquement va ensuite pouvoir être utilisé pour remonter une instance dans une autre région en cas de perte de la région nominale. Le tier Basic lui n’a pas le choix et conserve ses backups dans la région d’origine. Si la région est perdue, les backups Azure ne peuvent pas servir à remonter l’instance ailleurs. Donc il faudra prévoir des backups externes via mysqldump ou mysqlpump à partir de la 5.7.8.
Concernant la restauration, le bouton Restaurer ou la commande az [ mysql | mariadb ] server [ restore | georestore ] permettront de ramener l’instance (et donc toutes les bases) à un point antérieur. Par contre on ne pourra pas restaurer sur la même instance, la restauration va créer une nouvelle instance avec un nouveau nom:
Ce qui n’est pas sans complications dans la mesure où une ressource ne peut pas être renommée dans Azure. Cela implique donc qu’il ne faut jamais utiliser le nom de la ressource dans les chaînes de connexion mais plutôt passer par un alias DNS.
Dans le cas de backups locaux, le nouveau serveur cible sera nécessairement dans la même région que le serveur origine. Dans le cas de backups géographiques, le nouveau serveur cible peut se trouver dans une région différente.
Autre problème, une restauration ne remonte ni la configuration, ni les règles firewalls, ni les alertes. Pour l’instant on ne peut pas facilement utiliser le JSON de définition de ces objets pour industrialiser leur recréation, on attend donc que MS les intègre pleinement dans la sauvegarde et la restauration …
Enfin on rappelle un paramètre important qui est une constante sur Azure même pour les autres bases dans le PaaS (SQL Database, PostgreSQL, etc…) : Lorsqu’une instance est supprimée, elle ne pourra plus être restaurée car les backups sont supprimés avec . Pour éviter de tout perdre sur un malentendu, il est possible de mettre en place des verrous logiques :
– Un verrou en suppression…
…qui empêchera un utilisateur de supprimer une instance :
PS > az mariadb server delete --resource-group='ResGroup_Test' --name='mariadb-azr' Are you sure you want to perform this operation? (y/n): y The scope '/subscriptions/6a7dad37-ff9e-4f13-b63d-428d116b139c/resourceGroups/ ResGroup_Test/providers/Microsoft.DBforMariaDB/servers/mariadb-azr' cannot perform delete operation because following scope(s) are locked: '/subscriptions/6a7dad37-ff9e-4f13-b63d-428d116b139c/resourceGroups/ ResGroup_Test/providers/Microsoft.DBforMariaDB/servers/mariadb-azr'. Please remove the lock and try again.
– Et un verrou en modification…
…qui empêchera un utilisateur de modifier les caractéristiques d’une instance :
PS > az mariadb server configuration set
--name='innodb_adaptive_hash_index' --resource-group='ResGroup_Test'
--server='mariadb-azr' --value='OFF'
The scope '/subscriptions/6a7dad37-ff9e-4f13-b63d-428d116b139c/resourceGroups/
ResGroup_Test/providers/Microsoft.DBforMariaDB/servers/mariadb-azr/
configurations/innodb_adaptive_hash_index'
cannot perform write operation because following scope(s) are locked:
'/subscriptions/6a7dad37-ff9e-4f13-b63d-428d116b139c/resourceGroups/
ResGroup_Test/providers/Microsoft.DBforMariaDB/servers/mariadb-azr'.
Please remove the lock and try again.
Haute disponibilité
Attention il n’y a pas de failover replica sur Azure MySQL ou Azure MariaDB. Donc il n’y a rien par défaut qui permet de basculer automatiquement vers un replica préprovisionné en cas de perte de la zone de disponibilité (AZ). C’est une différence importante avec GCP.
Il y a globalement deux cas de figure : un problème à l’intérieur d’une région (problème matériel dans l’AZ, perte de l’AZ toute entière), ou un problème régional (perte de toute la région).
1) Concernant une perte matérielle locale à l’AZ , la doc indique que la remontée du service se fait automatiquement:
| “If a node-level interruption occurs, the database server automatically creates a new node and attaches data storage to the new node. Any active connections are dropped and any inflight transactions are not committed.” |
2) En revanche en cas de perte d’une région, l’issue va dépendre du tier choisi:
– Si vous êtes en Basic (et vous ne devriez pas, mais admettons), il vous faudra avoir pris soin de lancer des backups externes via un client soit sur Azure VM ou on-premise chez vous, en plus des backups automatiques, car ces derniers sont confinés à la région dans laquelle se trouve l’instance.
– Si vous êtes en General Purpose / Memory Optimized, et que vous avez choisi à la création de l’instance un stockage géographique des backups, alors vous pourrez remonter une instance dans une autre région en utilisant ces backups. L’offre garantit un temps de restauration de 12 heures maximum et un RPO de 1hr, le temps de recopier le dernier backup disponible. Testé sur une instance General Purpose et effectivement on peut bien remonter une instance dans une autre région avec un backup à moins d’une heure.
Par sécurité c’est bien aussi de faire des backups via mysqldump de temps en temps et les conserver par exemple sur un storage Azure dans une autre région.
Conclusion : la notion de haute-disponibilité (99.99%) est donc juste valide dans le cas d’un incident local à l’AZ, pas dans le cas d’un incident au niveau régional. On se rappelle que dans le cas de GCP, le failover replica se trouvera dans une autre zone de la même région, donc couvre la perte de l’AZ.
Fenêtres de maintenance
Là aussi il y a une différence importante avec GCP, il n’y a pas sur Azure de fenêtre de maintenance personnalisable par l’utilisateur. On en conclue donc que les instances peuvent être coupées à n’importe quel moment sans préavis.
Seuls les patches mineurs seront appliqués, donc pas de migration automatique de 5.6 en 5.7, et pas non plus de support de MySQL 8.0 ou MariaDB 10.3 ou 10.4 annoncé pour l’instant.
Arrêt et démarrage
Pour moi c’est le plus gros point noir de la solution: on ne peut pas arrêter une instance, si on ne veut plus la payer on est obligé de la … supprimer. Rien que de le dire déjà, on pense à une grosse blague…
Donc si je résume, on est sur un service en pay-as-you-go, pas possible de réserver de la capacité ni de payer un mois ou un an upfront en espérant avoir une réduction, et on ne peut pas stopper le service si on ne l’utilise pas. On est obligé de le supprimer … et le recréer … plus tard ? Sachant qu’on perd ses backups si on supprime une instance…
Donc l’idée d’avoir des environnements hors-prod, ou les environnements qui peuvent être coupés la nuit parce qu’il n’y a pas d’activité, déjà vous pouvez l’évacuer, ça c’est fait. Pas de réduction possible des coûts dans le PaaS de cette manière. La seule façon qui reste est de réduire le dimensionnement des machines: passer de 16 à 2 vCPUs pendant la nuit, pour remonter à 16 vCPUs le matin, etc…
Et ce problème concerne la plupart des services dans le PaaS Azure, aussi bien les bases open-source que les bases SQL Server. Il y a eu évidemment des demandes de modification de la part des utilisateurs, mais pour l’instant c’est closed by design merci au revoir.
C’est moche.
Supervision
Côté métrologie, Azure propose 15 compteurs pour MySQL / MariaDB, essentiellement orientés PaaS et pas particulièrement MySQL: Active Connections, Failed Connections, Backup Storage Used, CPU Percent, IO Percent, Storage Percent, etc… Plusieurs compteurs sont affichables dans le même graphe ou dans des graphes séparés. Les graphes peuvent être exportés sous forme de tableau de valeurs au format excel:
Chaque compteur peut être la source d’une alerte de métrologie, ce qui est particulièrement pratique pour le stockage dans la mesure où il ne s’étend pas tout seul et bloque les mises à jour à 95% de remplissage. Une alerte peut traiter des emails ou SMS en destination, avec un coût annoncé de 0.10 USD par alerte émise (bien que les tarifs pour la France ne soient pas affichés dans la doc). Egalement une alerte sur la limite de connexions autorisées (5000) peut être intéressante.
Pour faire du scale-down de ressources, puisque c’est le seul moyen d’optimiser ses coûts, on peut aussi mettre des alertes sur des seuils de CPU et de mémoire, par exemple moins de 20% sur 16 vCPUs, ou moins de 5Gb de mémoire utilisée, pour savoir quand réduire. Le mettre sur les I/Os ne sert à rien puisqu’on ne peut pas réduire le stockage une fois provisionné.
Pour ce qui est du monitoring des métriques propres à MySQL, on peut reprendre l’inventaire déjà fait pour GCP dans l’épisode précédent:
| Analyse de performance générale | Disponibilité dans Cloud SQL |
|---|---|
| PERFORMANCE_SCHEMA | Le paramètre est bien activé même s’il n’est pas modifiable. |
| VARIABLES DE STATUT | OK |
| SHOW ENGINE INNODB STATUS | OK |
| PARAMETRES ORIENTES PERFORMANCES | plus de paramètres disponibles par rapport à GCP, par exemple join_buffer_size ou sort_buffer_size. |
| Analyse de requêtes | Disponibilité dans Cloud SQL |
|---|---|
| EXPLAIN | OK |
| @@optimizer_switch | Mêmes remarques que pour GCP, BKA est à OFF par défaut, le paramètre n’est pas modifiable en GLOBAL |
| SET OPTIMIZER TRACE=1 | OK (dans la session) |
| Paramètres requêtes lentes | log_queries_not_using_indexes, log_slow_admin_statements, log_slow_slave_statements, et long_query_time sont paramétrables. Le fichier est ensuite disponible au téléchargement via le portal ou Az CLI pour retraitement |
| SET PROFILING=1 | OK |
Replication
Deux types de réplication sont possibles:
– Soit configurer une instance MySQL dans le PaaS comme un slave, à partir d’un master externe, ce qui est plutôt une bonne nouvelle pour les aspects migration notamment.
– Soit configurer des read replicas à partir d’une instance MySQL dans le PaaS. La limite est fixée à 5 read replicas maximum.
Les deux solutions ne sont accessibles que pour les tiers General Purpose et Memory Optimized.
Il y a quelques restrictions par exemple le master on-premise et le slave dans le PaaS doivent tous les deux avoir la même version majeure (tous les deux en 5.6, ou tous les deux en 5.7), le seul moteur autorisé côté master reste InnoDB, les journaux binaires doivent être activés sur le master, mais bon rien de particulier en soi. Comme c’est une réplication asynchrone classique à base de binlog / positions et pas une GTID, il n’y a pas de restriction sur la version du master comme pour GCP.
Côté read replicas, il y a aussi quelques différences annoncées, notamment le fait que le master peut être supprimé indépendamment des read replicas, qui restent en tant qu’instances standalone ensuite. Au départ le replica possède les mêmes caractéristiques que le master en termes de dimensionnement, paramétrage, etc… mais cela peut être changé ensuite.
Enfin, comme pour GCP, le privilège SUPER étant verrouillé il existe un lot de procédures stockées dans le schéma système mysql pour gérer les aspects réplication : CHANGE MASTER TO par exemple est remplacé par la procédure mysql.az_replication_change_master.
Migrer sur Azure MySQL / MariaDB
Dans le cas d’Azure, les possibilités sont équivalentes à ce que propose GCP :
– Soit une migration via mysqldump et restauration dans le PaaS si le temps d’interruption le permet.
– Sinon via une réplication avec un master externe, si les contraintes de version notamment le permettent.
– Il existe enfin un outil sur le portal spécialisé pour la migration de bases on-prem vers le cloud Azure : Azure database Migration Service. Mais le sujet est vaste est mérite un article complet.
Attention on rappelle que pour l’instant MariaDB ne supporte pas les fonctions / triggers, peut être que ce sera adopté avec le passage en GA.
Azure vs GCP, le match
Déjà si on compare les deux configurations du point de vue du coût:
Le simple fait que la solution GCP intègre un failover replica pré-provisionné pour gérer la bascule automatique en cas de perte d’une région, ça change tout au niveau du prix. L’équivalent n’existe pas sur Azure, et si vous ne voulez pas de failover replica dans GCP, il suffit de ne pas cocher la case et l’addition retombe à 870€/mois.
Si on compare au niveau des fonctionnalités principales:
Les avantages d’Azure par rapport à GCP:
– Déjà le fait de proposer MariaDB en plus de la version communautaire. Il y a beaucoup de fonctions sophistiquées dans MariaDB qui n’existent pas chez les autres fournisseurs MySQL à l’heure actuelle.
– Les 35 jours de rétention des backups
– Le nombre de paramètres modifiables plus important que sur GCP.
– Le moteur MEMORY supporté pour les tables temporaires (attention toutefois en cas de réplication)
Les points faibles d’Azure par rapport à GCP:
– Pas de vraie solution de haute disponibilité. Il n’est pas du tout prévu un failover replica même déjà dans une AZ différente et dans la même région. Les 99.99% ne s’appliquent que sur un incident à l’intérieur d’une zone (incident matériel sur un noeud par exemple), pas en cas de perte de la zone toute entière (coupure datacenter), ou de la région (incident réseau général). Dans ce cas seuls les backups géorépliqués sur les tiers General Purpose et Memory Optimized peuvent être utilisés.
– Pas de choix sur les fenêtres d’application des patches. Les mises à jour peuvent donc se faire sans préavis.
– Pas de possibilité de couper un service qui ne serait pas utilisé. On est obligé de réduire le dimensionnement du tier ou heuuu … supprimer les données et les backups qui vont avec.
– Pas de possibilité de restaurer un backup sur l’instance source. La restauration créé une nouvelle instance avec un nouveau nom, avec la complication de gestion des noms de ressource dans les chaînes de connexion ou dans les annuaires DNS.
En conclusion
L’offre PaaS d’Azure pour MySQL ou MariaDB est encore très jeune. Au vu du nombre de suggestions dans le feedback azure (37 en cours pour MySQL et seulement 4 pour MariaDB au 4 janvier 2019), on peut supposer que l’adoption reste pour l’instant très faible. Certaines suggestions expliquent aussi pourquoi les clients préfèrent rester chez le concurrent : l’offre manque de maturité et de souplesse, notamment le fait de ne pas pouvoir stopper le service pour arrêter de le payer. Erreurs de jeunesse, quoi. Il faudra refaire le match dans un an !
D’autant que la course n’est pas terminée, mais il faut reconnaître que jusqu’à aujourd’hui, Cloud SQL sur GCP semble une option bien plus viable pour faire tourner une production MySQL dans le PaaS.
Il nous reste encore à voir un autre concurrent très sérieux : Amazon avec ses solutions RDS MySQL et Aurora MySQL. La suite au prochain épisode !
A bientôt !
David B.
Continuez votre lecture sur le blog :
- MySQL dans le PaaS : le radar de notation des solutions (David Baffaleuf) [AWSAzureGCPMySQL]
- Azure et PostgreSQL en PaaS (Capdata team) [AzurePostgreSQL]
- Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (2/2) (David Baffaleuf) [AWSMySQL]
- Comparatif MySQL dans le PaaS, épisode 3 : Amazon RDS (1/2) (David Baffaleuf) [AWSMySQL]
- Comparatif MySQL dans le PaaS, épisode 1 : Google Cloud SQL (David Baffaleuf) [GCPMySQL]