Si usted es un gerente de proyecto o gerente de unidad que trabaja en un lugar de trabajo corporativo y está en contacto con TI, encontrará que una palabra tecnológica diferente (por ejemplo, Kubernetes) es popular cada año. A veces has sentido que tus propios proyectos se subieron a este tren de popularidad y a veces contribuyeron positivamente a tus proyectos, pero a veces te sentiste perdido entre decenas de detalles técnicos que no entendías.
Recientemente de su unidad de TI Kubernetes, OpenShift, DockerSi ha comenzado a escuchar mucho las palabras Contenedor o DevOps y está en el proceso de tomar una decisión de inversión, este artículo fue escrito tanto para convencerlo como para registrar sistemáticamente mis pensamientos en esta área.
La TI como unidad se estableció inicialmente para ayudar a las unidades comerciales a aumentar el valor agregado y acelerar el negocio. Los desarrollos tecnológicos en esta unidad a lo largo de los años han llevado la importancia de TI en muchos sectores casi al mismo nivel que el destino de la empresa. Hoy, por ejemplo, a la hora de decidirte por el banco para trabajar en el sector financiero, además de las oportunidades que te ofrece, el nivel avanzado de banca sin sucursales también se ha convertido en uno de tus criterios de selección. Como tal, es cierto que se necesita una unidad de TI sólida, rápida y adaptable para mantenerse por delante de la competencia.
Aunque TI es una unidad tan importante, si la empresa en sí misma no es una empresa de TI, no es una unidad que pueda trabajar sola. Por ello, para producir valor, esta unidad debe recibir las solicitudes de las unidades de negocio de su entorno, procesarlas, producir resultados significativos y presentarlos a sus clientes internos o externos. De lo contrario, incluso si se instala el sistema más poderoso, brillante, agradable y maravilloso del mundo, la unidad de TI estará lejos de producir algún valor.
Las unidades de negocios, por otro lado, han estado buscando una forma de trabajar eficientemente con TI durante mucho tiempo, agregando a veces actores adicionales que traducirán las solicitudes de la unidad de negocios al lenguaje de TI (y viceversa) o considerarán las PMO (oficina de gestión de proyectos) como una estructura separada y tomar posesión de este trabajo por parte de la PMO. En las unidades de negocios con menor conocimiento de TI, las expectativas y demandas no se pueden transmitir bien, TI no puede asignar el tiempo a cada unidad según lo requiera el trabajo entre las docenas de proyectos que maneja (¿alguna vez has visto a alguien que dice que mi trabajo no es urgente?) , la capacidad de TI para continuar trabajando y creando valor Hasta ahora, hemos experimentado o escuchado de nuestro entorno que el proceso, con el que ya es difícil trabajar en armonía, se ha vuelto tan malo que a veces provoca peleas sangrientas entre la unidad de negocios y TI.
Entonces, ¿cómo puede ayudarlo Kubernetes, que es solo un software al final del día? ¿Puede un software ser una cura para los problemas, alimento para los hambrientos, un hogar para los sin techo y un amigo para los solitarios? Por supuesto, Kubernetes es solo software, pero Kubernetes es una buena zanahoria para que su equipo de TI cambie su perspectiva comercial y comience a implementar prácticas de DevOps para usarlo de manera efectiva. Entonces, incluso si no es solo amigable, Kubernetes puede ser el capitán perfecto para que usted tenga una TI más ágil.
¿Qué tan diferente puede ser la gente de TI?
Si tiene un trabajo en el que usa un traje todos los días, al menos puede comprender que las personas de TI son personas diferentes de su ropa. Ya sea que estén desarrollando software o administrando sistemas, (la mayoría) de los profesionales de TI piensan que su trabajo es demasiado difícil, complejo y diferente para que nadie más que ellos lo entienda y no se puede comparar con otros trabajos. No deberías enojarte con ellos por eso, porque nosotros (la mayoría de nosotros) tenemos pensamientos muy similares sobre nuestro propio trabajo. Si bien esta idea puede parecer correcta desde el exterior, tanto su trabajo como el de ellos en realidad no son tan complicados.
Como casi cualquier trabajo que requiera esfuerzo mental, los trabajos de TI se pueden dividir en dos categorías muy generales. Estas son tareas repetitivas y cognitivas. Los trabajos de la primera categoría son los que haces con frecuencia y no tienes que pensar demasiado mientras los repites. Son parte de la rutina diaria y realmente pueden quitarte el tiempo sin darte cuenta. Por otro lado, cuando necesitas dedicar un esfuerzo mental a trabajos cognitivos, la mayoría de las veces hay un proceso que conduce al surgimiento de un nuevo trabajo intelectual y, por regla general, el valor que agregas a tu trabajo surge en este punto. Aunque la gente de TI tiende a pensar que cada trabajo es un trabajo cognitivo (si realmente quiere enojar a un desarrollador de software, dígale que el código será escrito por robots en el futuro), ese no es exactamente el caso, y algunos trabajos están obligados. para repetirse.
Entonces, ¿Kubernetes es un robot que realiza tareas repetitivas por usted? ¿Es Kubernetes una IA totalmente electrónica semiorgánica hipersónica que agrega alguna contribución cognitiva a cada tarea repetitiva? ¡La respuesta es no! Entonces, ¿por qué pagaríamos dinero a este Kubernetes, que no es una cura para el sufrimiento y no puede escribir código para nosotros? Siga leyendo para conocer la respuesta...
¿Es Kubernetes una cura para los problemas, lluvia sobre tierras áridas, un compañero de los afligidos?
El libro de Eliyahu Goldratt The Goal (los ingenieros industriales tienen los ojos llorosos) nos cuenta mucho más que la historia de amor de un ingeniero y condujo al surgimiento de la Teoría de las Restricciones. En un sistema administrado de acuerdo con la teoría de las restricciones, siempre hay una o más restricciones, y para maximizar la eficiencia, toda la organización debe organizarse de tal manera que la restricción funcione de la manera más eficiente. Al mismo tiempo, cada movimiento que no aumenta la eficiencia de la restricción es solo una ilusión y no tiene mucho sentido aumentar la eficiencia.
Cuando mira hacia abajo en una línea de producción en una fábrica o entra a la cocina de un restaurante, es relativamente fácil entender cuál es la restricción. Cuando ves que la capacidad de la máquina de prensa en una fábrica que produce ollas de acero es menor que la máquina que corta el acero, es tan difícil decidir que no hay necesidad de invertir capacidad adicional en la máquina de fijación de asas (a menos que sea también es un condicionante) o que la presencia de 4 parrillas es innecesaria cuando en la parrilla solo se pueden hacer tres platos a la vez.
Y si lo mismo ocurre con TI, ¿quién debe decidir qué es necesario y qué no?
Aunque las limitaciones de cada departamento de TI variarán según la organización de esa institución y la organización de la unidad, podemos decir que estas limitaciones suelen ser comunes con una lluvia de ideas corta. El presupuesto limitado, la cantidad de equipos cortos para el trabajo, la falta de maquinaria y capacidad, y la baja coordinación con las unidades comerciales suelen ser las principales limitaciones. Cuando agregamos deficiencias/errores de planificación, objetivos de entrega difíciles de alcanzar y demoras debido a la naturaleza del proceso de I+D, estas limitaciones a menudo conducen a resultados dramáticos.
Si bien algunos de los cambios que experimentamos en la tecnología permitieron la eliminación de algunas de las restricciones o la aceleración de los procesos, estos cambios no pudieron aumentar la eficiencia en la medida deseada, ya que estos cambios no trajeron consigo cambios de perspectiva. Por ejemplo, en el mundo previrtual, comenzar un proyecto de TI a menudo requería mucho trabajo, como comprar servidores físicos, reinstalar dispositivos existentes, cableado, instalación de sistemas operativos e instalación de software.
Aquí tenemos que parar y hacernos esta pregunta. ¿Ha disminuido realmente este tiempo? Realmente, en un entorno de tamaño promedio en este momento, cuando un desarrollador necesita un sistema limpio para probar un trabajo corto, ¿cuánto tiempo lleva obtenerlo? ¿En cuestión de horas? ¿En días? ¿O en cuestión de semanas como la mayoría de nosotros lo experimentamos? Teniendo en cuenta las aprobaciones que deben obtenerse, las instrucciones que deben realizarse y los permisos que deben otorgarse, puede llevar mucho tiempo transferir un valor que la unidad de negocio puede esperar con urgencia al entorno de prueba.
Por supuesto, hay muchas razones para esta situación. La primera es que en la estructura de TI clásica, que se divide en silos, cada subequipo tiene sus propias prioridades diferentes. Por esta razón, por ejemplo, mientras que el equipo de virtualización crea una nueva máquina para usted rápidamente, el equipo de red puede tardar en asignar incluso una simple IP porque tienen otras prioridades (¡siempre debido a estos usuarios de red!).
Por otro lado, también se sabe que tales trabajos repetitivos no siempre son hechos con amor por la fuente que está allí para crear un valor. A la mayoría de nosotros no nos gusta dejar de hacer un trabajo que nos emociona y volver a hacer un trabajo rutinario, por supuesto, esto también es cierto para quienes trabajan en la industria de TI.
Por último, en trabajos repetitivos, aunque se haga mucho trabajo, el hecho de que el procedimiento no sea claro o solo lo puedan realizar 1-2 personas en el equipo aumentará los tiempos de espera.
Entonces, ¿Kubernetes es un juego que convierte el trabajo aburrido en divertido? ¿O es un editor de texto que dice, dime cómo lo haces y escribimos el documento? ¡De nuevo, la respuesta es no! Entonces, ¿por qué invertimos en un software que no nos hace reír cuando estamos aburridos y que no es solo amigable?
Aunque decimos que TI no es una fábrica, es un organismo complejo que consta de diferentes especializaciones con procesos muy complejos en sí mismo, como dije anteriormente, TI es en cierto sentido una línea de producción (y realmente compleja). En cualquier caso, es posible aumentar la eficiencia de esta banda y automatizar algunas partes de la misma. Entonces, ¿realmente queremos hacerlo o tendremos el poder de hacerlo una vez que decidamos hacerlo? Esa es la verdadera pregunta, en mi opinión. Aquí es donde Kubernetes puede ser una cura para los problemas, lluvia en tierras áridas y un compañero para los afligidos. Si no es eso, ¿qué es este Kubernetes?
Leemos 1.000 palabras, ¿somos nuevos en el tema?
Si piensas como el título, blogbienvenidos mis amigos. Lo siento, necesito 2.000 palabras para escribir un saludo sobre cualquier tema. Kubernetes es en realidad un orquestador de contenedores de código abierto.
Creo que entendimos que Kubernetes es un director, pero puedo escucharte decir quién es la orquesta (no me estropees). Si es tu orquesta, los contenedores antes mencionados. Un contenedor es el trabajo de llevar el conjunto de requisitos que harán que la aplicación funcione en un paquete estándar. De esta forma, al igual que los contenedores que se cargan en los barcos, las aplicaciones pueden cargarse en un sistema operativo y virtualizarse en espacios de usuario aislados. Gracias a esta virtualización se reduce la carga que crea el sistema operativo sobre la misma capacidad y casi todo el rendimiento lo aprovechan las aplicaciones. Al mismo tiempo, se garantiza que una aplicación que se empaqueta una vez funcione de la misma manera en todos los entornos que cumplan los requisitos mínimos con sus configuraciones y componentes, lo cual es extremadamente importante en el entorno de software actual.
Container and Kubernetes no es un componente que agrega súper funciones al software que usa, es un componente de infraestructura que está casi completamente relacionado con el funcionamiento interno de TI y, a menos que contemos casos especiales, ni siquiera sabe si se está ejecutando. en Kubernetes o si se instala con métodos tradicionales al usar el software en la vida diaria. Sin embargo, la transición de Kubernetes y la implementación de prácticas DevOps son lo suficientemente importantes como para cambiar la forma en que toda la empresa hace negocios.
Aunque la tecnología es conceptualmente antigua (chroot, zonas Solaris, etc.), la solución y solución que ha traído Docker en los últimos años se ha convertido en un estándar de la industria al ir más allá de la empresa. El kernel de Linux creó un nuevo paradigma que también permite el control total de los recursos del sistema asignados a cada contenedor, lo que se convirtió en un punto de inflexión para la industria de TI.
Si bien es fácil administrar un solo contenedor en una sola máquina, sería muy difícil administrar N contenedores en N versiones diferentes con requisitos de alta disponibilidad, por lo que necesitábamos a alguien que hiciera esto por nosotros y comenzamos a buscar un conductor para liderar esta orquesta Aunque hace unos años me preguntaba si debería escribir algún desarrollador orquestador que empezara temprano en la mañana (ver Guerras de formato y Betamax), hoy casi toda la industria está de acuerdo en que Kubernetes ha ganado esta carrera.
¿Hay paz en Kubernetes?
Con Kubernetes, puede automatizar los procesos de implementación, escalado y administración involucrados en el desarrollo de aplicaciones. En sus propias palabras, Kubernetes tiene como objetivo crear una plataforma para la implementación, escalado y administración automáticos de contenedores de aplicaciones en servidores agrupados. Bueno, veamos dónde usaremos esta información en la vida real.
Ahora nosotros, como unidad de negocios, usamos software para crear valor para nuestros clientes en la empresa para la que trabajamos, y digamos que es un software de CRM. Nuestra unidad de TI es responsable del mantenimiento y mantenimiento de este software CRM, y nosotros somos los usuarios del software. No nos importa qué tecnología usa el software o cómo funciona. Todo lo que necesitamos es trabajo. Hasta que una persona inteligente de nuestro equipo (entonces decimos que no hay innovación en el país) salió y dijo que si usamos datos que no están en el software, obtendremos un mejor resultado.
En este punto, necesitamos no solo el mantenimiento del software, sino también su desarrollo. Para hacer esto, primero determinamos nuestras necesidades (los equipos de TI dicen LoL aquí) y luego llamamos a la puerta de la unidad de TI. Entienden nuestra necesidad, la evalúan y finalmente deciden implementarla. Ejecutan sus propios procesos para esto, y lo llaman unos trimestres más tarde y le dicen que esta es la función que desea. Mientras vamos a abrir el champán y celebrar, nos damos cuenta de que no tenemos los datos que queremos, sino datos que no necesitamos, y el mercado ya ha cambiado mientras tanto, e incluso si mantenemos los datos correctos, ya no lo necesitamos. Esta historia es realmente muy agotadora para todos los lados de la historia. Si bien usted, como unidad de negocios, no puede obtener lo que desea, la otra parte se sentirá decepcionada por el hecho de que TI no pudo alcanzar el resultado a pesar de sus esfuerzos. Por eso cuando pasan cosas así, en lugar de buscar al culpable, lo que hay que hacer es buscar una solución y la paz está en Kubernetes.
¿Qué hará Kubernetes?
En realidad nada. Nuestro objetivo es proporcionar un incentivo para cambiar la perspectiva de nuestro equipo de TI y de nosotros mismos al permitir el uso de una tecnología que se ha vuelto “bombo” en el sector. Cuando la virtualización del sistema operativo llegó a nuestras vidas, podríamos haber aprovechado la oportunidad para cambiar esta perspectiva, pero no estábamos del todo preparados entonces y hasta el día de hoy.
La primera clave para trabajar pacíficamente en un entorno de Kubernetes orquestado es que su equipo automatice rápidamente todo el trabajo repetitivo. Como puede deducir de las definiciones anteriores, nuestras aplicaciones ya no deben ser cargas que requieran una atención especial para su instalación, sino contenedores que se pueden cargar en el barco como estándar, y el barco debe estar preparado para aceptar esto. Lograr esto requiere aplicar técnicas de DevOps para lograr zanahorias y recompensas.
Un cambio de perspectiva que permitirá a nuestro equipo de operaciones administrar las herramientas y los entornos que administran la operación en lugar de administrar la operación real, y permitir que nuestro equipo de desarrollo desarrolle imaginando todo el entorno desde la solicitud hasta la entrega, en lugar de simplemente ejecutar el desarrollo en su propia computadora, es necesario para que Kubernetes se sienta seguro en el medio de su negocio. Repasemos el ejemplo anterior nuevamente, esta vez examinemos juntos cómo su primera solicitud de desarrollo y su segunda solicitud de desarrollo resultarán cuando no escuche las solicitudes de orquestación y contenedorización de TI y asigne un presupuesto.
Después de la mala experiencia que tuvimos con CRM, el software favorito de la gente, encarcelamos a todos nuestros compañeros de equipo con diferentes ideas en un cuarto oscuro y nos prometimos mutuamente que estaríamos contentos con lo que el software nos diera como unidad de negocios. Sin embargo, sucedió, y un colega que escapó de la mazmorra oscura llamó a nuestra puerta con una nueva idea que llevaría el software que usamos un paso más allá. Llamaste a la puerta de TI una vez más con tus esperanzas, diciendo que tal vez este corazón inquebrantable es irrompible, pero esta vez tu equipo de TI te dijo que conceptos como Docker y Kubernetes que no tienen nada que ver con tu negocio, con los ojos brillantes, saltando en el aire, mostrándose unos a otros ( Choca esos cinco ¿ Me parece una pérdida lingüística solo para mí que su turco no sea de alta fidelidad sino de alta fidelidad ? ) . Apoyaste el presupuesto con muchos ceros al decir ok y te encontraste en un nuevo proyecto.
Dijiste cuáles eran tus deseos y pensaste que sería mejor dejarte solo por un momento y sumergirme en tu propio negocio hasta la próxima reunión de estado. Aquí, nuestro escenario se dividirá en dos.
En el primer escenario, el equipo invertirá en Kubernetes pero no cambiará su perspectiva. En este caso, en la primera reunión a la que asistirá, el equipo de desarrollo hablará sobre los sistemas de prueba que aún no están listos, mientras que el equipo de operaciones dirá que solo el software que está próximo a funcionar e instalarse merece el sistema de prueba, y dirá que el desarrollador no entiende por qué el código que se ejecuta en su computadora no funciona en el entorno de prueba. Por otro lado, se dirá que Kubernetes aporta mucha complejidad al entorno y no está seguro qué funcionará y qué no funcionará en este momento. Te sentarás en el medio y tal vez mires un anuncio en LinkedIn.
En el segundo escenario, su equipo de TI dedicará el 99.976 % de su reunión con usted (medida científicamente, controlable) para explicar cómo automatizan muchas tareas que consumen mucho tiempo antes. Por ejemplo, los desarrolladores ahora realizan automáticamente las solicitudes de nuevas máquinas y los servidores de mantenimiento del estado se crean automáticamente en el entorno virtual, mientras que en el entorno de Kubernetes, cada desarrollador puede usar el portal de autoservicio para crear nodos hasta su cuota en la prueba. entorno sin obtener la aprobación de nadie. Las asignaciones de IP y el enrutamiento se han automatizado con los servicios de IPAM, e incluso el desmantelamiento ha comenzado a automatizarse. El equipo de desarrolladores comenzó a automatizar la creación de contenedores necesarios para entornos como pruebas, preparación y producción en canalizaciones. Así, en vez de apoyar la operación en la instalación y ajuste del software cada vez, han pasado a poder comisionar directamente. "Entonces, ¿mis características?" Cuando diga eso, obtendrá la respuesta del 0.024 % de la reunión: “Sí, también lo estamos analizando”, pero esta vez no es necesario iniciar sesión en LinkedIn porque ahora también florece la esperanza en esta casa.
Nuestra unidad de TI comenzó a cumplir con los requisitos del entorno y comenzó a automatizar todas las tareas repetitivas, por lo que comenzó a utilizar los recursos limitados de manera más eficiente y comenzó a producir valor. Ahora la operación tiene respuestas a la pregunta de cómo configurar una máquina virtual automática en lugar de instalar una máquina virtual. Por un lado, dado que el primer paso de la automatización es la documentación correcta, solo Handan / Nuri sabe cómo hacerlo, ese trabajo ha comenzado a llegar a su fin.
De manera similar a la operación, sus equipos de desarrollo de software ahora pueden tomar medidas en lugar de dejar que la operación realice la configuración, la integración, la puesta en marcha y las actualizaciones, porque la operación ahora es un árbol estandarizado y empaquetado en lugar de un árbol de componentes que intentará (ya menudo tendrá dificultades) instalarse por sí solo. El contenedor está esperando. Por esta razón, también se ha producido un requisito similar de documentación e intercambio de información en la operación en el lado del software.
Sí, a nadie parece interesarle esa gran mejora que tanto deseas y que es importante, pero tampoco hay muchas peleas alrededor de la mesa. Se dice que después de algunas reuniones de estado, ahora puede probar la actualización y esta vez obtendrá lo que desea en un poco menos de tiempo de lo habitual. Cuando cantes la misma mente una vez más, tu unidad de TI, donde estos procesos están aún más asentados, recibirá tus solicitudes y en muy poco tiempo vendrá a ti y te dirá si quieres algo así. Porque ahora se pueden destinar más recursos al trabajo cognitivo y al mismo tiempo se dotará de la infraestructura necesaria para la rápida creación de valor.
¿Necesita Kubernetes en todos los hogares?
Por supuesto, Kubernetes no es para todos. Por ejemplo, puede que no vaya más allá de crear una carga de trabajo adicional para un equipo que es demasiado corto frente a todo el trabajo. Si tienes 4 aplicaciones y no son escalables, tu prioridad no debe ser cambiarte a esta tecnología.
Me doy cuenta de que suena tanto bueno como increíble en teoría, pero los ejemplos de buenas prácticas que he observado han sido que las inversiones en Kubernetes y los cambios de perspectiva generados por esta zanahoria a menudo aumentan el valor que las unidades comerciales obtienen de TI. Entonces, aquellos de ustedes que han aprendido Container, Kubernetes, orquestación en las últimas 2.000 palabras o más, han entendido que necesitan ir para ayudar cuando TI llama a su puerta en busca de soporte, o si no acuden a usted con esta solicitud, tal vez deberías ir a ellos con esta solicitud (espero).
En este artículo traté de hablar sobre Kubernetes, Containers y cómo estas tecnologías pueden agregar valor a las unidades de negocio gracias a las diferencias que traen a nuestra perspectiva, y que nosotros como unidades de negocio no debemos perder esta ventana de oportunidad. Por supuesto, esta no es la única razón de la fricción entre TI y la unidad de negocios, y esta tecnología no es una panacea, pero es un buen punto de partida.
El tema de la próxima publicación es otro tema de fricción: "Hermano, ¿es este el único trabajo de TI para hacer su proyecto?" Estará en el título. En este artículo, intentaré responder por qué la respuesta a la pregunta es un rotundo NO.
Gracias por leer.
nota: Si pudiera hacer que alguien involucrado en TI leyera un libro, El Proyecto FénixLe haría leer. (Si tuviera que hacer que todos en el mundo leyeran un libro, haría que todos leyeran La guía del autoestopista galáctico para que vieran lo sabio que soy porque los obligué a leer este libro y me elegirían como el líder natural y sabio del mundo, el universo y todo lo demás). La razón principal por la que escribí este artículo fue que este libro dio forma a la mayoría de mis puntos de vista. Por lo tanto, es normal darse cuenta de que el libro inspiró la mayor parte del artículo.
Versión original de este artículo en este enlace Este es el artículo fechado el 17 de febrero de 2020.
