Tecnología del Área de la Bahía de Wells Fargo SF

Piel escamosa .NET Core Aplicaciones y microservicios para un rendimiento extremo

Para .NET, Java y Node.js

Por Iqbal Kan
Presidente y evangelista tecnológico

Las aplicaciones de servidor actuales necesitan procesar muchas transacciones muy rápido. Muchos de estos son aplicaciones web que sirven a millones de usuarios todos los días. Otros son microservicios que sirven a millones de aplicaciones móviles o dispositivos inteligentes de Internet de las cosas (IoT).

La mayoría de estas aplicaciones ahora se implementan en contenedores como Kubernetes para simplificar y automatizar la implementación, el escalado y la administración. Y, los entornos de implementación de elección se han alejado de las instalaciones locales a las nubes líderes como AWS, Azure, Google Cloud y más.

Aprenda a desarrollar aplicaciones que cumplan con los requisitos de rendimiento extremo de hoy en día al eliminar los cuellos de botella de rendimiento relacionados con el almacenamiento de datos y las bases de datos y también la comunicación entre las diferentes partes de las aplicaciones de microservicios.

General

Muchas gracias Mike y gracias Jason por darme la oportunidad de hablar con un grupo tan importante en Wells Fargo, el Grupo de Tecnología del Área de la Bahía de San Francisco. Como mencionó Mike, trabajo en Alachisoft y la palabra Alachi, que les estaba explicando a Mike y Jason, es una especie de derivado de la palabra hindi Ellachi, que es o Elaichi, que es un nombre de especia cardamomo. Entonces, estábamos nombrando a la compañía hace muchos años, y queríamos crear algo único, así que se nos ocurrió Alachisoft.

Nuestro producto es en realidad NCache. Entonces, no voy a estar hablando de NCache. La charla de hoy trata sobre '¿Cómo puede escalar sus aplicaciones web y microservicios a un rendimiento extremo?' Si está desarrollando estas aplicaciones en Java, .NET, .NET Core o Node.js, entonces has venido a la conversación correcta.

¿Qué es la escalabilidad?

Entonces, entendamos algunas definiciones, antes de entrar en la conversación real. La primera es: ¿Qué es la escalabilidad? La escalabilidad es en realidad un alto rendimiento de la aplicación, pero bajo cargas máximas. Por lo tanto, si su aplicación se ejecuta súper rápido con solo 5 usuarios, no es realmente escalable a menos que tenga el mismo excelente rendimiento a una velocidad de 5000, 50,000 500,000 o XNUMX XNUMX usuarios. Si su aplicación puede hacer eso, entonces es escalable y, obviamente, queremos que muchas de nuestras aplicaciones sean escalables y lo analizaré.

¿Qué es la escalabilidad lineal?

La siguiente definición es '¿Qué es la escalabilidad lineal?' Esto es más una terminología de implementación y arquitectura de aplicaciones. Si su aplicación está diseñada correctamente, será linealmente escalable, lo que significa que si necesita aumentar la capacidad de transacciones por segundo, ¿cuántos usuarios puede manejar? ¿Cuántas solicitudes de aplicación puede manejar? Si desea aumentar eso, simplemente agregue más servidores y cada servidor que agregue aumenta la capacidad de transacciones por segundo de manera lineal.

Entonces, no hay bloqueo, no hay cuello de botella. Obviamente, las curvas de lectura versus escritura son diferentes, pero ambas son lineales. Si puede hacer eso, su aplicación es linealmente escalable y eso es algo que definitivamente queremos.

¿Qué es la escalabilidad no lineal?

Esto es algo que no queremos y es si diseñó su aplicación de una manera en la que hay algunos cuellos de botella, entonces, a medida que aumenta su carga en la aplicación y agrega más cuadros, algo comienza a ceder y su aplicación comienza para reducir la velocidad, de hecho, incluso a veces incluso se bloquea.

Por lo tanto, definitivamente no queremos que nuestras aplicaciones estén diseñadas para ser escalables de forma no lineal.

¿Quién necesita escalabilidad?

Bien, ahora que hemos entendido lo que significa escalabilidad, lo siguiente que debemos entender es quién la necesita. ¿Qué aplicaciones necesitan escalabilidad?

• Aplicaciones web

  Las aplicaciones más comunes son las aplicaciones web. Estos son para un banco como Wells Fargo u otros bancos con los que trabajamos como el grupo Citi y Bank of America y Barclays y el banco de Tokio. Estas son aplicaciones orientadas al cliente, tiene wellsfargo.com, que es para banca de consumo y pequeñas empresas, y estas aplicaciones web deben poder manejar una gran cantidad de usuarios sin ralentizarse. Por lo tanto, es muy importante que estas aplicaciones funcionen súper rápido bajo una carga extrema.

• Servicios web / API web

  El número dos son los servicios web, las aplicaciones web API. Por lo general, están ahí para dar servicio a muchas aplicaciones móviles o cualquier otra aplicación que los requiera para realizar ciertas tareas. Entonces, si tiene, digamos, Wells Fargo tiene una aplicación móvil para la banca de consumo, esa aplicación móvil tiene que hablar con algún back-end, y ese back-end hoy en día es probablemente servicios web. Obviamente, no lo sé, pero asumo que lo es, porque muchos de los otros bancos con los que trabajamos tienen esta situación en la que los servicios web son los que manejan esta solicitud de aplicación móvil. Y tienen exactamente la misma sensibilidad. Necesitan poder manejar una gran cantidad de carga sin disminuir la velocidad.

• Microservicios

  Los microservicios son algo que es una palabra de moda en estos días y, voy a hablar un poco más sobre esto en un momento, pero es esencialmente, estás rediseñando los servicios web de una manera nueva y mejor, déjame solo dilo de esa manera en este momento.

• Aplicaciones de servidor

  El cuarto tipo de aplicación es cualquier otra aplicación de servidor que pueda tener. Estos pueden ser, las aplicaciones del servidor están realizando un procesamiento por lotes. Estos también pueden manejar transacciones en vivo, pero se incluyen en alguna otra categoría. Pero también tienen el mismo tipo de requisito de rendimiento de transacción por segundo.

Entonces, si está desarrollando cualquiera de estos cuatro tipos de aplicaciones. También hay algunos otros, digamos, podría estar haciendo aprendizaje automático en vivo e IA, pero no voy a entrar en eso en esta charla, no tenemos suficiente tiempo. Pero, digamos, si tiene estas cuatro aplicaciones, definitivamente necesita que sean escalables. Y, esta es la charla que va a repasar sobre ellos. En cuanto a la tecnología, las aplicaciones web generalmente se desarrollan en Java o ASP.NET, ASP.NET Core, siendo la nueva versión de ASP.NET y Node.js y, los otros tres tipos son Java o .NET/.NET Core, los microservicios están en Java o .NET Core porque es la nueva tecnología.

Introducción a los microservicios

Para aquellos de ustedes que no saben cómo son los microservicios, solo quería darles una breve vista arquitectónica. Y, para aquellos que lo hacen, solo tengan paciencia conmigo. Entonces, Microservicios, la razón por la que se están volviendo tan populares porque le permiten dividir sus aplicaciones monolíticas en Microservicios de tamaño de byte y cada Microservicio está desacoplado de otros Microservicios. Y, ese desacoplamiento significa, que no se llaman entre sí. Tienen sus propias bases de datos generalmente lógicas. No tienen por qué tener bases de datos físicas separadas pero, al menos lógicamente, suelen tener las suyas propias. Algunos de los microservicios pueden usar un NoSQL database, MongoDB o algo más. Algunos de ellos utilizarán bases de datos relacionales, SQL Server, Oracle, DB2. Algunos de ellos podrían ir a los datos de mainframe heredados.

Entonces, el desacoplamiento requiere que se comuniquen entre sí a través de algún tipo de bus de eventos, que es lo que es esa tubería en el lado derecho. Y son llamados por aplicaciones móviles, aplicaciones web de una sola página o aplicaciones web MVC estándar en Java, .NET o Node.js, a través de la puerta de enlace API. Entonces, esta es solo una buena vista de lo que son los Microservicios. Y voy a explicar cómo incluso ellos tienen los mismos problemas de escalabilidad que otras aplicaciones que tradicionalmente han tenido.

Entornos de implementación de aplicaciones

Otra cosa que quería abordar rápidamente porque quería poner el contexto sobre lo que voy a hablar es, los diferentes tipos de entornos de implementación que tuvimos que abordar a lo largo de los años. He estado haciendo esto durante más de 15 años y durante mucho tiempo fue todo en centros de datos locales con control total. Incluso ahora, muchos de los bancos con los que trabajamos siguen teniendo sus propios centros de datos. Pero casi todo el mundo se está moviendo o al menos planea moverse a la nube. Algunas pequeñas y medianas empresas se trasladan a la nube pública. Muchas empresas más grandes, especialmente, nuevamente los servicios financieros y los bancos, generalmente prefieren una implementación de nube privada. De hecho, algunos de los bancos con los que trabajamos prefieren una nube privada en un tipo de marco Pivotal Cloud Foundry o Red Hat Open Stack, lo que les da un control total sobre el entorno de la nube privada, sin importar dónde esté el existe una nube privada. Ya sea que exista dentro de una nube pública como un espacio alquilado o esté encima de su centro de datos que tienen en este momento, o sea algo más, les da libertad. Pero, de cualquier manera, se van a la nube.

Y, Kubernetes es algo que también voy a mencionar más adelante, pero se está convirtiendo en otra palabra de moda, al igual que los microservicios. Porque es una tecnología muy poderosa que simplifica sus Dev Ops. También le brinda portabilidad del entorno. Por lo tanto, haga lo que haga una vez, funciona en todos los entornos. Ya sea que esté en las instalaciones, esté en cualquiera de las nubes, tiene el mismo entorno de implementación que funciona. Y, en Kubernetes también, muchos de los bancos con los que trabajamos prefieren una oferta neutral de plataforma en la nube como Tanzu Kubernetes o Red Hat OpenShift. Entonces, voy a repasar esos conceptos más adelante como parte del tema de escalabilidad del que estamos hablando.

Problema de escalabilidad

Bien, volvamos al problema real del que hablamos, que es, ¿hay algún problema de escalabilidad que debamos resolver? Sí hay. Pero, no está en el nivel de aplicación. No está en la arquitectura de la aplicación. Es en el almacenamiento de datos, que se convierte en el cuello de botella. Y, cuando digo la palabra almacenamiento de datos, me refiero a bases de datos relacionales o bases de datos o datos heredados de mainframe. NoSQL databases, no tienen el mismo tipo de cuello de botella y se utilizan cada vez más. Pero, lamentablemente, no pueden ser la respuesta a todo este problema de escalabilidad.

Los cuellos de botella de la escalabilidad

Si ve esta imagen, verá que la razón por la cual las bases de datos relacionales y el mainframe heredado son un cuello de botella es porque, a diferencia del nivel de aplicación, puede agregar más servidores. Digamos que tiene las aplicaciones web implementadas aquí en un entorno de equilibrio de carga de múltiples servidores, tiene servicios web y microservicios también de la misma manera.

Nuevamente, no estoy hablando de sus entornos en este momento, solo les doy un desglose lógico de ser múltiples servidores. Por lo tanto, tener la capacidad de agregar más servidores significa que el nivel de la aplicación nunca se convierte en un cuello de botella. Pero, a medida que aumenta el tamaño de ese nivel, el almacenamiento de datos se convierte cada vez más en un cuello de botella. Y aunque NoSQL no se convierte en un cuello de botella, la razón por la que no es una respuesta a todos sus problemas es porque, NoSQL requiere que mueva sus datos lejos de lo relacional y lejos del mainframe. Lo cual, en un mundo ideal, no debería ser un gran problema, pero es un gran problema. La mayoría de las empresas no pueden alejarse por completo de lo relacional. No pueden alejarse completamente del mainframe. pueden usar NoSQL como una combinación de algunos datos se podría poner en NoSQL database pero muchos de los datos tienen que seguir estando en bases de datos relacionales y en el mainframe. Y, mientras eso sea cierto, entonces lo que eso significa es que cualquier solución de escalabilidad que tengamos que encontrar no puede ser una NoSQL database. Tiene que ser algo más que un NoSQL database. Tiene que funcionar con bases de datos relacionales y con la base de datos de mainframe heredada.

Cuellos de botella de microservicios

Los microservicios, como les mostré la arquitectura, incluso no les brindan una escalabilidad integrada. Incluso tienen los mismos cuellos de botella de rendimiento que tienen los servicios web o las aplicaciones web. A menos que estén usando un NoSQL database, que por supuesto no van a tener, pero incluso ellos tienen que hablar con el mainframe para obtener datos heredados y muchos de ellos seguirán hablando con bases de datos relacionales. Y tienen un cuello de botella potencial adicional que es el bus de eventos que está allí para comunicarse entre sí.

Si tiene un entorno de transacciones realmente alto, ese bus de eventos también puede ser un cuello de botella. Si no tiene la solución adecuada para el bus de eventos.

Solución de escalabilidad

Entonces, afortunadamente, hay una solución para esto y es un caché distribuido en memoria. Y, voy a entrar en las razones por las que es? Pero déjame hacer algunas afirmaciones. La razón por la que es una solución es porque es extremadamente rápido. Proporciona escalabilidad lineal y le brinda alta disponibilidad. Entonces, esas son las tres razones por las que es una solución para el problema de escalabilidad. Y hay un beneficio adicional que obtiene al usar un caché distribuido en memoria que, en una gran empresa como Wells Fargo, en realidad puede usar como una plataforma para compartir datos en múltiples aplicaciones. Repasaré eso un poco más, pero es una especie de beneficio adicional o como un beneficio secundario de usar esto. La razón principal es la escalabilidad.

Caché distribuida en memoria

Entonces, ¿cómo proporciona esta respuesta una caché distribuida en memoria? ¿Cómo es esa solución a ese problema? La razón por la que es una solución es porque un caché distribuido en la memoria, en primer lugar, está en la memoria, por lo que es súper rápido. In-memory es más rápido que incluso NoSQL databases. Y, en segundo lugar, se distribuye. Un caché de distribución en memoria en realidad es una colección de múltiples servidores de caché de bajo costo. Y, cada servidor de caché no es un tipo de base de datos de un servidor. Estos son más como servidores web, de 4 a 8 núcleos, a veces más. 16 a 32 gigas de RAM. Obtenga tantos como desee para cada aplicación y créelo como una infraestructura súper rápida y altamente escalable para la aplicación. Una vez que tenga el nivel de aplicaciones que ve aquí arriba con las aplicaciones web, los servicios web y los microservicios y las bases de datos, ya sean relacionales, heredadas o NoSQL. Incluso NoSQL, como dije, no es tan rápido como un caché distribuido en memoria.

Entonces, ¿qué hace el caché de distribución en memoria? Crea un grupo de estos servidores de caché y ese grupo agrupa la memoria, la CPU e incluso la capacidad de la tarjeta de red de todos estos servidores de caché juntos. Al igual que el nivel de aplicación y, al igual que el NoSQL database, aunque incluso más fácilmente que el NoSQL database, simplemente agrega más servidores de caché a medida que crece su capacidad de transacción. Entonces, ahora de repente tiene una redundancia y, además, debido a que está en la memoria, tiene que proporcionar replicación de datos de una manera inteligente y lo revisaré en un momento para asegurarme de que si algún servidor de caché se cae, no pierdes ningún dato. Porque de lo contrario, cualquier almacenamiento en memoria no es valioso. Porque, si pierde gigabytes y gigabytes de datos solo porque un servidor deja de funcionar, en realidad no es una solución muy atractiva. Entonces, un caché distribuido en memoria no solo distribuye los datos, sino que también los replica de manera inteligente sin comprometer el rendimiento. y escalabilidad.

Entonces, al tener un caché distribuido en memoria como parte de su infraestructura, de repente ahora tiene la capacidad de eliminar ese cuello de botella, el 80% de sus lecturas de datos van al caché distribuido. El 20% se destina a las bases de datos reales porque las bases de datos siguen siendo la fuente de datos maestra. Por lo tanto, cualquier actualización que realice a esos datos debe realizarse en la base de datos relacional del mainframe heredado o en el NoSQL. Pero, a veces, incluso más del 80%, el 90% de su tráfico de lectura o escritura puede limitarse a la memoria caché distribuida. Y, de repente, sus aplicaciones ya no sienten ningún cuello de botella.

Entonces, esto es algo así como un patrón de arquitectura de aplicaciones esencial ahora, donde debe tener un caché distribuido en memoria, si desea que sus aplicaciones puedan escalar.

Escalabilidad de caché distribuida

Estas son algunas números de referencia de escalabilidad de NCache, donde puedes ver que con solo 4 a 5 nodos, puedes hacer 2 Millones de operaciones por segundo. Y, como es una escala lineal, si desea llegar a 4 millones, solo agregue 5 nodos más. Y, como saben, 2 millones de operaciones por segundo es una carga de transacciones bastante alta, que la mayoría de sus aplicaciones, si pueden permanecer en esa carga, el 90 % de sus aplicaciones estarán felices con ese tipo de carga. Tal vez algunos no lo harán y necesitan más. Y, cuando necesiten más, simplemente agregue más servidores.

Usos comunes de la caché distribuida

Por lo tanto, espero que a estas alturas ya los haya convencido de que un caché distribuido en memoria es una gran idea en cuanto a la arquitectura de una aplicación. Entonces, la próxima o la primera pregunta que me viene a la mente después de eso es, está bien, ¿cómo aprovecho esto, como desarrollador de aplicaciones? Porque todo esto se trata de aplicaciones. ¿Cómo uso un caché distribuido para aprovechar?

• Almacenamiento en caché de datos de aplicaciones

  Entonces, hay tres formas comunes en las que puede usar un caché distribuido. el número uno es Almacenamiento en caché de datos de aplicaciones. Esta es la forma más común, que es de lo que estaba hablando. Lo cual es que, independientemente de los datos que estés leyendo de la base de datos, los guardas en el caché, así que la próxima vez, solo los lees desde el caché, muy simple. Y, independientemente de lo que actualice, actualiza tanto el caché como la base de datos.

  Ahora, una cosa que debe comprender de inmediato, que para el almacenamiento en caché de datos de la aplicación existe un problema único, que es que ahora los datos existen en dos lugares, uno es la base de datos maestra, que podría ser su relacional, NoSQL o mainframe heredado y uno es el caché. Entonces, lo primero que puede salir mal es que el caché se vuelva obsoleto. Entonces, ha actualizado los datos, tiene una aplicación que no está hablando con el caché, va y actualiza los datos en la base de datos y, de repente, el caché tiene datos obsoletos y los datos obsoletos son realmente malos. Estoy seguro de que ustedes saben que, más que nadie, un banco sabría que los datos obsoletos son muy malos. Algunos datos obsoletos están bien, pero muchos datos obsoletos son muy malos. Entonces, esta es la razón por la cual la mayoría de las personas cuando piensan en el almacenamiento en caché, la reacción instintiva es que está bien, solo voy a almacenar en caché datos de solo lectura, que nunca cambian o, al menos, en la vida útil de mi aplicación o lo que sea , en mucho tiempo no va a cambiar. Bueno, si eso es solo alrededor del 10%, 15% de sus datos totales. Si solo vas a almacenar en caché el 10 % o el 15 %, entonces realmente no estás aprovechando una caché distribuida. Debe poder almacenar en caché datos que cambian tal vez cada 5 segundos. O, incluso antes de eso. Porque, incluso durante esos 5-10 segundos, puedes leerlo 10 veces. Y, cuando multiplica eso por millones de transacciones que su aplicación procesa todos los días, está ahorrando muchos viajes a la base de datos y cómo va a ganar escalabilidad.

  Por lo tanto, cualquier caché distribuida que no aborde esto omita este desafío, que el caché no debe quedar obsoleto, siempre debe estar fresco, lo obligará a no usarlo por completo. Entonces, eso es lo primero que hay que tener en cuenta.

• Almacenamiento en caché específico de la aplicación web

  El caso de uso número dos es la aplicación web. Y, el uso más común para la aplicación web es sesiones. Ya sea que tenga Java, ASP.NET, ASP.NET Core o Node.js, todos quieren guardar sus sesiones en un almacén rápido y escalable. Y, un caché distribuido es una tienda mucho mejor que cualquier otra cosa que esté disponible. Ya sea Java o .NET o no Node.js. Y, hay otras cosas como, ahí está la página almacenamiento en caché de salida. También hay aplicaciones web en vivo. En el caso de .NET esto se llama SeñalR, que puede usar un caché distribuido como plataforma para compartir los eventos.

  Pero, una aplicación web, cuando no es el almacenamiento en caché de datos de la aplicación, cuando la aplicación web almacena sus datos en el caché distribuido, tiene un tipo diferente de problema que abordar. Lo cual es, que ahora, no hay una base de datos que tenga una copia de esos datos. Cache es el almacén principal. Y un caché que es un almacén maestro significa que si el servidor de caché deja de funcionar, perderá esos datos. Lo cual no es aceptable, no desea perder una sesión de usuario solo porque un servidor de caché o un servidor web se cayó. Si desea tener una alta disponibilidad, necesita que el caché tenga las características de la capacidad de replicar esos datos de manera inteligente en varios servidores. Entonces, si algún servidor de caché se cae, no perderá esos datos. Entonces, esa es la parte importante. El almacenamiento en caché de datos de aplicaciones tiene un desafío diferente. El almacenamiento en caché específico de la aplicación web tiene un desafío diferente.

• Mensajería Pub/Sub, CQ y Eventos

  Y, el tercer caso de uso es que puede usar y, esto es algo que mucha gente no sabe en absoluto, que es que puede usar un caché distribuido como un Mensajería de publicación/suscripción Plataforma y Eventos. Hablamos y les mostraré que incluso los microservicios necesitan hacer Pub/Sub. Por lo tanto, si usan la caché distribuida como una plataforma de mensajería Pub/Sub además de usarla para el almacenamiento en caché de datos de aplicaciones, entonces la mensajería Pub/Sub no será un cuello de botella para ellos.

  Hay muchos otros productos de mensajería que tienen muchas funciones de mensajería. Y, un caché distribuido no coincide con todas esas características, pero lo que hace el caché distribuido es que crea una plataforma de mensajería en memoria muy rápida para aquellos mensajes que solo necesitan compartirse dentro de este entorno de microservicios o aplicación web. Por lo tanto, es un entorno mucho más simple en el que no necesita mantener esos mensajes durante horas. Solo necesitan compartirse en los próximos milisegundos, tal vez. Pero hay tanta actividad de transacciones que, sin tener una arquitectura realmente distribuida en memoria, la plataforma de mensajería en sí misma se convierte en un cuello de botella. Entonces, además de que el almacenamiento de datos es un cuello de botella, su plataforma de mensajería también es un cuello de botella. Así que tenlo en mente. Y, nuevamente, la plataforma de mensajería tiene el mismo problema que el almacenamiento en caché específico de una aplicación web, que es que, por lo general, lo que sea que se mantenga como mensaje, no tiene una copia de respaldo en la base de datos. Bueno, podría ser una versión transformada de algunos datos que ya existen en la base de datos y es posible que pueda volver a crearlos, pero no quiere hacerlo. Entonces, no quieres perder esos datos, no quieres perder esos mensajes. Entonces, es por eso que un buen caché distribuido no solo debe ser rápido y escalable, sino que también debe proporcionar esa replicación inteligente no solo para el almacenamiento en caché específico de la web, sino también para la mensajería Pub/Sub.

Kubernetes y almacenamiento en caché distribuido

Así es como tenemos un entorno de Kubernetes que ejecuta aplicaciones web y microservicios y usa un caché distribuido. Entonces, esta área verde es un clúster de Kubernetes. Y Kubernetes tiene este concepto de clúster. Dentro de cada clúster, tiene múltiples implementaciones. Entonces, cada uno de estos tres rectángulos de caja es un despliegue. Entonces, hay una implementación de aplicaciones web, hay dos implementaciones de microservicios y hay una implementación de caché distribuida y hay una puerta de enlace API para los microservicios.

No voy a entrar en detalles sobre cómo funciona Kubernetes, pero básicamente, en un entorno como este, los microservicios usan la caché distribuida tanto para el almacenamiento en caché de datos de la aplicación como para la mensajería Pub/Sub. Mientras que la aplicación web utiliza la memoria caché distribuida para el almacenamiento en caché de datos de la aplicación y las sesiones web.

La mayoría de las aplicaciones web no tienen un Mensajería de publicación/suscripción porque Pub/Sub Messaging generalmente requiere algún tipo de proceso de servidor estable para comunicarse entre sí. Pero de todos modos, algunos de ellos podrían pero la mayoría de ellos no. Pero, la misma infraestructura de almacenamiento en caché que tiene para el almacenamiento en caché de datos de aplicaciones se puede usar para sesiones web y también se puede usar para Pub/Sub Messaging y, en este caso, como puede ver, estas son instancias de Docker como Pods. . Estas podrían ser cajas de Windows o Linux, ya sabes, eso depende de tu preferencia sobre el camino que quieras tomar. La mayoría de los bancos en estos días están trasladando todo a Linux e incluso .NET Core porque es compatible con Linux. Ahora puede tener aplicaciones .NET y Java y, por supuesto, Node.js en Linux.

Entonces, así es como se ve un entorno de Kubernetes tanto para servicios y aplicaciones web como para alojar un caché distribuido. Una cosa que quería señalar aquí es que un caché distribuido para vivir en Kubernetes tiene que ser compatible con Kubernetes. Tiene que haber implementado lo que llaman un Operador de Kubernetes. NCache lo tiene Entonces, cualquiera que sea el caché distribuido que mire, asegúrese de que sea compatible con Kubernetes.

Descripción general del almacenamiento en caché de datos de la aplicación (API)

Entonces, esta es mi única diapositiva de codificación. No voy a entrar más en la codificación que esto. La idea general de esto es que, está bien, el almacenamiento en caché de datos de la aplicación es el caso de uso principal para el caché distribuido, que debe utilizar cada aplicación que esté desarrollando. Ya sea una aplicación web, servicios web o microservicios. Y puede ver que esta es una API muy simple que tiene un caché distribuido.

• Conexión de caché

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

• Recuperacion de datos

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

• Escribir datos

  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");

Tienes un manejador de caché, haces cache.Get, cache.Contains. Hay una clave que suele ser una cadena y obtienes un valor y un valor puede ser un objeto, podría ser un objeto .NET, podría ser un objeto Java, podría ser un documento JSON. Node.js obviamente funciona en JSON. Pero, incluso podría hacer que las aplicaciones .NET y Java almacenen sus objetos o datos como JSON. Y eso le permite incluso usar esto como una plataforma para compartir datos porque tiene una aplicación Java que almacena, digamos, un objeto de cliente que era un objeto de cliente Java. Cuando se almacena en el caché distribuido, digamos, como NCache se transforma en un documento JSON y luego cuando una aplicación Node.js o .NET o .NET Core la aplicación quiere buscarlo, lo consiguen... Digamos, .NET Core la aplicación lo obtendrá como un objeto de cliente .NET o un documento JSON y Node.js probablemente obtendrá un documento JSON de todos modos. Entonces, la simplicidad está ahí, obtener, agregar, insertar, eliminar tan simple como sea posible. Entonces, la curva de aprendizaje es muy rápida al usar un caché distribuido.

Características del almacenamiento en caché de datos de la aplicación

Voy a repasar rápidamente algunas de las áreas clave en el almacenamiento en caché de datos de aplicaciones porque, si va a utilizar el caché distribuido, el caso de uso más importante es el almacenamiento en caché de datos de aplicaciones. Y, ¿qué es lo que debe tener en cuenta? El número uno, como mencioné, hay dos copias de los datos, una en la base de datos y otra en el caché, entonces, ¿cómo mantiene el caché actualizado?

• Vencimientos (absolutos y móviles)

  El número uno es una característica llamada Vencimiento que casi todos los cachés distribuidos tienen como característica y, por lo general, es el Caducidad absoluta. Algunos lo llaman TTL o vencimientos de tiempo de vida. El otro vencimiento se llama Caducidad móvil que no es para el almacenamiento en caché de datos de la aplicación, es más para el tipo de sesión de una situación en la que desea que caduque el objeto si nadie lo usa durante un cierto período de tiempo. Pero, la Caducidad Absoluta, le estás diciendo a la memoria caché que sé que estos datos que estoy almacenando en la memoria caché no van a cambiar durante los próximos cinco minutos o durante las próximas cinco horas o 24 horas. Cualquiera que sea la naturaleza de los datos, puede especificarlo. Y, al final de ese tiempo, el caché caducará automáticamente. Entonces, la aplicación puede simplemente agregarlo y continuar. La aplicación no tiene que preocuparse por realizar un seguimiento de todos esos datos. Entonces, eso es lo mínimo que debe tener cada caché y la mayoría de ellos lo tienen. Pero el problema o la limitación de los vencimientos es que solo está haciendo una suposición informada. En algunos casos, está bien porque los datos no cambian con tanta frecuencia pero, como mencioné anteriormente, el beneficio real está en el almacenamiento en caché de datos transaccionales. Entonces, en los datos transaccionales, desea poder ser más preciso.

• Sincronizar caché con base de datos

  Otra característica que debe tener un caché distribuido es que debe estar al tanto de su base de datos hasta cierto punto, para que pueda sincronizarse con los datos que haya almacenado en caché, si esos datos, los datos correspondientes en la base de datos cambian, entonces el caché debería eliminar automáticamente ese elemento del caché, de modo que la próxima vez que su aplicación lo desee, no lo encuentre en el caché y se verá obligado a obtenerlo de la base de datos o el caché debería volver a cargar una copia de eso. Y, la recarga solo es posible a través de otra función de la que voy a hablar, se llama lectura y escritura. Pero, si puede sincronizar el caché con la base de datos.

  Por lo tanto, hay dos formas de sincronizar. Uno está basado en eventos. Entonces, la mayoría de las bases de datos en estos días ahora tienen eventos de cambio de datos. SQL Server lo tiene, Oracle lo tiene, MongoDB, Cosmos DB, todos lo tienen. Creo que Cosmos DB lo llama cambio de fuente, MongoDB lo llama flujo de cambio y SQL Server lo llama Dependencia de SQL y Oracle, creo que lo llama Notificaciones de base de datos o algo así.

  Entonces, si su caché distribuida está aprovechando esas capacidades en la base de datos, puede crear algún tipo de relación entre sus elementos almacenados en caché y los conjuntos de registros de la base de datos. Entonces, cuando esos datos cambien, la base de datos notifique a la memoria caché distribuida que está bien que estos datos hayan cambiado, por favor cuide su propia copia. Entonces, su caché puede eliminarlo o volver a cargarlo desde la base de datos y si la base de datos no tiene eventos como una característica, entonces puede usar el sondeo como otro mecanismo.

• Manejar datos relacionales

  Lo tercero que desea hacer es si está almacenando en caché datos relacionales, hay algunos problemas de integridad de datos relacionados con las relaciones, uno a muchos, uno a uno. Entonces, si puede decirle al caché que este artículo, tengo este objeto de cliente y tengo este objeto de pedido, están relacionados. Entonces, si la aplicación elimina el objeto del cliente, el caché elimina automáticamente todos los pedidos. Entonces, de esa manera no hay, ya sabes, lo que llamas referencias colgantes en el caché. Son cosas así, si puedes hacer eso, entonces tu caché siempre estará fresca.

• Consultas SQL

  Entonces, con estas funciones, si su caché tiene al menos las dos primeras funciones, entonces tendrá la confianza de colocar todo tipo de datos en la caché. Y, una vez que tenga esa confianza, comenzará a colocar una gran cantidad de datos en el caché. Y, una vez que coloca una gran cantidad de datos en el caché, surge otro problema, que ahora no es suficiente con encontrar datos basados ​​​​en claves. Entonces, desea poder encontrar datos tal como puede encontrarlos en la base de datos, que son consultas SQL. Para .NET, .NET Core también hay un LINQ. Entonces, si puede buscar datos en función de los atributos de los objetos. Puede decir algo como dame todos los objetos del cliente, donde la ciudad es San Francisco. Entonces actúa más como una base de datos. También hay datos de referencia que puede buscar. Hay una gran cantidad de datos de búsqueda que puede buscar. Entonces, si puede buscar los datos, ahora el caché se vuelve más amigable. Se siente más seguro almacenando en caché más y más datos porque puede encontrarlos. Porque, si no pudiera hacer consultas SQL, entonces su aplicación de repente se vuelve muy complicada. Tienes que hacer un seguimiento de cada clave que has almacenado.

• Grupos, etiquetas, etiquetas con nombre

  El otro aspecto está nuevamente en la misma relación: desea poder agrupar datos relacionados para poder obtenerlos todos a la vez. Entonces, diferentes cachés distribuidos brindan este concepto de grupos y etiquetas y etiquetas de nombre que luego puede obtener todo lo que coincida con esta etiqueta. O elimínelo todo del caché o recójalo del caché. Por lo tanto, la capacidad de encontrar datos rápidamente, además de las claves, se vuelve muy importante una vez que comienza a almacenar en caché más y más datos.

• Lectura y escritura simultánea

  Esta es la función de la que estaba hablando, la función de lectura y escritura. La importancia de esta característica es que, digamos... Permítanme explicarles primero qué es esto. Entonces, cuando tiene un caché distribuido, si no tiene esta función, su aplicación lee todos los datos, los coloca en el caché y también actualiza la base de datos con ellos. Pero, a medida que hace que el caché sea cada vez más relevante para múltiples aplicaciones, ahora se supone que el caché... si el caché puede volverse más autosuficiente, puede cuidar de sí mismo, entonces eso simplifica las aplicaciones. Entonces tiene múltiples aplicaciones que solo están tratando ese caché como una representación en memoria de las fuentes de datos maestras. Ya sabes, como podrían, como dije mainframe, relacional o NoSQL. Entonces, van a este caché distribuido en memoria como un almacén de valores clave, que es muy sencillo, muy simple, todo está en la memoria, por lo que es súper rápido y el caché distribuido puede leer los datos, si no está disponible para leer -through es algo que es su código que se registra en el caché distribuido. Entonces, el caché distribuido llama a su código, va a la base de datos y lee el elemento correspondiente. Por lo tanto, digamos que hace un caché. Obtenga una clave determinada y ese elemento no estaba en el caché, el caché llamará a la lectura para ir y obtenerlo de la base de datos.

• escribir detrás

  De la misma manera, también puede usar el caché para actualizar los datos no solo en el caché, sino también para actualizar el caché en la base de datos. Y, la escritura en segundo plano es una versión más avanzada en la que la actualización de la memoria caché se realiza de forma sincrónica, pero la actualización de la base de datos se realiza de forma asincrónica.

• Cargador/Actualizador de caché

  El cargador y actualización de caché es nuevamente otra forma en la que puede calentar el caché. Cuando inicia el caché, lo completa con todos los datos que sabe que siempre tendrá. Entonces, de esa manera no tiene que llamar a la lectura directa cada vez. Entonces, una vez que haya cargado ese caché con, digamos, millones de objetos, la actualización de caché es otra característica que puede actualizar periódicamente ciertos subconjuntos de esos datos, según las reglas comerciales que especifique. Esos podrían estar basados ​​en eventos, podrían estar basados ​​en el tiempo, lo que sea que diga su lógica comercial. Puede decir, está bien, vaya y obtenga una copia más reciente de los datos de la fuente de datos maestra.

  Ahora, en muchas de estas situaciones, tendrá este escenario en el que si los datos no son muy confidenciales para el negocio, está bien tener una copia obsoleta, si no es demasiado tarde o demasiado retrasada. Pero al tener estas tres características, lectura directa, escritura simultánea y cargador/actualizador de caché, de repente ahora tiene una caché que es muy inteligente. Puede ingresar y cargarse desde múltiples fuentes de datos y estar disponible no solo dentro de la aplicación, como ya mencioné, sino en múltiples aplicaciones.

Plataforma de intercambio de datos

Entonces, hay múltiples aplicaciones, como mencioné anteriormente, es el beneficio adicional. El beneficio adicional de usar un caché distribuido en memoria. ¿Entonces que significa eso? Lo que eso significa es que ahora el caché distribuido se convierte en una infraestructura común en múltiples aplicaciones. Entonces, cuando las aplicaciones necesitan compartir datos entre sí, en lugar de que se llamen entre sí o vayan a sus bases de datos, simplemente colóquelo en un almacén de valor clave muy simple de entender, que está en la memoria, súper rápido, altamente escalable. Y, debido a que todas las características que mencioné, la lectura directa, la escritura directa, el cargador de caché, la actualización, todas las demás búsquedas de SQL, todas ellas hacen que esto sea una base de datos, pero no es una fuente de datos maestra.

Entonces, en la plataforma de intercambio de datos, el caché no es el maestro. Es solo una copia de otros maestros, pero está destinado solo para compartir. Y sé que muchas empresas en estos días se están enfocando mucho en consolidar múltiples aplicaciones para tener una vista común, una funcionalidad común.

Sé que muchos de los bancos con los que hablamos quieren que se entienda el recorrido del cliente a través de múltiples aplicaciones. Entonces, ¿cómo se comunican esas aplicaciones entre sí? ¿Cuál es ese punto central donde pueden compartir datos entre ellos? Tiene que ser algo en la memoria. Si no está en la memoria, será otro cuello de botella. Y, la belleza de en memoria es que siempre puede reiniciarlo y no hay pérdida de datos. Porque solo recarga datos de las fuentes de datos maestras. Pero, se hará disponible. Y, debido a que es redundante, se replica en varios servidores. Ya sabes, la probabilidad de perder un caché distribuido por completo es muy, muy baja. Y repasaré algunas de las otras funciones en las que puede tener el mismo caché en vivo en varias regiones, varios centros de datos, uno en San Francisco, otro en Nueva York, etc. Y, de esa manera, si tiene alguna situación de recuperación ante desastres, sé que vi en las noticias que hace unos años ustedes enfrentaron un cierre bastante importante. Bueno, situaciones como esa requieren que tengas una verdadera recuperación ante desastres. Entonces, todo tiene que ser replicado en múltiples regiones. Y, cuando usa un caché distribuido para compartir datos, ese caché distribuido también debe replicarse por múltiples razones, iré a eso. Pero este es un beneficio adicional muy importante para las grandes corporaciones, especialmente como Wells Fargo, para reunir múltiples aplicaciones. Y, nuevamente, puede tener varios de estos porque, si es una empresa tan grande, es posible que no tenga un maestro para toda la empresa o puede que sí. O puede tener varios de estos en ciertas partes de su empresa para compartir datos.

Arquitectura de caché distribuida

Ahora que he hablado sobre todas las formas en que puede usar un caché distribuido, ¿qué debe esperar de un buen caché distribuido en términos de su arquitectura?

Alta disponibilidad

El número uno es la alta disponibilidad. Debido a que una caché distribuida se usa en entornos de producción en vivo, si no le brinda una disponibilidad realmente alta, debe ser muy escéptico al respecto y la alta disponibilidad significa que el clúster que crea la caché distribuida debe tener un peer- arquitectura entre pares. Si no tiene una arquitectura peer-to-peer, si tiene algo de maestro esclavo, entonces una vez que el maestro muere, los esclavos se vuelven de solo lectura o inoperables. Por lo tanto, la capacidad de agregar o eliminar un servidor, cualquier servidor en tiempo de ejecución, es muy importante.

Escalabilidad lineal

El número dos es la escalabilidad lineal y eso viene al particionar los datos. Voy a ir a la siguiente diapositiva y hablar de ello. Entonces, la partición es de dos maneras, una solo partición sin replicación y la segunda es partición con replicación. Entonces, un caché distribuido, como mencioné, le brinda redundancia y una replicación inteligente.

¿Qué es esa replicación inteligente? La replicación inteligente significa que todos los datos son... los datos están particionados y cada partición está respaldada en un servidor diferente y todo eso es dinámico. Por lo tanto, es autocurativo. Entonces, cuando agrega un nuevo servidor, se crea una nueva partición y se crean nuevas réplicas y los datos se equilibran automáticamente.

Entonces, aquí hay un ejemplo. Supongamos que comenzó con un clúster de caché de dos servidores y desea agregar un tercero porque su carga de transacciones está creciendo. Tan pronto como agrega un tercer servidor, automáticamente crea una tercera partición. Ahora tienes tres particiones. Entonces, las réplicas también tienen que reajustarlo. Todo eso sucede de forma dinámica o automática.

Y, de la misma manera, digamos, lo desea o un servidor se cayó por alguna razón. Digamos que el servidor 3 se cayó, la partición 3 está caída. Tan pronto como la partición 3 está inactiva, la réplica 3 se activa. Y ahora tiene una anomalía en la que tiene dos servidores y tres particiones. Entonces, ahora tiene que fusionarse automáticamente en dos particiones y dos réplicas. Todo eso debe hacerse automáticamente sin ninguna intervención humana. Si requiere la intervención humana, entonces no es verdaderamente de alta disponibilidad. NoSQL databases, debido a que son bases de datos que tienen que lidiar con el almacenamiento persistente de una gran cantidad de datos, no brindan este reparticionamiento dinámico. Y, está bien para un NoSQL database. Pero no está bien para una tienda en memoria. El almacenamiento en memoria tiene que ser mucho más rápido, mucho más ágil para moverse hacia arriba y hacia abajo en términos de la cantidad de servidores.

Replicación WAN

Aquí está esa alta disponibilidad donde tiene múltiples sitios. Entonces, si tiene un caché distribuido en el sitio 1, digamos en San Francisco y quiere tener el sitio 2, puede tener un activo-pasivo o un activo-activo. Solíamos ver más activo-pasivo, ahora casi todo el mundo se está moviendo a activo-activo debido a la nube. Es mucho más fácil poner en marcha la infraestructura. Entonces, las personas solo tienen sitios activos-activos.

Y en el desafío activo-activo es más porque ambas partes pueden estar actualizando los mismos datos, por lo que debe haber alguna capacidad de resolución de conflictos integrada en el caché distribuido que NCache tiene, pero debe tener en cuenta que, para obtener una verdadera alta disponibilidad, tiene que ir más allá de un centro de datos y tiene que ir a varios centros de datos.

En muchas situaciones, es posible que dos centros de datos no sean suficientes, por lo que, si tiene tres o más centros de datos, aún necesita tener la misma capacidad de replicación activa-activa. Por lo tanto, si un centro de datos deja de funcionar, los otros dos centros de datos deberían poder hacerse cargo de la carga y luego debería poder volver a activar ese centro de datos y hacer que se reincorpore y sus usuarios no deberían ver ninguna interrupción.

Si puede lograr ese objetivo con un caché distribuido, todo de forma dinámica, sin ningún ser humano... una vez más, por supuesto, restaurar un centro de datos necesita la intervención humana. Pero, no debe haber intervención humana cuando un centro de datos deja de funcionar, para que la alta disponibilidad sea realmente alta. Si es incluso cinco minutos menos, no es aceptable.

Ese es el final de mi charla. He tratado de mantenerlo lo más rápido posible, solo para que nos quede algo de tiempo. Sólo voy a darle algunos pensamientos resumidos. Creo que lo principal que quería transmitir es que cada aplicación que está desarrollando, le recomiendo enfáticamente que debe tener un caché distribuido en memoria, para esos tres casos de uso de los que he hablado. Y, entonces, idealmente, también debería usarlo para compartir datos entre múltiples aplicaciones. Y, de cualquier manera, incluso dentro de la misma aplicación, debe intentar tener varios sitios para asegurarse de tener la recuperación ante desastres en esto.

Y, estoy hablando de esto desde 15 años de experiencia. Hemos estado haciendo esto. NCache tiene más de 15 años en el mercado y hemos estado trabajando con muchos bancos. Tradicionalmente hemos sido una tienda .NET, pero NCache ahora es totalmente compatible con .NET, Java y Node.js. Tanto el código del lado del cliente como del lado del servidor para .NET y Java y Node.js son solo la API del cliente. Ese es el final de mi charla.

Gracias, Iqbal. No puedo enfatizar lo suficiente que, a medida que avanzamos en el camino de la modernización en Wells Fargo, cuán oportuna y relevante fue esta presentación. Así que gracias por eso. Equipo, le recordaré que si tiene alguna pregunta, continúe y pregúntela en su chat. Tenemos una serie de preguntas Iqbal. Mucho del equipo de preguntas está presente, ¿estarán disponibles esta presentación y el video? La respuesta es sí. Después de la presentación, esto estará disponible para usted a pedido. Te enviaremos el enlace para arriba. Entonces, Iqbal, estas son algunas de las preguntas que han llegado.

¿Cómo manejan los cachés distribuidos los datos confidenciales? Como, el cifrado transparente es una pregunta.

Sí, creo que no tuve tiempo de entrar en eso, pero ese también es un aspecto muy importante. un producto como NCache, por ejemplo, proporciona EN LINEA en múltiples niveles. Existe la Autenticación, Autorización, Seguridad. No es el cifrado. Entonces, múltiples algoritmos de encriptación. Cifrado de 128 bits y de 256 bits. Existe el TLS, seguridad en el transporte. Entonces, el caché de un banco como Wells Fargo tiene que brindar seguridad y, por eso, trabajamos con bancos. Esa es la característica que hemos tenido durante mucho tiempo. Por lo tanto, los datos se pueden cifrar. Y de nuevo, todo esto es automático. No se necesita programación para hacer esto. Estas son solo configuraciones. Pero una caché distribuida debe abordar la seguridad a través de estas diferentes características.

La siguiente pregunta es, ¿cuál es la diferencia entre tener la base de datos, como los objetos y la memoria de caché de Oracle, y tener otro caché de memoria frente a Oracle? Básicamente, ¿puedo lograr el mismo resultado asignando más memoria a Oracle?

Creo que la palabra clave es 'distribuido'. Cualquier cosa, que no esté distribuida, puede ser rápida pero no escalable. Es por eso que mi primera diapositiva fue la definición de la palabra escalabilidad. ¿Se puede pasar de 1 caja a 10 cajas a 50 cajas como despliegue? Algunos de nuestros clientes tienen una granja de servidores de aplicaciones de 150 o más servidores de aplicaciones. Y, ya sabes, también trabajamos con... por cierto, State Street Bank también es otro cliente nuestro, y con eso, no hay absolutamente ninguna manera de que el almacenamiento en caché en memoria por un solo servidor de base de datos pueda manejar eso. Sí, esa es una característica muy importante para que Oracle, SQL Server y otros sean rápidos, pero no pueden ser escalables. La escalabilidad solo se puede lograr a través de la distribución.

¿Cómo NCache rendimiento en comparación con Redis, Coherence y otros productos del mercado. Y, luego, la otra parte de la pregunta es, ¿tiene algún plan en su hoja de ruta para admitir lenguajes de programación adicionales como Scala o Python? En realidad, déjame responder primero a la segunda pregunta. Sí, vamos a apoyar mucho a Scala y Python. De hecho vamos a hacer eso este año. Hemos estado apoyando a Java durante los últimos casi 10 años. La mayoría de los clientes que utilizan NCache, si son grandes corporaciones, lo usan tanto para Java como para .NET. Aunque, podrían comprarlo desde una perspectiva de .NET. Entonces, esa es la primera.

La segunda pregunta era, ¿cómo NCache rendimiento comparar con Redis ¿y otros? Quiero decir, son todos rápidos. No voy a hacer que nadie se vea mal y creo que ustedes deberían hacer su propia comparación, pero todos son rápidos. Creo que lo único contra lo que te advertiría es que algunos de los jugadores, más o menos, te dan la impresión equivocada de hacer los puntos de referencia. Por ejemplo, los puntos de referencia que damos, incluyen ida y vuelta completa. Entonces, si está haciendo un cache.Get o cache.Insert a menos que la operación de inserción regrese a la aplicación, esa operación no se completa. Sin embargo, algunos de los otros proveedores le mostrarán un punto de referencia mucho más grande que el nuestro, pero harán lo que llaman disparar y olvidar. Entonces, si solo voy a enviarlo y no me preocupo por eso, obviamente puedo hacer mucho más. Y, de hecho, en el lado de Java, Hazelcast y Redis Los laboratorios se han estado persiguiendo exactamente en el mismo punto. Entonces, solo voy a dejarlo así.

Ha trabajado con otros bancos y otras cosas, otros problemas de cumplimiento en torno al uso de datos PCI de nuevo a los datos confidenciales en el espacio de caché. ¿Ha encontrado algún problema de cumplimiento normativo allí?

En realidad no. Me refiero, en primer lugar, al hecho de que proporcionamos todas esas diferentes características de seguridad encriptadas, tanto a nivel de datos. Porque puede cifrar los datos antes de almacenarlos en caché y también a nivel de transporte. También tenemos autenticación y autorización en el extremo del servidor y este es el extremo del servidor de caché. Y creo que eso es suficiente para... y además, un caché se ejecuta dentro de un centro de datos seguro. Un caché no es algo accesible para ninguna entidad externa. Entonces, cuando combinas todo esto con el hecho de que el caché se ejecuta dentro, no hemos tenido ninguno y, ya sabes, hemos tenido... Quiero decir, por ejemplo, Citi Group y Bank of America y Barclays han estado usando NCache durante más de una década y no tuve ningún problema.

¿Cómo funcionará con las bases de datos de mainframe?

Creo que un mainframe es algo que ustedes... Digamos que lo más probable es que ustedes... probablemente tengan servicios web hoy y probablemente desarrollarán algunos microservicios para permitir que las aplicaciones accedan al mainframe. Mainframe es otro caso en el que obtener datos del mainframe es muy costoso. Tanto en términos de velocidad como, a veces, si su mainframe está alojado fuera, es posible que incluso tenga que pagar por transacción o por viaje. Entonces, si puede almacenar en caché más de esos datos dentro de su capa de Kubernetes o Microservicios, como dije, y hacer menos viajes al mainframe, no solo ganará en rendimiento, sino que probablemente también pueda ahorrar mucho dinero.

¿Cómo se garantiza la coherencia y la disponibilidad de los datos en la caché distribuida en memoria cuando se agregan y eliminan nodos?

Entonces, al menos puedo hablar de NCache esa NCache asegura que cuando agrega o elimina nodos, cualquier actualización que se esté realizando, cualquier cambio que se esté realizando se complete con el hecho de que estamos haciendo la transferencia de estado, digamos, estamos moviendo la partición y esas cosas, NCache es consciente de que debe asegurarse de que todas esas actualizaciones se apliquen correctamente mientras se asegura de que el nodo se agrega y la transferencia de estado, lo que llamamos transferencia de estado, que es el equilibrio de datos para mover datos de una partición a otra que también sigue pasando. Asi que, NCache lo asegura

Al tener Microservicios distribuidos con sus propias bases de datos, como vi en la imagen, ¿cómo pueden estos brindar una experiencia omnicanal al cliente?

Entonces, la parte de la base de datos distribuida, creo que el jurado está deliberando sobre cuán distribuidas serán esas bases de datos. Cuán particionadas van a estar esas bases de datos. Porque, como dije en mi charla, al menos en teoría, cada microservicio puede tener su propia base de datos lógica, aunque físicamente puedan residir en los mismos servidores de base de datos, porque, cuando está implementando cosas, no va a tener 100 servidores de bases de datos diferentes, cada uno para cada microservicio. Vas a tener algunos servidores de bases de datos consolidados. El hecho de que tengas separación probablemente te da un poco más de flexibilidad al igual que NoSQL pero, el jurado aún está deliberando sobre cuánto puede realmente salirse con la suya con esa limitación de una base de datos relacional. Mi predicción es que terminará con los mismos servidores de bases de datos relacionales. Puede o no tener la separación lógica. Puede tener esquemas separados o puede tener el mismo esquema, solo está hablando con tablas diferentes, pero los servidores de la base de datos seguirán siendo los mismos. Entonces, es el mismo problema que está abordando incluso en los servicios web, ellos lo abordarán en los microservicios. Creo que con el tiempo se acaba. No puedo agradecerte lo suficiente. Esto ha sido muy interesante. Las preguntas siguen llegando, pero está claro que no podemos abordarlas todas. Entonces, con eso te lo devolveré.

¿Qué hacer a continuación?

• NCache Detalles
• Descargar NCache
• Solicite una demostración EN VIVO personalizada