SaaS Architecture Pregunta de Newbie

Question

He desarrollado una serie de aplicaciones departamentales de cliente-servidor, y ahora estoy listo para comenzar a trabajar en el traslado de una de estas aplicaciones a un modelo SaaS. He hecho algunos desarrollos web básicos, pero soy un novato en lo que respecta a las arquitecturas SaaS.

Una de las primeras preguntas que me viene a la mente cuando trato de diseñar la arquitectura es la cuestión del alquiler individual o múltiple. Los pros y los contras de cada uno varían significativamente según el tipo de aplicación y la escala requeridas, por lo que me gustaría describir mi aplicación y las necesidades de escala a continuación, y espero que otros puedan comentar cómo debo comenzar con la arquitectura.

La aplicación cliente-servidor actualmente consiste en una base de datos Firebird y una aplicación de Windows. La base de datos contiene aproximadamente 20 tablas que contienen algunos miles de registros en 4 tablas principales, y unos cientos de registros en varias tablas de búsqueda y relacionadas. Aunque la cantidad de registros es pequeña, el tamaño puede ser grande, ya que la base de datos puede contener grandes BLOB. Cada cliente establece su propia base de datos y tiene un puñado de usuarios dentro de la organización conectada a ella. Cuando actualizo el esquema db, se lanza una nueva aplicación de Windows, que verifica el esquema db y luego aplica las actualizaciones según sea necesario.

Para la aplicación SaaS, estoy diseñando para 100 (no 1000 o millones) de nuevos clientes por año. Lo primero que pensé fue ir con un modelo multi tenancy para facilitar las actualizaciones (cerrar las actualizaciones en una base de datos y luego iniciarlas). Por otro lado, un único modelo de arrendamiento proporcionaría un medio para transferir actualizaciones a un grupo de clientes a la vez, y extender el riesgo de corrupción de datos, es decir, si algo va mal con una base de datos, tendrá un impacto en un cliente en lugar de todos los clientes Con esta idea, estaba pensando en tener una interfaz web única que se conectaría a una única base de datos de clientes al iniciar sesión. Por lo tanto, cuando un nuevo cliente crea una cuenta, se crearía una nueva base de datos (cada cliente tendría su propia base de datos con múltiples usuarios según fuera necesario para el cliente).

En este modelo, una actualización db requeriría un proceso para pasar cada db para aplicar cambios de esquema o un desencadenante al iniciar sesión para iniciar una actualización de esquema similar al modelo de cliente-servidor actualmente en uso.

¿Alguien me puede indicar información para aplicaciones similares que se han transferido del servidor cliente al SaaS? ¿O proporcionar algún consejo para considerar? Básicamente estoy buscando ejemplos de arquitectura para tomar una aplicación departamental y hacerla disponible como un sitio web de autoservicio para múltiples clientes. Gracias por cualquier sugerencia, recursos, etc.

Answer 1

Buenas preguntas.

Una cosa que le viene a la mente es que si tiene múltiples bases de datos que distribuye de forma escalonada para reducir la probabilidad de romper a todos sus clientes, tendrá que abordar el problema de qué hacer si el DB cambios de estructura. Deberá ser muy riguroso con respecto a mantener la compatibilidad con versiones anteriores, o bien implementar versiones separadas de su base de códigos y de alguna manera administrar qué inquilinos están asociados con qué bases de datos.

También proporcionamos nuestra aplicación utilizando un modelo SaaS.

Fue, inicialmente, una aplicación de Windows que funcionaba de manera similar a su propuesta de base de datos múltiple. Al iniciar sesión, la aplicación win se autenticaba frente a una única base de datos de "licenciatario" que luego respondía con información de conexión para una base de datos específica para ese licenciatario. Lo bueno de esto fue que proporcionó 1) separación física de los datos del licenciatario, que a nuestros clientes les gustó y 2) nos permitió ubicar físicamente la base de datos en un servidor geográficamente más cercano a los usuarios, lo que mejora el rendimiento y evita algunos obstáculos legales y cuestiones reglamentarias con respecto a proporcionar datos a través de los límites del país.

Por supuesto, ya que la aplicación era una aplicación de cliente grueso, podíamos hacer cambios en la base de datos y enviarlos a un licenciatario a la vez. Cuando estuvimos listos para actualizar, pudimos lanzar un cliente grueso actualizado junto con la nueva base de datos, asegurando así que la base de código coincidiera con la base de datos. Mientras la base de datos de autenticación de "licenciatario común" se mantuviera constante, esto funcionó bastante bien.

Por otro lado, sin embargo, esta solución trajo consigo todos los problemas de mantenimiento y gestión de un enfoque de cliente grueso que finalmente nos llevan al enfoque cliente-navegador basado en el navegador.

En nuestro nuevo modelo, todo está en una única base de datos. Cuando tenemos actualizaciones, sacamos el código y el db al mismo tiempo. Esto resuelve el problema de mantener la base del código coherente con la estructura de la base de datos. Sin embargo, ahora nos enfrentamos con los problemas mencionados en los puntos 1 y 2, que aún tenemos que resolver.

Espero que esto proporcione algo de reflexión para usted.

Yo también estoy interesado en esta pregunta.

Gracias por el mensaje.

-S