Bases de données Cloud : Oracle lance le combat des historiques
AWS est l'historique du DBaaS. Oracle celui des SGBD sur site. A l'OpenWorld 2016, la violente charge de Larry Ellison montre que les sirènes d'AWS commencent à préoccuper un Oracle décidé à défendre, bec et ongles, son coeur de métier jusque dans le Cloud.
Larry Ellison s'en est pris plus que violemment au service de bases de données hébergées (DBaaS) d'AWS lors de l'OpenWorld 2016. La preuve, en creux, que le marché du SGBD commence à être sensible à ce type d'offres en mode Cloud et que, d'une certaine manière, cette évolution peut menacer le coeur de métier d'Oracle.
Menacer dans le sens où de nouveaux entrants, puissants, lui font de plus en plus de concurrence.
Certes, Oracle propose depuis deux ans un DBaaS dans son PaaS, et la Release 2 d'Oracle 12c est taillée pour le Cloud et le multi-tenant ("C, c'est pour Cloud", rappelle le CTO). Mais le message était visiblement encore mal passé auprès des clients.
Dans les allées du salon, un speaker d'Oracle sur le stand Big Data va même jusqu'à raconter qu'un visiteur - client d'Oracle donc - étonné, lui aurait lancé "Ha? Mais... vous avez un Cloud ?".
L'anecdote est amusante et certainement pas représentative de l'assemblée de l'OpenWorld. Mais elle traduit la même idée que celle sous-jacente de l'attaque en règle de Larry Ellison contre AWS. Oracle n'est pas encore totalement identifié par le marché comme un acteur majeur du Cloud - comme le sont, eux, Microsoft, Google ou donc, AWS.
L'attaque Ellison
Ceci explique la manière forte qu'a utilisée le fondateur de l'éditeur pour détruire - littéralement - l'offre de Database as a Service d'AWS, en utilisant les ficèles les plus brutales (et les plus efficaces) de la publicité comparative.
Que dit Larry Ellison à ses clients et prospects ?
En résumé, trois choses. Que les bases d'AWS sont moins performantes que les siennes. Qu'elles ne tournent que sur AWS. Et que, bien que s'appuyant sur des produits open source, elles sont propriétaires, et donc captives dès que vous y placez vos données.
On pourra rétorquer que MySQL mis à part, Oracle lui aussi propose du propriétaire. Et que s'il est possible de "transférer" une base Oracle 12c d'une infrastructure sur site à une appliance Exadata ou aux Clouds d'Oracle, de Microsoft... ou d'AWS, il est beaucoup moins aisé de reprendre ses données pour les mettre dans un autre SGBD (SQL Server ou autre).
Mais peu importe, dirions-nous presque. Car le gros de la charge de cavalerie concerne l'architecture sous-jacente et, surtout, les performances et les fonctionnalités. Deux points critiques dès lors que l'on traite des données industrielles ou financières, et qui risquent fort de faire mouche auprès des clients traditionnels d'Oracle qui aiment "que ça marche... et on dira ce que l'on voudra, mais Oracle ça marche" (dixit un DSI d'un groupe du Nord de la France croisé cette semaine à l'OpenWorld).
D'après les évaluations maisons de Larry Ellison, une base Oracle hébergée sur AWS serait 24 fois plus lente en terme de requêtage que la même base placée sur Oracle Public Cloud et 8 fois plus lente pour des tâches transactionnelles (OLTP).
"L'infrastructure d'AWS n'est pas optimisée pour Oracle", ascène Larry Ellison.
Raid rouge contre Redshift
"Mais elle n'est pas optimisée non plus pour ses propres bases", raille-t-il en embrayant sur Redshift, le Data warehouse d'AWS.
"Redshift, qui est en fait un fork propriétaire de PostgreSQL issu de ParAcell - une société de 15 personnes qui a fait faillite et qui a été rachetée par Amazon - est 100 fois plus lent qu'une base Oracle sur OPC", de surcroit sur une configuration AWS avec deux fois plus de coeurs CPU.
"Et en plus, c'est simple de savoir où vous pouvez déployer Redshift et où vous ne pouvez pas déployer Redshift. Même à mon âge, c'est simple de se souvenir d'une liste de 1. Redshift ne tourne que sur AWS."
Pour achever le produit, Larry Ellison frappe une nouvelle fois, avec une certaine justesse il faut bien l'avouer. "Voici les raisons qui font que c'est lent", dit-il en commentant un slide, "je ne vais pas les lire toutes, il y en a trop. Mais en résumé il manque à Redshift des fonctionnalités qu'on a sorties il y a 20 ans. A l'époque les gens utilisaient des cellulaires".
Les 20 ans de retards d'AWS Redshift dixit Larry Ellison
Deuxième produit d'AWS ciblé par le CTO d'Oracle : Aurora.
Haro sur Aurora
Le traitement infligé est identique. "C'est un fork propriétaire de MySQL - et en retour Amazon ne reverse aucune contribution à la communauté. Ce n'est PAS open source", martèle-t-il pour bien faire comprendre - avec plus ou moins de bonne foi - à ses clients potentiels ou indécis que choisir AWS est une option quasiment sans retour.
Côté performances, le benchmark d'Oracle conclue qu'Aurora - "qui n'est disponible que sur AWS", répète le CTO pour ceux qui ne l'auraient pas compris - est 35 fois plus lents qu'Oracle sur OPC en nombre de transactions par minutes. Et là encore, dixit Larry Ellison, "parce qu'il lui manque des fonctionnalités OLTP qu'on a sorties il y a 20 ans".
Les 20 ans de retards d'AWS Aurora dixit Larry Ellison
Ce n'est pas qu'une question de performances. Cela représente aussi des temps de compute plus importants, et donc une facture globale plus élevée à l'usage - parachève-t-il en substance.
DynamoDB épargné
Pour terminer la démonstration de la supériorité du DBaaS d'Oracle, le fondateur de l'éditeur aborde les "workloads mixtes". Sous-entendu, une base Oracle peut faire aussi bien de l'analytique que du transactionnel, celles d'AWS non.
"Faites du transactionnel sur Redshift et le résultats est plusieurs milliers de fois plus lents qu'avec une base Oracle sur OPC. Ce n'est juste pas possible. Cela ne fonctionne pas. Redshift, ce n'est fait que pour l'analytique". Même sanction pour de l'analytique sur Aurora, plusieurs milliers de fois plus lent qu'une base maison.
Fermez le banc.
On s'étonnera juste que la charge de Larry Ellison ne se soit pas continuée avec une comparaison entre Oracle NoSQL et Dynamo DB. Peut-être parce que les résultats sont meilleurs. Ou que la menace sur le NoSQL se fait moins pressente sur un marché moins mature (et moins historique pour Oracle)
L'historique du DBaaS vs l'historique du SGBD
Sur le fond, Larry Ellison n'a pas foncièrement tort et ses benchmarks (PDF) ont intérêt à être solides pour ne pas être attaqués en retour (et en justice) par AWS.
Redshift et Aurora sont propriétaires et leurs usages touchent rapidement leurs limites si on les pousse dans leurs retranchements dans des gros projets industriels ou de BI. Or ce sont bien ces clients que vise Oracle.
Des clients qui, au vue des armes lourdes sorties par l'éditeur, ont testé l'offre "historique" d'AWS dans le DBaaS et ne sont pas encore assez venus sur celle de l'historique du SGBD sur site. En tout cas au goût de Larry Ellison.
Car pour mémoire, Oracle propose désormais trois "services" de bases de données Cloud, qui s'appuient tous les trois sur Oracle 12c : Exadata Express Services (pour les développeurs), Enterprise et Exadata. Le premier étant tarifé à 175 $ par mois, "contre 245 $ pour Aurora".
Quand on pose la question en conférence de presse à Thomas Kurian, Président d'Oracle en charge du développement produits, de savoir comment il réagirait à ces annonces s'il travaillait pour AWS et non pas pour Oracle, sa réponse est simple et neutre : "Je me dirais juste que la compétition se renforce sur le marché" (en vo : "More competition is coming to the market").
Rien de plus ? "Non, que voulez-vous qu'ils disent d'autre ? On n'a pas les mêmes technologies".
Une manière plus policée de faire passer le même message aux clients tentés par le pêché de la concurrence AWS. Plus diplomatique et feutré, certes, mais qui confirme que du côté d'Oracle, le combat des historiques est bel et bien lancé dans le DBaaS. Il s'annonce tout aussi brutal que celui du IaaS. Avec le client comme vainqueur ?
