A medida que las organizaciones recurren a DevOps para el desarrollo, la entrega y la integración continuos de las funciones empresariales, un control riguroso es crucial.
Las organizaciones están pasando del desarrollo de software tradicional en cascada, donde el código se produce en periodos definidos y se combina con la gestión de sistemas operativos y la gestión de aplicaciones, a enfoques más ágiles.
Ante la creciente necesidad de un aprovisionamiento funcional rápido mediante la integración continua, el desarrollo continuo y la entrega continua, muchas empresas buscan adoptar un proceso DevOps.
DevOps busca reunir a los equipos de desarrollo, pruebas y operaciones para optimizar el flujo de código y aplicaciones funcionales a través de estas tres áreas.
Sin embargo, el proceso requiere un alto nivel de control con los mecanismos de retroalimentación adecuados para garantizar que todo funcione sin problemas, logrando el mayor beneficio para la empresa con el menor impacto negativo.
Transición liderada por los desarrolladores
El problema para las organizaciones es que DevOps está creciendo rápidamente, y lo hace de abajo hacia arriba, en lugar de ser controlado de arriba hacia abajo.
Muchas herramientas DevOps están disponibles como software de código abierto; no hay obstáculos para que un individuo en una organización descargue una herramienta que le resulte atractiva y comience a usarla.
Para muchos empleados de desarrollo u operaciones, esta es una oportunidad demasiado buena para rechazarla. Los desarrolladores han estado buscando sistemas derivados que puedan integrar en sus entornos de desarrollo integrados (IDE) existentes, ya sean sistemas comerciales como IBM Rational Software Architect o Microsoft Visual Studio, o sistemas de código abierto como Eclipse o Anjuta, o software de gestión de proyectos de software como Atlassian Jira Software o CA PPM.
Esto ha llevado a un mayor uso de [herramientas como Jenkins](https://searchitoperations.techtarget.com/tip/Secure-Jenkins-for-fast-and-safe-app-deliveryChef y Puppet son utilizados por desarrolladores y personal de operaciones. Jenkins proporciona un conjunto automatizado de procesos que gestiona el versionado del software, con complementos para integrar herramientas de versionado existentes como Perforce, CVS, Subversion, Git y Accurev, además de procesos optimizados para la entrega continua. Chef y Puppet se centraron inicialmente en la parte operativa de DevOps, utilizando principios de gestión de configuración para crear paquetes funcionales que luego se implementan automáticamente en el entorno operativo.
Opciones en expansión
Las capacidades de estas herramientas han mejorado considerablemente desde su lanzamiento al mercado en 2005 (Puppet), 2009 (Chef) y 2011 (Jenkins, que fue esencialmente una continuación del trabajo realizado en el proyecto Hudson, iniciado por Sun en 2004 y ahora propiedad de Oracle).
Sus capacidades se complementan mucho más que hace tan solo un par de años, y la necesidad de incorporar otras herramientas específicas para crear un entorno DevOps completo es menor que antes.
El mayor soporte para el trabajo en equipo y los ciclos de retroalimentación completos significan que lo que comenzó esencialmente como herramientas puntuales para individuos ahora brinda soporte completo a grupos, incluso en sitios distribuidos y grupos que trabajan en diferentes empresas, como contratistas y consultores.
Junto a estos tres gigantes, existen otras herramientas disponibles bajo diversas licencias de código abierto que se ajustan al mismo ámbito, como Ansible y Salt, así como herramientas integradas en sistemas de gestión de software de contenedores como Docker y Kubernetes. Para un enfoque integrado con Ubuntu y con soporte empresarial, Canonical ofrece su propia distribución de **[Kubernetes a través de JuJu](https://www.computerweekly.com/blog/Open-Source-Insider/AppScale-FastStart-for-Google-Compute-Engine-AWSKubernetes se está consolidando rápidamente como una fuerza importante en la orquestación de contenedores, integrable en entornos DevOps. Cuenta con el respaldo de la Cloud Native Computing Foundation (CNCF), cuyos miembros incluyen a empresas como Amazon Web Services (AWS), Google, Microsoft, IBM, Intel, Twitter y otras.
Cloud Foundry es otro sistema de código abierto, también disponible comercialmente, al igual que la mayoría de las herramientas mencionadas. Ofrece capacidades de automatización que se adaptan perfectamente a DevOps, brindando un alto nivel de soporte para otros sistemas, tanto ascendentes como descendentes. Si bien Cloud Foundry también forma parte de la CNCF, comparte algunas funcionalidades con Kubernetes, pero su alcance es mucho mayor, ya que va más allá de los entornos de contenedores. Un proyecto independiente dentro de Cloud Foundry, llamado KuBo (Kubernetes on BOSH), proporciona una pila integrada de Cloud Foundry/Kubernetes para quienes trabajan con código de aplicación heterogéneo, máquinas virtuales (VM) o entornos de contenedores.
Demasiadas herramientas
Lidiar con una situación en la que desarrolladores y administradores de sistemas utilizan herramientas diferentes, lo que resulta en una mezcla de distintas herramientas en todo el entorno de TI, puede convertirse en un problema para las organizaciones. Esto se puede abordar de dos maneras.
Primero, ser estricto: Decidir qué conjunto de herramientas usar y establecer reglas: todos los desarrolladores y administradores de sistemas deben usar el mismo conjunto. Desafortunadamente, esto está prácticamente condenado al fracaso; recuerde que está tratando con desarrolladores y administradores de sistemas. Mire en el cajón superior de su escritorio y verá la cantidad de CD y memorias USB con software no autorizado que les resulta útil en su día a día. Puede que parezcan estar de acuerdo con usted sobre la necesidad de una sola herramienta, pero es muy probable que luego continúen usando sus propias herramientas cuando usted ya no los esté supervisando.
Las organizaciones caen entonces en la autosuficiencia: después de haber dado instrucciones a todos para que hagan lo que se les dice, dan por sentado que así es. Entonces algo falla, y el análisis posterior al incidente revela los problemas: funcionalidades aisladas sin una supervisión centralizada.
En segundo lugar, hay que ser pragmático: aceptar que ya es demasiado tarde para revertir la situación y encontrar una manera de transformar una mezcla caótica de herramientas de uso individual en algo más apto para entornos empresariales.
Muchas herramientas de código abierto, gracias al uso cada vez mayor de complementos o de interfaces de programación de aplicaciones (API) abiertas, pueden integrarse con otras herramientas de código abierto con un nivel de precisión aceptable.
Cuando se requiere un mayor control, junto con soporte empresarial completo, una suscripción con soporte integral a una de las distribuciones de software de código abierto —como CloudBees, con su compatibilidad con Jenkins y sus componentes adicionales— puede proporcionar la funcionalidad empresarial que buscan las organizaciones.
Los sistemas abiertos ofrecen longevidad
Además, existen sistemas comerciales que permiten un buen grado de apertura para dar soporte a las herramientas existentes. Un ejemplo es CA Automic, que ofrece un buen enfoque automatizado para la optimización de los procesos DevOps, al tiempo que acepta diferentes herramientas subyacentes de forma abierta.
La capacidad de estos sistemas para permitir el intercambio de diferentes herramientas subyacentes es un punto clave: hace cinco años, no mucha gente hablaba de **[Chef y Puppet](https://searchitoperations.techtarget.com/tip/How-the-Puppet-architecture-manipulates-configurationsKubernetes se lanzó hace tan solo tres años. ¿Cómo será el mercado dentro de cinco años? Si el sistema general es cerrado y está vinculado a herramientas específicas, podrías quedarte atrás. Si es abierto y permite la integración y desconexión de herramientas, podrás adoptar nuevas herramientas a medida que vayan surgiendo.
Existen muchas otras empresas que operan en el ámbito de DevOps. Por ejemplo, HashiCorp cuenta con varias herramientas, como Terraform y Vagrant, que simplifican la gestión de un entorno DevOps. Perforce se ha diversificado más allá de su enfoque principal en el control de versiones y ha lanzado su portafolio de herramientas Helix, que ofrece una amplia gama de funciones DevOps.
En el mundo del software de gestión de configuración de sistemas tradicionales, BMC ofrece su suite de automatización BladeLogic. Modernizada para integrar la computación en la nube y los contenedores, BladeLogic Server Automation, especialmente al combinarse con otros productos de BMC, como Atrium Orchestrator, Control-M Automation y el portafolio TrueSight, puede proporcionar funcionalidades DevOps. La infraestructura componible de HPE salva la brecha entre hardware y software, permitiendo configurar fácilmente plataformas lógicas y aprovisionar software físico, virtualizado o en contenedores mediante OneView.
Por supuesto, también existen opciones de DevOps en la nube. IBM ofrece un amplio conjunto de funcionalidades a través de su plataforma BlueMix. AWS, Google y Microsoft ofrecen herramientas directamente en sus plataformas, mientras que muchas de las herramientas ya mencionadas están disponibles para su implementación mediante autoservicio en sus plataformas en la nube.
DevOps se está convirtiendo en un medio fundamental para proporcionar a las empresas lo que desean y necesitan: desarrollo continuo de nuevas funcionalidades que se pueden entregar rápidamente según sea necesario. Cabe destacar que debería denominarse «BusDevOps»; estas necesidades y deseos deben ser definidos por la empresa, no por los desarrolladores.
Para aprovechar al máximo un entorno BusDevOps, se requieren herramientas rigurosas, y es improbable que esto se logre mediante reglas prescriptivas o restrictivas. Sea pragmático: proporcione sistemas generales que pongan orden en el caos existente y permitan a los desarrolladores y administradores de sistemas trabajar de la manera que les resulte más conveniente.
Fuente: https://www.computerweekly.com
