Technologie Wells Fargo SF Bay Area

écaillage .NET Core Applications et microservices aux performances extrêmes

Pour .NET, Java et Node.js

Par Iqbal Khan
Président et évangéliste de la technologie

Les applications serveur d'aujourd'hui doivent traiter très rapidement un grand nombre de transactions. Beaucoup d'entre elles sont des applications Web desservant des millions d'utilisateurs chaque jour. D'autres sont des microservices desservant des millions d'applications mobiles ou d'appareils intelligents de l'Internet des objets (IoT).

La plupart de ces applications sont désormais déployées dans des conteneurs tels que Kubernetes afin de simplifier et d'automatiser le déploiement, la mise à l'échelle et la gestion. De plus, les environnements de déploiement de choix sont passés des environnements sur site aux principaux clouds tels qu'AWS, Azure, Google Cloud, etc.

Apprenez à développer de telles applications qui répondent aux exigences de performances extrêmes d'aujourd'hui en supprimant les goulots d'étranglement de performances liés au stockage de données et aux bases de données, ainsi qu'à la communication entre les différentes parties des applications Microservices.

Vue d’ensemble

Merci beaucoup Mike et merci Jason de m'avoir donné l'opportunité de parler à un groupe aussi important chez Wells Fargo, le San Francisco Bay Area Technology Group. Comme Mike l'a mentionné, je travaille à Alachisoft et le mot Alachi, j'expliquais à Mike et Jason est une sorte de dérivé du mot hindi Ellachi qui est ou Elaichi, qui est un nom d'épice cardamome. Donc, nous étions en train de nommer l'entreprise il y a de nombreuses années, et nous voulions proposer quelque chose d'unique, alors nous avons proposé Alachisoft.

Notre produit est en fait NCache. Donc, je ne vais pas parler de NCache. L'exposé d'aujourd'hui porte sur « Comment faire évoluer vos applications Web et vos microservices vers des performances extrêmes ? » Si vous développez ces applications en Java, .NET, .NET Core ou Node.js, alors vous êtes au bon endroit.

Qu'est-ce que l'évolutivité?

Alors, essayons de comprendre quelques définitions, avant que je n'entre dans la conversation proprement dite. La première est : qu'est-ce que l'évolutivité ? L'évolutivité est en fait des performances d'application élevées, mais sous des charges de pointe. Ainsi, si votre application fonctionne très rapidement avec seulement 5 utilisateurs, elle n'est pas vraiment évolutive à moins que vous n'ayez les mêmes super performances à une vitesse avec 5000 50,000, 500,000 XNUMX ou XNUMX XNUMX utilisateurs. Si votre application peut faire cela, alors elle est évolutive et évidemment nous voulons que beaucoup de nos applications soient évolutives et j'y reviendrai.

Qu'est-ce que l'évolutivité linéaire ?

La définition suivante est "Qu'est-ce que l'évolutivité linéaire ?" Il s'agit davantage d'une architecture d'application et d'une terminologie de déploiement. Si votre application est correctement architecturée, elle sera évolutive de manière linéaire, ce qui signifie que si vous devez augmenter la capacité de transaction par seconde, combien d'utilisateurs pouvez-vous gérer ? Combien de demandes de candidature pouvez-vous traiter ? Si vous voulez augmenter cela, vous ajoutez simplement plus de serveurs et chaque serveur que vous ajoutez augmente la capacité de transaction par seconde de manière linéaire.

Donc, il n'y a pas de blocage, il n'y a pas de goulot d'étranglement. Évidemment, les courbes de lecture et d'écriture sont différentes, mais elles sont toutes les deux linéaires. Si vous pouvez le faire, votre application est linéairement évolutive et c'est quelque chose que nous voulons vraiment.

Qu'est-ce que la scalabilité non linéaire ?

C'est quelque chose que nous ne voulons pas et c'est si vous avez architecturé votre application d'une manière où il y a des goulots d'étranglement, donc, à mesure que vous augmentez votre charge sur l'application et que vous ajoutez plus de boîtes, quelque chose commence à céder et votre application démarre pour ralentir, en fait, il se bloque même parfois.

Donc, nous ne voulons certainement pas que nos applications soient conçues pour être évolutives de manière non linéaire.

Qui a besoin d'évolutivité ?

Bon, alors, maintenant que nous avons compris ce que signifie l'évolutivité, la prochaine chose à comprendre est, qui en a besoin ? Quelles applications ont besoin d'évolutivité ?

• Applications Web

  Les applications les plus courantes sont les applications Web. Ce sont pour une banque comme Wells Fargo ou d'autres banques avec lesquelles nous travaillons comme le groupe Citi et, Bank of America et, Barclays et, Bank of Tokyo. Ce sont des applications orientées client, vous avez wellsfargo.com, c'est-à-dire pour les services bancaires aux particuliers et les petites entreprises, et ces applications Web doivent pouvoir gérer un grand nombre d'utilisateurs sans ralentir. Il est donc très important que ces applications fonctionnent très rapidement sous une charge extrême.

• Services Web / API Web

  Deuxièmement, les services Web, les applications API Web. Ceux-ci sont généralement là pour desservir de nombreuses applications mobiles ou toute autre application qui les appelle pour effectuer certaines tâches. Donc, si vous avez, disons, Wells Fargo a une application mobile pour les services bancaires aux consommateurs, cette application mobile doit communiquer avec un back-end, et ce back-end aujourd'hui est très probablement des services Web. Évidemment, je ne le sais pas, mais je suppose que oui, car de nombreuses autres banques avec lesquelles nous travaillons se trouvent dans cette situation où les services Web sont ceux qui traitent cette demande d'application mobile. Et, ils ont exactement la même sensibilité. Ils doivent être capables de supporter beaucoup de charge sans ralentir.

• Microservices

  Les microservices sont quelque chose qui est un mot à la mode très chaud ces jours-ci et, je vais en parler un peu plus dans un instant, mais c'est essentiellement, vous réorganisez les services Web d'une nouvelle meilleure façon, laissez-moi dites-le simplement de cette façon en ce moment.

• Applications serveur

  Le quatrième type d'application est toute autre application serveur que vous pourriez avoir. Il se peut que les applications serveur effectuent un traitement par lots. Ceux-ci peuvent également gérer des transactions en direct, mais ils relèvent d'une autre catégorie. Mais, ils ont également le même type d'exigence de débit de transaction par seconde.

Donc, si vous développez l'un de ces quatre types d'applications. Il y a aussi quelques autres, disons, vous pourriez faire de l'apprentissage automatique en direct et de l'IA, mais je ne vais pas en parler dans cette conférence, nous n'avons pas assez de temps. Mais, disons, si vous avez ces quatre applications, vous avez certainement besoin qu'elles soient évolutives. Et, c'est le discours qui va passer sur eux. En ce qui concerne la technologie, les applications Web en général sont développées en Java ou ASP.NET, ASP.NET Core, étant la nouvelle version d'ASP.NET et Node.js et, les trois autres types sont Java ou .NET/.NET Core, les microservices étant soit en Java soit .NET Core parce que c'est la nouvelle technologie.

Introduction aux microservices

Pour ceux d'entre vous qui ne savent pas à quoi ressemblent les microservices, je voulais juste vous en donner une brève vue architecturale. Et, pour ceux qui le font, soyez patients avec moi. Donc, un Microservices, la raison pour laquelle ils deviennent si populaires parce qu'ils vous permettent de décomposer vos applications monolithiques en Microservices de taille octet et, chaque Microservice est découplé des autres Microservices. Et, ce découplage signifie qu'ils ne s'appellent pas. Ils ont leurs propres bases de données généralement logiques. Ils n'ont pas besoin d'avoir des bases de données physiques séparées mais, au moins logiquement, ils ont généralement les leurs. Certains des microservices peuvent utiliser un NoSQL database, MongoDB ou autre chose. Certains d'entre eux utiliseront des bases de données relationnelles, SQL Server, Oracle, DB2. Certains d'entre eux pourraient être dirigés vers les données de l'ordinateur central hérité.

Ainsi, le découplage les oblige à se parler ensuite via une sorte de bus d'événements, ce qu'est ce tuyau sur le côté droit. Et, ils sont appelés par des applications mobiles, des applications Web à page unique ou des applications Web MVC standard en Java, .NET ou Node.js, via la passerelle API. Donc, ce n'est qu'un bon aperçu de ce que sont les microservices. Et, je vais expliquer comment même elles ont les mêmes problèmes d'évolutivité que d'autres applications qui ont traditionnellement eu.

Environnements de déploiement d'applications

Une autre chose que je voulais aborder rapidement parce que je voulais mettre en contexte ce dont je vais parler est les différents types d'environnements de déploiement auxquels nous avons dû faire face au fil des ans. Je fais cela depuis plus de 15 ans maintenant et pendant très longtemps, tout était sur site, dans des centres de données avec un contrôle total. Même maintenant, de nombreuses banques avec lesquelles nous travaillons ont toujours leurs propres centres de données. Mais presque tout le monde migre ou du moins prévoit de migrer vers le cloud. Certaines petites et moyennes entreprises passent au cloud public. De nombreuses grandes entreprises en particulier, encore une fois, les services financiers et les banques préfèrent généralement un déploiement de cloud privé. En fait, certaines des banques avec lesquelles nous travaillons préfèrent un cloud privé sur un framework de type Pivotal Cloud Foundry ou Red Hat Open Stack, ce qui leur donne un contrôle total sur l'environnement de cloud privé, peu importe où le le cloud privé existe. Qu'il existe à l'intérieur d'un cloud public en tant qu'espace loué ou qu'il soit au-dessus de leur centre de données qu'ils ont actuellement, ou qu'il s'agisse d'autre chose, cela leur donne la liberté. Mais, de toute façon, ils vont dans le cloud.

Et, Kubernetes est quelque chose que je vais également aborder plus tard, mais cela devient vraiment un autre mot à la mode, tout comme les microservices. Parce que c'est une technologie très puissante qui simplifie vos Dev Ops. Il vous donne également la portabilité de l'environnement. Ainsi, quoi que vous fassiez une fois, fonctionne dans tous les environnements. Que vous soyez sur site ou dans n'importe quel cloud, vous disposez du même environnement de déploiement qui fonctionne. Et, dans Kubernetes également, de nombreuses banques avec lesquelles nous travaillons préfèrent une offre plus neutre en matière de plate-forme cloud comme Tanzu Kubernetes ou Red Hat OpenShift. Donc, je vais juste passer en revue ces concepts plus tard dans le cadre du sujet d'évolutivité dont nous parlons.

Problème d'évolutivité

D'accord, revenons au problème réel dont nous avons parlé, à savoir, y a-t-il un problème d'évolutivité que nous devons résoudre ? Oui il y a. Mais, ce n'est pas dans le niveau d'application. Ce n'est pas dans l'architecture de l'application. C'est dans le stockage des données, qui devient le goulot d'étranglement. Et, quand je dis le mot stockage de données, je veux dire des bases de données relationnelles ou des bases de données ou des données héritées du mainframe. NoSQL databases, ils n'ont pas le même type de goulot d'étranglement et ils sont de plus en plus utilisés. Mais, malheureusement, ils ne peuvent pas être la réponse à tout ce problème d'évolutivité.

Les goulots d'étranglement de l'évolutivité

Si vous voyez cette image, vous verrez que la raison pour laquelle les bases de données relationnelles et le mainframe hérité sont un goulot d'étranglement est que, contrairement au niveau application, où vous pouvez ajouter plus de serveurs. Disons que vous avez ici les applications Web déployées dans un environnement à charge équilibrée multi-serveurs, vous avez également des services Web et des microservices de la même manière.

Encore une fois, je ne parle pas de leurs environnements pour le moment, je vous donne simplement une répartition logique du fait qu'il s'agit de plusieurs serveurs. Ainsi, en ayant la possibilité d'ajouter plus de serveurs, le niveau d'application ne devient jamais un goulot d'étranglement. Mais, à mesure que vous augmentez la taille de ce niveau, le stockage des données devient de plus en plus un goulot d'étranglement. Et bien que NoSQL ne devient pas un goulot d'étranglement, la raison pour laquelle ce n'est pas une réponse à tous vos problèmes est que, NoSQL vous oblige à déplacer vos données loin du relationnel et loin du mainframe. Ce qui, dans un monde idéal, ne devrait pas être un gros problème, mais c'est un gros problème. La plupart des entreprises ne peuvent pas complètement s'éloigner du relationnel. Ils ne peuvent pas s'éloigner complètement de l'ordinateur central. Ils peuvent utiliser NoSQL car une combinaison de certaines données pourrait être mise en NoSQL database mais une grande partie des données doit continuer à se trouver dans des bases de données relationnelles et dans l'ordinateur central. Et, tant que cela est vrai, cela signifie que quelle que soit la solution d'évolutivité que nous devons trouver, cela ne peut pas être un NoSQL database. Il faut que ce soit autre chose qu'un NoSQL database. Il doit fonctionner avec des bases de données relationnelles et avec la base de données mainframe héritée.

Goulots d'étranglement des microservices

Les microservices, comme je vous ai montré l'architecture, même s'ils ne vous offrent pas une évolutivité intégrée. Même ils ont les mêmes goulots d'étranglement de performances que les services Web ou les applications Web. À moins qu'ils n'utilisent un NoSQL database, ce qu'ils n'auront bien sûr pas, mais même s'ils doivent parler au mainframe pour les données héritées et beaucoup d'entre eux vont continuer à parler aux bases de données relationnelles. Et, ils ont un goulot d'étranglement potentiel supplémentaire qui est le bus d'événements qui est là pour communiquer entre eux.

Si vous avez un environnement de transactions très élevé, ce bus d'événements peut également être un goulot d'étranglement. Si vous n'avez pas la bonne solution mise en place pour le bus événementiel.

Solution d'évolutivité

Donc, il existe heureusement une solution à cela et c'est un cache distribué en mémoire. Et, je vais entrer dans les raisons pour lesquelles c'est? Mais, laissez-moi, juste faire quelques réclamations. La raison pour laquelle il s'agit d'une solution est qu'elle est extrêmement rapide. Il offre une évolutivité linéaire et vous offre une haute disponibilité. Ce sont donc les trois raisons pour lesquelles il s'agit d'une solution au problème d'évolutivité. Et, il y a un avantage supplémentaire que vous obtenez en utilisant un cache distribué en mémoire que dans une grande entreprise comme Wells Fargo, vous pouvez réellement l'utiliser comme une plate-forme de partage de données sur plusieurs applications. Je vais y revenir un peu plus, mais c'est une sorte d'avantage marginal ou comme un avantage secondaire de l'utilisation de cela. La principale raison est l'évolutivité.

Cache Distribué En-Mémoire

Alors, comment un cache distribué en mémoire fournit-il cette réponse ? Comment est-ce la solution à ce problème? La raison pour laquelle il s'agit d'une solution est qu'un cache distribué en mémoire est avant tout en mémoire, il est donc ultra-rapide. En mémoire est plus rapide que même NoSQL databases. Et, deuxièmement, il est distribué. Un cache de distribution en mémoire est en fait une collection de plusieurs serveurs de cache à faible coût. Et, chaque serveur de cache n'est pas un type de base de données d'un serveur. Ce sont plutôt des serveurs web, 4 à 8 cœurs, parfois plus. 16 à 32 Go de RAM. Obtenez-en autant que vous le souhaitez pour chaque application et créez-en une infrastructure ultra-rapide et hautement évolutive pour l'application. Une fois que vous avez le niveau d'applications que vous voyez ici avec les applications Web, les services Web et les micro-services et les bases de données, qu'elles soient relationnelles, qu'elles soient héritées ou NoSQL. Même NoSQL, comme je l'ai dit, n'est pas aussi rapide qu'un cache distribué en mémoire.

Alors, que fait le cache de distribution en mémoire ? Il crée un cluster de ces serveurs de cache et ce cluster regroupe la mémoire, le processeur et même la capacité de la carte réseau de tous ces serveurs de cache. Tout comme le niveau d'application et, tout comme le NoSQL database, bien qu'encore plus facilement que le NoSQL database, vous continuez simplement à ajouter des serveurs de cache au fur et à mesure que votre capacité de transaction augmente. Donc, maintenant, tout à coup, vous avez un redondant et, en plus, parce qu'il est en mémoire, il doit fournir une réplication de données de manière intelligente et j'y reviendrai un peu pour m'assurer que si un serveur de cache tombe en panne, vous ne perdez aucune donnée. Parce que sinon, tout magasin en mémoire n'a pas de valeur. Parce que, si vous perdez des gigaoctets et des gigaoctets de données simplement parce qu'un serveur tombe en panne, ce n'est pas vraiment une solution très attrayante.Ainsi, un cache distribué en mémoire ne distribue pas seulement les données, il les réplique également de manière intelligente sans compromettre les performances et l'évolutivité.

Ainsi, en ayant un cache distribué en mémoire dans le cadre de votre infrastructure, vous avez soudainement la possibilité de supprimer ce goulot d'étranglement, 80 % de vos lectures de données vont au cache distribué. Les 20 % vont aux bases de données réelles car les bases de données sont toujours la source de données principale. Ainsi, toutes les mises à jour que vous apportez à ces données doivent être apportées à la base de données relationnelle de l'ordinateur central hérité ou du NoSQL. Mais, parfois même plus de 80 %, 90 % de votre trafic de lecture ou d'écriture peut simplement être limité au cache distribué. Et, du coup, vos applications ne ressentent plus aucun goulot d'étranglement.

Donc, c'est un peu comme un modèle d'architecture d'application essentiel maintenant, où vous devez avoir un cache distribué en mémoire, si vous voulez que vos applications puissent évoluer.

Évolutivité du cache distribué

Voici quelques-uns numéros de référence d'évolutivité de NCache, où vous pouvez voir qu'avec seulement 4 à 5 nœuds, vous pouvez effectuer 2 millions d'opérations par seconde. Et, comme il s'agit d'une échelle linéaire, si vous vouliez passer à 4 millions, ajoutez simplement 5 nœuds supplémentaires. Et, comme vous le savez, 2 millions d'opérations par seconde est une charge de transaction assez élevée, que la plupart de vos applications, si elles peuvent rester dans cette charge, 90 % de vos applications seront satisfaites dans ce type de charge. Peut-être que certains ne le feront pas et qu'ils ont besoin de plus. Et, lorsqu'ils en ont besoin, ajoutez simplement plus de serveurs.

Utilisations courantes du cache distribué

Donc, j'espère que maintenant, je vous ai convaincu qu'un cache distribué en mémoire est une excellente idée en ce qui concerne une architecture d'application. Donc, la prochaine ou la première question qui vient à l'esprit après cela est, d'accord, comment puis-je en profiter, en tant que développeur d'applications ? Parce qu'il s'agit d'applications. Comment utiliser un cache distribué pour en profiter ?

• Mise en cache des données d'application

  Il existe donc trois manières courantes d'utiliser un cache distribué. Le numéro un est Mise en cache des données d'application. C'est le moyen le plus courant dont je parlais tout à l'heure. C'est-à-dire que, quelles que soient les données que vous lisez à partir de la base de données, vous les conservez dans le cache, donc la prochaine fois, vous les lisez simplement à partir du cache, très simple. Et, quoi que vous mettiez à jour, vous mettez à jour à la fois le cache et la base de données.

  Maintenant, une chose que vous devez comprendre immédiatement, c'est que pour la mise en cache des données d'application, il y a un problème unique qui existe, qui est que maintenant les données existent à deux endroits, l'un est la base de données principale, qui pourrait être votre relationnelle, NoSQL ou mainframe hérité et l'autre est le cache. Ainsi, la première chose qui peut mal tourner est que le cache peut devenir obsolète. Donc, vous avez mis à jour les données, vous avez une application qui ne parle pas au cache, elle va mettre à jour les données dans la base de données et, tout à coup, le cache a obtenu des données obsolètes et les données obsolètes sont vraiment mauvaises. Je suis sûr que vous le savez, plus que n'importe qui d'autre, une banque saurait que les données obsolètes sont très mauvaises. Certaines données obsolètes sont acceptables, mais beaucoup de données obsolètes sont très mauvaises. Donc, c'est la raison pour laquelle la plupart des gens pensent à la mise en cache, la réaction instinctive est que d'accord, je ne vais mettre en cache que des données en lecture seule, qui ne changent jamais ou, au moins pendant la durée de vie de mon application ou quoi que ce soit , dans très longtemps, ça ne changera pas. Eh bien, si ce n'est qu'environ 10%, 15% de vos données totales. Si vous n'allez mettre en cache que 10%, 15%, vous ne profitez pas vraiment d'un cache distribué. Vous devez être en mesure de mettre en cache des données qui changent peut-être toutes les 5 secondes. Ou, même plus tôt que cela. Parce que, même pendant ces 5 à 10 secondes, vous pouvez le lire 10 fois. Et, lorsque vous multipliez cela par des millions de transactions que votre application traite chaque jour, vous économisez autant de déplacements vers la base de données et comment vous allez gagner en évolutivité.

  Ainsi, tout cache distribué qui ne répond pas à ce défi, que le cache ne doit pas devenir obsolète, il doit toujours être frais, va vous obliger à ne pas l'utiliser pleinement. Donc, c'est la première chose à garder à l'esprit.

• Mise en cache spécifique à l'application Web

  Le deuxième cas d'utilisation est l'application Web. Et, l'utilisation la plus courante de l'application Web est brainstorming. Que vous ayez Java, ASP.NET, ASP.NET Core ou Node.js, ils souhaitent tous enregistrer leurs sessions dans un store rapide et évolutif. Et, un cache distribué est un bien meilleur magasin que tout ce qui existe. Que ce soit Java ou .NET ou pas de Node.js. Et, il y a d'autres choses comme, il y a la page mise en cache de sortie. Il existe également des applications Web en direct. Dans le cas de .NET, cela s'appelle Signal R, que vous pouvez utiliser un cache distribué comme plate-forme pour partager les événements.

  Mais, une application Web, lorsqu'elle est autre que la mise en cache des données d'application, lorsque l'application Web stocke ses données dans le cache distribué, elle a un type de problème différent à résoudre. C'est-à-dire que maintenant, il n'y a pas de base de données contenant une copie de ces données. Le cache est le magasin principal. Et un cache étant un magasin principal signifie que si le serveur de cache tombe en panne, vous perdez ces données. Ce qui n'est pas acceptable, vous ne voulez pas perdre une session utilisateur simplement parce qu'un serveur de cache ou un serveur Web est tombé en panne. Si vous souhaitez bénéficier d'une haute disponibilité, vous devez disposer d'un cache capable de répliquer intelligemment ces données sur plusieurs serveurs. Ainsi, si un serveur de cache tombe en panne, vous ne perdez pas ces données. Donc, c'est la partie importante. La mise en cache des données d'application présente un défi différent. La mise en cache spécifique aux applications Web présente un défi différent.

• Pub/Sub Messagerie, CQ & Événements

  Et, le troisième cas d'utilisation est que vous pouvez utiliser et, c'est quelque chose que beaucoup de gens ne savent pas du tout, c'est que vous pouvez utiliser un cache distribué comme un Messagerie Pub/Sub plate-forme et événements. On a parlé et je vais vous montrer que même les Microservices, ils ont besoin de faire du Pub/Sub. Ainsi, s'ils utilisent le cache distribué comme plate-forme de messagerie Pub/Sub en plus de l'utiliser pour la mise en cache des données d'application, la messagerie Pub/Sub ne sera pas un goulot d'étranglement pour eux.

  Il existe de nombreux autres produits de messagerie dotés de nombreuses fonctionnalités de messagerie. Et, un cache distribué ne correspond pas à toutes ces fonctionnalités, mais ce que fait le cache distribué, c'est qu'il crée une plate-forme de messagerie en mémoire très rapide pour les messages qui doivent simplement être partagés dans cet environnement de microservices ou d'application Web. C'est donc un environnement beaucoup plus simple, vous n'avez pas besoin de garder ces messages pendant des heures. Ils doivent juste être partagés dans les prochaines millisecondes peut-être. Mais, il y a tellement d'activité transactionnelle que sans une véritable architecture distribuée en mémoire, la plate-forme de messagerie elle-même devient un goulot d'étranglement. Ainsi, en plus du stockage des données qui est un goulot d'étranglement, votre plate-forme de messagerie est également un goulot d'étranglement. Donc, retiens-le bien. Et, encore une fois, la plate-forme de messagerie a le même problème qu'une mise en cache spécifique à une application Web, à savoir que, généralement, tout ce qui est conservé comme message, n'a pas de copie de sauvegarde dans la base de données. Eh bien, il peut s'agir d'une version transformée de certaines données qui existent déjà dans la base de données et vous pourrez peut-être la recréer, mais vous ne le souhaitez pas. Donc, vous ne voulez pas perdre ces données, vous ne voulez pas perdre ces messages. C'est pourquoi un bon cache distribué doit non seulement être rapide et évolutif, mais il doit également fournir cette réplication intelligente non seulement pour la mise en cache spécifique au Web, mais également pour la messagerie Pub/Sub.

Kubernetes et mise en cache distribuée

Voici comment nous avons un environnement Kubernetes exécutant à la fois des applications Web et des microservices et utilisant un cache distribué. Ainsi, cette zone verte est un cluster Kubernetes. Et, Kubernetes a ce concept de cluster. Dans chaque cluster, vous disposez de plusieurs déploiements. Ainsi, chacun de ces trois rectangles de boîte est un déploiement. Donc, il y a un déploiement d'application Web, il y a deux déploiements de microservices et il y a un déploiement de cache distribué et il y a une passerelle API pour les microservices.

Je ne vais pas entrer dans les détails du fonctionnement de Kubernetes, mais en gros, dans un environnement comme celui-ci, les microservices utilisent le cache distribué à la fois pour la mise en cache des données d'application et pour la messagerie Pub/Sub. Tandis que l'application Web utilise le cache distribué pour la mise en cache des données d'application et les sessions Web.

La plupart des applications Web n'ont pas de Messagerie Pub/Sub car la messagerie Pub/Sub nécessite généralement une sorte de processus de serveur stable pour communiquer entre eux. Mais de toute façon, certains d'entre eux pourraient, mais la plupart d'entre eux ne le font pas. Mais, la même infrastructure de mise en cache que vous avez mise en place pour la mise en cache des données d'application peut être utilisée pour les sessions Web et peut également être utilisée pour la messagerie Pub/Sub et ce sont, dans ce cas, comme vous pouvez le voir, ce sont des instances Docker en tant que pods . Il peut s'agir de boîtiers Windows ou Linux, vous savez, cela dépend de votre préférence dans la direction que vous souhaitez suivre. De nos jours, la plupart des banques migrent tout vers Linux et même .NET Core parce qu'il prend en charge Linux. Vous pouvez maintenant avoir à la fois des applications .NET et Java et bien sûr Node.js sur Linux.

Voici donc à quoi ressemble un environnement Kubernetes à la fois pour les services et les applications Web et pour l'hébergement d'un cache distribué. Une chose que je voulais souligner ici est qu'un cache distribué pour vivre dans Kubernetes doit être compatible avec Kubernetes. Il doit avoir implémenté ce qu'ils appellent un opérateur Kubernetes. NCache a-t-il. Et donc, quel que soit le cache distribué que vous regardez, assurez-vous qu'il est compatible avec Kubernetes.

Présentation de la mise en cache des données d'application (API)

Donc, c'est ma seule diapositive de codage. Je ne vais pas entrer plus dans le codage que cela. L'idée générale est que, d'accord, la mise en cache des données d'application est le principal cas d'utilisation du cache distribué, que chaque application que vous développez devrait utiliser. Qu'il s'agisse d'une application Web, de services Web ou de microservices. Et, vous pouvez voir qu'il s'agit d'une API très simple dont dispose un cache distribué.

• Connexion au cache

  ICache cache = CacheManager.GetCache(“myDistributedCache”);
  cache.Dispose();

• Récupération des données

  Employee employee = cache.Get<Employee>("Employee:1000"); 
  bool isPresent = cache.Contains("Employee:1000");

• Écrire des données

  cache.Add("Employee:1000", employee);
  cache.AddAsync("Employee:1000", employee);
  
  cache.Insert("Employee:1000", employee);
  cache.InsertAsync("Employee:1000", employee);
  
  Employee employee = (Employee) cache.Remove("Employee:1000");
  cache.RemoveAsync("Employee:1000");

Vous avez un handle de cache, vous faites cache.Get, cache.Contains. Il y a une clé qui est généralement une chaîne et, vous récupérez une valeur et une valeur peut être soit un objet, soit un objet .NET, soit un objet Java, soit un document JSON. Node.js fonctionne évidemment en JSON. Mais, vous pouvez même faire en sorte que les applications .NET et Java stockent leurs objets ou leurs données au format JSON. Et cela vous permet même de l'utiliser comme plate-forme de partage de données car vous avez une application Java qui stocke, disons, un objet client qui était un objet client Java. Lorsqu'il est stocké dans le cache distribué, disons, comme NCache il est transformé en un document JSON, puis lorsqu'un Node.js ou une application .NET ou .NET Core l'application veut le récupérer, ils l'obtiennent… Disons, .NET Core l'application l'obtiendra en tant qu'objet client .NET ou document JSON et Node.js obtiendrait probablement un document JSON de toute façon. Donc, la simplicité est là, obtenez, ajoutez, insérez, supprimez aussi simple que possible. Ainsi, la courbe d'apprentissage est très rapide dans l'utilisation d'un cache distribué.

Fonctionnalités de la mise en cache des données d'application

Je vais juste passer rapidement en revue quelques-uns des domaines clés de la mise en cache des données d'application car, si vous envisagez d'utiliser le cache distribué, le cas d'utilisation le plus important est la mise en cache des données d'application. Et, de quoi devez-vous être conscient ? Le numéro un, comme je l'avais mentionné, il y a deux copies des données une dans la base de données une dans le cache, alors comment gardez-vous le cache à jour ?

• Expirations (absolues et glissantes)

  Le numéro un est une fonctionnalité appelée Expiration que presque tous les caches distribués ont comme fonctionnalité et, généralement, c'est le Expiration absolue. Certains l'appellent TTL ou ou time to live expirations. L'autre expiration s'appelle Expiration glissante ce qui n'est pas pour la mise en cache des données d'application, c'est plutôt pour le type de session d'une situation où vous souhaitez faire expirer l'objet si personne ne l'utilise pendant un certain temps. Mais, l'expiration absolue, vous dites au cache que je sais que ces données que je mets en cache ne vont pas changer pendant les cinq prochaines minutes ou pendant les cinq prochaines heures ou 24 heures. Quelle que soit la nature des données, vous pouvez le spécifier. Et, à la fin de cette période, le cache expirera automatiquement. Ainsi, l'application peut simplement l'ajouter et passer à autre chose. L'application n'a pas à se soucier de garder une trace de toutes ces données. C'est donc le minimum que chaque cache devrait avoir et la plupart d'entre eux l'ont. Mais le problème ou la limitation des expirations est que vous ne faites qu'une supposition éclairée. Dans certains cas, ça va parce que les données ne changent pas aussi souvent mais, comme je l'ai mentionné plus tôt, le véritable avantage réside dans la mise en cache des données transactionnelles. Ainsi, dans les données transactionnelles, vous voulez pouvoir être plus précis.

• Synchroniser le cache avec la base de données

  Une autre fonctionnalité qu'un cache distribué devrait avoir est qu'il doit être conscient de votre base de données dans une certaine mesure, afin qu'il puisse se synchroniser avec les données qu'il a mises en cache, si ces données, les données correspondantes dans la base de données changent, alors le cache devrait automatiquement supprimer cet élément du cache, de sorte que la prochaine fois que votre application le voudra, elle ne le trouvera pas dans le cache et sera obligée de l'obtenir de la base de données ou le cache devrait recharger une copie de ce. Et, le rechargement n'est possible qu'à travers une autre fonctionnalité dont je vais parler, ça s'appelle lecture et écriture. Mais, si vous pouvez synchroniser le cache avec la base de données.

  Il existe donc deux façons de synchroniser. L'un est basé sur les événements. Ainsi, la plupart des bases de données de nos jours ont maintenant les événements de changement de données. SQL Server l'a, Oracle l'a, MongoDB, Cosmos DB, ils l'ont tous. Cosmos DB l'appelle, je pense, changer de flux, MongoDB l'appelle changer de flux et SQL Server l'appelle Dépendance SQL et Oracle, je pense l'appelle Notifications de base de données ou quelque chose du genre.

  Ainsi, si votre cache distribué tire parti de ces fonctionnalités dans la base de données, il peut créer une sorte de relation entre ses éléments mis en cache et les jeux d'enregistrements de la base de données. Ainsi, lorsque ces données changent, la base de données informe le cache distribué que ces données ont changé, veuillez prendre soin de votre propre copie. Ainsi, votre cache peut soit le supprimer, soit le recharger à partir de la base de données et si la base de données n'a pas d'événements en tant que fonctionnalité, vous pouvez utiliser l'interrogation comme un autre mécanisme.

• Gérer les données relationnelles

  La troisième chose que vous voulez faire est que si vous mettez en cache des données relationnelles, il y a des problèmes d'intégrité des données liés aux relations, un à plusieurs, un à un. Donc, si vous pouvez dire au cache que cet article, j'ai cet objet client et j'ai cet objet commande, ils sont liés. Ainsi, si l'application supprime l'objet client, le cache supprime automatiquement toutes les commandes. Donc, de cette façon, il n'y a pas, vous savez, ce que vous appelez des références pendantes dans le cache. C'est des trucs comme ça, si vous pouvez faire ça, alors votre cache sera à nouveau toujours frais.

• Requêtes SQL

  Ainsi, avec ces fonctionnalités, si votre cache possède au moins les deux premières fonctionnalités, vous aurez la confiance nécessaire pour mettre tous les types de données dans le cache. Et, une fois que vous aurez cette confiance, vous commencerez à mettre beaucoup de données dans le cache. Et, une fois que vous avez mis beaucoup de données dans le cache, un autre problème survient, qui est maintenant de trouver des données basées sur des clés n'est plus suffisant. Donc, vous voulez pouvoir trouver des données comme vous pouvez les trouver dans la base de données, c'est-à-dire des requêtes SQL. Pour .NET, .NET Core il y a aussi un LINQ. Donc, si vous pouvez rechercher des données en fonction des attributs d'objet. Vous pouvez dire quelque chose comme donnez-moi tous les objets client, où la ville est San Francisco. Ensuite, il agit plus comme une base de données. Il existe également des données de référence que vous pouvez rechercher. Il y a beaucoup de données de recherche que vous pouvez rechercher. Donc, si vous pouvez rechercher les données, le cache devient maintenant plus convivial. Vous vous sentez plus en confiance pour mettre en cache de plus en plus de données parce que vous pouvez les trouver. Parce que, si vous ne pouviez pas faire de requêtes SQL, alors votre application devenait soudainement très compliquée. Vous devez garder une trace de chaque clé que vous avez stockée.

• Groupes, balises, balises nommées

  L'autre aspect est à nouveau dans la même relation, c'est que vous voulez pouvoir regrouper des données liées afin de pouvoir les récupérer toutes en même temps. Ainsi, différents caches distribués fournissent ce concept de groupes et de balises et de balises de nom que vous pouvez ensuite obtenir tout ce qui correspond à cette seule balise. Ou supprimez tout du cache ou récupérez-le depuis le cache. Ainsi, par sa capacité à trouver rapidement des données, autres que les clés, cela devient très important une fois que vous commencez à mettre en cache de plus en plus de données.

• Lecture et écriture

  C'est la fonctionnalité dont je parlais, la fonctionnalité de lecture et d'écriture. L'importance de cette fonctionnalité est que, disons… Permettez-moi d'abord d'expliquer ce que c'est. Ainsi, lorsque vous avez un cache distribué, si vous ne disposez pas de cette fonctionnalité, votre application lit toutes les données, les met dans le cache et met également à jour la base de données avec. Mais, à mesure que vous rendez le cache de plus en plus pertinent pour plusieurs applications, maintenant le cache est censé… si le cache peut devenir plus autonome, il peut prendre soin de lui-même, alors cela simplifie les applications. Ensuite, vous avez plusieurs applications qui traitent simplement ce cache comme une représentation en mémoire de toutes les sources de données principales. Vous savez, comme ils pourraient, comme je l'ai dit mainframe, relationnel ou NoSQL. Ainsi, ils accèdent à ce cache distribué en mémoire en tant que magasin de valeur clé, ce qui est très simple, tout est en mémoire, donc c'est super rapide et le cache distribué est capable de lire les données, si elles ne sont pas disponibles pour lire -through est quelque chose c'est votre code qui est enregistré sur le cache distribué. Ainsi, le cache distribué appelle votre code, il va dans la base de données et lit l'élément correspondant. Donc, disons que vous faites un cache. Obtenez une certaine clé et que cet élément n'était pas dans le cache, le cache appellera la lecture pour aller le chercher dans la base de données.

• Écriture derrière

  De la même manière, vous pouvez également utiliser le cache pour mettre à jour les données non seulement dans le cache, mais également pour mettre à jour le cache dans la base de données. Et, l'écriture différée en est une version plus avancée où la mise à jour du cache se produit de manière synchrone mais la mise à jour de la base de données se produit de manière asynchrone.

• Chargeur de cache / Rafraîchissement

  Le chargeur et le rafraîchisseur de cache sont encore une autre façon de réchauffer le cache. Lorsque vous démarrez le cache, vous le remplissez avec toutes les données que vous savez que vous aurez toujours. Ainsi, de cette façon, vous n'avez pas à appeler la lecture continue à chaque fois. Ainsi, une fois que vous avez chargé ce cache avec, disons, des millions d'objets, le rafraîchissement du cache est une autre fonctionnalité qui peut périodiquement mettre à jour certains sous-ensembles de ces données, en fonction des règles métier que vous spécifiez. Ceux-ci peuvent être basés sur des événements, ils peuvent être basés sur le temps, quelle que soit votre logique métier. Vous pouvez dire, d'accord, allez chercher une copie plus récente des données à partir de la source de données principale.

  Maintenant, dans bon nombre de ces situations, vous aurez ce scénario où si les données ne sont pas très sensibles pour l'entreprise, il est normal d'en avoir une copie obsolète, s'il n'est pas trop tard ou trop retardé. Mais avec ces trois fonctionnalités, la lecture, l'écriture et le chargeur/rafraîchissement de cache, vous disposez soudainement d'un cache très intelligent. Il peut entrer et se charger à partir de plusieurs sources de données et se rendre disponible non seulement dans l'application, comme je l'ai déjà mentionné, mais dans plusieurs applications.

Plateforme de partage de données

Donc, il y a plusieurs applications, comme je l'ai mentionné plus tôt, c'est l'avantage secondaire. L'avantage marginal de l'utilisation d'un cache distribué en mémoire. Alors qu'est-ce que cela signifie? Cela signifie que le cache distribué devient désormais une infrastructure commune à plusieurs applications. Ainsi, lorsque les applications doivent partager des données entre elles, au lieu de s'appeler ou d'accéder à leurs bases de données, placez-les simplement dans un magasin de valeurs clés très simple à comprendre, qui est en mémoire, super rapide, hautement évolutif. Et, parce que toutes les fonctionnalités que j'ai mentionnées, la lecture, l'écriture, le chargeur de cache, le rafraîchissement, toutes les autres recherches SQL, tout cela en fait une base de données, mais ce n'est pas une source de données principale.

Ainsi, dans la plate-forme de partage de données, le cache n'est pas le maître. Il ne s'agit que d'une copie d'autres maîtres, mais il n'est destiné qu'à des fins de partage. Et je sais que de nos jours, de nombreuses entreprises se concentrent beaucoup sur la consolidation de plusieurs applications pour avoir une vue commune, une fonctionnalité commune.

Je sais que de nombreuses banques à qui nous avons parlé souhaitent que le parcours client soit compris à travers plusieurs applications. Alors, comment ces applications communiquent-elles entre elles ? Quel est ce point central où ils peuvent partager des données entre eux ? Il doit s'agir de quelque chose en mémoire. Si ce n'est pas en mémoire, ce sera encore un autre goulot d'étranglement. Et la beauté de la mémoire est que vous pouvez toujours la redémarrer et qu'il n'y a aucune perte de données. Parce qu'il ne fait que recharger les données des sources de données principales. Mais, il se rendra disponible. Et, comme il est redondant, il se réplique sur plusieurs serveurs. Vous savez, la probabilité de perdre entièrement un cache distribué est très très faible. Et, je vais passer en revue certaines des autres fonctionnalités où vous pouvez réellement avoir le même cache en direct dans plusieurs régions, plusieurs centres de données, un à San Francisco, un à New York et ainsi de suite. Et, de cette façon, si vous avez une situation de reprise après sinistre, je sais que j'ai vu dans les nouvelles qu'il y a quelques années, vous avez dû faire face à un arrêt assez important. Eh bien, de telles situations exigent que vous disposiez d'une véritable reprise après sinistre. Donc, tout doit être reproduit dans plusieurs régions. Et, lorsque vous utilisez un cache distribué à des fins de partage de données, ce cache distribué doit également être répliqué pour plusieurs raisons, j'y reviendrai. Mais, c'est un avantage marginal très très important pour les grandes entreprises, en particulier comme Wells Fargo, pour rassembler plusieurs applications. Et, encore une fois, vous pouvez en avoir plusieurs parce que, vous êtes une si grande entreprise, vous n'avez peut-être pas un seul maître pour toute l'entreprise ou vous le pouvez. Ou vous pouvez en avoir plusieurs dans certaines parties de votre entreprise pour partager des données.

Architecture de cache distribué

Maintenant que j'ai parlé de toutes les manières dont vous pouvez utiliser un cache distribué, à quoi devez-vous vous attendre dans un bon cache distribué en termes d'architecture ?

Haute Disponibilité

Le premier est la haute disponibilité. Parce qu'un cache distribué est utilisé dans des environnements de production en direct, s'il ne vous offre pas une disponibilité vraiment élevée, vous devez être très sceptique à son égard et la haute disponibilité signifie que le cluster créé par le cache distribué doit avoir un homologue. architecture homologue. S'il n'a pas d'architecture peer-to-peer, s'il y a un truc maître-esclave, alors une fois que le maître meurt, vous savez, ces esclaves deviennent en lecture seule ou inopérants. Ainsi, la possibilité d'ajouter ou de supprimer un serveur, n'importe quel serveur au moment de l'exécution, est très critique.

Évolutivité linéaire

Le numéro deux est l'évolutivité linéaire et cela vient en partitionnant les données. Je vais simplement passer à la diapositive suivante et en parler. Ainsi, le partitionnement se fait de deux manières, l'une juste partitionnant sans réplication et la seconde partitionnant avec réplication. Ainsi, un cache distribué, comme je l'ai mentionné, vous offre une redondance et une réplication intelligente.

Quelle est cette réplication intelligente ? La réplication intelligente signifie que chaque donnée est… les données sont partitionnées et chaque partition est sauvegardée sur un serveur différent et tout cela est dynamique. Donc, c'est de l'auto-guérison. Ainsi, lorsque vous ajoutez un nouveau serveur, une nouvelle partition est créée et de nouvelles répliques sont créées et les données sont automatiquement équilibrées.

Alors, voici un exemple. Supposons que vous ayez commencé avec un cluster de cache à deux serveurs et que vous vouliez en ajouter un troisième car votre charge de transaction augmente. Dès que vous ajoutez un troisième serveur, il crée automatiquement une troisième partition. Vous avez maintenant trois partitions. Ainsi, les répliques doivent également le réajuster. Tout cela se passe dynamiquement ou automatiquement.

Et, de la même manière, disons, vous le voulez ou un serveur est tombé en panne pour une raison quelconque. Disons que le serveur 3 est tombé en panne, la partition 3 est en panne. Dès que la partition 3 est arrêtée, la réplique 3 devient active. Et, maintenant vous avez une anomalie où vous avez deux serveurs et trois partitions. Donc, maintenant, il doit se fusionner automatiquement en deux partitions et deux répliques. Tout cela devrait être fait automatiquement sans aucune intervention humaine. S'il nécessite une intervention humaine, il n'est pas vraiment hautement disponible. NoSQL databases, parce qu'il s'agit de bases de données qui doivent gérer un stockage persistant d'un grand nombre de données, elles ne fournissent pas ce repartitionnement dynamique. Et, c'est bien pour un NoSQL database. Mais ce n'est pas acceptable pour un magasin en mémoire. Le magasin en mémoire doit être beaucoup plus rapide, beaucoup plus agile pour monter et descendre en termes de nombre de serveurs.

Réplication WAN

Voici cette haute disponibilité où vous avez plusieurs sites. Donc, si vous avez un cache distribué sur le site 1, disons à San Francisco et que vous voulez avoir le site 2, vous pouvez avoir un actif-passif ou un actif-actif. Nous avions l'habitude de voir plus actif-passif, maintenant presque tout le monde passe à l'actif-actif à cause du cloud. Il est beaucoup plus facile de faire fonctionner l'infrastructure. Ainsi, les gens ont juste des sites actifs-actifs.

Et dans le défi actif-actif, c'est plus parce que les deux parties peuvent mettre à jour les mêmes données, il doit donc y avoir une capacité de résolution de conflit intégrée dans le cache distribué qui NCache a mais, vous devez être conscient de ce que, pour obtenir une véritable haute disponibilité, vous devez aller au-delà d'un centre de données et vous devez vous rendre dans plusieurs centres de données.

Dans de nombreuses situations, il se peut que deux centres de données ne suffisent pas. Par conséquent, si vous disposez de trois centres de données ou plus, vous devez toujours disposer de la même capacité de réplication active-active. Ainsi, si un centre de données tombe en panne, les deux autres centres de données devraient pouvoir prendre en charge la charge, puis vous devriez pouvoir restaurer ce centre de données et le faire rejoindre et vos utilisateurs ne devraient voir aucune interruption.

Si vous pouvez atteindre cet objectif avec un cache distribué, le tout de manière dynamique, sans aucun humain… encore une fois, bien sûr, la sauvegarde d'un centre de données nécessite une intervention humaine. Mais, il ne devrait y avoir aucune intervention humaine lorsqu'un centre de données tombe en panne, pour que la haute disponibilité soit vraiment élevée. S'il y a même cinq minutes de retard, ce n'est pas acceptable.

C'est la fin de mon exposé. J'ai essayé d'être aussi bref que possible, juste pour qu'il nous reste du temps. Je vais juste vous donner quelques réflexions sommaires. Je pense que la principale chose que je voulais souligner est que chaque application que vous développez, je vous recommande fortement d'avoir un cache distribué en mémoire, pour ces trois cas d'utilisation dont j'ai parlé. Et, idéalement, vous devriez également l'utiliser pour le partage de données entre plusieurs applications. Et, dans tous les cas, même dans la même application, vous devriez essayer d'avoir plusieurs sites pour vous assurer que vous disposez de la reprise après sinistre.

Et, je parle de cela à partir de 15 ans d'expérience. Nous avons fait cela. NCache est présent sur le marché depuis plus de 15 ans et nous travaillons avec de nombreuses banques. Nous sommes traditionnellement une boutique .NET, mais NCache prend désormais entièrement en charge .NET, Java et Node.js. Le code côté client et côté serveur pour .NET et Java et Node.js n'étant que l'API client. C'est la fin de mon exposé.

Merci Iqbal. Je ne saurais trop insister sur le fait que, alors que Wells Fargo s'engage sur la voie de la modernisation, à quel point cette présentation était opportune et pertinente. Alors, merci pour ça. Équipe, je vous rappellerai si vous avez des questions, n'hésitez pas à les poser dans votre chat. Nous avons une série de questions Iqbal. Une grande partie de l'équipe de questions est autour, cette présentation et la vidéo seront-elles disponibles ? La réponse est oui. Après la présentation, celui-ci sera mis à votre disposition sur demande. Nous vous enverrons le lien. Alors, Iqbal, voici quelques-unes des questions qui ont été posées.

Comment les caches distribués gèrent-ils les données sensibles ? Par exemple, le cryptage transparent est une question.

Oui, je pense que je n'ai pas eu le temps d'aller plus loin mais c'est aussi un aspect très important. Un produit comme NCache, par exemple, fournit sécurité à plusieurs niveaux. Il y a l'authentification, l'autorisation, la sécurité. Il y a le cryptage. Donc, plusieurs algorithmes de chiffrement. Certains 128 bits, certains cryptage 256 bits. Il y a le TLS, la sécurité des transports. Donc, le cache d'une banque comme Wells Fargo doit assurer la sécurité et c'est pourquoi parce que nous travaillons avec des banques. C'est la fonctionnalité que nous avons depuis longtemps. Ainsi, les données peuvent être cryptées. Et encore une fois, tout cela est automatique. Aucune programmation n'est nécessaire pour cela. Ce ne sont que des configurations. Mais, un cache distribué doit aborder la sécurité à travers ces différentes fonctionnalités.

La question suivante est la suivante : quelle est la différence entre le fait d'avoir la base de données telle que les objets et la mémoire du cache Oracle et d'avoir un autre cache mémoire devant Oracle ? Fondamentalement, puis-je obtenir le même résultat en allouant plus de mémoire à Oracle ?

Je pense que le mot-clé est "distribué". Tout ce qui n'est pas distribué, vous pouvez être rapide mais pas évolutif. C'est pourquoi ma première diapositive était la définition du mot évolutivité. Pouvez-vous passer de 1 boîtier à 10 boîtiers à 50 boîtiers en déploiement ? Certains de nos clients ont une ferme de serveurs d'applications de 150 serveurs d'applications ou plus. Et, vous savez, nous travaillons également avec… au fait, State Street Bank est également un de nos clients, et avec cela, il est absolument impossible qu'une mise en cache en mémoire par un seul serveur de base de données puisse gérer cela. Oui, c'est une fonctionnalité très importante pour rendre Oracle et SQL Server et autres rapides, mais ils ne peuvent pas être évolutifs. L'évolutivité ne peut être obtenue que par la distribution.

Comment la NCache performances par rapport à Redis, cohérence et autres produits du marché. Et, puis l'autre partie de la question est, avez-vous des plans dans votre feuille de route pour prendre en charge des langages de programmation supplémentaires comme Scala ou Python ? En fait, permettez-moi de répondre d'abord à la deuxième question. Oui, nous allons vraiment supporter Scala et Python. En fait, nous allons le faire cette année. Nous soutenons Java depuis presque 10 ans maintenant. La plupart des clients qui utilisent NCache, s'il s'agit d'une grande entreprise, ils l'utilisent à la fois pour Java et .NET. Même s'ils pourraient l'acheter du point de vue de .NET. Donc, c'est le premier.

La deuxième question était, comment NCache comparaison des performances avec Redis et d'autres? Je veux dire, ils sont tous rapides. Je ne vais faire mal paraître personne et je pense que vous devriez faire votre propre comparaison, mais ils sont tous rapides. Je pense que la seule chose contre laquelle je vous mettrais en garde, c'est que certains des joueurs, en quelque sorte, vous savez, vous donnent la mauvaise impression de faire les benchmarks. Par exemple, les repères que nous donnons, ils incluent l'aller-retour complet. Ainsi, si vous effectuez un cache.Get ou un cache.Insert, à moins que cette opération d'insertion ne revienne à l'application, cette opération n'est pas terminée. Mais, certains des autres fournisseurs vous montreraient en fait une référence beaucoup plus grande que la nôtre, mais ils feront ce qu'ils appellent tirer et oublier. Donc, si je vais seulement l'envoyer et ne pas m'en soucier, évidemment je peux faire beaucoup plus. Et, en fait côté Java Hazelcast et Redis Les laboratoires se sont poursuivis exactement sur le même point. Donc, je vais m'en tenir à cela.

Vous avez travaillé avec d'autres banques et autres, d'autres problèmes de conformité concernant l'utilisation des données PCI vers les données sensibles dans l'espace de cache. Avez-vous rencontré des problèmes de conformité réglementaire là-bas ?

En fait non. Je veux dire, tout d'abord, le fait que nous fournissons toutes ces différentes fonctionnalités de cryptage de sécurité, tant au niveau des données. Parce que vous pouvez chiffrer les données avant de les mettre en cache et également au niveau du transport. Nous avons également une authentification et une autorisation côté serveur et c'est le côté serveur de cache. Et, je pense que c'est suffisant pour… et en plus, un cache s'exécute dans un centre de données sécurisé. Un cache n'est pas quelque chose qui est accessible à une entité extérieure. Donc, lorsque vous combinez tout cela avec le fait que le cache s'exécute à l'intérieur, nous n'en avons pas eu et, vous savez, nous avons eu… Je veux dire, par exemple, Citi Group, Bank of America et Barclays ont utilisé NCache depuis plus d'une décennie maintenant et, n'a eu aucun problème.

Comment cela fonctionnera-t-il avec les bases de données mainframe ?

Je pense qu'un mainframe est quelque chose que vous… Disons que vous serez probablement… vous avez probablement des services Web aujourd'hui et vous allez probablement développer des microservices pour permettre aux applications d'accéder au mainframe. Le mainframe est un autre cas où la récupération des données du mainframe est très coûteuse. À la fois en termes de vitesse et, parfois aussi, si votre ordinateur central est hébergé à l'extérieur, vous devrez peut-être même payer par transaction ou par voyage. Donc, si vous pouvez mettre en cache plus de ces données dans votre couche Kubernetes ou Microservices, comme je l'ai dit, et faire moins de déplacements vers le mainframe, non seulement vous gagnerez en performances, mais vous pourrez également probablement économiser beaucoup d'argent.

Comment la cohérence et la disponibilité des données dans le cache distribué en mémoire sont-elles assurées lorsque des nœuds sont ajoutés et supprimés ?

Donc, au moins, je peux parler de NCache qui NCache garantit que lorsque vous ajoutez ou supprimez des nœuds, toutes les mises à jour en cours, toutes les modifications en cours sont effectuées avec le fait que nous effectuons le transfert d'état, disons, nous déplaçons le partitionnement et tout, NCache est conscient qu'il doit s'assurer que toutes ces mises à jour sont appliquées correctement tout en s'assurant que le nœud est ajouté et le transfert d'état, ce que nous appelons le transfert d'état qui est l'équilibrage des données pour déplacer les données d'une partition à l'autre qui continue également à se produire. Alors, NCache l'assure.

Lorsque les microservices sont distribués avec leurs propres bases de données, comme je l'ai vu sur la photo, comment ceux-ci peuvent-ils offrir une expérience omnicanale au client ?

Donc, la partie de la base de données distribuée, je pense que le jury est sur la distribution de ces bases de données. Comment partitionné ces bases de données vont être. Parce que, comme je l'ai dit dans mon exposé, au moins en théorie, chaque microservice peut avoir sa propre base de données logique, même si physiquement ils peuvent résider sur les mêmes serveurs de base de données, car, lorsque vous déployez des choses, vous n'aurez pas 100 serveurs de base de données différents, chacun pour chaque micro service. Vous allez avoir des serveurs de bases de données consolidées. Le fait que vous ayez une séparation vous donne probablement un peu plus de flexibilité, tout comme NoSQL mais, le jury ne sait toujours pas dans quelle mesure pouvez-vous vraiment vous en tirer avec cette limitation d'une base de données relationnelle. Ma prédiction est que vous allez vous retrouver avec les mêmes serveurs de bases de données relationnelles. Vous pouvez ou non avoir la séparation logique. Vous pouvez avoir des schémas séparés ou vous pouvez avoir le même schéma, vous parlez simplement à des tables différentes, mais les serveurs de base de données resteront les mêmes. Donc, c'est le même problème que vous abordez même dans les services Web, ils vont s'attaquer aux microservices. Je pense que le temps presse. Je ne peux pas vous remercier assez. Cela a été très intéressant. Les questions continuent d'affluer, mais il est clair que nous ne pouvons pas toutes les aborder. Donc, sur ce, je vous redonne la parole.

Que faire ensuite?

• NCache Détails
• Télécharger NCache
• Demander une démo personnalisée en direct