Arquitectura para la aplicación SaaS de RoR

Question

He realizado una cantidad decente de trabajo RoR básico, pero realmente no he tenido que hacer frente a la ampliación y ejecución de múltiples aplicaciones.

Estoy en el proceso de crear una aplicación para un cliente que espero comercializar para otros usuarios en industrias similares, pero estoy luchando con la arquitectura de alto nivel. Parece innecesario ejecutar una instancia completamente separada de la aplicación para cada cliente, pero no sé cómo cargar diferentes configuraciones/diseños/características para los distintos usuarios. No espero que cada aplicación individual tenga un tráfico extremadamente alto, por lo que parece un desperdicio tener una única instancia/base de datos. Sin embargo, cada instancia probablemente requerirá su propio CSS así como una configuración potencialmente diferente de la funcionalidad disponible.

¿Esto es algo que se puede hacer fácilmente mediante subdominios? ¿Puedo cargar diferentes configuraciones basadas en esto? ¿Alguien tiene una idea de cómo las 37 aplicaciones de señales administran diferentes configuraciones basadas en la cuenta?

Answer 1

Negación

Asegúrese de que esté en condiciones de comercializar la aplicación que está escribiendo para otros clientes. ¿Has firmado un contrato con tu cliente? Si es así, es probable que posean los derechos del código que está escribiendo, en cuyo caso usted estará en violación de su contrato.

---

Hay un muy buen artículo en la wikipedia sobre Multitenancy, que definitivamente debe leer. Responderá a muchas de sus preguntas y le hará pensar en su estrategia. Mi sugerencia es construir su aplicación de tal manera que pueda soportar multiempresas ya que es mucho más difícil instalarla después de los hechos.

Las aplicaciones de los años 37 no permiten ninguna personalización que no sea la combinación de colores que probablemente se realiza al tener una configuración que cambia la hoja de estilo. Por ejemplo:

<%= stylesheet_link_tag(@tenant.style.name) %> 

Se podría cargar el inquilino basado en el subdominio:

before_filter :load_tenant, :if => :tenant_request? 
def tenant_request? 
    request.subdomain.present? && !request.subdomain == 'www' 
end  

def load_tenant 
    @tenant = Tenant.find_by_name(request.subdomain) 
end 

Si usted quiere ser capaz de tener funcionalidad se puede activar y desactivar la manera más fácil sería probablemente para añadir una máscara de bits (hay un gem for bit masks) que le permite consultar las repeticiones disponibles. Esto no escalaría más allá de una cierta cantidad de características, pero sería un buen comienzo. Terminarías con código de vista como:

<% if tenant.has_feature?(:messaging) %> 
    <li><%= link_to 'Messages', messages_url %></li> 
<% end %> 

Asegúrate de que la elección que hagas sea lo más simple que funcione.

Answer 2

Cuando estábamos haciendo la misma decisión para nuestra aplicación, se consideran varias cosas ...

En primer lugar, consideramos la complejidad. Cuando comienza a agregar clientes múltiples en la misma base de datos, debe considerar cómo va a segmentar sus datos. Si ha escrito la aplicación para un cliente, es probable que no haya tenido que preocuparse demasiado por esto. En muchos casos, estos problemas están arraigados en el modelo de datos básicos, lo que dará lugar a un lote de refactorización (si no es una reescritura total).

Además, nunca escapa a esta complejidad. Especialmente en una aplicación comercial, exponer los datos de un cliente a otro cliente puede ser mortal.Siempre necesitará agregar código adicional y muchas pruebas adicionales para protegerse de esto.

En segundo lugar, hemos tenido en cuenta el costo. Cuando consideramos que podíamos ejecutar varios clientes en sus propias instancias de Rails en la misma instancia de Amazon EC2 con sus propias bases de datos de Amazon RDS dentro de la misma instancia de RDS, el costo se volvió muy atractivo. Debido a que tenemos una aplicación orientada a los negocios y no tendremos más de 200 clientes pronto, probablemente estamos hablando de unos pocos miles de dólares en costos adicionales de hosting en un período de 3 a 5 años.

Cuando comparamos el costo con la complejidad, concluimos que mantener a todos en sus propias instancias valía la pena teóricos problemas de escala.

La desventaja de este enfoque es que usted tiene que asegurarse de que usted es capaz de mantenerse al día con el mantenimiento, supervisión y actualización de varias instancias. Algunos scripts y herramientas simples como Chef pueden llegar muy lejos aquí.