Kubernetes no debe ser un vuelo a ciegas.

Antes de elegir la plataforma, analizamos qué aplicaciones deben incorporarse y qué necesidades tienen los equipos. ¿Cómo se despliegan hoy las nuevas versiones? ¿Qué datos deben conservarse de forma permanente? ¿Quién asume los cambios en la plataforma? Estas preguntas ayudan a delimitar el alcance necesario. Kubernetes puede tener sentido, pero debe adaptarse a las aplicaciones y a las competencias disponibles. Una decisión basada únicamente en una tecnología deseada no resolvería aún la cuestión del esfuerzo organizativo y técnico adicional.

Por eso las variantes adecuadas también se analizan según cómo se distribuyen las tareas. En el caso de un servicio gestionado, queda por aclarar qué trabajos siguen siendo necesarios en la aplicación, la configuración y los datos. La visión objetivo indica estas tareas que quedan a su cargo y determina cuáles de ellas asume OTOKO® dentro del encargo. Una aplicación piloto representativa hace tangibles los requisitos. Con ella puede comprobarse si la estructura elegida y los procesos previstos cumplen realmente las expectativas, antes de incorporar a más equipos o aplicaciones.

Un equipo necesita más que el acceso al clúster. Debe saber dónde puede trabajar, cómo se asignan los recursos y qué aprobaciones son válidas para un cambio en producción. Estas bases se configuran conjuntamente y se conectan con el proceso de despliegue. Las imágenes, las comprobaciones y la versión deseada deben corresponderse de forma trazable. La implementación concreta se basa en sus aplicaciones y en las herramientas existentes; los procesos que ya funcionan se incorporan a la visión objetivo en la medida en que resulten adecuados.

El primer release se realiza de forma conjunta. En este proceso comprobamos no solo si el arranque tiene éxito, sino también si el procedimiento resulta comprensible: ¿pueden identificarse los mensajes de error, es inequívoca la aprobación y saben el desarrollo y la operación cuándo deben actuar? También se comentan o se prueban los casos de error acordados y las opciones de vuelta atrás. La documentación que resulta de ello debe servir de apoyo para los siguientes releases. Así, su equipo obtiene un método de trabajo utilizable y no solo un entorno técnico cuyo manejo haya que averiguar más adelante.

Los contenedores pueden volver a desplegarse, pero los datos asociados y los servicios conectados necesitan procedimientos propios. Analizamos junto con usted qué información debe conservarse de forma permanente y cómo se comprueba su recuperación. Esto incluye también el orden en el que la aplicación y los datos vuelven a estar disponibles. Por eso un procedimiento de copia de seguridad debe corresponderse con la aplicación real. Las tareas se asignan de forma explícita para que no surja, sin querer, un vacío entre el soporte de la plataforma y la responsabilidad sobre la aplicación.

Las actualizaciones de la plataforma también necesitan preparación y coordinación. Las dependencias, las posibilidades de prueba y las aprobaciones necesarias se describen en el procedimiento de operación. La monitorización y las vías de notificación determinan cómo se detectan los problemas y se transmiten a las personas responsables adecuadas. En un soporte continuo, el alcance de servicio indica qué tareas de plataforma y de operación están cubiertas y cuáles permanecen a cargo de sus equipos. Esta delimitación facilita incorporar más adelante nuevos requisitos de forma consciente y planificar de manera realista el trabajo necesario en la plataforma.