Saltar al contenido

Arquitectura y despliegue

Nube privada: infraestructura dedicada operada como plataforma

Una nube privada reúne servidores dedicados a una sola organización y los ofrece como recursos virtualizados que se crean, amplían y retiran de forma automatizada. Puede estar en las instalaciones de la empresa o en un centro de datos externo, siempre que nadie más comparta esa capacidad. Se elige para combinar el control de la infraestructura propia con parte de la agilidad de la nube: entornos que se levantan en minutos, plantillas repetibles y aislamiento entre aplicaciones. El precio es una plataforma que alguien debe mantener, actualizar y vigilar. Aquí explicamos cuándo compensa, qué capas intervienen y en qué casos un orquestador de contenedores aporta valor real.
Plantear un proyectoVer escenarios
Ejemplo ilustrativo de capas en una nube privadaEsquema ilustrativo

  1. 01 · Hardware dedicado

    • Servidores con capacidad de reserva
    • Almacenamiento compartido

  2. 02 · Virtualización

    • Hipervisor con API
    • Redes segmentadas por aplicación

  3. 03 · Plataforma

    • Plantillas e infraestructura como código
    • Orquestador si se justifica

  4. 04 · Aplicaciones

    • Entornos separados
    • Identidades centralizadas
    • Monitorización

  5. 05 · Continuidad

    • Copias en otra ubicación
    • Procedimiento de reconstrucción

El problema

Por qué hay que decidirlo bien

Algunas organizaciones ya tienen un centro de datos con virtualización y necesitan alojar varias aplicaciones con requisitos de aislamiento, pero cada despliegue sigue siendo artesanal: alguien crea máquinas a mano, configura la red por teléfono y documenta poco. Otras se plantean montar una nube privada por soberanía o por coste sin calcular el equipo que exige operarla. En ambos casos el riesgo es el mismo: una plataforma que nadie domina del todo, difícil de actualizar y frágil ante la salida de la persona que la conoce. La decisión debe apoyarse en motivos concretos y en una operación asumible.

Escenarios

Situaciones en las que se plantea

Ejemplos de lo que se podría diseñar. No describen proyectos realizados.

  • 01

    Varias aplicaciones con aislamiento entre ellas

    Una organización necesita alojar sistemas de distintos departamentos sin que compartan red ni credenciales. Se definen redes y proyectos separados en la plataforma de virtualización y plantillas que aplican la misma configuración base a cada aplicación nueva.

  • 02

    Entornos de prueba bajo demanda

    El equipo de desarrollo necesita levantar copias del sistema para validar cambios y destruirlas después. La infraestructura descrita como código permite crear esos entornos de forma repetible sin depender de peticiones manuales al equipo de sistemas.

  • 03

    Servicios en contenedores con muchas piezas

    Un sistema compuesto por varios servicios que escalan de forma independiente puede beneficiarse de un orquestador como Kubernetes. Antes se valora si el equipo puede operarlo, porque añade una capa que también hay que actualizar y vigilar.

  • 04

    Requisito de que la infraestructura no se comparta

    Un contrato o una política interna exige que los servidores estén dedicados a la organización. Una nube privada alojada en un centro de datos externo puede cumplir ese requisito sin que la empresa gestione el edificio ni la energía.

Decisiones técnicas

Qué hay que decidir y con qué criterio

  1. 01

    Motivación y alternativa

    Se ponen por escrito los motivos (aislamiento, soberanía, aprovechamiento de inversión existente, latencia) y se comparan con la opción de nube pública o de servidores tradicionales, incluido el coste del personal que operará la plataforma.

  2. 02

    Capa de virtualización

    Se parte de la tecnología que ya domine la organización siempre que encaje. Se revisan su ciclo de soporte, las licencias, la capacidad de automatizarla mediante API y cómo se respaldan las máquinas virtuales.

  3. 03

    Kubernetes solo cuando tenga sentido

    Un orquestador aporta valor con muchos servicios, despliegues frecuentes y necesidad de escalar componentes por separado. Para una aplicación con pocos servicios, máquinas virtuales bien automatizadas suelen ser más sencillas de operar y de diagnosticar.

  4. 04

    Aislamiento y red

    Segmentación por aplicación y por entorno, reglas de tráfico explícitas entre segmentos, gestión centralizada de identidades y separación clara entre la red de administración de la plataforma y la de las aplicaciones.

  5. 05

    Mantenimiento de la plataforma

    Calendario de actualizaciones del hipervisor, del almacenamiento y, si existe, del orquestador; ventanas acordadas; pruebas previas en un entorno equivalente y responsables nombrados para cada capa.

  6. 06

    Continuidad fuera de la propia plataforma

    Copias almacenadas en otra ubicación, capacidad de reserva para absorber la caída de un servidor físico y un procedimiento probado para reconstruir la plataforma si falla el almacenamiento compartido.

Riesgos y límites

Lo que conviene tener presente

  • La plataforma se convierte en un sistema más que mantener: sin equipo o contrato de operación, envejece y acumula vulnerabilidades.
  • La capacidad es finita: a diferencia de la nube pública, crecer exige comprar y montar hardware con antelación.
  • Adoptar un orquestador por moda añade complejidad que puede superar sus beneficios en sistemas pequeños.
  • Los cambios de licencia o de soporte del fabricante de virtualización pueden obligar a migraciones no previstas.

Preguntas frecuentes

¿Nube privada es lo mismo que tener servidores propios?

No exactamente. Los servidores pueden ser propios, pero una nube privada añade virtualización, automatización y autoservicio para crear recursos sin intervención manual. Un servidor físico con una aplicación instalada a mano es un despliegue on-premise tradicional.

¿Necesitamos Kubernetes?

Depende del sistema y del equipo. Si hay muchos servicios, despliegues frecuentes y personal capaz de operarlo, puede compensar. Si no, máquinas virtuales automatizadas suelen dar el mismo resultado con menos carga de mantenimiento.

¿Podéis desplegar en nuestra plataforma de virtualización actual?

Es lo habitual cuando ya existe y está mantenida. Se revisa antes su versión, su capacidad libre y cómo se automatiza, para confirmar que admite el despliegue previsto sin forzarla.

Sectores, capacidades y lecturas relacionadas

Sectores donde se plantea

Capacidades relacionadas

Para profundizar

Más en arquitectura y despliegue

Cuéntanos qué infraestructura tienes y qué aplicaciones quieres alojar en ella

Ninguna modalidad está disponible por defecto en todos los proyectos: se elige tras evaluar requisitos, sistemas existentes y riesgos.

Plantear un proyecto

Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.