El término DevOps fue acuñado por Patrick Debois quien allá por 2009 organizó una serie de conferencias bajo el título DevOpsDays. El objetivo de estos eventos era incentivar una visión holística de la entrega de software derribando las barreras de la visión tradicional que separaban el desarrollo del software de su operación. A pesar que el término fue acuñando hace ya más de 5 años, creo que fue en los último 3 que tuvo un salto de popularidad potenciado entre otras cosas por herramientas como Chef, Puppet, Docker, y Vagrant y por prácticas como Infraestructura as Code, Test-Driven Infraestructure y Self-Service Provisioning.

Si bien la idea de DevOps aún hoy puede parecer novedosa para algunas organizaciones, para algunas otras siempre ha sido moneda corriente. Hablando más en concreto creo que DevOps suele resultar novedoso o incluso revolucionario para grandes organizaciones de tipo «tradicional» como bancos, telcos e incluso organismos gubernamentales. Al mismo tiempo me parece que es moneda común en organizaciones surgidas en la era de internet como .coms y startups.

Personalmente desde 2012 soy parte del equipo de Tipit, una empresa dedicada a brindar soluciones web y que adicionalmente cuenta con un conjunto de aplicaciones ofrecidas como servicio.
Tipit es una empresa chica pero que tiene bien claro que sus clientes pagan por el valor aportado al negocio y que en este contexto se traduce en software funcionando en manos del usuario. Dicho de otra forma, en términos de valor no existe la diferencia entre desarrollo y operación, la cuestión es blanco o negro: ¿está la funcionalidad lista para ser usada en un ambiente productivo o no?

Al igual que la mayoría de mis colegas en Tipit, yo trabajo tanto en tareas de desarrollo como en tareas de operaciones. Esto no implica que todos hagamos todo, todo el tiempo, sino que cada uno tiene un rol en cada proyecto pero más allá de ese rol particular que cada uno desempeña, todos somos responsables de que el software este disponible en manos del usuario cuando este lo necesite. Entre otras cosas esto requiere no dejar las cuestiones de operaciones para la última milla, sino tenerlas presentes en forma temprana, ya desde el momento del diseño de cada funcionalidad.