Stockages et manipulations des données dans Microsoft Azure

Dans le cadre de mes activités en clientèle, j’ai très souvent des remarques concernant le stockage ou la manipulation des données dans Azure. Remarques ayant souvent pour source la méconnaissance de la plateforme. A décharge de mes contacts, Azure évoluant très vite et de nouvelles fonctionnalités étant ajoutées régulièrement il n’est pas forcement facile d’être systématiquement à jour !

D’où ce billet pour recenser les différentes options de stockage et manipulation de données disponible dans Azure.

La plateforme de cloud computing Azure de Microsoft fournit donc de multiples fonctionnalités de stockage. Des plus classiques (comprendre historique) aux plus récentes, commercialisées ou non par Microsoft.

A noter que certaines des options évoquées ci-après ne sont pas obligatoirement accessibles dans les 2 portails de gestion de vos sousciptions Azure (l’officiel http://manage.windowsazure.com, ou celui en beta : http://portal.azure.com/)

 

Par Microsoft dans Azure :

• SQL Azure (relationnel en mode ‘cloud’ SAS, compatible SQL Server)
• SQL Server (relationnel en mode serveur dans une/des machine(s) virtuelle(s))
• Azure Storage 
  • Blob : stockage de donnée ‘binaire’ avec metadata. Utilisable en acces type « stream » ou direct (disque)
  • Queue : file de messages
  • Table : stockage de données non relationnel, par entité/colonne, schéma libre, requêtage limité, haute performance, grand volume de données, support transactionnel limité.
• HDInsight : stockage HBase (nosql, transactionnel avec faible latence), prioritairement destiné à être exploité à travers Hadoop pour la manipulation et l’analyse de données façons ‘BigData’
• Cache (en Preview) : base de donnée clé/valeur en mémoire, basé sur Redis
• DocumentDB (en Preview) : base de données NoSQL orienté document en mode SAS.
• Azure Search (en Preview) : moteur d’indexation en mode SAS (accessible uniquement sur le portail beta http://portal.azure.com ). Permet d’indexer vos jeux de données et fournit des fonctionnalités de type intellisense, correction orthographique, recherches par synonymes ou approchants.
• StorSimple : stockage avec appliance hardware local jouant le rôle de cache avec débord persistant dans Azure. Permet d’avoir de gros volume de données stockés dans Azure avec un cache local dans votre infrastructure afin d’optimiser les temps d’accès et donc améliorer les performances des vos applications.
• Recovery Service : destiné à archiver et gérer les backups de vos systèmes

 

Par Microsoft hors Azure :

• OneDrive (indirectement via les apis)
• Office365 (Sharepoint)

 

Autres éditeurs  avec facturation et réservation totalement ou partiellement intégrée (se reporter aux sites des éditeurs pour plus d’informations) :

• ClearDB : base de données relationnelle compatible MySQL en mode SAS.
• MongoDB : (edition Enterprise) base de données noSQL orienté document en mode SAS
• MongoLab : autre commercialisation de MongoDB  en mode SAS.
• RavenDB : base noSQL orienté document en mode SAS
• Oracle DB 12c Standard/Enterprise Edition + Windows Server 2012
• Oracle DB 11g R2 Standard/Enterprise + Windows Server 2008 R2
• Oracle DB 11g Standard/Enterprise + Windows Server 2008 R2
• Oracle DB 12.1.0.1 + Oracle Linux 6.4

 

 

En se référant au classement de db-engines.com (http://db-engines.com/en/ranking), on constate qu’Azure supporte donc directement 4 moteurs de bases de données du TOP5 . A noter que même si PostgresSQL (ainsi que d’autre bases de données plus exotiques) ne sont pas directement accessible à partir du portail de services Azure, il est tout à fait possible de déployer déployer ces bases sur une machine vituelle en mode IaaS (windows ou linux).

Au final, Azure supporte donc 100% des bases de données du TOP 5 db-engines.com.

 

Attention : la plupart des services évoqués ci-avant ont un coût d’utilisation variable. Reportez-vous aux conditions d’utilisations ou de vente de ces services pour obtenir les informations de tarifications officielles.

Les primaires électorales … ou l’intérêt des architectures élastiques

Loin de moi l’idée d’utiliser mon blog technique pour faire de la politique. Au contraire, je vais utiliser un évènement politique pour parler d’architecture logicielle.

Aujourd’hui (dimanche 9/10/11 [jolie suite au passage]), Le parti socialiste organisait le premier tour de leurs primaires afin de choisir un candidat pour la prochaine élection présidentielle française. Les bureaux de vote ne se trouvant pas forcement dans leur lieu habituelle (en mairie), un site web (http://bureauxdevote.lesprimairescitoyennes.fr/) a été mis en place afin de permettre à tout un chacun de trouver le bureau de vote correspondant à son domicile. Initiative louable, et surtout mis en œuvre suffisamment tôt avant le vote pour permettre de tester le site, ou pour le votant de vérifier avant le rush final son lieu de vote.

Malgré cela, l’affluence des visiteurs sur le site ce dimanche à été tel, qu’il a rapidement cesser de fonctionner correctement, renvoyant un message joliment formaté mais totalement inutile pour le potentiel votant :

Cet état a perduré assez longtemps, puis dans l’après midi, la page de recherche a été remplacé par une page HTML pure et dure :

Liste par ailleurs généré directement à partir d’Excel (cf. les méta données), ce qui indique l’incapacité du prestataire ou de l’équipe technique à faire monter en charge rapidement leur site, ou leur hébergement.

 

L’hébergement du site de recherche sur une architecture de type “cloud” aurait permit de profiter de l’élasticité offerte par ces plateformes de cloud computing, c’est à dire la capacité à adapter de manière dynamique la quantité de serveurs (frontaux web dans ce cas) gérant les requêtes de recherche (qui ne devaient pas être si compliqué que cela) à la charge réelle.

Un hébergement dans une plateforme de type Windows Azure aurait en effet permit en quelques clics (et quelque minutes de déploiement) d’augmenter le nombre de frontaux web; et ce soit en anticipation (dès le samedi par exemple), soit de manière dynamique au fur et à mesure de la journée (en fonction de l’état de charge des instances déjà déployées via un monitoring).

 

La prise en compte des contraintes des architectures élastique dans la conception de la page de recherche n’aurait engendrée aucun couts de développement supplémentaire vu la simplicité de la fonction de recherche à implémenter.

Le surcout lié à l’utilisation des ressources du cloud pendant une courte durée aurait été imperceptible par rapport au cout d’organisation d’une telle journée de vote, et – de toute façons – inférieur aux couts développement (à perte) d’un site non évolutif qui n’a pas rendu son service.

A titre d’information, sur la base des couts unitaires de la plateforme Azure, le cout de 10 instances “small” pour 24h aurait été de 24*10*0.0852€ht, soit 20,448€ht (http://www.microsoft.com/windowsazure/fr/fr/pricing/).

A contrario, l’incapacité pour un potentiel votant de trouver facilement son bureau de vote, ou l’image négative véhiculé par un site critique qui ne tient pas la charge et ne rend pas le service attendu aura surement un impact beaucoup plus important.