BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Construire des applications scalables en .NET : FatDB, la plateforme applicative distribuée

Construire des applications scalables en .NET : FatDB, la plateforme applicative distribuée

Construire des applications modernes et scalables peut être une tâche ardue. Les clients attendent haute performance, temps de réponse rapides et accès "toujours disponible" à leurs données. Les équipes de production attendent des applications faciles à configurer, à maintenir, à migrer et à dépanner. Les équipes de développement souhaitent des paradigmes familiers, des API simples, un bon outillage et pouvoir tirer parti des compétences existantes comme de la base de code existante. Enfin, les équipes "métier" demandent un avantage compétitif : ils veulent que les applications soient rentables, permettent un Time To Market (TTM) rapide et soient capables de s'adapter rapidement aux stratégies business changeantes. Dans le passé, il était presque certain qu'une entreprise aurait à sacrifier un grand nombre de ces besoins dans la course vers le déploiement d'une application. Même de nos jours, il est courant de voir un ensemble de technologies disparates rafistolées entre elles, formant un édifice byzantin frêle, lourd et bien trop compliqué. L'explosion actuelle de toutes les technologies Cloud, PaaS ou NoSQL, technologies proposant justement apporter des solutions à ces maux, n'est pas une coïncidence. La dure réalité est que "faire les choses bien", répondre aux attentes de toutes les parties prenantes, est difficile et nécessite l'abandon des vieilles habitudes et l'adoption de nouvelles façons de penser.

La solution FatDB

Il y a environ 6 ans, Wilshire Media, société sœur de FatCloud, a construit quelques-uns des plus importants systèmes de streaming media du moment sur le Web, pour des sociétés comme CBS Radio, AOL et Yahoo. Le développement de ces applications a présenté des caractéristiques et des défis similaires. Nous avons découvert que nous faisions toujours les mêmes choses de projet en projet sans pour autant rendre jamais les projets plus faciles. Nous devions trouver une solution permettant de :

  • communiquer entre nœuds de façon flexible, avec tolérance aux pannes
  • stocker, récupérer et requêter les données et les fichiers
  • mettre la donnée en cache
  • paralléliser et éliminer la latence réseau autant que possible pour les charges extrêmes
  • effectuer des traitements synchrones et asynchrones, sur de multiples threads, pour exécuter une logique métier fréquemment soumise à changements
  • augmenter les capacités d'un cluster ou le reconfigurer avec interruptions de service les plus minimes
  • automatiser la configuration, le monitoring, la maintenance de gros clusters
  • gérer des échéances agressives, là où le TTM était primordial

On en est venu à réaliser que nous pourrions capitaliser et tirer profit de nos travaux précédents, tout en satisfaisant les besoins des parties prenantes et en réduisant les sacrifices faits au cours du processus. Résoudre ces problèmes requérait un concept simple : abstraire et généraliser les caractéristiques essentielles de toute application d'entreprise en une plate-forme éprouvée, réutilisable, performante, tolérante aux pannes, intégrée et distribuée. La charpente de notre approche est ce que nous appelons maintenant Mission Oriented Architecture, ou MOA. Ce framework générique a depuis évolué vers ce qui est à présent connu sous le nom de plate-forme FatDB. Il y a environ deux ans, FatDB a connu son premier test. Cricket Wireless s'est engagé dans une initiative majeure pour la musique sur mobile appelée Muve music, qui sert aujourd'hui plus d'1 million d'abonnés. Le backend de Muve est construit presque entièrement sur la plate-forme FatDB et s'exécute sur des centaines de serveurs. Depuis, nous avons récupéré cette technologie et fondé une société appelée FatCloud. Le nombre d'applications différentes pouvant être créées au-dessus de la plate-forme FatDB est sans limite et l'ensemble des entreprises l'utilisant couvre de nombreux secteurs verticaux. Notre mission est de réduire la complexité et les coûts autour du développement en entreprise en fournissant cette technologie à la communauté Microsoft. Nous voulons aider nos clients à éviter de faire les erreurs que nous avons faites initialement, en leur fournissant un ensemble d'éléments puissants et matures pour construire leurs applications, éléments qu'ils peuvent utiliser pour améliorer radicalement leur façon de mettre sur le marché des applications à l'échelle d'Internet et pour résoudre tous les défis associés.

Donc, quels sont ces éléments qui composent la plate-forme FatDB ? Le cœur du produit peut être découpé en 9 domaines :

  • Core Foundation - Fournit toute la plomberie basique pour toute la plate-forme FatDB
  • FatDB / Cache - Une base NoSQL et un service de cache mémoire
  • FatFMS - Un service de gestion de fichiers distribué
  • FatWQ - Un service de mise en file d'attente et de traitement des jobs, en mode batch asynchrone
  • FatApps - Un SDK, Software Development Kit, et un cadre d'architecture pour les services synchrones, basés sur WCF, Windows Communication Services
  • FatProcessors - Un SDK et un cadre d'architecture pour fournir des routines asynchrones de traitement des batchs s'intégrant avec FatWQ
  • FatDB Management Studio (FatDBMS) - Une interface graphique (GUI) permettant aux utilisateurs de configurer, inspecter, monitorer, requêter, déployer et maintenir leurs serveurs, leurs données et leur logique métier dans chacun de leurs environnements (développement, staging, production, etc.)
  • SQL Integration - Un sous-ensemble fonctionnel de FatDB, FatWQ et FatDBMS permettant aux utilisateurs de préserver et d'étendre tous leurs investissements faits dans SQL Server, de différentes façons, à l'appui des core services de FatDB.
  • Fonctions analytiques de type Map/Reduce - Un sous-ensemble de FatDB, DatWQ et FatDBMS rassemblant la performance nécessaire à du data mining ou autres fonctions analytiques de type Online Analytical Processing (OLAP), qui peuvent aider à distiller de vastes quantités de données en métriques métiers actionnables.

Core Foundation : la plomberie

La Core Foundation est composée d'un ensemble d'API disponibles pour tous les utilisateurs. Cela correspond à tout le nécessaire pour construire nos core services comme FatDB ou FatFMS et pour que nos clients puissent construire leurs propres services. Les fonctions de base sont les suivantes :

  • Portable application host - FatCloud est un hôte applicatif exécuté comme Windows Service. Les points de communication sont implémentés avec WCF afin de présenter un paradigme familier aux développeurs Microsoft. Les services métier WCF peuvent être exposés et hébergés en citoyens de première classe au sein d'un cluster de la plate-forme FatDB.
  • Discovery - Le cluster s'auto-agrège avec des mécanismes de découverte des serveurs (discovery) et de broadcasting en s'appuyant sur différentes stratégies, comme du bavardage entre serveurs, "gossip", soit via multicast UDP (User Datagram Protocol) lorsque possible, soit via un service broker de discovery comme Azure ou via TCP (Transmission Control Protocol)
  • Couches Proxy et Service - Tous les services au sein de FatCloud sont partitionnés en deux couches : la couche proxy et la couche service. La couche proxy route les appels aux serveurs appropriés et la couche service fait le vrai travail en exécutant la logique métier ou en stockant et récupérant les données. Grâce à la séparation claire des deux problématiques, nous avons facilité les stratégies de déploiement, ce qui va nous aider à éliminer les goulots d'étranglement et à répartir la charge via la couche proxy tout en gardant le travail difficile là où il doit être, au sein de la couche service.
  • Routage unifié - La capacité de router tous les appels aux services de façon unifiée couplée aux capacités d'hébergement applicatif de la plate-forme FatDB est une des forces clés du produit et un différenciateur unique. FatDB s'appuie sur une clef de hash SHA 20 bytes pour fournir un localisateur garantissant de façon inhérente la non-collision et une distribution uniforme au sein des groupes de sous-clusters. Ce concept est au cœur de la MOA de FatCloud. De plus, chaque sous-cluster, appelé groupe, est partitionné en shards et en miroirs pour la disponibilité et la tolérance de panne. Les serveurs prennent place au sein d'une grille et, contrairement aux architectures de type "anneau" (ring) ou "maître-esclave" que l'on trouve dans d'autres technologies de ce type, chaque miroir fonctionne en tant que primaire et assure une distribution uniforme. Cette structure permet une excellente scalabilité, la tolérance de panne et une meilleure réactivité, sans aucun "hot spot".
  • API unifiée - La plate-forme FatDB présente un ensemble d'API exposées de façon à ce que le développeur puisse construire des services FatApp et des FatProcessors avec les mêmes fonctionnalités que les core services. Ceci comprend toutes les stratégies d'accès aux appels de services utilisées pour la consistance des données, tels que les accès "quorum", parallèles et séquentiels, aussi bien que les points d'extension et les callbacks permettant les mécanismes d'anti-entropie et de maintenance. La liste est à la fois large et complète. Par exemple, imaginez pouvoir créer une quelconque logique métier, s'appuyant sur des accès "quorum" et s'exécutant sur le serveur-même où la donnée réside, simplement en fournissant une callback d'une ligne et un squelette de code pour le proxy !

FatDB / Cache : la base de données NoSQL

FatDB est notre produit phare. Il s'agit d'une base de données NoSQL multi-modèle, parfaitement consistante et présentant plusieurs fonctionnalités clés :

  • Consistance de données flexible - Il y a une variété de stratégies de consistance de la donnée que l'utilisateur peut choisir pour chaque base qu'il crée. Les niveaux de consistance peuvent aller de la consistance la plus faible à la plus forte et même, mode bientôt disponible, à une consistance globale multi-datacenters.
  • Tolérance de version dans le modèle de données - Dans FatDB, la donnée peut être stockée soit de façon opaque, dans des blobs, soit comme des objets transparents. Nous utilisons ProtoBuf comme mécanisme de sérialisation pour les objets transparents. Puisque nous maintenons des métadonnées pour toutes les versions des objets, il y a de nombreuses possibilités en matière de tolérance de versions dans le modèle de données. Pour faire simple, les utilisateurs peuvent en cours de route ajouter et supprimer des champs de la définition d'un objet sans avoir peur de casser un code client existant ou d'avoir à exécuter des opérations de conversion en masse des données.
  • Locking - FatDB fournit le nécessaire pour poser des verrous au niveau de l'objet, assurant qu'il n'y a qu'une seule mise à jour à un moment donné, ce qui permet de fonctionner à un niveau de consistance forte.
  • LINQ distribué - LINQ est utilisé en tant que syntaxe de requêtage, les champs peuvent être indexés dans la définition des objets. Si une requête LINQ fait référence à un champ qui n'a pas été indexé, une opération similaire à un table scan SQL Server sera invoquée. Il existe aussi la possibilité d'indexer des blobs opaques pour des requêtes rudimentaires. Notre implémentation de LINQ supporte actuellement les projections, le tri, la pagination et supportera bientôt les jointures.
  • Caching - FatDB est, en son cœur, un cache mémoire avec persistance sur disque optionnelle. Il peut être utilisé pour définir une expiration en mode fenêtre glissante ou absolue sur n'importe quelle base de données. À noter, à l'heure actuelle, les requêtes LINQ ne sont pas supportées sur le cache en mémoire seulement (c’est-à-dire non persisté).
  • Intégration SQL - FatDB peut aider à décharger le serveur SQL Server pour les données soumises à des lectures intensives et qui peuvent faire l'objet d'une migration. FatDB peut en effet être utilisé comme magasin de données haute-performance, avec persistance, pour les données SQL migrées. FatDB peut aussi servir de cache mémoire devant SQL Server, pour lectures et écritures. Il peut également servir de cache distribué pour les sessions Web, à la place de SQL Server.
  • Map/Reduce - Grâce à la fonction LINQ distribué, il est possible d'exécuter des requêtes map/reduce relativement simples. L'utilisateur peut créer des instructions basiques pour les mappers et les reducers et les exécuter pour de l'analyse de données rudimentaire sur le périmètre d'un groupe.

FatFMS : Le service de gestion de fichiers

FatFMS est notre système de gestion de fichiers distribué. Au cœur du système, FatFMS consolide toute l'infrastructure de stockage en un sous-cluster et le traite comme s'il s'agissait d'un seul gros disque dur. Quelques aspects de FatFMS sont à relever :

  • Copies multiples - Avec FatFMS, un utilisateur a la possibilité de stocker autant de copies d'un item sur différents disques durs qu'il le souhaite.
  • Récupération flexible - Les utilisateurs peuvent récupérer leurs fichiers par liste d'UNC, d'URL ou par flux.
  • Tag de métadonnées et recherche- Les utilisateurs de FatFMS peuvent placer des tags sur les fichiers avec les métadonnées et rechercher les fichiers correspondant à un ensemble de tags.
  • Intégration SQL - FatFMS peut aider à décharger SQL Server en stockant les objets volumineux en tant que fichiers physiques plutôt que de les garder dans la base SQL Server.

FatWQ : la file d'attente asynchrone

FatWQ est une file haute-performance de jobs, de type batchs asynchrones, et un moteur d'exécution supporté par FatDB, bénéficiant donc de ses avantages. FatWQ travaille directement avec de simples FatProcessors qu'un utilisateur fournit pour exécuter les étapes individuelles du graphe de job. Tout ce qu'un développeur peut coder en C# peut être exposé en tant que job processor. La philosophie du "diviser pour mieux régner" sur un mode asynchrone, est au cœur d'une utilisation efficace de la technologie.

Des exemples d'utilisations possibles sont :

  • Traitement des "leads" d'une équipe de vente
  • Évaluation des portefeuilles de stocks d'une société de courtage
  • Transcodage des fichiers média
  • Détection des fraudes dans des transactions financières
  • Reconnaissance faciale dans des flux vidéo
  • Rendu de frames d'animation
  • Calcul de la N-ième décimale de Pi
  • Ingestion et normalisation des données de senseurs
  • Data Mining ou traitements Map/Reduce
  • Calcul de filtres collaboratifs massifs

Voici quelques fonctionnalités faisant la puissance de FatWQ :

  • Soutenu par FatDB - Puisqu'il s'appuie sur FatDB, il peut de façon certaine traiter les jobs sur le nœud même où la donnée réside avec garantie sur la consistance des données.
  • Proximité des données - Puisqu'il utilise un mécanisme de routage unifié, il peut potentiellement traiter les jobs sur le nœud même où la donnée réside, résultant en un degré de performance beaucoup plus important qu'avec une approche SOA stricte.
  • Graphes de jobs composables - Les étapes individuelles d'un job peuvent être composées en une structure de graphe orienté acyclique s'exécutant de façon parfaitement synchrone, ce qui donne la possibilité d'exécuter des workflows fortement parallélisés.
  • Planification en fonction des priorités - Les jobs peuvent être priorisés dans la file d'attente.
  • Processeurs de jobs - Les utilisateurs peuvent écrire leurs propres processeurs de jobs, qui peuvent prendre en charge un ou plusieurs types de jobs.
  • File d'attente autonome - FatWQ peut être utilisé en remplacement de MSMQ si un utilisateur souhaite décharger le traitement de jobs d'une autre entité ou utiliser le wrapper de job de toute autre façon.
  • SQL intégration - FatWQ peut efficacement prendre en charge la gestion des workflow à la place d'approches basées sur SQL Server, qui ont tendance à être lentes et fragiles.

FatApps et FatProcessors : la plate-forme applicative

La logique métier est une part essentielle de toute application d'entreprise. La plate-forme FatDB permet d'héberger les services WCF, tout en s'intégrant au noyau de la plateforme. En exposant la logique métier de la sorte, l'utilisateur bénéficie de toutes les fonctionnalités de la plate-forme sous-jacente. Toute la plomberie et tout le gros œuvre pour le scaling, le routage et la redondance deviennent partie intégrante du service sans effort pour l'utilisateur. Ces capacités sont de grande valeur : l'utilisateur tire ainsi parti d'une plate-forme intégrée, de la synergie entre les capacités de la plate-forme en matière d'hébergement d'applications et les services du noyau. Pour un trafic de type requête-réponse synchrone, l'utilisateur peut simplement écrire sa logique métier dans un service WCF traditionnel et l'héberger en tant que FatApp. Pour un traitement asynchrone, il n'a qu'à créer, dans une assembly, des classes contenant la logique métier et implémentant une interface simple, avec deux méthodes. Les FatApps, comme les FatProcessors, seront déployées en utilisant FatDBMS sur un groupe de sous-clusters et automatiquement installées sur les machines appropriées. Toute l'application d'entreprise peut être écrite de cette façon, c'est la philosophie. FatCloud build, déploie et se charge du scaling des applications d'entreprise avec pour niveau de cohésion le sous-cluster, ou groupe. Les données et les traitements sont "fusionnés".

Toutes les pièces s'assemblent : Mission Oriented Architecture

L'architecture applicative a évolué du "tout-packagé" en de larges et monolithiques boites vers des systèmes hautement distribués exécutés selon un maximum de séparation des responsabilités. Ceci est l'essence d'une architecture orientée services (SOA) et imite les concepts de la programmation orientée objet (OOP). L'intention derrière la séparation des responsabilités est saine car elle induit une isolation des unités fonctionnelles et promeut un couplage lâche. Cependant, comme dans l'OOP, le mantra prônant la séparation des responsabilités peut aller trop loin… il doit y avoir un équilibre entre la complexité et la performance. Voici trois exemples résultant de l'échec de SOA, tel que couramment pratiqué aujourd'hui :

  • Performance - Si les données sont isolées du traitement, cela induit une latence réseau supplémentaire pour le stockage et la récupération… point. Dans de nombreux cas, cette latence peut s'accumuler au point où les cas d'utilisation nécessitant une latence faible ou un haut débit échouent de façon spectaculaire. Dans d'autres cas, on va être forcé de chercher une solution de scaling qui induira de grosses dépenses dont on aurait pu se passer. Le besoin de combiner traitements et données est précisément la raison d'être des procédures stockées.
  • Configuration et communication - Vouloir tout "à la carte" est une mentalité qui fait fureur de nos jours. Les entreprises veulent combiner la technologie de différents éditeurs et faire fonctionner tout cela. Ce qui est le plus souvent oublié, c'est le simple fait qu'il existe des incompatibilités inévitables entre composants et que, pour que chacun fonctionne correctement, l'utilisateur aura à écrire une foule d'adaptateurs et de couches d'abstraction. Sans une approche intégrée, on obtient généralement un méli-mélo de composants, pléthore de stratégies de communication et des configurations cauchemardesques. Maintenir, modifier ou diagnostiquer un tel système deviendra très difficile et requerra inévitablement les compétences d'ingénieurs de haut niveau.
  • Scaling et changements de cap - Il arrive souvent qu'une application doive augmenter en capacité pour faire face à une demande grandissante. En utilisant les approches traditionnelles "à la carte", il est nécessaire de faire augmenter en capacité chacun des composants, de façon individuelle. Ceci peut s'avérer être une réelle difficulté pour les équipes de production, car cela demande des changements manuels sur les serveurs et les configurations. Pourquoi ne suffirait-il pas d'ajouter des serveurs pour bénéficier de plus de capacités ? Pire encore, il y a le risque de se mettre une épine dans le pied en enfouissant les hypothèses métier sous la complexité de l'architecture. Il devient alors très coûteux pour les équipes de développement de réagir à un changement de cap lorsque les besoins métier évoluent. Beaucoup de temps et d'énergie ont été dépensés pour assembler les composants, il en faudra encore pour désassembler et tout réassembler sous une configuration différente. Une grande part des problèmes peuvent être évités en pensant en termes de regroupements de clients, de données et de logique métier en ensembles cohésifs définis par la mission qu'ils remplissent. Prenons l'exemple d'un site d'e-commerce : parmi les composants à gérer, on trouve les comptes utilisateurs, les listes de souhaits, ce que l'utilisateur aime, ce qu'il n'aime pas, l'historique des commandes, etc. Définissons donc un "groupe utilisateur", contenant toute la logique métier et la plupart des données susceptibles d'être consommées. On sait qu'il y a aussi le catalogue produits et les procédures d'ingestion des données des fournisseurs. Définissons donc un groupe avec cette donnée-là et la logique métier associée. Il y a ensuite le besoin de prendre en charge les commandes et les livraisons, chacun de ces aspects pouvant donner lieu à un groupe. Les transactions financières et le reporting seront eux aussi des groupes à part entière, mais ils s'appuieront sur SQL Server, qui excelle en ce domaine.

En définissant ces groupes, en regroupant les données et la logique métier, on récolte un bénéfice de performance immédiat. De plus, le scaling et les pivots deviennent beaucoup plus faciles car les utilisateurs n'ont qu'à ajouter des serveurs au groupe pour plus de capacité ou à changer les FatApps ou FatProcessors quand ils changent de cap. Enfin, FatDB ayant monté les données sur une plate-forme standard unifiant le routing, le scaling, la configuration, la discovery et la tolérance de panne, les utilisateurs peuvent se concentrer sur la logique métier et ne pas se faire prendre par la règle des 90-90 (c’est-à-dire : les 10 derniers pourcents du projet prennent encore 90% du temps de développement. Crédit : Tom Cargill, Bell Labs). C'est la vision de FatCloud de l'avenir de l'informatique distribuée, qui est pour FatCloud sa version de la MOA.

FatDB Management Studio : aperçu des outils

Une des requêtes les plus fréquentes des clients est de pouvoir bénéficier du meilleur outillage. La gestion au jour le jour des environnements nécessite plusieurs choses, que FatDB met à disposition dans une interface utilisateur, à l'apparence familière (elle ressemble fortement à SQL Management Studio). Les fonctionnalités existantes ou prévues sont :

  • Manipulation des éléments de base - Les utilisateurs peuvent créer, visualiser, configurer, mettre à jour, supprimer tous les éléments de base au sein des clusters, groupes, serveurs, magasins de données, magasins de fichiers, files d'attente, FatApps, FatProcessors et instances de serveurs. Le drag and drop facilite la restructuration et l'organisation des serveurs, des données et des applications et services de logique métier.
  • Inspection et requêtage - Les clients peuvent inspecter, éditer, requêter les magasins de données, de fichiers ou les files avec la syntaxe LINQ.
  • Superviser, maintenir, augmenter la capacité et pivoter - Les utilisateurs peuvent superviser le statut temps-réel des environnements, des groupes, des serveurs et réaliser des tâches de maintenance variées. Ils peuvent aussi ajouter de la capacité ou reconfigurer les groupes et les environnements en temps réel sans être forcés de prévoir une fenêtre d'indisponibilité.
  • Établir des liaisons d'intégration entre SQL Server et le code - Les utilisateurs peuvent facilement s'intégrer avec SQL Server et soulager des goulots d'étranglement en utilisant FatDB en tant que cache, et éventuellement en important des données depuis la base ou en en exportant vers celle-ci. En tant que cache, FatDB peut également gérer les modèles de données des utilisateurs et importer/exporter des objets de transfert de données (DTO) pour servir des fonctions d'ORM. Les packages SQL Server Integration Services (SSIS) sont aussi disponibles pour des opérations de masse.
  • Fonctions analytiques de type Map/Reduce - Les utilisateurs peuvent exécuter des analyses Map/Reduce via de simples instructions LINQ ou en créant de façon visuelle des graphes de jobs dynamiques. C'est l'un des aspects les plus excitants et les plus puissants de FatDBMS, qui devrait connaître une forte activité au cours des mois à venir.
  • Fonctionnalités additionnelles - Il est prévu de se lier à des fournisseurs de IaaS comme Amazon et Azure. De plus FatDBMS va être exposé en tant qu'add-in Visual Studio.

Conclusion

La plate-forme FatDB offre un écosystème complet pour développer des applications .NET modernes et distribuées. FatCloud fournit tous les blocks de construction de base dont une entreprise a besoin pour créer ses solutions complètes, autant pour les nouveaux développements que pour améliorer et faire évoluer les investissements légataires d'une architecture existante, d'un environnement d'hébergement, du matériel et du logiciel. En adoptant l'état d'esprit MOA, une entreprise peut construire une application qui peut à la fois rencontrer plus de succès que les méthodes traditionnelles ou les approches SOA et être plus facile à maintenir, à déplacer vers un autre datacenter ou vers du IaaS, à configurer, à mettre à l'échelle et à adapter fonctionnellement. De plus, les coûts, les risques, les sacrifices et le TTM peuvent être réduits de façon radicale. FatCloud est parmi les premières plate-formes intégrées d'hébergement de systèmes applicatifs distribués qui vont changer radicalement les méthodes actuelles de développement d'applications à l'échelle du Web.

Au sujet de l'auteur

 La passion précoce de Justin Weiler pour la conception, l'architecture et le développement de logiciels d'entreprise l'a conduit à travailler sur quelques-uns des plus importants services de média pour des clients comme CBS Radio, AOL, Yahoo et Cricket Wireless. De ces projets fascinants et stimulants, Justin a tiré les enseignements qui lui ont permis de devenir CTO de FatCloud et contributeur principal à la plate-forme FatDB destinée à accélérer le développement d'applications distribuées et de Cloud Computing. Vous pouvez télécharger FatDB ici ou envoyer vos questions au sujet de FatDB à sales@fatcloud.com.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT