🛠️ 💇🏼 🍐 Cómo OpenShift está cambiando la estructura organizativa de una organización de TI. La evolución de los modelos organizacionales al pasar a PaaS ⚗️ 🤬 🧔🏾

Aunque las soluciones de PaaS (Plataforma como servicio) por sí solas no son capaces de cambiar las formas de interacción individual y de equipo, a menudo sirven como un catalizador para el cambio organizacional en respuesta a la mayor flexibilidad de las tecnologías de TI.

De hecho, el retorno máximo de la inversión en PaaS a menudo es posible solo si se cambian los roles organizacionales, las áreas de responsabilidad (tareas) y las relaciones. Afortunadamente, las soluciones PaaS, como OpenShift Container Platform, son lo suficientemente flexibles como para que cada organización de TI pueda determinar de forma independiente la velocidad y el alcance del cambio en relación con las personas involucradas y los procesos que están teniendo lugar.

En la primera etapa de la contenedorización empresarial, la prioridad principal es la implementación de la plataforma contenedor como un nuevo sistema de implementación de aplicaciones. En este punto, las organizaciones vinculan trabajos familiares a roles familiares para responder a las solicitudes estándar de los equipos de desarrollo en temas como sistemas de almacenamiento, entornos de implementación y más. En las etapas posteriores de la contenedorización, ya estamos hablando de automatización o de proporcionar a los desarrolladores capacidades de autoservicio para reducir la carga sobre los administradores del sistema y llevar la autonomía y eficiencia de los desarrolladores a un nivel superior. Así es como la organización comienza a moverse hacia DevOps. En la etapa final de la contenedorización empresarial, se trata de un modelo DevOps más limpio y canónico,en el marco del cual muchas de las tareas y trabajos anteriores están bajo el control de equipos multifuncionales, que se agrupan no en base a plataformas o tecnologías, sino desde el punto de vista de garantizar el funcionamiento de las aplicaciones o servicios de aplicaciones.

En esta publicación, brindaremos orientación sobre los cambios organizativos necesarios y describiremos cómo están cambiando los roles tradicionales de TI con la introducción de la tecnología de contenedores en la empresa.

Vinculación de nuevos trabajos a roles antiguos

En su forma inicial básica, el modelo organizativo PaaS se forma para asignar recursos de TI de manera más flexible y eficiente a las aplicaciones como un entorno de tiempo de ejecución. Y aunque esto brinda ciertas ventajas a los administradores de sistemas, los desarrolladores aquí, por regla general, no reciben ningún beneficio significativo y nuevas oportunidades, ya que en esta etapa la empresa puede prescindir de la automatización, la introducción del autoservicio o la mejora radical de la tubería de implementación. Sin embargo, afectando mínimamente los procesos de desarrollo en esta etapa, PaaS aumenta el dinamismo del sistema de TI, lo que permite a los administradores atender mejor las solicitudes de los desarrolladores. Por ejemplo, si antes podría llevar días, o incluso semanas, crear un entorno de desarrollo a partir de varias máquinas virtuales y volúmenes de almacenamiento,y si requería la participación de varios administradores diferentes, entonces en PaaS todo se hace mucho más rápido y solo un administrador. En otras palabras, los equipos de desarrollo presentan solicitudes como antes, pero el trabajo en la implementación de estas aplicaciones ya se está llevando a cabo de acuerdo con el nuevo esquema.

Hacia una organización DevOps

Al lanzar PaaS y transferir especialistas de operación de sistemas de TI y desarrolladores de aplicaciones, la organización puede continuar implementando la metodología DevOps, que, entre otros, incluye los siguientes principios básicos:

Divida el trabajo en pequeñas etapas para obtener retroalimentación en las primeras etapas, reducir los riesgos y evitar la "parálisis analítica";
Automatice las operaciones lo suficiente como para no crear obstáculos o cuellos de botella en el proceso de implementación de la aplicación;
Compartir el conocimiento es la clave para generar confianza;
Pague regularmente deudas técnicas , asignando una cierta cantidad de tiempo en cada ciclo de trabajo para mejoras sistemáticas.

En la segunda etapa de implementación de tecnologías de contenedores, los equipos de desarrollo, naturalmente, comienzan a ver oportunidades de mejora, y la compañía se inclina hacia un modelo DevOps más canónico. El mecanismo tradicional para enviar y ejecutar solicitudes de servicio ahora se percibe como un cuello de botella, por lo que la organización busca automatizar acciones repetitivas y proporcionar a los desarrolladores capacidades de autoservicio. Además, estas capacidades de los desarrolladores en el marco de una aplicación en particular están determinadas por los esfuerzos conjuntos de los especialistas de TI en la operación de las plataformas y los responsables de entregar las aplicaciones. En otras palabras, los administradores del sistema que realizan acciones a pedido de los desarrolladores están siendo reemplazados por las dos categorías anteriores de empleados que son responsables de la descripción y aplicación de las políticas que rigenqué es exactamente lo que los desarrolladores pueden hacer solos. Los procedimientos automatizados ayudan a garantizar el cumplimiento de estos requisitos y coordinan acciones en casos donde la situación va más allá del alcance de las políticas existentes.

Cambiar a una línea de tiempo iterativa en la que el entorno de TI y el modelo operativo experimentan cambios iterativos a lo largo del tiempo es un hito crítico en términos de construir un sistema DevOps maduro en la empresa. El grado de adopción de la metodología DevOps depende de la tolerancia de cada organización en particular al cambio y de qué cambios son más beneficiosos. Por ejemplo, si la necesidad de crear nuevos entornos o aplicaciones surge con poca frecuencia, entonces optimizar las acciones apropiadas será menos importante que fortalecer el control de los desarrolladores sobre el ciclo de vida de la aplicación.

Nuevos desafíos que enfrentan las organizaciones de TI cuando se mudan a OpenShift

En esta sección, veremos los roles y tareas que las organizaciones que cambiaron a OpenShift suelen usar para acelerar la automatización y el autoservicio utilizando tecnología y PaaS.

La siguiente tabla enumera las tareas principales del nivel superior que existen en cualquier organización que haya implementado OpenShift, con ejemplos de trabajo y habilidades relevantes. Esta lista de tareas no debe confundirse con el esquema de trabajo compartido o la estructura organizativa de los equipos, esto es solo un conjunto de tareas que deben ser cerradas por los responsables de apoyar los entornos de TI para la implementación exitosa de la plataforma de contenedores. De hecho, mostraremos además que la implementación de tecnologías de contenedores crea los requisitos previos para la formación de una estrategia DevOps más madura en la empresa, que a su vez aumenta el grado de funcionalidad cruzada de los equipos y reduce los riesgos de una especialización limitada a nivel de los empleados individuales y los equipos.

Tabla 1. Definiciones de tareas de OpenShift

Tareas	Habilidades requeridas
(provisioning) - :	- Linux
OpenShift :	Linux (Ansible) Kubernetes OpenShift
(tenant provisioning), - : RBAC	Kubernetes OpenShift , ,
:	Linux runtime- middleware (application build frameworks) , imagestream
:	immutable – , . . OpenShift, buildconfigs, deploymentconfigs, services, routes, configmaps
:	(cloud native)
: ( ) -
: UI ( )	Marcos de prueba Plantillas de diseño de aplicaciones

Nuevas funciones que surgen en las organizaciones de TI al migrar a OpenShift

A medida que avanza hacia un modelo organizativo basado en DevOps, el número de especialización de roles tiende a disminuir, y el número de equipos y roles multifuncionales a su vez aumenta para maximizar la eficiencia de la colaboración. Aquí, en nuestra opinión, está la lista de puestos clave en una organización de TI que usa OpenShift:

Ingeniero de operaciones de aplicaciones O ingeniero de confiabilidad del sitio. Anteriormente, este puesto podría llamarse "Administrador del servidor de aplicaciones".
Desarrollador de aplicaciones / Desarrollador de software / Ingeniero de software.
Administrador de clúster / plataforma de aplicaciones. Anteriormente, este rol podría llamarse "Administrador del sistema" o "Administrador de la plataforma Linux".
Administrador de versiones de software (ingeniero de compilación).

Rol RACI y matriz de tareas

Finalmente, pasamos a comparar las posiciones y tareas discutidas anteriormente para dar una idea general de cómo debería ser la estructura de una organización que implementa DevOps en la plataforma OpenShift. Inicialmente, los siguientes roles pueden ser desempeñados por diferentes ramas de la antigua estructura organizativa tradicional. Pero con el tiempo, se producen consolidaciones y surgen nuevos equipos, basados en aplicaciones, que cierran la mayoría o incluso todas las tareas a continuación.

Tareas	Roles
Tareas	Ingeniero de Operaciones de Aplicaciones / Ingeniero de Confiabilidad del Sitio	Desarrollador de aplicaciones / Desarrollador de software / Ingeniero de software	Administrador de plataforma de clúster / aplicación	Gerente de lanzamiento de software / ingeniero de ensamblaje
Automatización y aprovisionamiento de infraestructuras informáticas.	yo	yo	R / a	C
Instalar y administrar la plataforma OpenShift	C	yo	R / a	C
Diseñar y administrar tuberías de implementación	C	C	yo	R / a
Administre el aprovisionamiento de inquilinos, el aislamiento y las capacidades de TI	C	yo	R / a	yo
Crea y gestiona imágenes básicas	R	C	R / a	C
Desarrollo de aplicaciones y pruebas.	C	R / a	yo	yo
Monitoreo operacional y gestión de aplicaciones	R / a	C	C	yo
Prueba de aceptación personalizada	C	R	yo	yo

Convenciones en la matriz RACI
Fuente: Wikipedia

Responsable : un ejecutor es aquel que hace lo necesario para completar una tarea.
Accountable – – , ; , .
Consulted – – , , ; .
Informed – – , (, ); .

DevOps-

El esquema tradicional para obtener recursos, como regla, es una serie de solicitudes de asignación de recursos, que luego son ejecutadas por varios comandos. Finalmente, todos los recursos necesarios son asignados y confirmados por el solicitante. A menudo, estos procesos se llevan a cabo de forma parcial o incluso manual y requieren interacciones frecuentes y numerosas entre los equipos para procesar con éxito cada solicitud.

Figura 1. Organización de TI tradicional

El diagrama anterior ilustra las relaciones típicas entre equipos en una organización de TI tradicional. Como parte de este esquema, algunos equipos recurren a otros equipos con una solicitud para realizar el trabajo necesario utilizando medios de comunicación más o menos formales, como un sistema de tickets o correo electrónico. Luego, estas solicitudes entran en la cola y esperan en las alas, y una larga espera a menudo conduce al deterioro, e incluso al agravamiento de las relaciones entre los equipos. La tensión se ve exacerbada por el hecho de que los miembros de diferentes equipos rara vez se encuentran personalmente y, por regla general, solo comparten la información mínima necesaria.

Figura 2. Organización de TI de DevOps

Este diagrama muestra cómo funciona la colaboración en una organización DevOps. Aquí, los mismos equipos del diagrama anterior abandonaron las comunicaciones ineficientes, lo que aumentó la desunión, y las reemplazaron por contactos personales, creando así canales permanentes de interacción entre los equipos. Estos canales ayudan a construir un conjunto de habilidades híbridas que ayuda a los empleados a comprender y representar mejor las necesidades, los desafíos y las capacidades de los equipos que representan. Los equipos se dan mutuamente la oportunidad de realizar el trabajo necesario a través de portales automáticos de autoservicio en lugar de procesar manualmente las solicitudes de cambio de otra persona, como era antes. Y debido a la presencia de canales de interacción, estos sistemas de autoservicio pueden adaptarse rápidamente a las necesidades de los equipos,para lo cual fueron creados. Para lograr una mayor comprensión mutua e intercambio de conocimientos dentro de la organización, los miembros del equipo rotan periódicamente los roles para ganar experiencia en la interacción con varios equipos y comprender mejor la imagen general de los sistemas de TI a los que sirven, aumentando así su nivel de funcionalidad y utilidad cruzada.

Resumiendo

En esta publicación, hablamos sobre cómo la implementación de soluciones PaaS puede alentar a la organización a implementar la metodología DevOps, y los roles y tareas tradicionales están sujetos a cambios dentro de este proceso. Por lo tanto, hemos enumerado las principales tareas de TI que surgen en la organización con la transición a OpenShift, así como las habilidades necesarias para su implementación. También presentamos el conjunto principal de roles organizacionales que ocurre cuando se crean equipos DevOps multifuncionales, y la matriz RACI que vincula nuevos roles con nuevas tareas. Finalmente, hablamos sobre cómo la plataforma OpenShift y su metodología DevOps asociada pueden cambiar la estructura organizacional de una organización al pasar de una jerarquía tradicional y sistemas de procesamiento de aplicaciones a equipos interfuncionales con un mayor nivel de comunicaciones personales.

Cómo OpenShift está cambiando la estructura organizativa de una organización de TI. La evolución de los modelos organizacionales al pasar a PaaS