OVHcloud necesita algo más que servidores contratados.

Quien consolida un entorno de hosting se encuentra a menudo con aplicaciones muy distintas. Algunas necesitan sobre todo una capacidad de cómputo constante; otras plantean requisitos particulares de almacenamiento de datos, red o capacidad de ampliación. Un mismo tamaño de servidor no se ajusta por sí solo a estas diferencias. Por eso, la planificación empieza con una asignación de aplicaciones, hipótesis de carga y dependencias. Se incluyen los contratos existentes y los cambios previstos, para que la configuración objetivo no refleje solo el estado actual, sino que tenga en cuenta también los próximos pasos previsibles.

Sobre esta base se seleccionan los recursos cloud o los sistemas dedicados adecuados, y se describe su papel dentro de la configuración global. Así, las responsabilidades y el esfuerzo propio posterior permanecen visibles. Si, por ejemplo, una aplicación necesita mantenimiento adicional o procedimientos de copia de seguridad especiales, esto forma parte de la decisión sobre la configuración. A continuación, se implementa y documenta la configuración acordada. De este modo, su equipo obtiene una asignación de recursos fundamentada y puede evaluar futuras ampliaciones según los mismos criterios, en lugar de decidir cada adquisición de forma aislada.

Una aplicación puede estar formada por servicios accesibles públicamente, bases de datos internas y accesos administrativos. Estas áreas deben conectarse entre sí de forma selectiva, sin abrir vías de comunicación innecesarias. Por eso analizamos juntos las conexiones privadas y públicas, la resolución de nombres y las reglas de acceso necesarias. Si intervienen sistemas en otras ubicaciones, estos flujos de datos también se incluyen. Las pruebas posteriores se orientan a la comunicación completa de la aplicación y a qué usuarios o sistemas deben trabajar realmente entre sí.

En el caso de las aplicaciones en contenedores, se añade el proceso de despliegue. Las nuevas versiones necesitan accesos, verificaciones y aprobaciones definidos; los cambios de plataforma deberían acordarse con los equipos implicados. Dentro del alcance acordado, configuramos estas bases y las probamos con una aplicación concreta. El traspaso incluye así no solo la configuración de la plataforma, sino también el procedimiento previsto para los cambios. El desarrollo y la operación pueden identificar qué tareas ejecutan ellos mismos y en qué puntos sigue siendo necesaria la coordinación.

En un traslado, la migración de datos, los accesos y la disponibilidad operativa deben coincidir en el mismo momento. Por eso, antes de la transferencia aclaramos cómo se preparan, verifican y utilizan después los datos actuales. Las interrupciones necesarias y las pruebas funcionales se acuerdan con sus responsables. También se trata la cuestión de una vuelta atrás antes de la conmutación. El objetivo es una transición en la que las partes implicadas sepan qué resultados deben existir antes de una aprobación y quién decide sobre ella.

Tras la aceptación, las tareas de plataforma, sistema operativo y aplicación se documentan por separado. Entre ellas se incluyen las copias de seguridad, la recuperación, el mantenimiento y la gestión de avisos. Un contrato de soporte puede complementar estas tareas de forma selectiva; sin embargo, no sustituye la delimitación necesaria frente al alcance contratado con el proveedor y frente a sus propias actividades internas. Los puntos pendientes se traspasan con responsables asignados. Así, después del proyecto queda claro qué se configuró, qué procedimientos se pueden utilizar y qué trabajos siguen pendientes de planificar.