Drupal vs Laravel: Por qué Drupal sigue siendo una opción Enterprise para construir un SaaS

Durante años se ha instalado una idea en el desarrollo web: si un proyecto nuevo es un SaaS, debe construirse sobre un framework moderno como Laravel, mientras que Drupal debería reservarse para sitios corporativos, portales o proyectos de contenido.

Esa conclusión es demasiado simplista.

Laravel es una excelente plataforma de desarrollo y existen muchos casos en los que será la elección natural. Pero utilizar Laravel no convierte automáticamente una arquitectura en moderna, escalable o Enterprise. De la misma forma, utilizar Drupal no convierte una aplicación en un sistema legacy.

La pregunta más interesante no es simplemente “¿Drupal o Laravel?”, sino:

¿Qué necesita realmente un SaaS y cuánto de esa plataforma queremos construir, integrar y mantener nosotros mismos?

Desde esa perspectiva, Drupal resulta mucho más interesante de lo que normalmente se reconoce. No solamente como CMS, sino como una plataforma de aplicaciones que combina framework, sistema de entidades, configuración, permisos, caché, eventos, plugins, APIs y herramientas de administración dentro de una misma arquitectura.

Este artículo analiza Drupal y Laravel desde esa perspectiva, especialmente pensando en aplicaciones SaaS, arquitecturas multisite y escenarios Enterprise.

Drupal no es simplemente un CMS

Probablemente este sea el primer concepto que debemos aclarar.

Drupal nació y se popularizó como CMS, pero reducir Drupal actual a un CMS es equivalente a reducir Symfony a un sistema de formularios porque incorpora un componente de formularios.

Drupal utiliza numerosos componentes de Symfony y proporciona una arquitectura extensible basada, entre otros elementos, en:

• Entity API
• Servicios y Dependency Injection
• Event Subscribers
• Plugins
• Form API
• Routing
• Configuration API
• Cache API
• Queue API
• Access API
• Render API
• REST y JSON:API
• Sistema de permisos y roles
• Sistema de actualización
• Logging
• Herramientas de administración

Por eso, una aplicación Drupal puede tener muy poco que ver con un sitio web tradicional. Puede ser una aplicación de negocio con entidades propias, servicios, procesos asíncronos, integraciones externas, workflows, reglas de acceso y operaciones transaccionales.

En otras palabras:

Drupal puede utilizarse como plataforma de aplicación, no solamente como CMS.

La comparación correcta no es CMS vs. Framework

Una comparación simplista sería:

Drupal = CMS

Laravel = Framework

Y a partir de ahí concluir que Laravel es necesariamente más apropiado para construir software empresarial.

El problema es que la comparación está mal planteada.

Drupal incorpora muchas capacidades que una aplicación construida sobre un framework debe decidir, integrar y mantener como parte de su arquitectura.

Por ejemplo, una aplicación empresarial puede necesitar:

• Usuarios
• Roles
• Permisos granulares
• Entidades de negocio
• Campos configurables
• Formularios
• Validación
• Configuración
• Caché
• Auditoría y logging
• Colas
• API
• Administración
• Internacionalización
• Workflows
• Actualizaciones
• Mecanismos de seguridad
• Integración con servicios externos

Laravel proporciona una excelente base para construir muchas de estas capacidades y su ecosistema ofrece herramientas maduras para resolverlas. La documentación actual de Laravel incluye, entre otras áreas, autenticación, autorización, eventos, cache, queues, rate limiting, almacenamiento, notificaciones, testing y acceso a bases de datos.

Por lo tanto, no sería correcto afirmar que Laravel requiere construir todo desde cero. Su principal fortaleza es precisamente la libertad de construir una plataforma utilizando componentes del framework y de su ecosistema.

La diferencia está en el punto de partida:

• Drupal: proporciona una plataforma de aplicación integrada y extensible.
• Laravel: proporciona un framework muy flexible sobre el cual el equipo puede ensamblar la plataforma que necesita.

Ambos enfoques son válidos. La diferencia está en cuánto queremos recibir integrado y cuánto queremos decidir y ensamblar nosotros mismos.

Un SaaS no es sinónimo de microservicios

Otro concepto que conviene separar es SaaS de arquitectura distribuida.

Un SaaS es, fundamentalmente, software que se entrega como servicio a múltiples clientes. Eso no implica automáticamente que tenga que utilizar:

• Microservicios
• Kubernetes
• Event-driven architecture distribuida
• Decenas de APIs independientes
• React o cualquier otro framework frontend
• Una base de datos independiente por servicio

Todas esas tecnologías pueden ser apropiadas en determinados escenarios, pero ninguna de ellas define por sí misma un SaaS.

Un SaaS puede comenzar perfectamente como un monolito modular y continuar siendo una arquitectura Enterprise durante muchos años.

Para muchos productos empresariales, un monolito modular tiene además una ventaja importante: reduce la complejidad distribuida y permite mantener las reglas de negocio dentro de una misma aplicación transaccional.

La arquitectura debe responder a las necesidades reales del producto, no a las tendencias del momento.

Multisite y Multitenancy no son lo mismo

Aquí es necesario hacer una distinción técnica importante.

Es frecuente utilizar las palabras multisite y multitenancy como si fueran sinónimos. No lo son.

¿Qué es multisite?

Drupal incorpora soporte nativo para multisite. Esto permite que diferentes sitios compartan una misma base de código mientras mantienen sus propias bases de datos, configuración y archivos.

Una arquitectura multisite puede conceptualizarse así:

                    Código Drupal compartido
                              |
             +----------------+----------------+
             |                |                |
          Sitio A           Sitio B          Sitio C
             |                |                |
          DB A             DB B             DB C
       Config A          Config B          Config C
       Files A           Files B           Files C

Esta capacidad puede ser especialmente interesante para una plataforma SaaS que administra múltiples instalaciones a partir de una base de código común.

¿Qué es multitenancy?

Multitenancy describe una arquitectura donde una aplicación sirve a múltiples clientes o tenants, manteniendo algún nivel de aislamiento entre ellos.

Ese aislamiento puede implementarse de distintas maneras:

• Una base de datos por tenant
• Un esquema por tenant
• Tablas compartidas con un identificador de tenant
• Una combinación de estas estrategias

Por lo tanto:

Drupal tiene multisite nativo. Multitenancy, en cambio, es una decisión arquitectónica que debe diseñarse según el modelo de aislamiento requerido por el SaaS.

Esta distinción es importante porque evita una afirmación incorrecta muy común: Drupal no debería presentarse simplemente como “un framework con multitenancy en el core”.

Lo correcto es decir que Drupal proporciona una infraestructura multisite madura que puede utilizarse como parte de una arquitectura SaaS con aislamiento por tenant.

El desafío real del multisite: operación, aislamiento y releases

Las ventajas del multisite no significan que sea una solución automática para cualquier SaaS.

El verdadero desafío no está simplemente en compartir el código, sino en gestionar correctamente el ciclo de vida de ese código cuando existen múltiples sitios con diferentes necesidades operativas.

Una arquitectura multisite puede compartir una misma base de código y, al mismo tiempo, mantener separados los datos, la configuración y los archivos de cada sitio:

                    Código compartido
                           |
             +-------------+-------------+
             |             |             |
          Sitio A       Sitio B       Sitio C
             |             |             |
           DB A          DB B          DB C
        Config A      Config B      Config C
        Files A       Files B       Files C

Esta separación proporciona un nivel de aislamiento importante, pero no significa que todos los aspectos de la plataforma estén completamente desacoplados.

Código compartido no significa necesariamente un único release para todos

Una de las ideas que conviene evitar es que utilizar Drupal multisite implica necesariamente que todos los sitios deban actualizarse exactamente al mismo tiempo.

La estrategia depende de cómo se haya organizado la plataforma.

En un entorno sencillo puede existir una única plataforma compartida:

                    Repositorio
                         |
                       Build
                         |
                      Release
                         |
          +--------------+--------------+
          |              |              |
       Tenant A       Tenant B       Tenant C

Pero una plataforma más grande puede organizarse en diferentes grupos de sitios o plataformas:

                    Repositorio
                         |
                    Build / CI
                         |
                      Release
                         |
              +----------+----------+
              |                     |
        Plataforma A          Plataforma B
              |                     |
        Tenants 1-50          Tenants 51-100

Incluso es posible utilizar despliegues progresivos, donde una nueva versión se prueba inicialmente en un subconjunto de sitios antes de extenderla al resto.

Por lo tanto, multisite no determina por sí mismo la estrategia de despliegue. Esa estrategia es una decisión arquitectónica y operacional.

El verdadero desafío: el ciclo de vida del código

Cuando varios sitios comparten código, una modificación de ese código puede afectar potencialmente a múltiples instalaciones.

Por eso, una plataforma multisite de cierta escala debería considerar como parte de su arquitectura:

• Control de versiones.
• Composer y versiones bloqueadas de dependencias.
• Builds reproducibles.
• Automatización mediante CI/CD.
• Pruebas automatizadas.
• Pruebas específicas para los módulos compartidos.
• Estrategias de despliegue progresivo cuando sea necesario.
• Gestión de actualizaciones de base de datos.
• Planificación de rollback.
• Monitoreo por sitio o tenant.

Drupal recomienda utilizar Composer y el archivo composer.lock como parte del proceso de despliegue, de manera que el entorno de producción utilice exactamente las versiones de dependencias que fueron probadas. Esto permite tratar el código de la aplicación como un artefacto reproducible y no simplemente como un conjunto de archivos modificados directamente en producción.

Código, datos y runtime son dimensiones diferentes

También es importante distinguir tres conceptos que a menudo se mezclan cuando se habla de multisite:

                 Plataforma SaaS
                       |
          +------------+------------+
          |            |            |
        Código       Datos       Runtime
          |            |            |
       Compartido   Aislados    Compartido
                                o separado

Dos sitios pueden compartir el mismo código y, sin embargo, utilizar bases de datos completamente independientes.

También pueden ejecutarse sobre runtimes o grupos de infraestructura diferentes, dependiendo de los requisitos de disponibilidad, rendimiento, aislamiento o despliegue.

Esto permite diseñar arquitecturas donde el nivel de compartición se adapte a las necesidades reales del SaaS.

El aislamiento también es una decisión arquitectónica

En un SaaS Enterprise, compartir código no significa que los tenants deban compartir necesariamente todos los recursos.

Dependiendo del nivel de aislamiento requerido, pueden existir diferentes estrategias:

• Una base de datos independiente por tenant.
• Archivos independientes por tenant.
• Configuración independiente por sitio.
• Runtimes independientes.
• Plataformas independientes que comparten el mismo repositorio.
• Una combinación de estas estrategias.

La elección dependerá de factores como seguridad, requisitos regulatorios, volumen de datos, disponibilidad, costos de infraestructura y necesidades de personalización.

Por eso, una arquitectura multisite no debería evaluarse únicamente preguntando:

“¿Podemos compartir el código?”

La pregunta correcta es:

“¿Qué queremos compartir, qué necesitamos aislar y cómo vamos a gestionar el ciclo de vida de cada componente?”

El costo operativo crece con la cantidad de tenants

El beneficio de compartir una base de código puede ser considerable cuando existen muchos sitios. Se evita duplicar código y se facilita la incorporación de nuevas funcionalidades a una plataforma común.

Pero a medida que aumenta el número de tenants también aumenta la importancia de la automatización.

Con pocos sitios puede ser suficiente una operación relativamente manual:

Desarrollador
     |
   Drush
     |
   Sitio A
   Sitio B
   Sitio C

Con decenas o cientos de sitios, ese enfoque deja rápidamente de ser adecuado:

                    Git
                     |
                    CI
                     |
                   Build
                     |
                 Automated
                 deployment
                     |
          +----------+----------+
          |          |          |
       Tenant A   Tenant B   Tenant C
          |          |          |
       Monitor    Monitor    Monitor

En ese escenario, la automatización del despliegue, las actualizaciones, las migraciones, los backups, el monitoreo y la recuperación ante errores pasan a formar parte de la propia arquitectura del producto.

Multisite no elimina la complejidad: la desplaza

Esta es probablemente la forma más precisa de entender el modelo.

Drupal multisite puede reducir una clase de complejidad: la duplicación de código y de infraestructura de aplicación.

Pero introduce o aumenta la importancia de otras áreas:

• Gestión centralizada de versiones.
• Compatibilidad entre sitios.
• Actualizaciones coordinadas cuando corresponda.
• Automatización de despliegues.
• Aislamiento de datos y archivos.
• Monitoreo individual por tenant.
• Gestión de excepciones.
• Recuperación ante errores.

Esto no es una debilidad exclusiva de Drupal. Es una consecuencia natural de cualquier plataforma que intenta operar múltiples clientes sobre una base tecnológica compartida.

La diferencia está en cómo se diseña y automatiza esa operación.

La conclusión importante

Drupal multisite no debería considerarse una solución mágica para construir un SaaS.

Tampoco debería descartarse simplemente porque varios sitios compartan código.

Es una primitiva arquitectónica que puede resultar muy útil cuando el modelo de negocio y los requisitos de aislamiento son compatibles con ella.

Su éxito dependerá de combinar correctamente:

Multisite
    +
Aislamiento de tenants
    +
Versionado
    +
Composer
    +
CI/CD
    +
Automatización
    +
Monitoreo
    +
Backups
    +
Estrategia de releases

En otras palabras:

El valor de Drupal multisite no está simplemente en compartir código, sino en poder construir una plataforma común mientras se mantiene el nivel de aislamiento y control operativo que el negocio necesita.

¿Y Laravel?

Laravel es una excelente alternativa y sería un error presentar lo contrario.

Laravel proporciona una base moderna para construir aplicaciones PHP y dispone de herramientas maduras para:

• Routing
• Dependency Injection
• ORM mediante Eloquent
• Migrations
• Queues y Jobs
• Eventos
• Cache
• Autenticación y autorización
• Testing
• Integración con servicios externos
• APIs
• Notificaciones
• Rate limiting
• Task scheduling

Además, existe un ecosistema amplio para resolver necesidades específicas de administración, permisos y tenancy.

Por lo tanto, no sería correcto afirmar que Laravel requiere construir todo desde cero. Su principal fortaleza es precisamente la libertad de construir una plataforma utilizando componentes del framework y de su ecosistema.

La diferencia está en el enfoque:

• Drupal: muchas capacidades forman parte de una plataforma integrada.
• Laravel: el framework proporciona una base flexible y el equipo decide qué componentes incorporar para construir su plataforma.

Ambos enfoques pueden producir excelentes aplicaciones Enterprise.

Drupal Entity API no es simplemente un ORM

Otra comparación frecuente es:

Drupal Entity API = Laravel Eloquent

Esa equivalencia es demasiado simplista.

Eloquent es un ORM orientado al trabajo con modelos y persistencia de datos.

La Entity API de Drupal es una abstracción más amplia. Permite definir tipos de entidades, propiedades, campos, bundles, relaciones, almacenamiento, acceso y metadatos asociados a las entidades.

Una entidad Drupal puede representar mucho más que una simple fila de una tabla.

Por ejemplo, una aplicación empresarial puede definir:

Property
Contract
Payment
Voucher
Settlement
Application
Invoice
Customer
Transaction

Cada una de estas entidades puede disponer de:

• Campos
• Relaciones
• Permisos
• Formularios
• Rutas
• Views
• Representaciones administrativas
• Serialización
• Cacheability metadata
• Integración con otros sistemas de Drupal

Esa integración es precisamente uno de los puntos fuertes de Drupal como plataforma de aplicaciones.

Configuración como parte de la arquitectura

Una de las diferencias interesantes de Drupal es el tratamiento explícito de la configuración.

Drupal distingue entre:

• Código
• Configuración
• Contenido y datos operacionales

La configuración activa se almacena en la base de datos, pero Drupal permite exportarla e importarla como archivos YAML.

Esto permite que la configuración forme parte del proceso de desarrollo y despliegue:

Desarrollo
    |
    | export
    v
config/sync/*.yml
    |
    | Git
    v
Repositorio
    |
    | deploy
    v
Producción
    |
    | import
    v
Configuración activa

Esto permite versionar configuraciones como:

• Tipos de contenido
• Campos
• Vistas
• Roles
• Permisos
• Configuración de módulos
• Workflows
• Formatos
• Configuración de determinados componentes del sistema

Es importante, eso sí, no confundir esto con un sistema automático de rollback.

Drupal no guarda mágicamente un historial completo de cada configuración que permita volver atrás sin más. La estrategia habitual consiste en combinar Configuration Management con control de versiones, normalmente Git, y con una estrategia de despliegue y respaldo adecuada.

Caché: una de las fortalezas menos reconocidas de Drupal

Cuando se habla de rendimiento en Drupal, muchas veces se piensa únicamente en “activar caché”.

El sistema es bastante más sofisticado.

Drupal trabaja con diferentes dimensiones de cacheabilidad, entre ellas:

• Cache keys
• Cache contexts
• Cache tags
• Cache max-age

Los cache contexts permiten indicar que una representación puede variar según determinados factores, como usuario, permisos, idioma, URL u otros contextos.

Los cache tags permiten expresar dependencias con datos concretos.

Por ejemplo, un resultado puede depender de:

node:123
user:45
config:system.site

Si una de esas dependencias cambia, Drupal puede invalidar los elementos de caché asociados.

Este modelo resulta especialmente interesante para aplicaciones empresariales donde la misma información puede aparecer en múltiples lugares y representaciones.

Y no se trata solamente de caché de páginas completas. Drupal puede gestionar la cacheabilidad a nivel de elementos renderizados y hacer que la información de cacheabilidad se propague por el árbol de renderizado.

Esto permite diseñar aplicaciones con estrategias de caché precisas sin tener que inventar desde cero un mecanismo de invalidación para cada tipo de dato.

Drupal y la complejidad de los permisos

En un SaaS empresarial, autenticarse no es suficiente.

La aplicación normalmente necesita responder preguntas como:

• ¿Qué puede hacer este usuario?
• ¿Qué puede modificar?
• ¿Qué información puede visualizar?
• ¿Puede acceder a esta entidad?
• ¿Puede editarla?
• ¿Puede eliminarla?
• ¿Puede ejecutar esta operación?

Drupal dispone de un sistema de roles y permisos integrado y permite implementar controles de acceso específicos para entidades y operaciones.

Esto es particularmente relevante cuando el SaaS crece y aparecen distintos perfiles:

Administrador
Administrador del tenant
Supervisor
Operador
Contador
Propietario
Usuario
Auditor
API Client

Laravel también proporciona mecanismos de autenticación y autorización, incluyendo Gates y Policies. La diferencia es que Drupal integra estas capacidades de manera muy estrecha con su sistema de entidades, administración y configuración.

En un proyecto Enterprise, esa integración puede reducir la cantidad de infraestructura que el equipo debe diseñar y mantener.

Eventos, servicios y plugins: el Drupal moderno

Una aplicación Drupal moderna no debería basarse en una acumulación de hooks procedurales sin estructura.

Drupal proporciona mecanismos modernos para separar responsabilidades.

Un flujo de negocio podría tener una arquitectura como:

HTTP Request
     |
     v
Controller
     |
     v
Application Service
     |
     +------------------+
     |                  |
     v                  v
Entity             External API
     |
     v
Event
     |
     v
Queue
     |
     v
Background Worker

Esto permite desarrollar módulos con responsabilidades bien separadas y aplicar principios habituales de arquitectura orientada a objetos.

El objetivo no es escribir Drupal “a la manera antigua”. El objetivo es aprovechar Drupal como una plataforma moderna basada en servicios, inyección de dependencias, eventos, plugins y APIs.

El verdadero costo de construir un SaaS

Una comparación entre Drupal y Laravel no debería limitarse al tiempo necesario para construir la primera funcionalidad.

La pregunta importante es cuánto cuesta construir, operar y mantener la plataforma durante cinco o diez años.

Supongamos que comenzamos con Laravel.

Tenemos un excelente framework y un ecosistema maduro. A partir de ahí, el equipo puede seleccionar los componentes necesarios:

Framework
    |
    +-- Usuarios
    +-- Roles
    +-- Permisos
    +-- Administración
    +-- Entidades
    +-- Formularios
    +-- Configuración
    +-- Auditoría
    +-- Cache
    +-- Workflows
    +-- API
    +-- Media
    +-- Search
    +-- Reporting
    +-- Integraciones
    +-- Jobs
    +-- Queues
    +-- Tenant management

Laravel tiene herramientas y paquetes para resolver muchas de estas necesidades. Esa es una fortaleza de su ecosistema.

Pero la arquitectura final dependerá de las decisiones del equipo: qué componentes utilizar, cuáles mantener, cómo integrarlos, cómo actualizarlos y cómo garantizar que funcionen correctamente como conjunto.

En Drupal, una parte importante de esta plataforma ya forma parte del sistema.

Por eso, la comparación correcta no es simplemente:

Drupal vs Laravel

Sino:

Plataforma Drupal

        vs.

Laravel + arquitectura + componentes
+ administración + infraestructura de aplicación

El resultado puede ser muy diferente dependiendo del problema.

Costo de propiedad: no todo es velocidad inicial

El costo de una plataforma no se limita al desarrollo inicial.

En un SaaS empresarial también hay que considerar:

• Actualizaciones de seguridad
• Actualizaciones de dependencias
• Compatibilidad entre componentes
• Pruebas de regresión
• Monitoreo
• Backups
• Recuperación ante fallos
• Despliegues
• Documentación
• Onboarding de nuevos desarrolladores
• Mantenimiento de integraciones
• Evolución del modelo de datos
• Escalabilidad

Por eso, una decisión tecnológica debería evaluarse como una decisión de costo total de propiedad (TCO), no únicamente como una comparación de productividad durante los primeros meses.

Drupal puede reducir parte de ese costo al proporcionar muchas capacidades integradas. Laravel puede reducirlo en otros escenarios gracias a su simplicidad, flexibilidad y ecosistema.

No existe una respuesta universal.

¿Significa esto que Drupal siempre es mejor para un SaaS?

No.

Y es importante decirlo claramente.

Laravel puede ser una excelente elección cuando:

• La aplicación es altamente especializada.
• El contenido y la administración no son relevantes.
• Se necesita controlar completamente la arquitectura.
• El equipo tiene experiencia profunda en Laravel.
• La aplicación está orientada principalmente a APIs.
• Se está construyendo un servicio pequeño y altamente especializado.
• Se prefiere ensamblar una plataforma a partir de componentes especializados.
• Drupal aportaría capacidades que el proyecto simplemente no necesita.

En esos escenarios, introducir Drupal podría agregar complejidad innecesaria.

La tecnología correcta es la que resuelve el problema con la menor complejidad razonable.

¿Cuándo tiene sentido Drupal para un SaaS?

Drupal se vuelve especialmente interesante cuando el SaaS combina lógica de negocio con una importante necesidad de gestión de información, usuarios, permisos, configuración y administración.

Algunos ejemplos pueden ser:

• Plataformas de administración
• CRM verticales
• Plataformas inmobiliarias
• Portales empresariales
• Plataformas de membresía
• Sistemas de gestión documental
• Plataformas B2B
• Marketplaces
• Plataformas educativas
• Sistemas de workflow
• Aplicaciones con múltiples roles y permisos
• Productos que requieren múltiples sitios o tenants

En estos casos, Drupal puede actuar como una plataforma de aplicación completa.

Enterprise no significa utilizar una tecnología determinada

La palabra Enterprise también suele utilizarse de manera incorrecta.

Una arquitectura no se vuelve Enterprise porque utilice:

• Microservicios
• Kubernetes
• Contenedores
• React
• Laravel
• GraphQL
• Cloud computing

Todas esas tecnologías pueden formar parte de una arquitectura Enterprise. Pero ninguna de ellas la define.

Una plataforma Enterprise debe ser capaz de abordar, según las necesidades del negocio:

• Seguridad
• Disponibilidad
• Escalabilidad
• Mantenibilidad
• Observabilidad
• Auditoría
• Control de acceso
• Integridad de datos
• Actualizaciones
• Automatización
• Despliegues reproducibles
• Respaldo y recuperación
• Gobernanza

Drupal proporciona mecanismos para una parte importante de estas necesidades. El resto corresponde a la arquitectura y operación que construya el equipo.

El monolito no es el enemigo

Existe otra idea que merece ser cuestionada: que una aplicación Enterprise debe necesariamente ser distribuida.

No es así.

Un monolito mal diseñado puede convertirse en un problema. Pero un monolito modular puede ser una arquitectura extremadamente eficiente.

Drupal puede utilizarse precisamente de esta forma:

                    Aplicación Drupal
                           |
       +-------------------+-------------------+
       |                   |                   |
    Billing            Contracts            Users
       |                   |                   |
   Payments            Workflows          Permissions
       |                   |                   |
       +-------------------+-------------------+
                           |
                    Shared Services
                           |
                  Database / Cache / Queue

Cada módulo puede encapsular una parte importante del dominio.

Esto permite evolucionar la aplicación sin introducir automáticamente la complejidad de una arquitectura distribuida.

¿Y la escalabilidad?

La escalabilidad tampoco depende exclusivamente del framework.

Un sistema Drupal puede escalar mediante diferentes estrategias:

• Caché de aplicación
• Caché de renderizado
• Reverse proxy
• CDN
• Cachés externas
• Colas
• Workers
• Optimización de consultas
• Índices
• Separación de responsabilidades
• Replicación de infraestructura cuando corresponda
• Escalamiento horizontal de servidores web

Drupal no elimina la necesidad de diseñar correctamente la infraestructura.

Ningún framework lo hace.

Un sistema mal diseñado en Laravel seguirá siendo un sistema mal diseñado aunque se ejecute sobre diez servidores.

Y un sistema Drupal correctamente diseñado puede manejar cargas importantes mediante una combinación adecuada de caché, base de datos, infraestructura y arquitectura de aplicación.

Dicho esto, también es importante reconocer una realidad: Drupal tiene una mayor superficie funcional y, en determinadas operaciones, un overhead superior al de una aplicación deliberadamente minimalista construida sobre Laravel. Para aplicaciones con requisitos de rendimiento extremadamente altos, APIs muy ligeras o lógica de negocio relativamente pequeña, este factor puede ser relevante.

La decisión debe basarse en mediciones y requisitos reales, no en afirmaciones genéricas sobre qué framework es “más rápido”.

La arquitectura importa más que la etiqueta “moderno”

Existe una tendencia a asociar automáticamente determinadas tecnologías con modernidad:

Laravel = moderno
Drupal = legacy

Pero una arquitectura no puede evaluarse de esa manera.

Podemos construir una aplicación moderna con Drupal y una aplicación completamente legacy con Laravel.

Todo depende de cómo se utilicen las herramientas.

Un Drupal moderno puede utilizar:

• PHP moderno
• Componentes de Symfony
• Dependency Injection
• Servicios
• Event subscribers
• Plugins
• APIs
• Colas
• Workers
• Testing automatizado
• CI/CD
• Git
• Contenedores
• CDN
• Observabilidad
• Infraestructura cloud

Nada de esto entra en contradicción con Drupal.

Sin embargo, también es honesto reconocer que Drupal arrastra una deuda histórica. Existen APIs y patrones heredados que pueden favorecer código procedural o dificultar el aprendizaje inicial. Un desarrollador sin experiencia puede caer fácilmente en malas prácticas.

Laravel, por su parte, suele ofrecer una experiencia más directa para quienes comienzan una aplicación desde cero y quieren establecer rápidamente una arquitectura propia.

La clave está en la disciplina del equipo y en seguir las mejores prácticas, independientemente de la tecnología elegida.

Un SaaS real: la plataforma por encima del framework

Pensemos en un SaaS empresarial real.

El framework es solamente una parte de la solución.

                         SaaS
                           |
             +-------------+-------------+
             |                           |
         Plataforma                   Negocio
             |                           |
      +------+-------+             +-----+------+
      |      |       |             |            |
    Users   Auth   Config       Contracts    Payments
      |      |       |             |            |
    Roles  Access Deploy       Workflows      Billing
      |      |       |             |            |
      +------+-------+-------------+------------+
                           |
                    Infrastructure
                           |
                   DB / Cache / Queue / CDN

La decisión arquitectónica importante consiste en determinar cuánto de esa plataforma ya proporciona la tecnología elegida y cuánto deberá desarrollar y mantener el equipo.

Esa es una de las razones por las que Drupal continúa siendo una alternativa válida para determinadas aplicaciones SaaS.

Drupal vs. Laravel: una comparación más justa

La tabla no pretende declarar un ganador.

Su objetivo es mostrar que estamos frente a dos filosofías diferentes para construir aplicaciones.

Entonces, ¿Drupal es legacy?

No.

Pero tampoco basta con decir que Drupal “no es legacy” porque tenga nuevas versiones.

La verdadera respuesta está en cómo se utiliza.

Drupal puede utilizarse como un CMS tradicional, pero también puede utilizarse como una plataforma de aplicaciones empresariales.

Puede contener entidades de negocio que no tienen relación con publicaciones.

Puede implementar workflows complejos.

Puede integrarse con APIs externas.

Puede ejecutar procesos asíncronos.

Puede manejar diferentes niveles de permisos.

Puede utilizar caché granular.

Puede utilizar Configuration Management.

Puede funcionar como base de una arquitectura multisite.

Y puede convivir con una infraestructura moderna de CI/CD, contenedores, CDN, observabilidad y cloud.

Todo esto es compatible con Drupal moderno.

El peligro real no es Drupal en sí mismo, sino utilizar mecanismos antiguos o inadecuados cuando existen alternativas modernas y mejor estructuradas.

La pregunta correcta para elegir tecnología

En lugar de preguntar:

“¿Qué tecnología está de moda?”

Conviene preguntar:

• ¿Qué problema estamos resolviendo?
• ¿Qué modelo de datos necesita la aplicación?
• ¿Qué nivel de aislamiento necesitan los tenants?
• ¿Cuántos usuarios y roles existirán?
• ¿Qué nivel de administración necesita el producto?
• ¿Qué procesos deben ser asíncronos?
• ¿Qué requisitos de seguridad existen?
• ¿Qué estrategia de despliegue utilizaremos?
• ¿Qué nivel de personalización necesita cada cliente?
• ¿Cuánto código queremos mantener nosotros mismos?
• ¿Qué experiencia tiene el equipo?
• ¿Qué costo tendrá mantener la arquitectura durante cinco o diez años?

La última pregunta suele ser especialmente importante y, sin embargo, es una de las menos consideradas al comenzar un proyecto.

La arquitectura que funciona hoy no es necesariamente la que seguirá funcionando mañana

Un SaaS no se diseña solamente para el lanzamiento.

Debemos pensar también en:

v1
 |
 +-- primeros clientes
 |
 +-- crecimiento
 |
 +-- nuevos módulos
 |
 +-- nuevas integraciones
 |
 +-- nuevos roles
 |
 +-- nuevos requisitos de seguridad
 |
 +-- nuevos tenants
 |
 +-- nuevos procesos
 |
 +-- nuevas necesidades de reporting

Una arquitectura Enterprise debe permitir evolucionar el producto sin que cada nueva funcionalidad obligue a reconstruir la plataforma.

Aquí es donde una plataforma como Drupal puede resultar particularmente interesante.

Muchas de las piezas necesarias para esa evolución ya forman parte de su arquitectura.

¿Cuándo elegir Drupal y cuándo Laravel?

La decisión no debería ser ideológica.

Drupal puede ser una excelente opción cuando:

• El proyecto requiere una plataforma integrada desde el inicio.
• Las entidades, relaciones, permisos y workflows son parte importante del negocio.
• La administración es una pieza fundamental del producto.
• Existe una necesidad importante de gestión de contenido o información estructurada.
• Se necesitan múltiples sitios o instalaciones con una base de código común.
• Se quiere reducir la cantidad de infraestructura que el equipo debe construir y mantener.
• El equipo tiene experiencia en Drupal o está dispuesto a invertir en ella.

Laravel puede ser una excelente opción cuando:

• La aplicación es altamente especializada.
• Se necesita un control muy preciso sobre la arquitectura.
• El producto es principalmente una API o un backend de dominio específico.
• Se prefiere una arquitectura altamente componible.
• El equipo tiene experiencia profunda en Laravel y su ecosistema.
• Las capacidades integradas de Drupal no aportan suficiente valor para justificar su incorporación.

En ambos casos, la calidad final dependerá mucho más de la arquitectura y del equipo que de la etiqueta del framework.

Conclusión

Drupal no debería compararse con Laravel desde la premisa de que uno es un CMS “legacy” y el otro un framework moderno.

Esa comparación parte de una clasificación demasiado antigua de ambas tecnologías.

Laravel es un excelente framework y puede ser la mejor elección para determinados productos.

Drupal también puede ser una excelente plataforma para construir aplicaciones SaaS, especialmente cuando el proyecto necesita combinar:

• Lógica de negocio
• Entidades complejas
• Usuarios
• Roles y permisos
• Configuración
• Administración
• Workflows
• APIs
• Caché avanzada
• Procesamiento asíncrono
• Multisite
• Aislamiento entre clientes
• Una plataforma extensible a largo plazo

La principal ventaja de Drupal en estos escenarios no es que permita hacer cosas que Laravel no pueda hacer.

La ventaja está en que muchas de las capacidades necesarias para construir la aplicación ya forman parte de la plataforma.

Laravel ofrece una filosofía diferente: un framework muy potente y flexible sobre el cual el equipo puede ensamblar una plataforma utilizando los componentes que considere adecuados.

Por eso, la decisión no debería ser:

“¿Cuál es más moderno?”

Sino:

“¿Cuál nos permite resolver nuestro problema con la mejor combinación de arquitectura, costo, mantenibilidad, seguridad y velocidad de evolución?”

Para algunos proyectos, la respuesta será Laravel.

Para otros, será Drupal.

Y para determinados SaaS empresariales, descartar Drupal simplemente porque “es un CMS” puede significar estar descartando precisamente una de sus mayores fortalezas: que, además de ser un CMS, puede funcionar como una plataforma completa de aplicaciones.

Drupal no es automáticamente Enterprise. Ninguna tecnología lo es.

Pero Drupal dispone de las capacidades arquitectónicas necesarias para formar parte de una solución Enterprise bien diseñada.

Y esa diferencia importa mucho más que la etiqueta de “legacy” o “moderno”.

La decisión tecnológica no debería ser una cuestión de defender una bandera, sino de elegir conscientemente la plataforma que mejor resuelve el problema.