DevOps un primer vistazo

Operaciones

En 2012, Adrian Cockcroft, Cloud architect de Netflix publica un artículo en su blog “Ops, DevOps and PaaS (NoOps) at Netflix”, o como su equipo en Netflix trabaja sin necesidad de contar con operaciones.

NoOps no significa que “operaciones” deja de existir, las responsabilidades siguen estando, no importa como se las llame, el trabajo debe ser realizado y eso incluye operaciones, porque NoOps es un movimiento para reemplazar operaciones con algo que se parece sospechosamente a operaciones.

La llegada de las computadoras personales en los 70’s y los 80’s creo una barrera entre los operadores del mainframe y los usuarios, creando los administradores de sistemas y redes de los 80’s y los 90’s, así es como concebimos las Operaciones de IT modernas.

La gran muralla de IT

Las empresas y los datacenters crecen todo el tiempo, no solo hay que desarrollar, hay que mantener la infraestructura corriendo, incluidas aplicaciones y websites, y la mentalidad de bombero de muchos sysadmins no cambia. Cuando la infraestructura de la compañía funcionaba en un 386, usar scripts mágicos era la forma adecuada de arreglar los problemas, pero en el mundo de IT actual, no funciona cuando la empresa tiene 200 nodos en Amazon o Rackspace.

Para un dev la evolución de internet fue pasar de páginas web simples a aplicaciones completas en el browser, para un sysadmin la evolución del internet fue pasar de administrar un servidor a administrar cientos o miles de nodos en la nube. Cuando hablamos de infraestructura a esa escala, resolver problemas desde la linea de comandos no es la mejor opción, más cuando las exigencias del negocio son “necesito 125 servidores en linea lo antes posible”, y no hay tiempo de automatizar nada.

Comenzamos a hablar de “Infrestructure as code”, donde no existen más máquinas físicas, entre más nos movemos lejos del hardware y las redes traicionales hacia la virtualización de todo, el viejo estilo de los sysadmins deja de tener validez. Si se van a hacer operaciones de forma confiable, se necesita que sea un un proceso reproducible y programático, es necesario poder saber con seguridad que cada máquina tiene el mismo software, con la misma configuración y tiene corriendo los servicios que necesitamos. En este nuevo mundo de IT si los sysamdins no están escribiendo código para gestionar sus servidores, no van a sobrevivir, la única forma efectiva de manejar esta nueva realidad es a través de software.

Un buen sysadmin siempre supo que automatizar era un componente importante de su trabajo, y hoy en día la automatizaión es mucho más importante. En este nuevo entorno, un sysadmin no necesita apagar una máquina, reemplazar un disco defectuoso, rebootear, instalar y recuperar todo desde un backup, ahora necesitamos sysadmins que escriban software que detecte automáticamente una instancia de EC2 que este fallando o puede llegar a fallar, cree una nueva instancia, la configure y la ponga a funcionar sin interrumpir el servicio. Con este nivel de automatización, la gente de operaciones se puede hacer cargo de 10, 50, 100 o miles de servidores.

Las nuevas aplicaciones, en su gran mayoría corriendo en la nube, necesitan ser resistentes y tolerantes a fallos, deben ser monitoreadas, deben adaptarse a la carga de requests. Todas esas caracteríticas que antes nos daba infraestructura, ahora deben ser parte de la aplicación, sobre todo dentro de ambientes “platform as a service”. Operaciones no desaparece, pasa a ser parte de desarrollo, y antes que buscar el “developer supremo”, que entienda de big data, web performance, optimización, aplicaciones middleware, software con tolerancia a fallos en un medio ambiente distribuido masivo, necesitamos equipos de operaciones dentro de los equipos de desarrollo. Los nuevos sysadmins deben escribir código para mantener esa infraestructura y cooperar con los equipos de desarrollo que crean esas aplicaciones en vez de aislarse, esto es lo que conocemos como DevOps.

El outage de Amazon EBS (Elastic Block Store)

Es viernes 13 de septiembre de 2013, 7.04 AM hora del pacífico y Amazon informa de que están investigando una degradación en su plataforma EBS, específicamente en la region US-EAST-1. Un error de configuración tira abajo GitHub y Heroku entre otros. Este es un claro ejemplo de la nueva naturaleza de “operaciones”, y existió una marcada diferencia entre las empresas que perdieron dinero y las que pudieron superar el problema. Entre las empresas que supieron responder al problema estuvo Netflix, que sabe como diseñar aplicaciones confiables, entienden que su aplicación debe ser resistente pero flexible, distribuyeron la aplicación entre distintas regiones y pusieron un montón más de ingeniería que permite a Netflix trabajar con confianza en sus sistemas. Netflix entiende que la solides y resistencia debe ser una propiedad de la aplicación, y trabajan entre gente de desarrollo y operaciones para asegurarse que la aplicación sobreviva cuando una parte de la red se cae.

Netflix usa una herramienta propia, Chaos Monkey, que mata de forma aleatoria instancias y servicios de la aplicación. Es una forma excelente, pero extrema de asegurar que una aplicación compleja y distribuida puede sobrevivir caidas. El equipo de desarrollo y de operaciones trabaja en conjunto para asegurarse que la aplicación es suficientemente robusta y que se pueden tener interrupciones en servicios y redes sin degradar el servicio.

Por otro lado, durante la caida de Amazon, nadie fuera de los empleados de Amazon tocó una sola pieza de hardware, lo que significa que nadie de IT de las empresas afectadas estuvo corriendo como loco tratando de resolver problemas.

Vamos a los números

Además de la redistribución de responsabilidades detnro del equipo, desde la primera capa del stack hasta la aplicación misma, también vemos una distribución en los costos. Es un error pensar que los costos de operaciones van a desaparecer, el costo de servidores va a ser reemplazado por pagos mensuales a Amazon, pero van a seguir existiendo. Algunas tareas tradicionales de IT van a seguir existiendo, pero muchos de los sysadmis comenzaran a moverse a los equipos de desarrollo, y esos costos no desaparecen, sino que cambian de lugar en la empresa.

El objetivo

El objetivo de proveer al usuario final una aplicación solida y estable sigue siendo el mismo, el lugar físico donde corre la aplicación, y como es administrada es lo que cambia. Una de las tareas más importantes de operaciones es entender el costo de canje entre mantener infraestructura in house y contratar servicios de terceros como Amazon o Rackspace.

Costos versus flexibilidad es un cambio importante, escalar es costoso y lento cuando se administra infraestructura in house, escalar para los picos de uso mientras el hardware está subutilizado la mayor parte del tiempo. Las compañías chicas y medianas están optando por una estratégia hibrida con parte de la infraestructura in house, parte en la nube púbica y parte en compañías de hosting privadas. Optimizar las tareas que deben ser distribuidas entre esta infraestructura no es algo simple, ese es el desafío de los nuevos equipos de operaciones. Desarrolalr aplicaciones que funcionen de forma efectiva en ambientes hibridos, esa es la responsabilidad de los desarrolladores, con cooperación del equipo de operaciones.

Metricas

El uso de métricas para monitorear la performance de las aplicaciones es algo fundamental y necesario para la evolución de operaciones a DevOps. En operaciones de los 80’s y 90’s sabíamos que un sistema estaba caido, porque comenzaba a sonar el teléfono sin sesar. Usabamos herramientas como dtrace que nos daban una visión de casi cada aspecto del sistema, el desafío ahora es generar herramientas de monitoreo que nos den métricas y poder usar esas métricas de forma predictiva. Entre más dependamos de nuestros sistemas distribuidos, más necesario se hace monitorearlos, tener PI’s y KPI’s que nos ayuden a tomar decisiones.

El exito de DevOps

El exito de operaciones es crucial, pero solo se puede lograr cooperando con desarrollo y participando en el desarrollo de las aplicaciones, las que deben monitorearse a si mismas. DevOps es un modelo de trabajo que se basa por completo en la integración de operacines dentro de desarrollo, y es importante que los desarrolladores tomen conciencia de las consecuencias de su trabajo, porque por lo general su código es el que desata incendios.

Compartir responsabilidades tiene otro beneficio, en vez de apuntar con el dedo en los post-mortem donde se trata de averiguar si el problema fue código o errores operacionales, cuando desarrollo y operaciones trabaja en conjunto, los post-mortem pueden enfocarse en encontrar soluciones y aprender de los errores para desarrollar aplicaciones robustas y estables.

En vez de culpar y generar procesos para que mal código no vuelva a producción nuevamente, el equipo debe diseñar sistemas que tengan poder de recuperación en los errores del día a día, inclusive cuando ocurrar en combinaciones impredecibles.

En la era de las aplicaciones web y moviles, el pasaje a producción no es doloroso como era antes. Podemos llevar código a producción de forma agil, movernos de integración continua a despliegue continuo.

Todos estos cambios requieren cooperación y colaboración entre el equipo de desarrollo y el equipo de operaciones.

Aún estamos aprendiendo como monitorear los sistemas, como analizar los datos generados y como construir tableros de control que nos permitan tener un panorama que nos ayude a tomar decisiones, que le permita a la aplicación tomar decisiones. La cantidad de información que podemos capturar es tremenda, y va mucho más allá de lo que un ser humano puede procesar y analizar sin la ayuda de machine learning.