Cuando una organizacion decide implementar Liferay DXP como plataforma de experiencia digital, la primera decision critica no es que version usar ni como estructurar el proyecto. Es donde va a vivir la plataforma. Esta decision impacta directamente en los costos operativos, la velocidad de desarrollo, las opciones de personalizacion y la autonomia del equipo tecnico.
Liferay ofrece tres modelos de despliegue: On-Premise, PaaS (Liferay Cloud / DXP Cloud) y SaaS (Liferay Experience Cloud). Cada uno tiene implicaciones profundas que van mucho mas alla de "quien gestiona el servidor". Despues de haber trabajado con los tres modelos en proyectos enterprise reales, puedo decir que no existe una respuesta universal -- pero si existen criterios claros para tomar la decision correcta.
El modelo On-Premise es el enfoque clasico. Tu organizacion adquiere la licencia de Liferay DXP, despliega la plataforma en sus propios servidores (fisicos o virtualizados) y se hace cargo de toda la operacion: actualizaciones, parches, backups, escalamiento, monitoreo y seguridad.
Este modelo sigue siendo la eleccion predominante en sectores con requisitos estrictos de residencia de datos y cumplimiento normativo. Bancos, instituciones gubernamentales, empresas del sector salud y organizaciones militares frecuentemente requieren que los datos residan en infraestructura controlada directamente por la entidad. En algunos paises, la legislacion exige que los datos de ciudadanos no salgan de servidores dentro del territorio nacional.
Tambien lo eligen organizaciones que ya tienen equipos de operaciones maduros y centros de datos propios. Si una empresa tiene experiencia operando middleware Java y ya cuenta con automatizacion de infraestructura, agregar Liferay a su stack no representa un salto significativo en complejidad operacional.
Con On-Premise tienes acceso completo al sistema operativo, la JVM, la base de datos, y el servidor de aplicaciones. Puedes optimizar la configuracion de Tomcat o WildFly a nivel de threads, ajustar los parametros de la JVM segun el perfil de carga real, y configurar el pool de conexiones de base de datos con precision. Tambien tienes libertad total para desplegar cualquier tipo de extension: modulos OSGi, Client Extensions, temas personalizados, y hooks legacy si fuera necesario.
Lo que muchos equipos subestiman es el costo operativo continuo. Un entorno productivo de Liferay On-Premise necesita como minimo: un cluster de al menos dos nodos para alta disponibilidad, un balanceador de carga, una base de datos relacional con replicacion, almacenamiento compartido para documentos (NFS o similar), Elasticsearch en cluster dedicado, y un pipeline de CI/CD para gestionar despliegues. Mantener todo esto requiere expertise especifico y tiempo dedicado.
En mi experiencia, los proyectos On-Premise que funcionan bien son aquellos donde la organizacion ya tenia la infraestructura y el equipo operativo antes de adoptar Liferay. Los que sufren son aquellos donde se eligio On-Premise "por defecto" sin evaluar si realmente era necesario.
Liferay Cloud (tambien llamado DXP Cloud) es la oferta Platform-as-a-Service de Liferay. La plataforma se ejecuta en infraestructura gestionada por Liferay, tipicamente sobre AWS o Azure, pero conservas la capacidad de desplegar codigo custom: modulos OSGi, temas, Client Extensions, y toda la gama de personalizaciones que permite el modelo On-Premise.
Liferay Cloud te proporciona un conjunto de entornos preconfigurados (tipicamente desarrollo, UAT e infra-produccion, y produccion). Cada entorno incluye:
La consola de administracion de Liferay Cloud te permite ver logs en tiempo real, reiniciar servicios, gestionar variables de entorno, configurar dominios custom, y monitorear metricas de rendimiento.
El flujo de trabajo cambia significativamente respecto a On-Premise. Tu codigo vive en un repositorio Git proporcionado por Liferay Cloud. La estructura del repositorio tiene directorios especificos para cada servicio: liferay/ para configs y modulos, search/ para configuracion de Elasticsearch, webserver/ para Nginx, y database/ para scripts de base de datos.
Cuando haces push, el pipeline de CI compila tus modulos, construye la imagen del servicio Liferay, y la despliega en el entorno correspondiente. Esto elimina la necesidad de gestionar Jenkins, Nexus o cualquier otra herramienta de CI/CD por tu cuenta.
No tienes acceso SSH directo a las maquinas. Si necesitas depurar un problema a nivel de sistema operativo o JVM, dependes de los logs disponibles en la consola y del soporte de Liferay. Tampoco puedes cambiar el servidor de aplicaciones (es Tomcat, no hay alternativa) ni la base de datos (MySQL). Y el auto-scaling, aunque conveniente, tiene limites configurables que dependen de tu plan de licenciamiento.
El modelo SaaS es la oferta mas reciente y la apuesta estrategica de Liferay a largo plazo. Con Liferay Experience Cloud, la plataforma es completamente gestionada: Liferay se encarga de la infraestructura, las actualizaciones, los parches de seguridad, y el escalamiento. Tu equipo se enfoca exclusivamente en la configuracion y el contenido.
En SaaS no puedes desplegar modulos OSGi. La unica forma de extender la plataforma es a traves de Client Extensions. Esto significa que toda la logica custom debe ejecutarse fuera del proceso de Liferay: como microservicios, funciones serverless, o aplicaciones frontend independientes que se comunican con Liferay via APIs headless.
Esta restriccion no es arbitraria. Liferay necesita un modelo de extension seguro donde el codigo de un cliente no pueda afectar la estabilidad de la plataforma compartida. Los modulos OSGi, al ejecutarse dentro del mismo proceso Java, representan un riesgo que no es aceptable en un entorno multi-tenant gestionado.
SaaS es ideal para portales de contenido, intranets corporativas, y sitios publicos donde la mayor parte del valor viene de las capacidades nativas de Liferay: gestion de contenido estructurado, segmentacion de audiencias, flujos de trabajo, formularios, y experiencias personalizadas. Si tu caso de uso puede resolverse con configuracion, fragmentos, y alguna Client Extension ligera, SaaS te ahorra toda la complejidad operativa.
| Criterio | On-Premise | PaaS (Cloud) | SaaS | |---|---|---|---| | Control de infraestructura | Total | Parcial (consola) | Ninguno | | Personalizacion | Sin limites | Casi sin limites | Solo Client Extensions | | Modulos OSGi | Si | Si | No | | Temas custom | Si | Si | Limitado (StyleBooks) | | Base de datos | Cualquiera soportada | MySQL gestionado | No accesible | | Velocidad de despliegue | Depende del equipo | Rapido (CI/CD integrado) | Inmediato | | Escalamiento | Manual | Auto-scaling | Transparente | | Mantenimiento | Equipo propio | Compartido con Liferay | Liferay | | Modelo de costo | Licencia + infraestructura | Suscripcion (incluye infra) | Suscripcion | | Time-to-market | Semanas/meses | Dias/semanas | Dias |
La eleccion del modelo de despliegue condiciona directamente la arquitectura de tu solucion:
On-Premise y PaaS permiten el stack completo: modulos OSGi con Service Builder para modelos de datos custom, MVC Portlets o portlets React con liferay-npm-bundler, temas con FreeMarker, hooks de eventos, y Client Extensions. Tienes acceso al Gogo Shell para depuracion de bundles y puedes desplegar herramientas custom dentro del servidor.
SaaS te restringe a Client Extensions unicamente. Esto significa que si necesitas un modelo de datos custom, lo implementas como un microservicio externo con su propia base de datos, exponiendo una API REST que Liferay consume. Si necesitas una interfaz custom, la implementas como un Custom Element Client Extension (tipicamente en React o Angular) que se comunica con tu backend via APIs.
La introduccion del modelo SaaS fue el catalizador para que Liferay acelerara el desarrollo de la arquitectura de Client Extensions. Liferay necesitaba un mecanismo de extension que fuera seguro en un entorno multi-tenant, y las Client Extensions resolvieron exactamente ese problema al mover toda la logica custom fuera del proceso del portal.
Pero el impacto va mas alla de SaaS. Liferay ha comunicado que las Client Extensions son el modelo de desarrollo recomendado incluso para On-Premise y PaaS. Los modulos OSGi siguen siendo soportados, pero la direccion estrategica es clara: eventualmente, la mayor parte del desarrollo custom deberia ser via Client Extensions.
Esto tiene sentido practico: si desarrollas tu solucion usando Client Extensions desde el principio, tienes la flexibilidad de migrar entre modelos de despliegue sin reescribir tu codigo.
El analisis de costos va mas alla del precio de la licencia:
On-Premise: Licencia de Liferay + servidores (fisicos o cloud IaaS) + base de datos + almacenamiento + equipo de operaciones + herramientas de monitoreo. En una estimacion conservadora, el costo operativo puede igualar o superar el costo de la licencia.
PaaS: Suscripcion que incluye infraestructura y soporte. Eliminas el equipo de operaciones dedicado, pero el costo por entorno es significativo. Para equipos de desarrollo grandes que necesitan multiples entornos de desarrollo paralelos, los costos pueden escalarse.
SaaS: Suscripcion tipicamente menor que PaaS, pero debes considerar el costo de infraestructura para tus microservicios y Client Extensions externas. Si tu solucion requiere logica backend significativa, tendras servidores propios de todos modos -- solo que para tu codigo, no para Liferay.
De On-Premise a PaaS: Es la migracion mas directa. Tu codigo (modulos OSGi, temas, Client Extensions) funciona sin cambios en la mayoria de los casos. Los ajustes principales son en configuracion de entorno y adaptacion al pipeline de CI/CD de Liferay Cloud.
De On-Premise a SaaS: Potencialmente compleja. Si tu solucion depende fuertemente de modulos OSGi con Service Builder, MVC Portlets, o hooks de eventos, necesitaras reescribir esas piezas como Client Extensions y microservicios externos. En proyectos grandes, esto puede equivaler a una reimplementacion parcial.
De PaaS a SaaS: Similar al caso anterior en cuanto a refactorizacion de codigo, pero con la ventaja de que la migracion de datos y configuracion es mas sencilla al permanecer dentro del ecosistema gestionado de Liferay.
Para proyectos nuevos, mi recomendacion es empezar con PaaS si el presupuesto lo permite. Te da la flexibilidad de desarrollo de On-Premise sin la carga operativa, y el pipeline de CI/CD integrado acelera significativamente los ciclos de entrega.
Para portales de contenido simples (intranets informativas, sitios publicos, bases de conocimiento), evalua SaaS seriamente. La reduccion en complejidad operativa es dramatica y las capacidades nativas de Liferay cubren la mayoria de estos casos de uso.
Para organizaciones con requisitos regulatorios estrictos o infraestructura existente, On-Premise sigue siendo una opcion valida, pero invierte en automatizacion desde el dia uno: infraestructura como codigo, CI/CD robusto, y monitoreo proactivo.
Independientemente del modelo, adopta Client Extensions como tu mecanismo principal de extension. Esto te da portabilidad entre modelos y te alinea con la direccion estrategica de la plataforma. Usa modulos OSGi solo cuando sea estrictamente necesario -- por ejemplo, para integraciones profundas con el kernel de Liferay que las Client Extensions aun no pueden resolver.
La decision sobre el modelo de despliegue no es solo tecnica. Involucra al equipo de operaciones, al area financiera, al area de seguridad, y a los sponsors del proyecto. Cuanto antes se tome, mejor -- porque cambiar de modelo despues de que el proyecto esta en produccion es ordenes de magnitud mas costoso que elegir bien desde el principio.