{"id":38521,"date":"2019-10-31T22:24:16","date_gmt":"2019-10-31T19:24:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-takie-devops\/"},"modified":"2019-10-31T22:24:16","modified_gmt":"2019-10-31T19:24:16","slug":"kto-takie-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"\u00bfQui\u00e9nes son los DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En este momento, esta es una de las posiciones m\u00e1s caras del mercado. La atenci\u00f3n en torno a los ingenieros de \u2018DevOps\u2019 supera todos los l\u00edmites imaginables, y lo que es peor a\u00fan, con los ingenieros Senior de DevOps.
\nTrabajo como l\u00edder del departamento de integraci\u00f3n y automatizaci\u00f3n; adivinen la traducci\u00f3n al ingl\u00e9s: DevOps Manager. \u00bfRefleja realmente esta traducci\u00f3n nuestra actividad diaria? Dudo que lo haga, pero la variante en ruso es m\u00e1s precisa en este caso. Debido a mi trabajo, es natural que deba entrevistar a los futuros miembros de mi equipo, y en el \u00faltimo a\u00f1o, he revisado alrededor de 50 personas, y tantas m\u00e1s fueron eliminadas en la preselecci\u00f3n con mis empleados.<\/p>\n

<\/p>\n

Todav\u00eda estamos buscando colegas, ya que detr\u00e1s del sello de DevOps se esconde una gran variedad de ingenieros de diferentes tipos.<\/a><\/noindex><\/p>\n

<\/p>\n

Todo lo que se escribe a continuaci\u00f3n es mi opini\u00f3n personal; no est\u00e1n obligados a estar de acuerdo, sin embargo, admito que podr\u00eda influir en su perspectiva sobre el tema. A pesar del riesgo de desagrado, publico mi opini\u00f3n porque creo que tiene su lugar.<\/p>\n

<\/p>\n

Las empresas entienden de diversas maneras qui\u00e9nes son los ingenieros de DevOps, y para una contrataci\u00f3n r\u00e1pida, otorgan esta etiqueta a todos. La situaci\u00f3n es bastante extra\u00f1a, ya que las empresas est\u00e1n dispuestas a pagar recompensas desorbitadas a estas personas, recibiendo a menudo, en la mayor\u00eda de los casos, a un administrador con herramientas.<\/p>\n

<\/p>\n

\u00bfEntonces, qui\u00e9nes son los ingenieros de DevOps?<\/h2>\n

<\/p>\n

Comencemos con la historia de su aparici\u00f3n: Development Operations surgi\u00f3 como un paso m\u00e1s hacia la optimizaci\u00f3n de la interacci\u00f3n en equipos peque\u00f1os para aumentar la velocidad de producci\u00f3n del producto, como resultado esperado. La idea era fortalecer al equipo de desarrollo con conocimientos sobre los procedimientos y enfoques en la gesti\u00f3n del entorno del producto. En otras palabras, un desarrollador debe entender c\u00f3mo funciona su producto en diferentes condiciones, debe saber c\u00f3mo desplegar su producto y qu\u00e9 caracter\u00edsticas del entorno ajustar para mejorar el rendimiento. As\u00ed, durante un tiempo, aparecieron desarrolladores con un enfoque DevOps. Los desarrolladores DevOps escrib\u00edan scripts de construcci\u00f3n y empaquetado para facilitar sus actividades y el funcionamiento del entorno productivo. Sin embargo, la complejidad de la arquitectura de las soluciones y la interacci\u00f3n mutua de los componentes de la infraestructura empezaron a deteriorar el rendimiento de los entornos con el tiempo; cada iteraci\u00f3n requer\u00eda una comprensi\u00f3n m\u00e1s profunda de ciertos componentes, reduciendo as\u00ed la productividad del propio desarrollador debido a los costos adicionales de entender los componentes y ajustar los sistemas para tareas espec\u00edficas. El costo propio del desarrollador aument\u00f3, el costo del producto junto con \u00e9l, y las demandas a los nuevos desarrolladores en el equipo se dispararon, ya que era necesario cubrir tambi\u00e9n las responsabilidades de la 'estrella' del desarrollo, y, naturalmente, estas 'estrellas' se volvieron cada vez menos accesibles. Tambi\u00e9n cabe destacar que, en mi experiencia, poco interesaba a los desarrolladores las especificidades del procesamiento de paquetes por el n\u00facleo del sistema operativo, las reglas de enrutamiento de paquetes y los aspectos de seguridad del host. Un paso l\u00f3gico fue atraer a un administrador, que es precisamente quien est\u00e1 familiarizado con esto, y asignarle dichas responsabilidades, lo que, gracias a su experiencia, permiti\u00f3 alcanzar los mismos indicadores a un costo menor en comparaci\u00f3n con el costo de la 'estrella' del desarrollo. Tales administradores se integraron en el equipo y su tarea principal era gestionar los entornos de prueba y productivos, seg\u00fan las reglas del equipo espec\u00edfico, con recursos asignados a ese equipo. As\u00ed, en realidad, es como surgieron los DevOps en la percepci\u00f3n de la mayor\u00eda.<\/p>\n

<\/p>\n

Con el tiempo, estos administradores de sistemas comenzaron a comprender las necesidades de este equipo espec\u00edfico en el \u00e1rea de desarrollo, c\u00f3mo facilitar la vida a los desarrolladores y probadores, y c\u00f3mo desplegar actualizaciones sin tener que quedarse en la oficina el viernes por la noche corrigiendo errores de despliegue. A medida que pasaba el tiempo, los \"estrellas\" comenzaron a ser los administradores de sistemas que entend\u00edan lo que los desarrolladores deseaban. Para minimizar el impacto, empezaron a adoptar herramientas de gesti\u00f3n, y todos recordaron viejos y confiables m\u00e9todos de aislamiento en el nivel del sistema operativo, que permit\u00edan minimizar los requisitos de seguridad, la gesti\u00f3n de la parte de red, as\u00ed como la configuraci\u00f3n del host en general, lo que a su vez redujo las exigencias a las nuevas \"estrellas\". <\/p>\n

<\/p>\n

Apareci\u00f3 una \"maravillosa\" cosa: docker. \u00bfPor qu\u00e9 es maravillosa? Porque crear un aislamiento en chroot o jail, as\u00ed como en OpenVZ, requer\u00eda conocimientos no triviales del sistema operativo. Con esta herramienta, se permit\u00eda crear f\u00e1cilmente un entorno aislado para aplicaciones en alg\u00fan host, con todo lo necesario dentro, y devolver las riendas del desarrollo, mientras que el administrador de sistemas solo deb\u00eda gestionar un host, asegurando su seguridad y alta disponibilidad: una simplificaci\u00f3n l\u00f3gica. Pero el progreso no se detiene y los sistemas se vuelven cada vez m\u00e1s complejos, con m\u00e1s y m\u00e1s componentes; un solo host ya no satisface las necesidades del sistema y es necesario construir cl\u00fasteres. Volvemos a depender de los administradores de sistemas que son capaces de construir estos sistemas.<\/p>\n

<\/p>\n

Ciclo tras ciclo, aparecen diversos sistemas que simplifican el desarrollo y\/o la administraci\u00f3n, surgen sistemas de orquestaci\u00f3n que, hasta que no se requiere desviarse del proceso est\u00e1ndar, son f\u00e1ciles de usar. La arquitectura de microservicios tambi\u00e9n surgi\u00f3 con el objetivo de simplificar todo lo mencionado anteriormente: menos interconexiones, m\u00e1s f\u00e1cil de gestionar. En mi experiencia, no he vivido una arquitectura de microservicios completamente establecida; dir\u00eda que es un 50 a 50: el 50 por ciento son microservicios, cajas negras, lo que entra se procesa y sale; el otro 50 por ciento es un monolito desgarrado, servicios incapaces de funcionar independientemente de otros componentes. Todo esto volvi\u00f3 a imponer limitaciones en el nivel de conocimientos tanto de desarrolladores como de administradores.<\/p>\n

<\/p>\n

Las \u00aboscilaciones\u00bb en el nivel de conocimientos de expertos de un recurso determinado contin\u00faan hasta el d\u00eda de hoy. Pero nos hemos desviado un poco, hay muchos aspectos que vale la pena abordar.<\/p>\n

<\/p>\n

Ingeniero de Construcci\u00f3n \/ Ingeniero de Lanzamiento<\/h2>\n

<\/p>\n

Son ingenieros altamente especializados, surgidos como un medio para estandarizar los procesos de construcci\u00f3n de software y de sus lanzamientos. En el marco de la implementaci\u00f3n masiva de Agile, pareciera que su demanda hab\u00eda disminuido, sin embargo, esto est\u00e1 lejos de ser cierto. Esta especializaci\u00f3n surgi\u00f3 como un medio para estandarizar la construcci\u00f3n y entrega de software a escala industrial, es decir, utilizando t\u00e9cnicas est\u00e1ndar para todos los productos de la empresa. Con la llegada de DevOps, los desarrolladores han perdido en parte estas funciones, ya que ellos mismos empezaron a preparar el producto para su entrega, y considerando la cambiante infraestructura y el enfoque en una entrega lo m\u00e1s r\u00e1pida posible sin tener en cuenta la calidad, con el tiempo se convirtieron en un freno para los cambios, ya que adherirse a est\u00e1ndares de calidad inevitablemente ralentiza las entregas. As\u00ed, gradualmente, parte de las funciones de los ingenieros de Build\/Release han reca\u00eddo sobre los administradores de sistemas.<\/p>\n

<\/p>\n

Los Ops son tan diversos<\/h2>\n

<\/p>\n

Avanzamos y nuevamente la amplia gama de responsabilidades y la falta de personal cualificado nos empujan a una especializaci\u00f3n estricta; como setas despu\u00e9s de la lluvia, surgen diversas Operaciones:<\/p>\n

<\/p>\n