Devops: cambiando el paradigma de desarrollo e implementación de software

La situación actual

Los modelos de gestión de desarrollo de aplicaciones que disponemos actualmente son inmanejables. Si alguna vez han tenido la posibilidad de trabajar en ambientes de desarrollo de aplicaciones, sabrán que los desarrolladores codifican su software esforzándose en satisfacer las necesidades del negocio y de los clientes de acuerdo a las especificaciones que le transmiten los analistas de negocio o managers en general. Por otra parte, el personal operativo tiene como objetivo principal garantizar la disponibilidad del servicio del cual dependen los ingresos de la compañía. Ambos grupos tienen objetivos diferentes, y podría decirse que hasta contradictorios. Los desarrolladores quieren mantener el software al día introduciendo cambios a la solución mientras que el personal operativo solo le interesa la estabilidad de la plataforma para que la aplicación funcione correctamente. Cuando los desarrolladores entregan su nuevo software a los operadores para comenzar el ciclo productivo de la aplicación, la trama esta servida. Si han tenido la fortuna de trabajar en desarrollo de software como yo, seguro que han escuchado frases como: “El nuevo parche no se ejecuta en nuestra plataforma”, “En el laboratorio de desarrollo la nueva aplicación funciona de maravilla”, “Esta nueva funcionalidad no puede ser instalada porque otro desarrollo activo lo impide”, “Porque vosotros, operadores, no mantienen el hardware al día”, “esta aplicación es un desastre y no hay servidor que la pueda soportar”, etc.

Tal como lo veo, los problemas se pueden resumir en los siguientes puntos:

Miedo al cambio

Cuando trabajé en un grupo de desarrolladores, temíamos que la plataforma fuese inestable y nos cohibíamos en cambiar la solución. Desconfiamos, y muchas veces con razón, de los desarrolladores y de sus desarrollos. Como tenemos miedo al cambio, recurrimos a procesos burocráticos para controlar y gestionarlos excesivamente rígidos. ¿Quién no ha sufrido durante una semana, o incluso más, para que el comité de cambios ITIL se reúna y discuta la vialidad de los cambios propuestos por los técnicos?

Inseguridad sobre los desarrollos creados

Nadie tiene garantías de que el nuevo código o sistema desarrollado funcione como lo esperamos en la plataforma productiva. ¿El servidor será capaz de soportar la carga actual del servicio? ¿Habrá algún código oculto que no valide la solución? Muchas veces no tenemos la respuesta a estas preguntas y nos empeñamos en seguir con la implementación.

Aislamiento

Los desarrolladores, una vez entregan su software a los operadores, se desentienden completamente de su implementación. Solo actúan si el problema es muy grave y apremiante. Por otro lado los operadores no involucran a los desarrolladores en sus decisiones sobre la plataforma, lo que hace que los desarrolladores pierdan contacto con la realidad de la plataforma productiva. Este comportamiento genera silos de conocimiento que no ayudan al desarrollo e implantación de las nuevas soluciones.

Que es Devops?

La palabra Devops, proviene de la unión de dos palabras anglosajonas “Developer” y “Operations”. Devops es un movimiento reciente (2009), tan reciente que no hay una entrada en Wikipedia sobre el mismo. Devops plantea solucionar los problemas a que nos enfrentamos constantemente en los ambientes de desarrollo y operación. Devops es un concepto paraguas que involucra cualquier intención de mejorar los procesos actuales de desarrollo de software, facilitando las interacciones entre desarrollo y operaciones. Es una propuesta bottom-up (las mejores que existen) de experimentados administradores de sistemas que saben que los desarrolladores, testers, managers, técnicos de redes y administradores de sistemas son parte de un equipo con un solo objetivo: proporcionar a los clientes un software competitivo, seguro y de gran calidad. Devops quiere ser el nuevo paradigma de desarrollo de aplicaciones cambiando el modelo actual, reactivo, centrado en procesos operacionales (ITIL es uno de ellos) a un nuevo modelo ágil y automatizado. Devops quiere alinear los objetivos de los desarrolladores y operadores para que ambos trabajen como equipo quitando barreras y alentando la comunicación.

Que tiene que ver Devops con la nube?

Como ya saben, en la nube la aplicación es rey. En el pasado, la unidad de despliegue en el Data Center era el servidor, con un OS especifico para una o varias aplicaciones, se conectaba a la red y se le asignaba una dirección IP. Antes la aplicación era secundaria. Ahora, y gracias a la virtualización, se crean servidores específicos para cada aplicación. Que importa si el sistema operativo es Linux o Windows, si puedo virtualizar servidores sobre el hardware que cumplan los requisitos de la aplicación.

Si la virtualización permite desarrollar servidores a la medida del software ¿no deberían los desarrolladores definir especificaciones para las maquinas donde se ejecutará el software? Es más, ¿estas especificaciones no podrían definirse de manera semiautomática y enviarlas instantáneamente al proveedor de nubes? ¿Acaso todo esto no implica una revolución en los perfiles del personal técnico de las compañías o de sus procesos de desarrollo de software?

Beneficios e inconvenientes que el nuevo paradigma traerá a los negocios

Los negocios se beneficiarán de Devops porque la nueva filosofía de desarrollo asiste a dos de las cualidades estratégicas más poderosas y deseadas por los negocios. La agilidad de negocio y el alineamiento IT. Devops alinea los objetivos del personal de desarrollo y operaciones con los objetivos del negocio. Las empresas se beneficiarán de esta nueva filosofía porque los equipos de desarrollo y operaciones estarán involucrados y facultados para obtener los mismos objetivos de la compañía.

Pero, ¿Cómo gestionar esta nueva filosofía de desarrollo? ¿Hay alguna metodología ya definida? El movimiento es muy reciente para tener parámetros bien definidos. Existen herramientas de gestión que ayudan a los managers y desarrolladores a la hora de agilizar el desarrollo. La familia de metodologías de desarrollo ágil de software ha intentado vencer la resistencia y burocracia de otros métodos, es más, la popularización de la misma es uno de los catalizadores que han hecho germinar el movimiento Devops. Lo que hace falta a esta metodología es saltar la brecha entre desarrollo y operaciones. El post de Robert Dempsey, uno de los padres del movimiento Devops, expresa exactamente esta idea. Aplicar este nuevo modelo significa cambiar la cultura y sistema de compensación de una empresa. Tarea que nunca es fácil pero necesaria si quiere beneficiarse del nuevo método de desarrollo e implementación.

Siendo manager o director ¿Cómo puedo comenzar a utilizar esta metodología?

Como manager de empresa IT, un primer paso, podría ser solicitar Devops, en vez de desarrolladores o administradores de sistemas. Este cambio de búsqueda deja claro que quieres gente comprometida con los objetivos de la empresa, capaces de ejercer múltiples funciones y la empresa es capaz de instruir a los empleados si requieren de alguna habilidad. Este primer paso puede ser el detonante del cambio de cultura de tu empresa IT. Un manager también debe de tomar en consideración qué cambios realizar en los parámetros de medición del performance de cada miembro del equipo. Lo que se cuantifica, influye e incentiva las conductas de los empleados. Comunica a los empleados qué parte fundamentan cumplen dentro del proceso de la empresa. El éxito de los individuos y grupos debe de ser medido de acuerdo al éxito de todo el ciclo de proceso e implementación.

Otro paso importante es unificar y automatizar los procesos. El método Devops analiza todo el ciclo desarrollo/implementación como uno solo. Procesos individuales pueden ser usados en cada fase, como desarrollo ágil de software en la fase de codificación o Visible Ops en la fase de operaciones, pero de manera que los dos procesos individuales puedan ser gestionado como uno solo.

Herramientas de control de versiones de software que permita compartir, documentar y mantener al día los desarrollos ya son disponibles y conocidas por todos; solo hace falta cambiar la mentalidad y permitir que todos los miembros involucrados en el ciclo de desarrollo y operación puedan leer y cambiar elementos si es necesario y de acuerdo a políticas de acceso. Actualmente existen grupos de trabajos creando herramientas que sirven para el desarrollo y operación de aplicaciones de forma unificada. Puppet, Chef o Cucumber Nagios son algunas de ellas. Frases como infraestructuras como código, modelos impulsados por automatización e implementación continua serán escuchadas dentro de poco en la jerga de los Devops.

Fuentes

Si desean saber más del movimiento Devops les aconsejo que accedan a los blogs, páginas web de los Devops, pero si desean estar al tanto de todo lo que pasa en el mundo Devops sigan a los gurús del tema en Twitter. Para finalizar les dejo una lista de fuentes:

DevopDays

http://www.devopsdays.org/

Patrick Debois Twitter: @patrickdebois

Damon Edwards
Twitter: @damonedwards

John Allspaw
Twitter: @allspaw

Lindsay Holmwood
Twitter: @auxesis

Andrew Shafer
Twitter: @littleidea


Paul Nasrat
Twitter: @nasrat


Mick Pollard
Twitter: @_lunix_

Robert Dempsey Twitter: @rdempsey

El negocio y la nube

La nube ha revolucionado el mundo de las telecomunicaciones. La invención de la nube posiblemente es uno de los mayores avances en la historia de la computación. La idea general de Cloud Computing es conocida por un gran número de profesionales del negocio de los sistemas de información pero desconocen las implicaciones técnicas y económicas que la nube puede tener en sus negocios. Antes de plantearse el cambio de paradigma hay que entender las implicaciones del cambio y los beneficios/riesgos del nuevo modelo. Mientras que las tecnologías mejoran constantemente gracias a las grande inversiones en investigación y desarrollo, no se invierte lo suficiente en entender las implicaciones que Cloud Computing tiene en los negocios. El documento titulado Cloud Computing – The Business Perspective provee de un análisis SWOT de la industria de la nube que quisiera compartir con ustedes. En el documento, el Doctor S. Bandyopadhyay identifica algunos de los inconvenientes que pueden afectar a los usuarios de la nube y también realiza recomendaciones para los gestores de nubes.

El National Institut of Standards and Technology (NIST) ofrece una definición de Cloud Computing muy completa . De acuerdo con dicho instituto, Cloud Computing es un modelo de servicio IT que permite acceder, por medio de Internet, bajo demanda a un conjunto de recursos compartidos (redes, servidores, espacio de disco, aplicaciones y servicios) con poco esfuerzo o interacción con el proveedor. La definición del NIST también describe unas características esenciales, modelos de servicio y de despliegue de Cloud Computing.

Muchos gestores de TI no quieren implementar una nube porque les preocupa la falta de control directa sobre la infraestructura, o peor aun sobre la información soportada en la misma. Pero no solo este problema les genera ansiedad; la posibilidad de que los proveedores de Cloud Computing se encasillen en una tecnología propietaria que no permita migrar o cambiar de proveedor, la falta de QoS y disponibilidad garantizados y la posibilidad de un corte de servicio o perdida de datos por razones de malfuncionamiento, desastres naturales, o incluso ataques terroristas en las instalaciones del proveedor son las peores pesadillas de los agentes del sector empresarial.

Pero la nube no es tan negra como los directores temen. Cloud Computing ofrece una gran cantidad de beneficios como es la ubicuidad de los recursos, la indudable reducción de CAPEX en plataformas IT/IS, la reducción de barreras técnicas y económicas para Pymes, el incremento de la escalabilidad de las plataformas IT/IS, y la creación de nuevos servicios y aplicaciones que antes de la nube no eran posibles (como lo pueden ser Facebook, Dropbox, Gmail, Mint, etc).

Análisis SWOT

Fortalezas

• La nube permite de forma casi instantánea y bajo demanda escalar recursos computacionales. En industrias con requerimientos temporales esta ventaja puede ser invaluable.

• Actualmente las capacidades de los servidores y demás elementos TI están infrautilizados, lo que hace difícil justificar financieramente la adquisición de nuevo hardware. Cloud Computing ofrece una alternativa real a este problema.

• La posibilidad de pre-configurar servidores y maquinas virtuales según las políticas de TI de la empresa reducen los costos de gestión TI significantemente.

Debilidades

• La falta de garantías de QoS y disponibilidad genera desconfianza a la hora de migrar aplicaciones criticas a la nube. 99,95% de disponibilidad al año puede no ser suficiente para las aplicaciones ERP de McDonalds.

Oportunidades

• Cloud Computing puede ayudar a los países en vías de desarrollo a disfrutar los beneficios de las tecnologías de información.

• Las Pymes pueden beneficiarse de aplicaciones como ERP y CRM que de otra manera no podrían acceder por costes o inexperiencia técnica.

• La oportunidad de crear y configurar nuevas Mashups es inigualable.

Amenazas

• Aunque el articulo del Doctor S. Bandyopadhyay describe como oportunidad la reducción de CO2 gracias a los servicios de la nube, Greenpeace ha publicado un articulo titulado Make IT Green: Cloud computing and its contribution to climate change que critica el excesivo uso de energías no renovables en los Data Centers. Considero que la critica de una ONG de gran visibilidad, como Greenpeace, es una amenaza para las compañías que quieran utilizar el modelo de tecnología de información propuesto por la nube.

• Existe el riesgo, de que compañías incumbentes no permitan el desarrollo de la nueva tecnología disruptiva. Esta demostrado que la gente se resiste al cambio, y para bien o para mal los departamentos de TI de las empresas pueden tener reticencias a la hora de implementar la nube dentro de sus soluciones.

• La falta de estándares de la nube a forzado a la ISO crear el subcomité de Servicios y Plataformas de Aplicaciones Distribuidas (DAPS de sus siglas en inglés) . Existen un gran número de organizaciones privadas que buscan armonizar las soluciones de Cloud Computing pero el riesgo es cierto y persistente.

• La legislación vigente puede complicar la implementación de la nube. Leyes como la famosa Sarbanes-Oxley exige que datos sensibles sean físicamente accesibles puede implicar que un negocio falle a la hora de pasar una auditoria si tienen sus datos en la nube.

Recomendaciones

Quisiera terminar mi post con algunas de las recomendaciones para los negocios que quieran implementar las soluciones de la nube:

1. Elegir que aplicaciones pueden ser migradas a la nube. Aplicaciones de colaboración y ofimática son candidatas perfectas para penetrar la nube primero. Cuidado con aplicaciones legacy, aplicaciones desarrolladas in-house o alguna aplicación de terceros que puedan complicar su implementación en la nube.

2. Es fácil entender porque las Pymes deben comenzar a desplegar sus soluciones en la red. Los beneficios económicos y técnicos son muchos para resistir el cambio. A la hora de hablar de grandes empresas la recomendación no es tan sencilla. Si quieres que tu empresa mueva servicios a la nube ten en cuenta las implicaciones de los SLAs.

3. Los proveedores de nubes deben de considerar las necesidades e intereses de sus clientes en vez de desarrollar aplicaciones porque si.

4. Los proveedores de nubes deben de seguir invirtiendo tiempo y dinero para promover la interoperabilidad de sus propuestas. Los clientes de las nubes quieren saber que van poder migrar sus servicios en cualquier momento y con las más altas garantías de éxito.