BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

La madurez de DevOps difiere de un mercado a otro (parte 2)

Conozca los principales desafíos que los departamentos de TI en diferentes industrias están enfrentando en su camino hacia la adopción o maduración de DevOps.

Nota: En la primera parte de este artículo, se describió los avances y retos que tiene la adopción de DevOps en industrias como los seguros, la banca y el comercio electrónico.

DevOps es un ajuste natural para los departamentos de TI de SaaS. Las empresas basadas en la web que ofrecen productos SaaS son los nuevos chicos de la cuadra en TI, y están a la vanguardia del movimiento hacia DevOps siendo pioneros en la automatización de software, así como en una revolución cultural en el campo de la tecnología.

Estos son los campos verdes: las empresas que pueden construir una moderna infraestructura impulsada por DevOps desde cero. Aquí encontrará los mayores defensores de la computación sin servidores, NoOps y otras ideas completamente innovadoras. Los departamentos de TI de software como servicio (SaaS) también tienen sus problemas de implementación de DevOps, pero, en la mayoría de los casos, ellos están por delante del juego.

Los profesionales de TI SaaS no tienen infraestructura heredada que acomodar y con frecuencia tienen pocos, si alguno, ingenieros de operaciones, ya que también tienden a basarse en servicios de nube pública. Sin embargo, deben asumir la responsabilidad de todos los trabajos de back-end de las aplicaciones que ofrecen, desplazándolos fuera del cliente que anteriormente operaba software en instalaciones locales. Por lo general, los profesionales de TI SaaS construyen sus propias herramientas de automatización de software desde cero, a partir de bloques de construcción de código abierto, ya que estos los diferencian del departamento de SaaS de al lado.

Tome Zenefits, con sede en San Francisco, fundada en 2013, por ejemplo. La compañía de SaaS de gestión de recursos humanos se basa en una plataforma de gestión de la infraestructura y despliegue de aplicaciones llamada Duplo, que el ingeniero principal de la compañía, Venkat Thiruvengadam, construyó desde cero.

En opinión de Thiruvengadam, hay dos tipos de empresas: las tradicionalistas empresariales y las pioneras web 2.0.

"El mundo está en la transición del primer enfoque hacia el segundo enfoque", dijo. "El software que [Microsoft] Azure, Google [Cloud Platform] y Amazon [Web Services] están construyendo hoy es mejor que el software que [anteriormente] ha existido, y esto es algo que las personas están comprendiendo, poco a poco".

La transición fuera de la burbuja de SaaS es lenta debido a que los tradicionalistas de TI tienen miedo de dar demasiado control a sus desarrolladores, dijo Thiruvengadam.

"Las empresas tradicionales tienen miedo, por razones de seguridad, de que un desarrollador cometa un error o cause una interrupción si hacen un despliegue arriesgado en la mitad del día", dijo. "Ahí es donde tenemos que mejorar el software para reducir los riesgos".

El riesgo también puede reducirse al mínimo cuando un equipo de desarrolladores SaaS puede manejar la solución de problemas de TI de sus propias aplicaciones, cree Thiruvengadam

"Uno no espera que un ser humano le diga cuál es el problema, solo interactúa con el software", dijo. Mientras tanto, si hay un problema de infraestructura en la nube pública, "confío en Microsoft y Amazon para resolverlo más rápido que los profesionales de TI en una nube privada, respondiendo a los tickets de soporte".

Contratos y sindicatos dividen a TI de DevOps en el sector público

A diferencia de los departamentos empresariales del sector privado, TI en el sector público no tiene competidores que los empujen a adoptar prácticas más ágiles o a entregar aplicaciones de software más rápido.

Lo que el gobierno sí tiene es una base de consumidores que está en rápida evolución, tanto en su uso de la tecnología, como en sus expectativas de cómo se entregan los servicios. Eso es suficiente para hacer que los gobiernos federales, estatales e incluso locales intensifiquen la entrega de software, incluso si esos esfuerzos siguen siendo un tanto dispersos y fragmentados debido a las estructuras contractuales de los empleados y las restricciones de seguridad.

"Esos mismos consumidores que impulsan la adopción de DevOps en el sector privado, también tienen las mismas expectativas crecientes en sus interacciones con las agencias gubernamentales", según el reporte de Forrester Research, "El Estado de la Adopción de la Industria DevOps para 2016 - ¿Dónde está el calor?". Los autores del informe también señalaron que "las frecuencias de lanzamiento tanto de nube, como móviles están aumentando, lo que requiere una mayor adopción de prácticas DevOps".

Aunque la motivación es fuerte, los retos que enfrenta TI en el sector público al adoptar DevOps son numerosas y espinosas. A nivel local, por ejemplo, los contratos de los sindicatos de los profesionales de TI no se renegocian fácilmente para combinar funciones en desarrollo y operaciones.

"En Nueva York, trabajos como los de administradores informáticos están sindicados ahora, y no es fácil tomar a alguien que solía ser un administrador de Windows y decir: 'Hey, vas a tener que aprender parte de la aplicación y añadir eso a tus responsabilidades de trabajo'", dijo Daniel MacDonald, arquitecto y director técnico principal de una agencia de Nueva York que está trabajando para adoptar técnicas de desarrollo de software ágiles. "Nos estamos acercando a ello desde una dirección de abajo hacia arriba, volviendo a los desarrolladores en DevOps, en lugar de realmente hacer un equipo conjunto de desarrolladores y operaciones".

La agencia de MacDonald ha comenzado a dividir aplicaciones monolíticas en microservicios que se ejecutan en contenedores Docker y son gestionadas con Rancher.

Los sindicatos no son tanta preocupación a nivel federal para TI en el sector público, pero un sistema de contratos federales bizantino lanza retenes similares a la colaboración DevOps, según Nirmal Mehta, jefe de tecnología senior para el grupo de innovación estratégica de Booz Allen Hamilton Inc., una empresa de consultoría con sede en McLean, Virginia, que trabaja con organizaciones gubernamentales para establecer una cultura DevOps.

Tradicionalmente, los grandes contratos de TI son de varios años y se conceden a un proveedor con varios subcontratistas. A menudo, los contratos exigen un adjudicatario que entregue una pieza de la aplicación, y la operación y mantenimiento va a un contratista separado, que interfiere con los esfuerzos por cultivar DevOps. A veces, se concede un gran contrato, lo que es un poco más óptimo para la colaboración dentro de él, pero si los requisitos no se establecen correctamente, "se puede volver muy inflexible para el lado del gobierno cambiar algo o adoptar nueva tecnología", dijo Mehta.

Aún así, Mehta ve que la marea comienza a cambiar en el gobierno federal, citando programas como el acuerdo de compra general de Administración de Servicios Generales Ágil, que fue ejecutada como un hackathon para determinar quién podría hacer una oferta sobre las tareas.

"Esa es una manera totalmente nueva de determinar quién es capaz de hacer una oferta sobre el trabajo, y luego, encima de eso, los contratos que están saliendo de eso son de corto plazo", dijo.

¿Pueden DevOps, el código abierto y la nube modernizar TI para los órganos de gobierno?

La comunidad de inteligencia es un área de TI para uso gubernamental, donde las agencias pueden estar en la punta de lanza de la tecnología. Por ejemplo, tanto la Agencia Nacional de Seguridad, como la Agencia Central de Inteligencia han hecho la transición hacia una región de nube amurallada de Amazon Web Services conocida como C2S, como parte de una estrategia para modernizar sus capacidades de computación.

Pero en términos más generales, hay un deseo entre TI en las agencias gubernamentales para ponerse al día y cerrar la brecha con el sector privado en la tecnología. Incluso el Pentágono ha tratado de aprovechar la velocidadl de desarrollo de tecnología en Silicon Valley como una ventaja para la seguridad nacional de Estados Unidos.

En 2015, la Agencia Nacional de Inteligencia Geoespacial (NGA) puso en marcha un proyecto para llevar la automatización de Chef a redes altamente seguras y aisladas, en colaboración con la Corporación MITRE, una organización sin fines de lucro con sede en Massachusetts que opera centros de investigación y desarrollo patrocinados por el gobierno federal.

"Queremos hacer la transición de un esfuerzo existente llamado entorno de analítica integrada, hacia una infraestructura de nube", dijo el ingeniero de sistemas senior de MITRE, Michael Kristan, hablando en una presentación pública en DevOpsDays Boston 2016. "Es un proyecto pequeño en la NGA, y nosotros deseamos utilizarlo como pionero para determinar el esfuerzo [requerido] para mover una arquitectura de un entorno tradicional en las instalaciones, hacia un modelo de nube".

En el camino, MITRE y sus homólogos de NGA en el proyecto GEOINT Pathfinder enfrentaron desafíos únicos transfiriendo cambios en el código entre la red sin clasificar basada en nube pública y las redes aisladas de alta seguridad dentro de la agencia. Cuando se realizaron cambios en el código en la red desconectada, se creó una serie entramada de versiones de código que a veces tenían que ser enderezados manualmente, dijo Kristan.

"He tenido que asignar manualmente y resolver conflictos de fusión, a veces para el código que yo no entendía completamente, y luego tengo el problema de los diferentes números de versiones de mis aplicaciones", dijo Kristan.

El esfuerzo, hasta el momento, ha dado como resultado, libros de cocina de Chef estandarizados y reutilizables, y recetas que tratan sobre parches y endurecimiento de los sistemas operativos, así como componentes de software comunes, como Apache, MySQL y Postgres. Algunos de los desafíos técnicos que enfrentó el equipo incluyeron la automatización de la red abierta hacia empujes de código fuente de red cerrada, y que el trabajo está todavía en curso.

"Hay tanto que hacer y somos un equipo muy pequeño", dijo Kristan.

Al igual que en varios otros mercados verticales, el talento con capacidades DevOps es todavía relativamente escaso y viene con altos precios para TI en el gobierno.

"Estamos tratando de trabajar en la construcción de una base técnica más grande de personas que se emocionan con algunos de los desafíos que tenemos aquí", dijo Kristan.

Nota del editor: Ash Carter, Secretario de Defensa de EE.UU., dijo la cita de arriba en un discurso en la Universidad de Stanford, el 23 de abril de 2015, titulado "Reasignar el Pentágono: Trazando un nuevo camino para la innovación y la ciberseguridad".

Nota: En la tercera parte de este artículo, hablaremos sobre los retos de la adopción de DevOps en transporte, ciencias de la vida, salud y medios de comunicación.

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close