Arquitectura y despliegue
Despliegue on-premise: software en la infraestructura de tu empresa
01 · Usuarios
- Red corporativa
- Acceso remoto por VPN
02 · Perímetro
- Proxy inverso con TLS
- Cortafuegos
03 · Aplicación
- Servicios en contenedores
- Base de datos
- Monitorización
04 · Continuidad
- Copias cifradas fuera del servidor
- Pruebas de restauración
El problema
Por qué hay que decidirlo bien
Muchas organizaciones tienen motivos legítimos para no llevar un sistema a la nube: contratos que exigen que los datos no salgan de sus instalaciones, máquinas que necesitan respuesta en milisegundos, redes aisladas o una inversión reciente en servidores. El riesgo aparece cuando se decide on-premise sin dimensionar la operación: nadie actualiza el sistema operativo, las copias no se prueban, el hardware envejece y el software queda atado a una máquina concreta. El reto es que la decisión responda a requisitos reales y que la operación quede definida y asumida.
Escenarios
Situaciones en las que se plantea
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Aplicación de gestión en el centro de datos de la empresa
La empresa ya opera servidores virtualizados y exige que los datos de clientes permanezcan en su infraestructura. El sistema se entrega como un conjunto de servicios con instrucciones de instalación, monitorización y copias integradas en sus procedimientos.
02
Sistema de planta con baja latencia
Un puesto de inspección necesita procesar imágenes junto a la línea sin depender de la conexión a internet. El procesamiento se ejecuta en un equipo local y solo los resultados agregados se envían a la aplicación central cuando hay conexión.
03
Red aislada por motivos de seguridad
El sistema debe funcionar en una red sin acceso a internet. Las actualizaciones se distribuyen mediante paquetes verificados y un procedimiento acordado, y la monitorización se resuelve con herramientas disponibles dentro de esa red.
04
Software instalado frente a solución sin conexión
No es lo mismo un servidor propio con conexión controlada que un equipo que debe funcionar desconectado durante días. En el segundo caso hay que diseñar almacenamiento local, sincronización posterior y resolución de conflictos.
Decisiones técnicas
Qué hay que decidir y con qué criterio
01
Quién opera el sistema
Se acuerda qué hace el equipo de la empresa y qué queda como soporte: parches del sistema operativo, actualizaciones de la aplicación, copias, renovación de certificados y atención a incidencias.
02
Empaquetado y actualizaciones
Contenedores, máquinas virtuales o instalación tradicional, según la infraestructura existente. Cada actualización debe poder aplicarse y revertirse con un procedimiento documentado y probado.
03
Red y seguridad perimetral
Qué puertos se exponen, cómo se accede desde fuera si hace falta, dónde termina el cifrado y cómo se segmenta el sistema respecto al resto de la red corporativa o de planta.
04
Copias y restauración
Frecuencia, ubicación fuera del servidor principal, cifrado y, sobre todo, pruebas periódicas de restauración. Una copia que nunca se ha restaurado no es un plan de recuperación.
05
Dimensionamiento y ciclo de vida del hardware
Capacidad prevista, crecimiento, vigilancia de recursos y qué ocurre cuando el equipo llega al final de su vida útil, para que el software no quede atado a una máquina concreta.
Riesgos y límites
Lo que conviene tener presente
- La operación queda sin dueño: sin actualizaciones ni vigilancia, el sistema acumula vulnerabilidades y fallos silenciosos.
- El hardware se convierte en dependencia: un fallo de disco o una avería sin repuesto puede parar el servicio si no hay redundancia.
- Las condiciones de soporte deben fijarse por contrato: tiempos de respuesta, acceso remoto permitido y qué queda fuera del alcance.
- Algunos servicios gestionados de la nube (correo transaccional, modelos de IA, colas) requieren alternativas locales o una excepción controlada.
Preguntas frecuentes
¿On-premise es más seguro que la nube?
No por sí mismo. Da más control sobre dónde están los datos, pero la seguridad depende de cómo se opere: parches, accesos, segmentación y vigilancia. Una nube bien configurada puede ser más segura que un servidor propio desatendido, y al revés.
¿Podemos empezar on-premise y pasar a la nube después?
Si se diseña pensando en ello, sí: empaquetado en contenedores, configuración externa y dependencias sustituibles facilitan el cambio. Conviene decidirlo al principio, porque adaptarlo después cuesta más.
¿Quién se encarga del mantenimiento?
Se pacta en cada proyecto. Puede asumirlo el equipo de sistemas de la empresa con nuestra documentación, o acordarse un soporte con alcance y tiempos definidos. Lo importante es que la responsabilidad quede escrita.
Sectores, capacidades y lecturas relacionadas
Sectores donde se plantea
Capacidades relacionadas
- Seguridad de aplicacionesControles de seguridad pensados desde el diseño de cada aplicación: amenazas identificadas, secretos protegidos, dependencias vigiladas y pruebas en el ciclo de desarrollo.
- Modernización legacySustituir por partes un software antiguo que sigue sosteniendo la operación, empezando por entender bien qué hace.
Más en arquitectura y despliegue
Cuéntanos qué infraestructura tienes y qué debe cumplir el sistema
Ninguna modalidad está disponible por defecto en todos los proyectos: se elige tras evaluar requisitos, sistemas existentes y riesgos.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.