Espacios de trabajo, instancias y alojamiento
Archestack suele desplegarse a través de un partner de implantación: una empresa que construye una aplicación sobre Archestack y la entrega a sus clientes. Esta página sigue un mismo ejemplo de principio a fin: una empresa de software que ha construido una aplicación para laboratorios de ensayo, las empresas que analizan alimentos, agua y materiales para otras empresas. La aplicación sigue cada muestra desde su recepción hasta el certificado, y la empresa de software la va implantando en un laboratorio tras otro. Cada laboratorio es un cliente, y cada uno tiene sus propios clientes empresariales: los productores de alimentos, las empresas de aguas y los fabricantes que le envían muestras.
El resto de esta página gira en torno a tres palabras:
- Cliente: una empresa a la que el partner entrega la aplicación. En este ejemplo, cada laboratorio.
- Espacio de trabajo: el entorno aislado en el que trabaja un cliente, con su propia aplicación, sus propios datos y sus propios miembros. Su nombre técnico es tenant.
- Instancia: una copia en ejecución de Archestack. Ejecuta uno o muchos espacios de trabajo.
En resumen: un cliente trabaja en un espacio de trabajo, y un espacio de trabajo se ejecuta en una instancia. Las secciones siguientes explican qué es un espacio de trabajo y qué lo mantiene separado, las dos formas de alojar los espacios de trabajo de tus clientes, cómo un laboratorio da acceso a sus propios clientes, cómo se aloja el propio Archestack y cómo llega una nueva versión de tu aplicación a cada cliente.
Qué es un espacio de trabajo
Un espacio de trabajo es el entorno aislado en el que trabaja un cliente. Contiene la aplicación entera, los datos con los que trabaja esa aplicación y las personas que tienen acceso, y queda separado de todos los demás espacios de trabajo. Cada laboratorio recibe uno.
Tenant es el nombre técnico de lo mismo. Las pantallas dicen espacio de trabajo; la API y el código dicen tenant, la palabra que da nombre al alojamiento single-tenant y multi-tenant. Espacio de trabajo y tenant no son dos capas, y ninguno contiene al otro: un laboratorio tiene un espacio de trabajo, y la API llama tenant a ese espacio de trabajo. En esta página se habla siempre de espacio de trabajo.
Instancia de Archestack Qué hay dentro de un espacio de trabajo
Un espacio de trabajo contiene tres cosas:
- Core, una base de datos PostgreSQL que contiene la propia aplicación: business entities, páginas, business events, script modules, scheduled events, plantillas PDF, paquetes, releases, test suites, endpoints de la Data API y claves de API, tokens de MCP, branding, app layouts, traducciones, ajustes, cuentas de correo y la bandeja de salida, además de las preferencias y notificaciones de sus usuarios. Las contraseñas y demás secretos que se guardan aquí están cifrados, y de las claves de API y los tokens de MCP solo se guarda un hash.
- Runtime, una base de datos PostgreSQL que contiene los datos de negocio: las tablas y sus filas, en este ejemplo las muestras, los análisis, los resultados, los certificados de análisis y las facturas. El Schema Designer muestra su estructura exactamente como está en la base de datos.
- Miembros: las personas que tienen acceso, cada una con un rol en este espacio de trabajo. Las invitaciones se envían por espacio de trabajo.
Como la aplicación vive en Core, dos laboratorios que usan la misma aplicación tienen cada uno su
propia copia. Un cambio hecho en un espacio de trabajo se queda allí hasta que lo entregues a los
demás, que es para lo que sirven los paquetes. Un espacio de trabajo
también puede tener su propia dirección, como peeters.labapp.example.com. Con el
alojamiento de Archestack también puede servirse en un dominio propio de la empresa, como
app.peeters.be: un administrador lo añade en la página Domains del builder
y lo demuestra con un registro DNS, y el certificado llega solo.
Qué mantiene separados los espacios de trabajo
La API y las tareas en segundo plano dan servicio a todos los espacios de trabajo de la instancia, pero cada petición y cada tarea programada trabajan para un único espacio de trabajo:
- Bases de datos separadas. Las páginas, las business entities y las consultas de un espacio de trabajo no pueden acceder a las tablas de otro.
- Un token, un espacio de trabajo. Cada petición con sesión iniciada lleva un token firmado que nombra exactamente un espacio de trabajo, y solo se abren las bases de datos de ese espacio de trabajo.
- Sin desvíos. Un token que nombra un espacio de trabajo inexistente o suspendido se rechaza, y nunca se redirige a otro espacio de trabajo.
- Claves que nombran su espacio de trabajo. Las claves de API y los tokens de MCP llevan el nombre del espacio de trabajo al que pertenecen y solo funcionan allí.
- Tareas que no salen de su espacio de trabajo. Las tareas programadas se ejecutan dentro del espacio de trabajo al que pertenecen.
- Copias de seguridad por espacio de trabajo. Las copias de seguridad, las restauraciones y las exportaciones abarcan el Core y el Runtime de un solo espacio de trabajo, así que los datos de un cliente se pueden restaurar o exportar sin tocar los de otro.
Una cuenta, un rol por espacio de trabajo
Las cuentas pertenecen a la instancia; las membresías, al espacio de trabajo. Una persona tiene una sola cuenta en una instancia, con una dirección de correo y una contraseña, y puede ser miembro de varios espacios de trabajo con un rol distinto en cada uno. Los consultores del partner pueden ser admin en el espacio de trabajo de cada laboratorio del que se ocupan, mientras que el personal de un laboratorio solo es miembro de su propio espacio de trabajo.
Quien pertenece a varios espacios de trabajo cambia de uno a otro desde el menú del avatar. El cambio emite un token nuevo, que abre el otro espacio de trabajo y solo ese. Quitar a alguien de un espacio de trabajo no afecta a sus demás membresías.
El espacio de trabajo principal y los nuevos
Cada instancia crea un espacio de trabajo principal la primera vez que arranca. Una empresa que necesita un único entorno simplemente trabaja en él. Un partner con muchos clientes reserva el espacio de trabajo principal para su propio equipo y crea un espacio de trabajo por cliente. Un espacio de trabajo nuevo se crea en aproximadamente un segundo y empieza vacío.
Dividir un espacio de trabajo
Dos funciones dividen aún más un espacio de trabajo. Ninguna crea un entorno nuevo: ambas funcionan dentro del espacio de trabajo, sobre su propio Core y su propio Runtime.
- Los business units lo dividen por equipo, para que cada equipo vea las páginas y business entities que le conciernen. No ocultan filas de datos, así que no son una separación.
- Las organizaciones cliente lo dividen por cliente. No son espacios de trabajo propios. Viven dentro del espacio de trabajo del laboratorio, no a su lado, sin bases de datos propias: los clientes del laboratorio usan la aplicación del laboratorio, lo que introducen acaba en el Runtime del laboratorio y cada cliente ve solo sus propias filas. Se explica más abajo.
Dos formas de alojar a tus clientes
Todo espacio de trabajo se ejecuta en una instancia: una copia en ejecución de Archestack, con su API, sus tareas en segundo plano y un servidor PostgreSQL que contiene las bases de datos de sus espacios de trabajo. Los espacios de trabajo de una misma instancia comparten la instancia que los rodea, no las bases de datos de los demás:
| Propio de cada espacio de trabajo | Compartido por los espacios de trabajo de una instancia | |
|---|---|---|
| La aplicación | Core: páginas, business entities, script modules, ajustes y lo demás | La versión de la plataforma. Una actualización llega a todos los espacios de trabajo a la vez. |
| Los datos | Runtime: sus tablas y filas | El servidor PostgreSQL que contiene las bases de datos |
| Personas | Miembros, roles e invitaciones | Las cuentas: una dirección de correo y una contraseña por persona |
| Trabajo en segundo plano | Sus tareas programadas, que se ejecutan dentro del espacio de trabajo | Las tareas en segundo plano y el planificador de tareas |
| Módulos | Los paquetes que tiene instalados | El catálogo del Module Store |
Los espacios de trabajo de una instancia también comparten su capacidad: procesador, memoria y conexiones a la base de datos. Para cada cliente, el partner decide si su espacio de trabajo recibe una instancia propia o comparte una con los espacios de trabajo de otros clientes. En ambos modelos cada cliente tiene un espacio de trabajo propio con su propio Core y su propio Runtime. Lo que cambia es cuántos espacios de trabajo comparten una instancia y, por tanto, qué comparten entre sí.
Un espacio de trabajo por instancia (single-tenant)
Archestack Archestack Archestack Cada laboratorio recibe una instancia propia, con su propia API y sus propias tareas en segundo plano, y un espacio de trabajo con sus propias bases de datos Core y Runtime. Es adecuado para clientes grandes, para clientes que deciden dónde viven sus datos y para clientes que eligen cuándo actualizar. El partner puede operar estas instancias o instalar una en la cuenta de nube o el centro de datos del propio laboratorio.
Ventajas
- La separación más fuerte posible. No se comparte nada con otros clientes, ni siquiera la plataforma.
- Capacidad propia. Un laboratorio con mucha actividad nunca ralentiza a otro, y su instancia se dimensiona solo para él.
- Actualizaciones al ritmo del cliente. Cada instancia pasa a una nueva versión de la plataforma cuando le conviene a ese cliente.
- Los datos viven donde el cliente quiere: una región, una cuenta de nube o sus propios servidores.
- Un final limpio. Entrega la instancia o apágala.
Desventajas
- Hay que operar cada instancia: servidores, certificados, copias de seguridad, monitorización y actualizaciones, una vez por cliente.
- Cada nueva versión de tu aplicación tiene que importarse en cada instancia por separado.
- Tu propio personal necesita una cuenta en cada instancia en la que trabaja.
- Hasta el cliente más pequeño necesita una instancia completa.
Varios espacios de trabajo por instancia (multi-tenant)
Archestack
Una sola instancia da servicio a muchos laboratorios. Cada laboratorio sigue siendo un espacio de
trabajo propio, con sus propias bases de datos Core y Runtime y, si quieres, su propia dirección,
como peeters.labapp.example.com. Los administradores de la instancia crean un espacio
de trabajo nuevo en aproximadamente un segundo.
Ventajas
- Cada cliente sigue teniendo sus propias bases de datos, sus propias copias de seguridad y su propia versión de la aplicación, adaptada a su forma de trabajar.
- Añadir un cliente lleva aproximadamente un segundo, y un cliente con poca actividad no cuesta casi nada: un espacio de trabajo sin uso no mantiene ninguna conexión a la base de datos.
- Una sola instancia que operar, proteger y actualizar.
- Tus consultores usan una sola cuenta y cambian de cliente desde el menú del avatar.
Desventajas
- Todos los clientes pasan a una nueva versión de la plataforma en el mismo momento.
- Los clientes comparten la capacidad de la instancia, así que dimensiónala para todos ellos juntos. Una instancia con más de unas decenas de espacios de trabajo en uso a la vez también requiere subir el límite de conexiones de PostgreSQL por encima de su valor por defecto, 100.
- Cada nueva versión de tu aplicación se sigue instalando espacio de trabajo por espacio de trabajo, desde el Module Store de la instancia o desde un ZIP.
Comparativa
| Un espacio de trabajo por instancia | Varios espacios de trabajo por instancia | |
|---|---|---|
| Bases de datos propias | Sí, en su propio servidor | Sí, en un servidor compartido |
| Capacidad | Por cliente | Compartida |
| Versión de la plataforma | Por cliente | Compartida |
| Dónde pueden estar los datos | En cualquier sitio, incluida la nube del propio cliente | Donde el partner opere la instancia |
| Entregar una nueva versión de la aplicación | Un ZIP importado en el espacio de trabajo de cada cliente | Instalada en el espacio de trabajo de cada cliente, desde el Module Store de la instancia o desde un ZIP |
| Añadir un cliente | Una instancia nueva | Aproximadamente un segundo |
| Coste por cliente | Más alto | Bajo |
Combinar ambos modelos es lo normal: los laboratorios pequeños comparten una instancia, un gran grupo de laboratorios recibe una propia, y ambos reciben los mismos paquetes. Desarrollo, pruebas, aceptación y producción son cada uno un espacio de trabajo propio. Pon desarrollo, pruebas y aceptación en una instancia y producción en una instancia propia, para que una actualización de la plataforma llegue a aceptación antes que a producción.
Los clientes de un cliente, dentro de su aplicación
Un laboratorio tiene sus propios clientes: productores de alimentos, empresas de aguas y fabricantes que le envían muestras. Quieren registrar las muestras que envían y seguir cada una mientras el laboratorio trabaja en ella. Un productor de alimentos nunca debe ver las muestras de otro productor; el laboratorio las ve todas. El laboratorio puede dar acceso a estos clientes a la aplicación que el partner construyó para él, como organizaciones cliente.
El partner construye la aplicación y elige el alojamiento, con cualquiera de los dos modelos anteriores. El laboratorio no nota cuál se ha elegido, y sus clientes tampoco. Después, el laboratorio invita a sus clientes o deja que se registren por sí mismos.
Una organización cliente no es un espacio de trabajo y no tiene bases de datos propias. Vive dentro del espacio de trabajo del laboratorio: la aplicación pertenece a ese espacio de trabajo, cada cliente tiene sus propios miembros, y todo lo que introducen acaba en la base de datos Runtime del laboratorio, marcado con la empresa que lo escribió. Cada cliente ve solo sus propias filas, el laboratorio las ve todas, y un cliente puede tener sus propias subunidades: un grupo alimentario, por ejemplo, con una subunidad para cada una de sus fábricas y otra para cada línea de producción de una fábrica. Cada unidad ve sus propias filas y las de las unidades que tiene por debajo. Los clientes usan la aplicación tal como la publica el laboratorio y no la modifican, y el propio administrador de cada cliente invita y quita a sus compañeros.
Infraestructura de alojamiento
Archestack se distribuye como una única imagen de contenedor que ejecuta tanto la API como las tareas en segundo plano: scheduled events, correo saliente, ejecuciones de test suites, sincronizaciones con otros sistemas y las copias de seguridad nocturnas. Escala en horizontal: ejecuta más copias de la misma imagen detrás de un balanceador de carga a medida que crece el número de usuarios. Las copias se coordinan a través de PostgreSQL, así que el trabajo programado se reparte entre ellas y cada tarea se ejecuta una sola vez.
Imagen de Archestack Imagen de Archestack Ejecutar más de una copia pide algunas cosas a la infraestructura que la rodea:
- Sin sesiones persistentes, pero los WebSockets tienen que pasar. Cualquier copia puede responder a cualquier petición. Las actualizaciones en vivo (tablas que se refrescan, quién más está en una página, notificaciones) viajan solo por WebSockets, así que un balanceador o una red que los bloquee deja la app funcionando sin actualizaciones en vivo.
- Volúmenes compartidos para copias de seguridad y archivos. La carpeta de
copias de seguridad y la carpeta con los archivos de cada espacio de trabajo (subidas, logos,
archivos que escriben los scripts) tienen que estar en un almacenamiento que monten todas las
copias (en Kubernetes, un volumen
ReadWriteMany); si no, cada copia solo ve las copias de seguridad y los archivos que escribió ella misma. - Una sonda de arranque. Las copias que arrancan a la vez se turnan para preparar las bases de datos, y con muchos espacios de trabajo que migrar eso lleva un rato. Da a los contenedores una startup probe en lugar de una liveness probe corta.
- Los límites de peticiones son por copia. Tres copias permiten tres veces más peticiones por usuario que una.
- Detrás de PgBouncer en modo transacción, apunta
ConnectionStrings__Clusterdirectamente a PostgreSQL: las copias se comunican por una conexión de PostgreSQL que tiene que permanecer abierta.
Además de los contenedores, una instancia necesita PostgreSQL 16 y un proxy que gestione TLS. Se
ejecuta en cualquier sitio donde se ejecuten contenedores: un único servidor, una cuenta de nube o
un clúster de Kubernetes. Puede alojarla el partner, puede alojarla Archestack o puede ejecutarse
en la propia infraestructura del cliente. Para Kubernetes hay un chart de Helm, y una instancia
también puede vivir bajo una ruta de un nombre de host que pertenece a otra aplicación, como
apps.example.com/archestack/.
Una instancia nueva no tiene usuarios. La primera persona que la abre crea el primer administrador, así que configúrala antes de que se pueda alcanzar desde internet.
Capacidad y dimensionamiento recoge las cifras medidas: a cuántas personas y espacios de trabajo atiende una instancia, y los servidores que necesita para ello. Alojamiento en AKS instala una instancia en Azure Kubernetes Service y la mantiene por sí sola en la release más reciente; Alojamiento con Docker hace lo mismo en un único servidor.
Llevar tu aplicación a cada cliente
Cuando cada cliente tiene su propio espacio de trabajo, cada nueva versión de la aplicación tiene que viajar, y lo hace en un paquete:
- Pon en un paquete las tablas, business entities, páginas, business events, script modules, plantillas PDF, scheduled events, test suites y app layouts de tu aplicación, y expórtalo como ZIP.
- Impórtalo en el espacio de trabajo del cliente. La importación muestra primero un plan y después aplica los cambios de tablas en la base de datos Runtime del espacio de trabajo.
- Ejecuta allí las test suites del paquete. Las pruebas se ejecutan en una base de datos sandbox aparte y nunca tocan los datos del cliente.
- Publica una release. Ese es el momento en que las nuevas páginas llegan a los usuarios del cliente. Un espacio de trabajo que nunca ha publicado una release muestra sus páginas en cuanto termina la importación.
Algunas cosas se configuran en cada espacio de trabajo en lugar de entregarse: los endpoints y claves de la Data API, las traducciones, los usuarios, los roles, los business units, el branding, las cuentas de correo y las conexiones con otros sistemas. Todo lo que está marcado como público llega como privado, así que instalar un paquete nunca puede, por sí solo, poner en internet los datos de un cliente.
En una misma instancia, un módulo publicado como público en el Module Store es visible para todos sus espacios de trabajo, y cualquiera de ellos puede instalarlo, lo que ahorra la exportación y la importación. Un listado privado solo es visible para el espacio de trabajo que lo publicó. Entre instancias, los paquetes viajan como archivos ZIP.
Cuando la aplicación vive en un repositorio git, Estrategia de despliegue describe cómo un pipeline la prueba y la despliega en cada entorno sin tiempo de inactividad.
A tener en cuenta
- Una actualización de la plataforma llega a la vez a todos los espacios de trabajo de la instancia. Un cliente que tenga que quedarse en una versión necesita una instancia propia.
- Un espacio de trabajo nuevo empieza vacío. Instala tus paquetes en él e invita a su gente; las membresías no se trasladan desde otros espacios de trabajo.
Hacia dónde va esto a continuación
Packages explica cómo construir y exportar el paquete que entregas a cada espacio de trabajo. La guía de la Data API muestra cómo un servicio se conecta a un espacio de trabajo con una clave de API, y Database Backups trata las copias de seguridad por espacio de trabajo.