Fotolia

Lo básico Póngase al día con nuestro contenido introductorio.

¿Construir o comprar? Esa es la cuestión con las herramientas DevOps

Una organización debe evaluar sus fortalezas y debilidades antes de elegir una secuencia DevOps. Una cadena de herramientas prefabricada es más simple que las herramientas recopiladas individualmente, pero sacrifica la flexibilidad.

Sería mucho más fácil si simplemente pudiera comprar DevOps.

No hay promesa de gratificación instantánea con DevOps. Es una forma de pensar y un enfoque para el desarrollo de software y los procesos de lanzamiento, no una categoría de producto o certificación específica. Sin embargo, la pregunta más acuciante para muchos usuarios es cómo construir, o comprar, el sistema DevOps correcto.

Aunque las organizaciones de todas las industrias y prácticas de TI se adhieren a los principios y mejores prácticas de DevOps, los detalles de las cadenas de herramientas y los procesos de DevOps suelen ser idiosincrásicos. Hay más de una forma de implementar y automatizar el desarrollo, lanzamiento y soporte de aplicaciones, con una gran cantidad de preferencias simples por una herramienta u otra liderando el camino.

DevOps es una filosofía centrada en herramientas, según Gartner. Dado que DevOps está idealmente entrelazado con otros procesos de desarrollo de software y TI, es intrínsecamente resistente a la estandarización del conjunto de herramientas cortadas con molde. Un ecosistema vibrante de productos DevOps principalmente de código abierto está disponible para automatizar y optimizar aspectos de la secuencia de entrega de software. Algunas compañías venden cadenas de herramientas DevOps de extremo a extremo. ¿Qué significa eso de no poder comprar DevOps?

Una cadena de herramientas de DevOps prefabricada es atractiva porque elimina el trabajo para integrar herramientas discretas, particularmente proyectos de código abierto que requieren personalización DIY. Algunas organizaciones de TI, particularmente las nuevas en DevOps, desarrollo ágil y entrega continua, prefieren adaptarse a un flujo de trabajo obstinado definido por un producto en particular. El proveedor maneja la integración de la cadena de herramientas, por un precio. Incluso si el costo no es un impedimento, cualquier organización que ya tenga un flujo de procesos establecido y tácticas de gestión del ciclo de vida de las aplicaciones debe examinar con vehemencia este enfoque.

Una secuencia DevOps empresarial incorpora integración y entrega continua.

Conjuntos de herramientas DevOps gestionados por la nube

Una organización de TI que desarrolle aplicaciones en una plataforma prediseñada o en una pila de infraestructura como servicio probablemente se adaptará cómodamente a un proceso diseñado para esa plataforma como servicio (PaaS) o como configuración de IaaS. Cloud Foundry, Microsoft Azure App Service y Amazon Web Services (AWS) se encuentran entre las opciones para las empresas que desean que los servicios gestionados en la nube complementen o eludan muchos recursos de administración de TI.

AWS es un ejemplo con varios servicios que se dirigen a varios segmentos del ciclo de vida de desarrollo y cadena de herramientas DevOps. AWS CodeStar es un servicio en la nube destinado a simplificar la configuración del sistema de DevOps. Los usuarios desarrollan, crean y despliegan aplicaciones a través de un conjunto de plantillas de proyecto para servicios básicos de AWS, como Elastic Compute Cloud (EC2), Elastic Beanstalk y Lambda. Hay cinco lenguajes admitidos y varios entornos de desarrollo integrados (IDE) para elegir.

CodeStar proporciona un paraguas de administración de proyectos de software con una interfaz única para las herramientas de AWS. A través de plantillas de CodeStar, un usuario automatiza el aprovisionamiento de la infraestructura de la aplicación, por ejemplo, en EC2, y el aprovisionamiento de otros servicios de desarrollador de AWS. Reúne una gama de servicios:

  • El repositorio de códigos Git de CodeCommit;
  • CodeBuild para automatización de compilación y prueba;
  • CodePipeline para integración continua y entrega continua (CI/CD); y
  • CodeDeploy y CloudFormation para implementación de código e infraestructura.

CodeStar también impone roles y políticas de seguridad a través de Gestión de Acceso e Identidad de AWS, para que los miembros del equipo puedan unirse a un proyecto sin mayores intervenciones.

CodeStar solo es apropiado para proyectos que se dirigen a AWS, y esta es la elección clave de compra frente a construcción que enfrenta cualquier implementación de la cadena de herramientas DevOps: los productos bien integrados generalmente funcionan en una plataforma o metodología de desarrollo en particular. Los clientes de AWS que prefieren construir sus propias secuencias de DevOps sobre el producto en la nube pueden evitar el servicio.

CodeStar es solo un ejemplo de un proceso DevOps obstinado. Otro proviene de la pila PaaS de Cloud Foundry, que tiene uso en algunas de las empresas más grandes. La PaaS de Cloud Foundry viene con la utilidad de administración de infraestructura BOSH para ingeniería de lanzamiento de software, implementación y administración del ciclo de vida, incluyendo monitoreo, recuperación de fallas y actualizaciones de código. Los clientes de la nube de Microsoft pueden recurrir a Azure App Service para configurar un conducto de CI/CD en la suite de código, paquete, lanzamiento y herramientas de administración de proyecto Visual Studio Team Services (VSTS), que ya están integradas con los servicios en la nube e IDE del proveedor.

Grados de apertura en una cadena de herramientas DevOps personalizada

Las secuencias de DevOps empaquetadas no son completamente exclusivas y tienen formas de integrar un grupo selecto de herramientas de desarrollador compatibles, generalmente Git, e IDEs como Eclipse. Por ejemplo, AWS CodePipeline y CodeBuild pueden usar GitHub para activar la compilación de código, las pruebas y el empaquetado de implementación. Del mismo modo, CodeStar ofrece a los desarrolladores su elección de entornos de edición con conexiones a Eclipse y Microsoft Visual Studio, asegurando que los cambios de código se introduzcan automáticamente en un proyecto de CodeStar. Del mismo modo, la interfaz abierta de VSTS se basa en APIs de transferencia de estado representacional y HTML, JavaScript y CSS para conectarse con software de terceros. Esta extensibilidad ha engendrado un mercado VSTS de productos de desarrollo compatibles.

Cuando una organización de TI crea su secuencia DevOps desde cero, normalmente recurre a una herramienta de CI (Jenkins, Travis CI y CircleCI son populares) para el centro de integración. Para empalmar el software de código abierto en la canalización de CI/CD, los usuarios deben trabajar con el método de la herramienta de CI para conectar el depósito de código con la secuencia de compilación. Por ejemplo, Jenkins depende de complementos, mientras que Travis CI usa un archivo de configuración YAML. Muchas organizaciones también quieren cambios de código y compilaciones para activar automáticamente las notificaciones en un canal de comunicación social, como Slack o Atlassian Hipchat. La conexión a herramientas externas a menudo se origina en la plataforma de CI, lo que la convierte en una opción fundamental para el resto de la cartera de DevOps.

Las organizaciones que no desean usar una pila de PaaS obstinada y su cadena de herramientas predefinida, pero no tienen el tiempo ni la experiencia para unir y administrar una gran cantidad de productos puntuales DevOps, tienen otra opción: servicios administrados. CloudHesive, iTMethods y TriNimbus son solo algunos de los proveedores de servicios administrados (MSP) de DevOps que trabajan con departamentos de TI empresariales. Los MSP pueden proporcionar entornos DevOps personalizables y soporte de software.

Como con cualquier decisión de construcción vs. compra, la elección de una cadena de herramientas DevOps empaquetada o personalizada se reduce a varios factores: la experiencia y comodidad de una organización con implementaciones de software de código abierto, su disposición para adaptarse a procesos obstinados frente a la necesidad de máxima libertad en la selección e integración de herramientas, y su uso de pilas PaaS que favorecen una metodología determinada.

Próximos pasos

Más sobre DevOps:

La aplicación de DevOps en Brasil genera una nueva mentalidad de trabajo

El rol de DevOps y su conexión con la arquitectura empresarial

DevOps e IoT se combinan para mejorar la calidad y seguridad de las apps

Este artículo se actualizó por última vez en noviembre 2017

Profundice más

PRO+

Contenido

Encuentre más contenido PRO+ y otras ofertas exclusivas para miembros, aquí.

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close