Entendiendo la arquitectura de datos de Salesforce

La confianza es el valor número uno en Salesforce se puede ver en la forma en que se ha diseñado la arquitectura central de Salesforce. Teniendo en cuenta que existen miles de millones de transacciones en la plataforma, no es una tarea fácil garantizar que los datos de los clientes estén debidamente asegurados y protegidos de los numerosos vectores de ataque utilizados por los malos actores.

Multi-tenancy

Salesforce trabaja en un modelo SaaS (Software as a Service), donde los clientes pagan una tarifa de suscripción por los servicios que utilizan proporcionados por Salesforce. Si ha utilizado servicios de correo electrónico como Hotmail, detrás de escena no hay un servidor de base de datos dedicado ni un servidor de aplicaciones. Más bien, Microsoft ha diseñado el sistema de modo que cientos de miles de usuarios puedan utilizar el mismo hardware y software.

Con SaaS, en lugar de tener usuarios individuales, tendrá varios grupos de usuarios que acceden a Salesforce. Piense en estos grupos de usuarios como empresas individuales que se suscriben a Salesforce y lo que acceden en Salesforce es una organización con un nombre adecuado. El aspecto clave de SaaS es la tenencia múltiple, lo que significa que grupos de usuarios comparten recursos. Detrás de escena, utilizan el mismo hardware y almacenamiento, pero el software mantiene sus datos separados.

Otro aspecto de Multi-tenancy es que, dado que los recursos se comparten, no se puede permitir que ningún tenant monopolice el sistema, poniendo en peligro los recursos que podrían afectar el rendimiento o, lo que es peor, derribar instancias completas. Salesforce emplea límites reguladores y buenas prácticas generales para alentar a sus usuarios a escribir consultas y códigos eficientes. 

Miles de clientes confían en Salesforce con sus datos críticos para el negocio, y no es poca cosa asegurarse de que el cliente A no pueda acceder a los datos de otro cliente. Esto se realiza mediante el ID de la organización, que es un ID único que se asigna a la organización de cada cliente de Salesforce. Siempre que se realiza una llamada a la base de datos a la plataforma para acceder a los datos, el ID de la organización se incluye automáticamente en ella para evitar el acceso no autorizado.

Los clientes de Salesforce también disfrutan del beneficio de estar al día con las versiones de lanzamiento del producto. Siempre hay una única versión de la plataforma que se ejecuta en todas las organizaciones de Salesforce. Esto significa que los clientes no tienen que preocuparse por la actualización o las pruebas de regresión porque todo ese trabajo pesado lo realiza Salesforce.

La arquitectura de la plataforma Salesforce es compleja y comprende muchas bases de datos y servidores de aplicaciones junto con una multitud de servicios que realizan diferentes funciones, como búsqueda, ejecución de lógica empresarial, almacenamiento en caché y gestión de eventos. 

Arquitectura impulsada por metadatos

Una plataforma multi-tenant como Salesforce, que está basada en la nube, tiene sus propios desafíos en términos de escalabilidad, confiabilidad y seguridad que deben superarse. Lo más importante de todo es cómo se asegura de que otros tenants no puedan acceder a los datos de un tenant. Además, dado que solo hay una versión del software en producción, aplicar actualizaciones sin un tiempo de inactividad significativo a la plataforma es otro desafío, especialmente cuando se realiza tres veces al año. ¿Qué sucede cuando un tenant personaliza una aplicación que creó o personaliza la aplicación de ventas lista para usar para cumplir con los requisitos comerciales? ¿Se escriben sus personalizaciones cuando Salesforce actualiza la instancia de producción? ¿El tenant tiene que volver a aplicar sus personalizaciones? ¿Qué sucede cuando un cliente almacena grandes cantidades de datos en la plataforma? ¿El sistema se ralentiza para otros clientes? Para responder a estas y otras preguntas relacionadas, veremos qué es la arquitectura basada en metadatos.

Como se puede ver en el siguiente diagrama, Salesforce utiliza una arquitectura que delimita entre el kernel del sistema, el motor principal que realiza la virtualización, del que hablaremos pronto, la base de datos y la aplicación de tenant, que debe ser de naturaleza polimórfica, en otras palabras, dinámico, para satisfacer las distintas necesidades de diferentes clientes:

Como se puede ver en el diagrama anterior, el runtime engine genera la aplicación en tiempo de ejecución utilizando metadatos y datos que pertenecen al tenant.

Cualquier actualización aplicada al kernel no afectará a otras capas de la arquitectura. De manera similar, cuando se realiza un cambio en los metadatos comunes, los metadatos específicos del tenant no se ven afectados, ni los datos del tenant. En el tiempo de ejecución, el kernel o el runtime engine de ejecución construye la aplicación del tenant utilizando los metadatos comunes, los metadatos específicos del tenant y los datos. En las siguientes subsecciones, analizaremos los componentes clave de la arquitectura basada en metadatos. Esta no es una discusión exhaustiva, sino más bien sugerencias para que comprendamos los componentes clave que debemos conocer desde la perspectiva de la arquitectura de datos.

El kernel

El kernel, o motor en tiempo de ejecución (runtime engine), es el núcleo de la plataforma que se compone de múltiples servicios que trabajan juntos para brindar servicios.

Dado que los metadatos se utilizan como un componente clave para generar la aplicación cliente en tiempo de ejecución, la plataforma utiliza una caché de metadatos para mejorar el rendimiento; de lo contrario, el sistema no podría escalar con cargas elevadas. La caché de metadatos almacena los metadatos de uso frecuente en la memoria, lo que reduce la necesidad de costosas llamadas a la base de datos que afectan el rendimiento.

El motor de procesamiento de datos masivo procesa grandes cantidades de datos y trabaja para realizar modificaciones de datos de forma masiva. El motor tiene tolerancia a fallas incorporada que le permite reintentar automáticamente operaciones masivas para registros que se pueden procesar con éxito.

La plataforma también tiene un servicio de motor de búsqueda con todas las funciones que optimiza el acceso a las capacidades de búsqueda completas. Este servicio procesa las actualizaciones de datos de forma asincrónica en segundo plano. Es posible que haya notado esto al cargar grandes volúmenes de datos e inmediatamente después de buscarlos. Debido a que el motor funciona de forma asincrónica, es posible que deba esperar hasta 15 minutos antes de que su búsqueda arroje resultados. Esto es diferente de una base de datos tradicional, donde los procesos en segundo plano se ejecutan en las tablas de la base de datos real y actualizan los índices.

Cuando abre una página o emite una llamada a la API para consultar datos, en las bases de datos tradicionales, se crea un plan de consulta y el optimizador determina y ejecuta el método más óptimo para ejecutar la consulta. Este tipo de optimizador no funcionaría con Salesforce debido a su naturaleza de múltiples tenants, en otras palabras, las tablas físicas en la base de datos tienen datos para decenas de miles de clientes y los resultados del optimizador de consultas no serían precisos ni eficientes. Aquí es donde entra en juego el optimizador de consultas de múltiples tenants, que es un optimizador inteligente que conoce la naturaleza de múltiples tenants de Salesforce. Determina las rutas de consulta más eficientes considerando al usuario que ejecuta la consulta y luego utiliza los metadatos específicos del tenant que se mantienen en el UDD, junto con algunas otras tablas clave, para ejecutar operaciones de datos optimizadas en la base de datos.

Diccionario de datos universal (UDD)

La base de datos física en Salesforce se ve muy diferente de lo que ve cuando mira los metadatos de un objeto en Configuración o ejecuta un método decribeSObject desde el backend. Esto se debe a que Salesforce emplea una capa de abstracción en el servidor de aplicaciones que, en tiempo de ejecución, lee datos de la base de datos y aplica otra lógica que da como resultado la forma de su organización, en otras palabras, objetos, campos, relaciones, vistas de lista, etc. sobre. Esta capa, llamada Universal Data Dictionary, o UDD para abreviar, es declarativa, lo que significa que los nombres de los objetos, sus atributos y relaciones se almacenan y no se generan a través del código. Lo que ve en la organización es el resultado de que el kernel actúa sobre el UDD, ya que el kernel actúa como una capa de mapeo entre el UDD y lo que ve en su organización. El siguiente es un diagrama del UDD y sus componentes:

Como se ve aquí, el UDD tiene varios componentes diferentes que se unen para entregar la aplicación en tiempo de ejecución.

Cuando crea un objeto en Salesforce, no está creando ese objeto como una tabla de base de datos, con los atributos del objeto como columnas y los datos que van a la tabla como filas. Si ha trabajado en una base de datos, utiliza el lenguaje de definición de datos (DDL) para crear tablas, agregar columnas / filas, eliminar filas, etc. Esto no es lo que sucede cuando se crea un objeto en Salesforce porque está interactuando con la capa intermedia y no directamente con la base de datos. Por supuesto, hay algunos datos relacionados con el objeto almacenados en la base de datos pero, como se mencionó anteriormente, se crea una tabla física con columnas como campos para su objeto. Una de las razones por las que se hace esto es para escalar el sistema y permitir que este modelo de tenencia múltiple funcione de manera eficiente. Otra razón es evitar el bloqueo de la base de datos de la tabla, lo que ocurre cuando se ejecuta un DDL con fines de integridad de datos. Esta es la razón por la que no puede ejecutar un DDL directamente en la base de datos, como crear una tabla como SOLICITANTE.

Debido a esta capa intermedia, no tendrá índices, claves externas o la capacidad de ejecutar planes de consulta en sus consultas SOQL porque no devolverá datos procesables ya que todo eso es manejado por la capa intermedia. Tenga en cuenta que el UDD almacena todos los metadatos definidos por el tenant, ya sea a través de la interfaz de usuario o mediante API.

Dado que los metadatos se utilizan como un componente clave para generar la aplicación cliente en tiempo de ejecución, la plataforma utiliza una caché de metadatos para mejorar el rendimiento; de lo contrario, el sistema no podría escalar con cargas elevadas. La caché de metadatos almacena los metadatos de uso frecuente en la memoria, lo que reduce la necesidad de costosas llamadas a la base de datos que afectan el rendimiento.

Todos los datos de la aplicación se almacenan en unas pocas tablas muy grandes en la plataforma y el kernel materializa tablas virtuales en tiempo de ejecución. Veremos algunas de las tablas clave en las siguientes secciones, pero la premisa es que cuando el tenant crea, por ejemplo, objetos personalizados en su organización, los campos, cualquier relación entre ellos y otros atributos se almacenan en el UDD. Estos metadatos, junto con las tablas de datos (tablas que contienen los datos de tipo transaccional del inquilino) y algunas tablas dinámicas especializadas mantienen los datos en un formato desnormalizado. Esto hace que la arquitectura esté optimizada y sea muy funcional para presentar rápidamente la estructura virtual que luego podemos ver desde la interfaz de usuario. Algunas de las tablas clave se dan aquí:

 Como se puede ver en el diagrama anterior, todos los objetos y campos personalizados se definen en tablas y no se crean tablas de base de datos físicas. 

Nuevos releases

Salesforce ha estado constantemente clasificada como una de las empresas más innovadoras del mundo. Una de las razones de esto es su extraordinario ritmo de innovación. Una de las formas en que esto se ha manifestado es en los tres principales lanzamientos al año que hace Salesforce. Estos lanzamientos incluyen decenas y, a veces, cientos de funciones nuevas que se introducen cada año. Entonces surge la pregunta de cómo Salesforce garantiza que la configuración / personalización de cada una de las miles de organizaciones de clientes no se rompa con cada nueva versión.

Aquí es donde entra Hammer. Hammer se refiere al período de tiempo antes de cada versión cuando Salesforce implementa una freeze de cambios interna unas semanas antes de actualizar sus entornos sandbox con la nueva versión. Hammer ejecuta todas las pruebas unitarias que existen en las organizaciones de clientes dos veces: una antes de la aplicación de la versión y después de que la versión se haya aplicado a un entorno de pruebas. Luego, los resultados se comparan con la expectativa de que todas las pruebas que pasaron o fallaron antes de la publicación seguirán dando el mismo resultado una vez que se haya aplicado la versión.

Por supuesto, las cosas no siempre salen según lo planeado en el mundo del software y cualquier discrepancia identificada como regresión debe corregirse rápidamente. Una aplicación automatizada analiza los resultados del antes y el después para garantizar que los resultados se hayan eliminado de cualquier dato confidencial antes de enviarlos al equipo de Salesforce para tomar medidas. Este ejercicio se conoce colectivamente como Hammer debido al esfuerzo masivo que requiere considerando que no solo es Apex sino Visualforce, y también otros componentes de metadatos. Ahora podemos ver por qué es importante escribir clases de prueba que realmente prueben su código, ya que Salesforce también las usa antes de cada versión para ejecutar estos millones de pruebas combinadas y garantizar que la versión no rompa nada. Esto significa que si en una nueva versión su código se rompiera, Salesforce lo detectaría al ejecutar Hammer y corregiría el código. Pero si las clases de prueba estaban mal escritas, o con miras a simplemente pasar el requisito de cobertura de prueba del 75%, es posible que estas no se detecten cuando el equipo de Salesforce esté ejecutando pruebas y luego necesitaría invertir recursos para corregir su código.