Varias instancias para aplicaciones-- ¿Una para cada cliente?

Question

Estoy pensando en ofrecer mi producto como un servicio entregado en línea. Actualmente se trata de un software empaquetado que los usuarios descargan en sus servidores y ejecutan en sus servidores, como fogbugz.

En mi nuevo modelo de negocio, ofreceré dos modos de negocios, uno es el tradicional software empaquetado que los usuarios instalan en sus servidores, y todo el mantenimiento y actualización. Otro es el tipo de software como servicio (SaaS), donde el alojamiento se realiza en mis servidores, y los usuarios reciben una sola URL para iniciar sesión. Por supuesto, cada cuenta de cliente tendrá una URL única, como companya.mysoft.com, companyb.mysoft.com.

La pregunta ahora es porque ya tengo una base de código existente, quiero hacer una modificación mínima de mi código para que admita dos modos de negocio. Para el modo SaaS, quiero crear varias instancias para la aplicación, una para cada cliente. Entonces, cada cliente tendrá sus propias bases de datos, sus propias aplicaciones. Todas las bases de datos y aplicaciones de los clientes se encuentran en mi servidor. Lo bueno es que no tengo que cambiar mi código en absoluto. Lo malo es que hay mucha redundancia y puede no ser escalable.

¿Qué opina de este cliente de varias instancias por cliente? ¿O debo modificar mi código para que ambos modos sean compatibles (fáciles de mantener y para actualizaciones)?

Editar: La versión de descarga es necesaria, no hay forma de evitar esto.

Editar 2: Mi aplicación es una aplicación de PHP.

Answer 1

Una instancia completa por cliente creará pesadillas de mantenimiento a medida que crezca su base de clientes. Pero puede funcionar para que comiences en el negocio de SaaS. Tenga en cuenta que el éxito probablemente signifique una nueva arquitectura de la aplicación para escalar mejor.

detalles importantes a tener en cuenta incluyen:

la segregación de datos, es muy importante, mantenimiento y actualización de miles de bases de datos individuales implica una gran cantidad de gastos generales. Una preocupación común es que los clientes se preocupen de que sus datos se mezclen con los de otras personas y de alguna manera sean menos seguros. He trabajado para tres compañías diferentes que ofrecían un modelo SaaS y la mezcla de datos nunca fue una preocupación del cliente. Al final del día tendrá todos los datos y será o no seguro, en realidad no importa cuántos dbs use. A menos que nunca puedas tener más de unas pocas docenas de clientes, recomiendo consolidar múltiples clientes en una única base de datos y admitir múltiples dbs, lo que hace que la administración de las bases de datos sea mucho más fácil. He trabajado con un sistema con varios PetaBytes de datos para más de 80.000 clientes distribuidos en un par de docenas de bases de datos, y era bastante manejable. He trabajado con un sistema con algunos TeraBytes de datos para varias docenas de clientes, cada uno con su propia base de datos, y funcionó bastante bien. Entonces, un día conseguimos un gran negocio que agregó 300 clientes a la vez y manejar las bases de datos se volvió incómodo muy rápido.

Marca, cada cliente es una marca separada, o muchos clientes compartirán una marca, o todos están felices de usar la marca de su empresa. Idealmente, puede ubicar los recursos de marca (css/images/etc.) Por URL o inicio de sesión, o probablemente ambos. Si solo necesita un puñado de marcas, puede ser razonable configurar servidores para cada marca.

Versiones, es razonable "forzar" a todos los clientes a actualizar al mismo tiempo. Le recomiendo encarecidamente que haga todo lo que esté a su alcance para mantener a todos los clientes en la misma versión, y admitir varias versiones aumentará sustancialmente sus costos de soporte. En general, es fácil girar la faceta "siempre tienes lo último y lo mejor", pero algunos clientes son realmente adversos al cambio.Los clientes que puedan necesitar quedarse atrás deberán estar en instancias separadas.

Personalización, no parece que tenga este problema, pero si actualmente está enviando compilaciones personalizadas a algunos clientes, necesitará instancias separadas para cada compilación hasta que pueda crear una compilación universal que funcione para todos.

Answer 2

Depende del número de clientes. Al principio, probablemente pueda salirse con la suya corriendo una instancia por VM, pero no es tan escalable como manejar varios clientes por instancia.

Si se convierte en una fuente básica de ingresos, definitivamente querrá pasar a ese modelo. Sin embargo, definitivamente vale la pena probar si hay una gran demanda antes de realizar el trabajo.

Answer 3

Es difícil responder a esta pregunta sin más información, pero con este tipo de problemas de marca/multi-homing, la pregunta clave es la siguiente:

Son estos sitios (por los diferentes clientes) más parecidos que diferente?

Ahora que es una pregunta subjetiva. ¿Cuánto cuestan dos sitios? ¿Puedes cuantificar eso? Realmente no.

Pero si la respuesta es "son casi iguales" o incluso "son lo mismo" (a pesar de los problemas de marca), hazte un favor y aloja una única versión del código y haz que ambos sitios apunten eso.

Puede determinar fácilmente a qué servidor se llamó y cambiar su lógica en consecuencia.

La creación de marcas es el otro problema, pero si has hecho bien tu aplicación esto debería ser una cuestión de cambiar tu CSS, posiblemente tu Javascript incluya (pe estilo jQuery) y (con suerte, el peor de los casos) cambiar tus encabezados y pies de página (usted tiene encabezados y pies de página globales ¿verdad?).

Básicamente, si los sitios son bastante similares, comparte el código y solo tienes excepciones para lo que sea diferente. Si son totalmente diferentes, haz lo opuesto. Presta atención a los escenarios más comunes.

Answer 4

DRY dice no. Es mejor agregar un sabor basado en roles a su aplicación para que pueda agregar más fácilmente a los clientes 2, 3, 4, etc.

Me gustaría pensar en qué cambios para los clientes en su aplicación y diseñar la aplicación ser conducido por datos o configuración.

Answer 5

Esta es siempre una decisión difícil, e identificó la mayor caída de la instalación de una nueva instancia en su servidor para cada cliente. No escala tan bien y es casi imposible actualizar fácilmente. Además, no es muy SaaS ya que básicamente solo instalas el software N veces.

Sin embargo, existe una alternativa. Mantenga su base de datos igual, e instale una nueva instancia de la base de datos para cada cliente. Pero cambie su interfaz, para que pueda manejar múltiples URL. De esta forma, solo tiene que tener una instancia de la aplicación ejecutándose en varias bases de datos dependiendo de la URL.

Esto también se escala muy bien, y creo que este es el modelo FogBugz? Entonces, si sus clientes quieren instalarlo, realmente no hay ningún cambio, ya que solo tendrán una URL que apunte a una base de datos. Y de su lado, tendrá múltiples URL apuntando a múltiples bases de datos, solo el software se ejecutará solo una vez que maneje todas estas solicitudes.

También es bueno tenerlo, es posible que desee considerar los dominios personalizados. En lugar de companya.mysoft.com, permite companya.com. Eso no requerirá ningún cambio real en el manejo de su URL, el componente solo tendrá que configurar un registro CNAME y apuntarlo a su servidor.

buena suerte

Answer 6

"Lo malo es que hay una gran cantidad de redundancia, y pueden no ser escalable."

¿De verdad? ¿Dónde está la redundancia?

Si ha utilizado un buen conjunto de herramientas, su instalación de SaaS puede tener una base de código utilizada por varios sitios de clientes.

Funciona así.

• En algún directorio de base (que usar directorios como /opt/theApp) que tiene el software.

• En algún directorio de trabajo (que utiliza directorios ejemplo /var/www/cust1, /var/www/cust2) tiene algunos archivos de configuración que hacen referencia al código.

Base de código único, varias instalaciones. En Django (y muchos otros marcos web), esto es relativamente fácil.

Si ha elegido mal sus herramientas, entonces un sitio == una copia completa del código y tiene un posible problema. Sin embargo, esto es para lo que son los enlaces. Usted tiene que la "copia" específica del cliente incluya enlaces suaves a la copia de referencia.

Después de realizar el esfuerzo de separar las "características específicas del cliente" de "instalación web" y "código base", encontrará que puede realizar QA correctamente y proporcionar funciones y extensiones específicas para el cliente.

Múltiples instancias es más escalable.Usted puede, sin mucha dificultad, tener sus entornos SaaS distribuidos entre múltiples procesadores concurrentes. Cada instancia específica del cliente sirve los datos del cliente, manteniendo a los clientes separados. Pueden (si aborda esto correctamente) todos comparten una base de código común, instalada en un (y solo uno) servidor.

Las instalaciones separadas por cliente (con una base de código común) son muy agradables para asegurar a los clientes que sus datos no están casualmente mezclados con los datos de su competencia.

Answer 7

Desde el ángulo DB Definitivamente iría con el modelo de una base de datos por cliente. Los beneficios de poder gestionar los datos de cada cliente de forma independiente son obligatorios. Y ese enfoque le permite escalar colocando datos de diferentes clientes en diferentes servidores a medida que crece el negocio.

También su servidor de aplicaciones/web debería ser capaz de manejar múltiples instancias de su aplicación ejecutándose para diferentes usuarios y clientes directamente de la caja. Debería ordenar una sola copia del código y múltiples segmentos de datos (suponiendo que el modelo aún se conserva después de 20 años). De nuevo, eso es escalable: suba a una granja de servidores web, y todo sigue funcionando, suponiendo que pueda ordenar sus sesiones.

Para que ganes o ganes, tu base de código se mantiene más o menos igual y obtienes escalabilidad según el entorno que estés usando. También puede configurar versiones diferentes, lanzamientos para que los clientes prueben; a menudo mantendríamos múltiples versiones del mismo sitio ejecutándose en paralelo para poder deshacer si un error fatal nos golpea en una nueva versión.

La clave para que esto funcione bien es mirar los encabezados HTTP y vincular la configuración, es decir, qué DB y qué versión de software realmente apuntan en función de eso.