Arquitectura multi-tenant en Salesforce

 Arquitectura multi-tenant en Salesforce



Es importante saber qué es la plataforma Lightning antes de comenzar a hablar sobre multi-tenancy. La plataforma Lightning es la infraestructura en la que las empresas pueden habilitar uno o más de los productos en la nube de Salesforce (Sales Cloud, Service Cloud, Marketing Cloud, IoT Cloud, Integration Cloud, Community Cloud, Health Cloud, y Financial Services Cloud), instalar aplicaciones desde AppExchange (la tienda de Salesforce) o crear sus propias aplicaciones personalizadas.

El uso de la plataforma sola, es decir, sin uno de los principales productos de nube como Sales Cloud o Service Cloud, también es posible a través de la opción de plataforma como servicio (PaaS) de Salesforce. De manera similar a su aplicación CRM, los clientes pueden pagar una tarifa mensual para acceder a los recursos compartidos y crear aplicaciones personalizadas a través de PaaS.

Los mayores beneficios de usar o comprar un producto de servicio en la nube es que el proveedor se encarga de todo, es decir, los servidores, el espacio de almacenamiento, la infraestructura, las redes, la seguridad, las copias de seguridad y las actualizaciones.

Algunas características del uso de servicios basados ​​en la nube son las siguientes:

  • Son modelos basados ​​en una suscripción.
  • Tienen tarifas de inicio bajas
  • Tienen costos fijos y predecibles (es decir, pagas según usas el servicio)
  • Son escalables
  • Incluyen actualizaciones regulares y automatizadas
  • Son plataformas multiusuario; esto significa que varios clientes usan (o comparten) la misma instancia

Estas son características importantes a tener en cuenta cuando se habla de multi-tenancy.


Que es multi-tenancy?

Cuando trato de explicar a mis clientes el concepto de multi-tenancy, siempre lo comparo con un grupo de departamentos.
Por ejemplo, considere un escenario en el que usted, como empresa o cliente, alquila un departamento en un edificio que es propiedad de Salesforce, que es su arrendador:




Aquí, su departamento tiene diseños y recursos específicos, es decir, tiene varias habitaciones divididas por paredes. Además de esto, tiene calefacción central, electricidad, agua, y más. Para acceder y utilizar este departamento, usted paga un alquiler mensual, y el propietario se encarga de todo lo demás para usted y los demás ocupantes del edificio.

Aparte de su departamento (que es su espacio privado), todos los demás recursos son compartidos por los ocupantes del edificio. Esto significa que si Salesforce decide actualizar la calefacción central a calefacción solar, automáticamente se beneficiará de esto. Puede ver esto como tres versiones (es decir, actualizaciones que contienen nuevas funciones y mejoras) al año, que implementa Salesforce.

¡Dentro de su apartamento, puede diseñar su interior de la manera que desee y ajustarlo a sus necesidades y preferencias personales! Por ejemplo, puedes elegir qué habitación tener como dormitorio o como cocina; o, alternativamente, puede utilizar todo el apartamento como espacio de oficina. Incluso puedes pintar las paredes de azul o verde llamativo si quieres. Esto es similar a usar una plataforma de Salesforce, donde una vez que tiene acceso a su espacio, puede crear nuevos objetos personalizados, agregar campos y automatizar funciones para satisfacer sus necesidades comerciales.

Lo único que no puedes hacer es derribar las paredes; de lo contrario, todo el edificio se derrumbará, ¿verdad? A pesar de que tiene total flexibilidad para reorganizar su departamento, ¡todavía está limitado cuando se trata de ciertas cosas! Por ejemplo, no puedes poner un sofá de 5 metros si el tamaño de la habitación es más pequeño que este; Además, no puedes poner un árbol de Navidad que sea más alto que la altura de tu habitación, o tendrías que romper el techo y tu vecino iniciaría una demanda en tu contra. ¡Alternativamente, no puedes simplemente instalar múltiples accesorios o máquinas de alto voltaje en su apartamento sin que la caja de electricidad explote y deje todo el edificio sin energía!

Utilizo esta analogía para explicar los límites que aplica Salesforce. Salesforce aplica estos límites para asegurarse de que ningún ocupante individual consuma recursos que puedan afectar a otros tenants u ocupantes que utilizan la infraestructura de Salesforce.

Salesforce utiliza una arquitectura multiusuario, lo que significa que varias organizaciones (orgs) comparten los mismos recursos de TI, a diferencia de los recursos dedicados. Esto da como resultado un entorno estándar totalmente operado y administrado por Salesforce, que es mucho más eficiente y rentable para su empresa.

La unidad autónoma que permite que se ejecute una organización(org) se denomina instancia; contiene todo lo que se necesita para ejecutar una organización:
  • Un servidor de aplicaciones y bases de datos.
  • Un servidor de archivos
  • Una infraestructura de servidor, almacenamiento y red.

Una org es una configuración independiente (o metadatos) y datos dedicados a un cliente. Está representado por una identificación única que puede encontrar en la sección Perfil de la empresa en Configuración. Debe proporcionar este ID cada vez que se comunique con el soporte de Salesforce para Casos, Solicitud de función y más. Cada organización (org) solo se ejecuta en una instancia, que sirve a miles de otras organizaciones (orgs).

La identificación única de la organización (org) se almacena en cada tabla en la base de datos compartida para permitir el filtrado de datos y garantizar que solo ese cliente acceda a los datos de un cliente.

Algunas ventajas multi-tenancy son las siguientes:
  • Todos los clientes de Salesforce, desde pequeñas empresas hasta grandes empresas, tienen la misma base de código y todos se benefician de las mismas características y la nueva funcionalidad.
  • Las actualizaciones de Salesforce son fáciles, automáticas y sin inconvenientes. Hay tres actualizaciones automáticas al año, que se denominan versiones de primavera, verano e invierno.
  • Con las actualizaciones, se asocia una versión con cada Apex Trigger y clase de Apex. Aquí, la compatibilidad con versiones anteriores está asegurada.
  • Cada clase tiene una versión asociada llamada versión API. Cuando pasa a la siguiente versión, la clase de Apex siempre usa la versión anterior del compilador para garantizar esta compatibilidad con versiones anteriores. De lo contrario, puede modificar el código para que funcione en la versión más reciente.

Entonces, si varios clientes comparten todos los recursos, ¿cómo se asegura Salesforce de que un cliente no consuma todos los recursos o rompa cosas que podrían afectar a todos los demás clientes en la misma instancia?
  • Gobierno de Límites: estos son los límites aplicados por Salesforce que no se pueden cambiar y son los mismos para cualquier persona que use la plataforma. Por ejemplo, solo puede usar 100 consultas en un contexto de ejecución o realizar 150 declaraciones DML (abreviatura de Lenguaje de manipulación de datos) en un contexto de ejecución. Puede encontrar la lista de todos los límites en la documentación de Salesforce en https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm.
  • Pruebas obligatorias: Salesforce lo obliga a probar su código antes de que se le permita implementarlo en producción o cargar un paquete en AppExchange. Al menos el 75% de todo el código debe estar cubierto por pruebas y todas deben pasar. Cada trigger dentro de su paquete de implementación necesita al menos algo de cobertura. Es una buena práctica probar todos los escenarios posibles, incluidas las pruebas positivas y negativas, además de probar la creación o las actualizaciones masivas.





Comentarios

Entradas más populares de este blog

Mejores practicas para migración de datos a Salesforce

AWS Lambda

Modelado de datos en Salesforce