¿Qué es DevOps?

“DevOps”, como un término, no tiene una definición realmente concreta. Es una filosofía, una forma de trabajar, y significa cosas diferentes para diferentes personas. En su mayor parte, la comunidad DevOps generalmente acepta la definición del artículo de DevOps en Wikipedia, que en parte dice:

… un método de desarrollo de software que hace hincapié en la comunicación, la colaboración, la integración, la automatización y la medición de la cooperación entre los desarrolladores de software y otros profesionales de las tecnologías de la información (TI).

Personalmente no siento que la definición sea mala. DevOps es mucho más que un “método de desarrollo de software”. Sin embargo, vamos a jugar por un momento, y a reconocer que el software gobierna el mundo. El presidente de los Estados Unidos no se puso de pie y dijo, “todos deben aprender de redes”, él dijo, “todo el mundo debe aprender a programar”. Internet es enorme, es un conjunto de ingeniería impresionante, de infraestructuras de redes como nunca se había visto, pero es en su mayor parte una tubería “tonta” utilizada para entregar software. Software es de lo que se trata. Pero el software no llega a ninguna parte solo, ni hace nada, sin una infraestructura que lo soporte. Ambos (software e infraestructura) trabajan juntos, y son lo que hace que la tecnología sea útil. Es por eso que DevOps comprende tanto “Desarrollo” como “Operaciones”. Así que, para este libro, me gustaría tomarme la libertad de volver a definir ligeramente a DevOps como:

… un enfoque de la gestión de la tecnología que hace hincapié en la comunicación, la colaboración, la integración, la automatización y la medición de la cooperación entre los desarrolladores de software y el personal de operaciones de TI con el fin de crear y entregar aplicaciones de software a sus usuarios.

Es importante comprender que DevOps es una cosa tan grande que es casi imposible verlo todo a la vez. Se trata de numerosas técnicas, múltiples funciones dentro de una organización (es por eso que la “cooperación” está en la descripción, junto con “colaboración”), y un montón de tecnologías que se cruzan. Pero no se preocupe. Este libro no va a tratar de cubrir todos esos aspectos..

Algunos Antecedentes

El término “DevOps” probablemente fue acuñado por Patrick Dubois, inspirado en una presentación de Velocity en 2009 de John Allspaw. Filosóficamente, está inspirado en gran parte por las enseñanzas de “Lean Manufacturing” de luminarias como W. E. Deming, Taiichi Ono, Eli Goldratt y otros. Eso es importante, porque esos señores basaron sus pensamientos en la premisa de que la mayoría de los trabajadores quieren hacer un buen trabajo. Un hilo común en Lean Manufacturing - y de hecho un punto específico del enfoque de Deming - era poner fin a la confianza en “QA” como un medio para lograr la calidad. Sí, usted establece las medidas adecuadas para ayudar a la gente a prevenir sus propios errores, pero olvida poner las “puertas”, resultará asumiendo que sus trabajadores son maliciosos o incompetentes. Ese principio a menudo se convierte en el mayor obstáculo en la adopción de Lean Manufacturing, DevOps, o cualquier otra cosa que derive de ese principio.

DevOps, para Ops

En su lugar, este libro examinará el microcosmos de DevOps relacionado más específicamente con la parte Ops. En cualquier organización que intente implementar un enfoque de DevOps, el lado operativo de la casa necesita de ciertas capacidades. En muchos casos, la parte operativa de la organización debe proporcionar un nivel de automatización y una especie de autoservicio, que le permita al departamento de desarrollo abstraerse de toda intervención operativa. Las operaciones a este respecto tienen que ver con la implementación de métodos seguros, manejables y monitorizables que permitan la liberación de software de manera rápida, sin que los proyectos se conviertan en una carga operativa importante. Exactamente cómo se procede, y qué capacidades se proporcionan, variará grandemente dependiendo de cada organización.

Para proporcionar esas capacidades, Operaciones tendrá que promover una cierta cantidad de desarrollo de software, de tal manera que se creen unidades de automatización que hagan que el lado de Operaciones de la organización funcione de manera más independiente. Esos esfuerzos de desarrollo de software pueden llevarse a cabo de una manera muy centrada en DevOps, y este libro se centrará en gran medida en esa actividad.

Es una Filosofía

DevOps se parece a la contabilidad, en que es un conjunto de principios abstractos, enfoques y patrones. En la contabilidad, se tienen prácticas contables generalmente aceptadas, o GAAP. No son reglas, per se, pero son tan generalmente aceptadas que llevan el peso de la ley de muchas maneras. DevOps es o puede llegar a ser así, ya que puede incorporar un conjunto de prácticas y enfoques que generalmente se reconocen como el mejor camino a seguir. Contabilidad también tiene herramientas que le ayudan a implementar sus prácticas. QuickBooks, por ejemplo, es un paquete de software que encarna y hace cumplir una gran cantidad de prácticas contables, por lo que es más fácil ponerlas en práctica en su organización. Del mismo modo, el mundo de DevOps tiene una serie de herramientas - muchas aún por nacer por lo que DevOps es relativamente nuevo - que le ayudan a implementar prácticas y enfoques de DevOps. A medida que el mundo de DevOps intenta cosas, aprende de ellas y perfecciona sus enfoques, así que podrá encontrar más y más herramientas creadas para ayudar a hacer esos enfoques más fáciles y más consistentes de aplicar en el mundo real. En este libro, nos centraremos mucho más en las prácticas y patrones que en las herramientas, de modo que podamos permanecer en un nivel superior y no forzarle a comprometerse con una pila de tecnología en particular.

A diferencia de la contabilidad, y como ya he mencionado, DevOps es relativamente nuevo. Y, a diferencia de la contabilidad, DevOps vive en un campo que está en constante evolución y cambio. Así que no espere cosas como, “aquí está lo que debe hacer” o reglas y regulaciones. En su lugar, la práctica de DevOps es actualmente el 80% de la teoría, el 10% lo que la gente ha experimentado hasta el momento, y el 10% pura conjetura. Hay un montón de empresas experimentando con los enfoques de DevOps, por lo que es una industria todavía estamos descubriendo. Gran parte de este libro se centrará en lo que se ha hecho con éxito en otros lugares, y buscará concretamente lo que las Operaciones ofrecen en esas situaciones.

Es un enfoque

Entender sobre todo que DevOps es un enfoque de gestión de la tecnología. Sugiere maneras de gestionar proyectos, maneras de gestionar el desarrollo de software y maneras de gestionar las operaciones. Dicho esto, sin la administración de buy-in en su organización, no se puede hacer DevOps. Así que, si usted está pensando, “bueno, en mi organización nunca vamos a apoyar la idea de que los desarrolladores “empujen” el código directo a producción”, entonces puede dejar de leer ahora mismo, a menos que esté interesado por curiosidad. Este libro, al menos, no va a intentar convencerlo de las ventajas de DevOps – eso ya se ha hecho en otros libros. Este libro supone que ya ha aceptado los beneficios de DevOps y que está interesado en profundizar un poco más en lo que eso significa para un equipo de operaciones de TI tradicional..

No hay tal cosa como un equipo de DevOps

Y seamos muy, muy claros: usted no puede tener un “Equipo de DevOps” en su organización. Eso es absurdo. DevOps es un enfoque de gestión que abarca el desarrollo de software, administradores y operaciones como una sola unidad. Todos trabajan juntos para facilitar la creación y el despliegue de aplicaciones. Es posible que sólo uno de los muchos proyectos internos se llevará a cabo en una forma DevOps - pero dado el tipo de cambios que Ops tendrá que hacer para facilitar el enfoque de DevOps, va a ser difícil de “hacer” DevOps de forma fragmentada. Sólo tenga en cuenta que - DevOps trata sobre cómo cambiar la forma de hacer negocios Si no se siente a gusto con esta idea, entonces siempre va a sentir algo de miedo

Puede tener equipos o proyectos específicos dentro de su organización que actúen de una manera DevOps, siempre y cuando el equipo sea lo suficientemente funcional para proporcionar todas las disciplinas de Dev, Test, Ops, etc., que sean necesarias. Así que la totalidad de la propiedad de TI no necesita “aplicar DevOps”, pero un proyecto individual si podría. Dicho esto, tener sólo un proyecto ejecutado en una “froma DevOps” puede no ser conveniente, porque en algún momento va a ir en contra de su “operaciones normales de TI”, y los dos podrían no llevarse bien.

Por lo tanto, podría tener equipos que se comportan de acuerdo a los principios de DevOps, y se puede llamar un “equipo de DevOps” si sólo tiene uno. Pero es incorrecto pensar que DevOps es implementado por algún equipo dedicado a las “implementaciones de DevOps”. Es importante distinguir que “el equipo que maneja DevOps para nosotros”, que no es lo mismo que “un equipo que se comporta de acuerdo con DevOps”. Esa es una línea super-fina, tal vez, pero es una distinción importante.

Lo que no es DevOps

Teniendo en cuenta que DevOps es una filosofía … un enfoque de gestión … y la combinación de múltiples disciplinas de TI … podría ser más fácil ver rápidamente lo que no es.

• DevOps no es ágil. Dicho esto, sus equipos podrían utilizar Agile como una metodología de desarrollo dentro de un enfoque global de estilo DevOps. Agile es ciertamente compatible con DevOps, y, al igual que DevOps, valora la mejora continua.
• DevOps no es Integración Continua. Dicho esto, CI es a menudo una parte del comportamiento de estilo DevOps. Los dos pueden estar estrechamente relacionados, de hecho - tan cerca que es difícil distinguir la diferencia. Supongo que podría argumentar que es difícil practicar la filosofía de DevOps sin usar CI, pero definitivamente puede tener CI sin comportarse como una organización de DevOps, por lo que los dos no son exactamente lo mismo.
• DevOps no es “los desarrolladores que operan”. En todo caso, las operaciones están automatizadas hasta el punto en que se ejecutan en respuesta a las acciones autorizadas tomadas por otros roles, incluidos los desarrolladores.
• DevOps no es una metodología de desarrollo de software. Vea la primera viñeta, arriba. DevOps es lo que ocurre mientras el desarrollo del software está sucediendo, y en gran parte lo que sucede cuando se desarrolla el software (o un ciclo de él). Usted todavía necesitara administrar su proceso de desarrollo de software - solo necesita usar una metodología que sea compatible con DevOps.
• DevOps no es automatización. Sin embargo, no puede tener DevOps sin automatización. La automatización es quizás el mayor beneficio que operaciones recibe de DevOps.

Además, parece ser un objetivo no declarado evitar la creación de cualquier tipo de marca registrada DevOps, o del típico libro de reglas de “cómo hacer DevOps”, a la ITIL o TQM o algo así. Este libro ciertamente no intenta proveer “reglas”. El objetivo aquí es proporcionar una cierta comprensión de lo que son los objetivos generales de DevOps..