Cuándo se queda el rack

La pregunta no es si, sino qué

Hace diez años «¿nos vamos a la nube?» era todavía una conversación. Ya no lo es: correo, documentos, trabajo en equipo y la mayoría de las aplicaciones de negocio funcionan mejor y más barato en un servicio cloud que en un servidor en el cuarto de instalaciones. Esa parte está decidida.

Lo que queda es el resto, y ahí es exactamente donde se acaban los consejos estándar. Un entorno de producción, una aplicación de un proveedor sin versión cloud, un sistema que debe hablar con equipos del mismo edificio. De eso va este artículo.

Cuatro razones por las que el rack se queda

Estas cuatro nos las encontramos de verdad, y las cuatro se pueden justificar.

• La aplicación no se mueve. Un proveedor sin versión cloud, o una versión a la que le faltan funciones que usted usa. Ese retraso no es suyo sino de ellos, y no se puede esquivar. Entonces montamos un entorno que pueda seguir gestionando hasta que el proveedor llegue.
• La conexión no da. Archivos grandes, trabajo de diseño, edición de vídeo, o una sede donde la línea disponible sencillamente no es suficiente. El cálculo es rápido: procesar en local y mover solo el resultado.
• Hay un requisito sobre dónde están los datos. A veces normativo, más a menudo contractual con un cliente. Si tiene que poder señalar el edificio donde está algo, eso es un requisito duro y no una preferencia.
• La carga es pesada y constante. La nube cobra por uso, lo que le favorece cuando el uso fluctúa. En un sistema que hace lo mismo veinticuatro horas al día, ese cálculo se inclina a menudo al otro lado.

Tres razones que no son razones

Y estas son las tres que oímos igual de a menudo y que no lo son.

• «Nuestros datos están más seguros en casa.» Normalmente no. Una gran plataforma cloud tiene un equipo de seguridad mayor que toda su organización. Lo que sí es cierto: con equipo propio decide usted quién llega a ellos, y ese es otro argumento distinto de la seguridad. Llámelo por su nombre.
• «Acabamos de invertir en ello.» Comprensible, pero es una razón para esperar, no para quedarse. Entonces planificamos el cambio para el momento en que el equipo haya de sustituirse igualmente. Eso es calendario, no aplazamiento.
• «Total, funciona.» Cierto hasta que deja de serlo. La pregunta es si sabe cuándo acaba el soporte y qué pasa entonces. Si nadie lo sabe, «funciona» es una suposición y no un estado.

Qué conlleva tener equipo propio

Si se queda un rack, la marca no es la parte interesante. Suministramos y gestionamos HPE entre otros para servidores y almacenamiento, y en virtualización trabajamos con VMware, Nutanix y Proxmox. Sea cual sea su marca, esto va con ello:

• Vigilancia que avisa sola. Un disco que falla en un conjunto de cuatro no es una avería. Un segundo disco que falla porque nadie vio el primero, sí.
• Repuestos y plazos acordados. No «ya lo pediremos», sino fijado de antemano en cuánto se puede sustituir algo y si eso cabe dentro de su tiempo de recuperación.
• Una fecha de fin que conoce. El hardware tiene una vida de soporte. La anotamos el día de la instalación, no el año en que vence.
• Un plan de recuperación que no necesite el edificio. Véase abajo; es donde más se falla.

El plan de recuperación es la diferencia real

Nube o equipo propio cambia poco en cómo se trabaja un día normal. Lo cambia todo el día en que algo falla.

Con un servicio cloud la pregunta es: en cuánto vuelve el proveedor y qué dice el contrato al respecto. Con equipo propio la pregunta es: dónde sigue funcionando si este edificio no está disponible. Una copia guardada en el mismo rack que el servidor protege contra un disco roto y contra nada más.

Por eso acordamos por sistema cuánto puede estar caído y cuánto trabajo puede perderse, y probamos la recuperación en un entorno reconstruido desde cero. Es otra prueba distinta de «¿vuelve el archivo?» y da sorpresas con más frecuencia.

Cómo lo dejamos por escrito y lo demostramos está en copias y continuidad.

Cómo tomamos la decisión

No tenemos una preferencia fijada de antemano, y no es modestia: es la única forma de dar un consejo que siga siendo válido dentro de tres años. En la práctica funciona así.

• Miramos primero qué sistemas hay y qué necesitan, no dónde corren ahora.
• Ponemos las cuatro razones al lado de cada sistema. Si no se cumple ninguna, el punto de partida es la nube.
• Donde el equipo se queda, planificamos la sustitución para cuando el actual llegue igualmente a su fin. Sustituir equipo que funciona porque lo dice un plan es caro y rara vez aporta algo.
• El resultado casi nunca es todo o nada. La mayoría acaba con una parte en la nube y otra en el rack, y eso está bien mientras pueda explicar el porqué de cada parte.

La migración y la gestión diaria están en servicios cloud y servicios gestionados de TI.