Un equipo pequeño debe poder operar su infraestructura
Valore quién gestiona las actualizaciones, las incidencias y la recuperación. Un portal pequeño muestra cuándo puede ayudar una mayor orquestación.
La decisión de infraestructura de un equipo pequeño debería empezar por la operación: ¿quién puede restablecer la aplicación tras una actualización fallida y qué sucede si falla un servidor? Una plataforma adicional se justifica cuando facilita esas tareas en sus condiciones reales.
Un portal con una estructura limitada
Un equipo hipotético de tres desarrolladores mantiene un portal de clientes, una base de datos y un proceso en segundo plano que transfiere pedidos. En este ejemplo, la carga es previsible. La distribución automática entre muchas máquinas aún no es un requisito. Hay objetivos de recuperación acordados para las caídas; el equipo todavía debe demostrar que puede cumplirlos.
Se comparan una operación documentada de contenedores en un servidor y un clúster Kubernetes operado por el propio equipo. Es una valoración de este ejemplo, sin una clasificación universal.
Pregunta operativa | Un servidor con contenedores | Un clúster autogestionado |
|---|---|---|
¿Qué debe actualizarse? | Sistema operativo, entorno de ejecución de contenedores y aplicaciones | Además, los componentes del clúster y su configuración |
¿Qué ocurre si falla una máquina? | El portal deja de funcionar; hay que sustituirla y recuperar el servicio | La distribución puede ayudar si hay suficientes nodos independientes y una configuración adecuada |
¿Cómo se recuperan los datos? | Copia de seguridad probada y restauración documentada | Sigue siendo necesario un plan propio para los datos de la aplicación y su recuperación |
La opción más sencilla podría encajar si el procedimiento de recuperación demostrado cumple los objetivos operativos. Un solo servidor no ofrece alta disponibilidad. Si esa interrupción es inaceptable para el negocio, se descarta esta opción en su forma actual.
La automatización desplaza tareas
Kubernetes puede reiniciar contenedores fallidos y distribuir aplicaciones entre nodos disponibles. Sin embargo, que un proceso vuelva a funcionar no demuestra que los pedidos y sus adjuntos estén completos. La recuperación de datos y la comprobación de las funciones del negocio siguen requiriendo planificación.
Un servicio gestionado también necesita un reparto claro de responsabilidades: ¿el proveedor se ocupa solo del plano de control, también de los nodos o de otras tareas? Los errores de la aplicación y la posibilidad de recuperar sus datos no se resuelven automáticamente.
Cuándo cambia la decisión
Si la empresa ya cuenta con una plataforma mantenida por un equipo de operaciones responsable, alojar allí el pequeño portal puede tener sentido. Para los tres desarrolladores, un servidor aparte podría exigir entonces más tratamiento especial. Una carga muy variable o requisitos vinculantes de disponibilidad también pueden requerir otra arquitectura.
Antes de elegir, solicite una demostración en un entorno de pruebas de un despliegue fallido y un caso de recuperación. Documente quién interviene y qué función del negocio se comprueba después. Esas pruebas explican mejor la idoneidad de una infraestructura que su número de componentes.
Fuentes
Escrito por
- Lukas SchneiderRedactor técnicoLukas Schneider escribe en ASES sobre tecnologías en la nube y la operación de aplicaciones. Sus artículos abarcan desde la elección de la infraestructura hasta el mantenimiento, las copias de seguridad y la supervisión de sistemas en funcionamiento.
Seguir leyendo
Todos los artículos
Cloud y operación con ASES
Hosting, despliegue, mantenimiento y soporte