Automatización de infraestructuras y del lanzamiento de aplicaciones Comprensión de la propuesta de valor de ambasde Julian Fish, director de gestión de productos de Serena Software (ahora parte de Micro Focus)

Informe oficial

Índice página

Resumen ejecutivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Por qué automatizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Breve historia de la automatización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Progresar no siempre es difícil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

¿Qué es la automatización de infraestructuras? . . . . . . . . . . . . . . . . . . . . . . . . . . 4

¿Qué es la automatización del lanzamiento de aplicaciones? . . . . . . . . . . . . . . . 5

Rasgos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Deployment Automation frente a Puppet para automatizar la

infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Deployment Automation frente a Puppet en la automatización del

lanzamiento de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

El valor de los canales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Implantaciones controladas por modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Una simple cuestión de capacidad de ampliación . . . . . . . . . . . . . . . . . . . . . . . . 13

Lo mejor de ambos mundos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1www.microfocus.com

Resumen ejecutivo

Las organizaciones que inician la transformación de DevOps o las que simplemente quieren

automatizar y configurar sus entornos a menudo no conocen el valor de la automatización del

lanzamiento de aplicaciones en contraposición al de las herramientas de automatización de

infraestructuras . Existen numerosas herramientas disponibles con funciones que aparentemente

se solapan . Este documento muestra el ejemplo de dos líderes del sector: Micro Focus

Deployment Automation1 para la automatización del lanzamiento de aplicaciones y Puppet2 para

la automatización de infraestructuras . También incluye información sobre las propuestas de valor

de cada uno, su enfoque principal y los beneficios que pueden ofrecer como parte de una cadena

de herramientas integradas de DevOps . .

Por qué automatizar

Muchas organizaciones desean simplificar y reducir la complejidad de las implantaciones de

aplicaciones al mismo tiempo que mantienen la estabilidad operativa, se adhieren a los SLA y

garantizan la capacidad de respuesta de las aplicaciones . Una mayor capacidad de respuesta

de la empresa y un enfoque de “avanzar sin romper nada” son cruciales para su supervivencia .

Para cumplir estos objetivos enfrentados, cada vez es más necesario una “pila de aplicaciones

completa”. Lamentablemente, la definición de “pila completa” tiende a variar dependiendo del

área de la organización que lo describa .

El sector de operaciones a menudo lo considera la infraestructura necesaria para alojar las

aplicaciones y sistemas compatibles, y contempla la aplicación como un pequeño componente

de la pila, mientras que los equipos de desarrollo suelen considerar la “pila completa” como una

agrupación de todos los niveles de la aplicación que funcionan correctamente, y tienen mucho

menos interés en la infraestructura subyacente . La realidad, especialmente desde una perspectiva

de DevOps, es que todas las áreas deben trabajar en estrecha colaboración a fin de garantizar el

soporte para lo que se ha convertido en los activos fundamentales de una organización . Durante

los diez últimos años, la función de TI ha dejado de considerarse un distintivo de negocio clave,

puesto que mantener los sistemas empresariales en funcionamiento ha dejado de aportar valor

añadido . Ahora es un requisito . Para las empresas, la aplicación es lo principal y los cambios

de aplicaciones forman parte del distintivo del negocio y generan valor empresarial . Resulta

esencial implantar el mayor número de cambios en las empresas en el menor tiempo posible y

con elevados niveles de calidad, estabilidad y funciones . Los procesos manuales para implantar

aplicaciones no cumplen estos requisitos clave . La automatización es obligatoria, no opcional .

Este documento muestra el ejemplo de dos líderes del sector: Micro Focus Deployment Automation para la automatización del lanzamiento de aplicaciones y Puppet para la automatización de infraestructuras. También incluye información sobre las propuestas de valor de cada uno, su enfoque principal y los beneficios que pueden ofrecer como parte de una cadena de herramientas de DevOps integradas.

__________

1 Deployment Automation (SDA) es una herramienta líder del sector, utilizada para la automatización de aplicaciones que puede tanto integrarse con herramientas de provisión de infraestructuras como adoptarlas. www.serena.com/sda

2 Puppet es una herramienta líder del mercado para la automatización de infraestructuras que se puede emplear para automatizar el lanzamiento de aplicaciones tras una cierta inversión y codificación. https://puppetlabs.com/

2

Informe oficialLa automatización del lanzamiento de aplicaciones frente a la automatización de infraestructuras

Breve historia de la automatización

Durante los últimos 15 años ha aumentado la tasa de cambio en la industria del software, que,

como Glenn O’Donnell de Forrester indica, se encamina a la “industrialización de TI”3 . Impulsados

inicialmente por una reducción del gasto en TI posterior al efecto 2000 y la burbuja “puntocom”,

y por la adopción masiva posterior de Internet y un enfoque empresarial de conexión continua,

estos cambios han generado un enorme impacto en el mundo corporativo y empresarial de TI .

Las empresas que hace 15 años no consideraban necesario disponer de un sitio web, por no hablar

del acceso ininterrumpido de los clientes, han tenido que adaptarse a un método de trabajo

completamente nuevo . La reducción del gasto en TI ha permitido a las organizaciones hacer más

con menos: reducir el personal y aumentar las exigencias al sector de TI de la empresa . La adopción

generalizada de Internet requiere niveles nunca vistos de eficiencia operativa, tiempo de actividad

del sistema y capacidad de respuesta . El nivel de complejidad inherente a muchas aplicaciones de

empresa dificulta la entrega de cambios eficiente y repetible. Los riesgos de exponer las aplicaciones

ante terceros, que pueden buscar debilidades o puertas traseras para acceder a los sistemas

administrativos esenciales de la empresa, ponen de relieve que agilizar las entregas no es suficiente.

Las aplicaciones deben implantarse rápidamente, mantener niveles de calidad y seguridad elevados

e incorporar las mejores funciones en todo momento . Apoyarse en procesos manuales para

garantizar la fiabilidad, la trazabilidad y el carácter repetible ya no es viable. La entrega manual de

aplicaciones puede dejar a la organización muy por detrás de la competencia .

Progresar no siempre es difícil

Los equipos de desarrollo siempre han aceptado el cambio, como el paso de los lenguajes de

programación legados, como COBOL y C, a nuevos lenguajes como Java y .Net . Los equipos de

desarrollo han modificado sus aplicaciones y procesos para contribuir al cambio, aun cuando los

beneficios iniciales podían verse superados por los gastos de la transición. La transición de las

disciplinas de gestión de proyectos en cascada a las disciplinas Agile, la adopción de prácticas

LEAN y la prevalencia de la adopción de software de código abierto son el primer ejemplo

de la voluntad de los equipos de desarrollo de contribuir al cambio . La capacidad de estas

organizaciones de desarrollo de ser más eficientes y ofrecer funciones de empresa de forma más

rápida y eficaz ha aumentado la presión ejercida sobre los equipos de operaciones para entregar

estas nuevas funciones con eficacia y rapidez.

Las empresas que hace 15 años no consideraban necesario disponer de un sitio web, por no hablar del acceso ininterrumpido de los clientes, han tenido que adaptarse a un método de trabajo completamente nuevo.

__________

3 O’Donnell, Glenn. 2010, IT Is Industrializing—What Does That Mean To Me? (La industrialización de TI: ¿qué significa para mí?), Blog de Glenn O’Donnell, visto el 24 de febrero de 2015, http://blogs.forrester.com/glenn_odonnell/10-04-21-it_industrializing_%E2%80%93_what_does_mean_me

3www.microfocus.com

Los equipos de operaciones siempre han adoptado un enfoque de “riesgo cero” para la gestión de

entornos operativos y de producción, como normalmente ha exigido su actividad . Las empresas

requieren un sistema estable y el mayor tiempo de actividad del sistema posible, lo que hace que

este enfoque sea totalmente comprensible . La responsabilidad de mantener en funcionamiento

un sistema de comercio, de pedidos o bancario que proporcione información precisa a los

consumidores no debe tomarse a la ligera . La inversión y la adopción de prácticas, procesos

y procedimientos basados en ITIL por parte de muchas organizaciones es una muestra de la

seriedad con que deben concebirse los sistemas operativos . Asegurarse de que todo el mundo

está de acuerdo es fundamental para que se sigan prácticas y procedimientos comunes .

A medida que las empresas se esfuerzan por proporcionar al cliente la mejor experiencia posible,

ofrecer nuevas funciones u obtener ventaja competitiva, la entrega constante de cambios en

aplicaciones de la forma más rápida y eficiente posible se ha convertido inmediatamente en

una prioridad . La pregunta es cómo cumplir estos dos requisitos aparentemente enfrentados .

¿Es posible conseguir el aumento de la tasa de entrega de aplicaciones que requiere el área de

desarrollo y los niveles de estabilidad, capacidad de seguimiento, control y rigor que necesita

el departamento de operaciones sin que ello perjudique al cumplimiento de los requisitos

normativos, del sector o de la empresa?

_______________________________________________________________

A medida que las empresas se esfuerzan por proporcionar al cliente la mejor experiencia posible, ofrecer nuevas funciones u obtener ventaja competitiva, la entrega constante de cambios en aplicaciones de la forma más rápida y eficiente posible se ha convertido inmediatamente en una prioridad.

Fig. 1

Desarrollo frente a retos operativos

_______________________________________________________________

4

Informe oficialLa automatización del lanzamiento de aplicaciones frente a la automatización de infraestructuras

La automatización, tanto de la implantación e instalación de aplicaciones como de la configuración de los sistemas, sirve para garantizar que el entorno es completamente uniforme. Gracias a ella, es posible repetir la implantación siempre que sea necesario y realizar y seguir auditorías completas en cualquier momento para ver con exactitud qué versión de qué elemento se ha implementado en cada entorno.

Gracias a los avances tecnológicos, ahora es mucho más fácil automatizar la entrega de

aplicaciones y la infraestructura de soporte al completo . El movimiento DevOps se esfuerza

por hacer frente a los retos relacionados con las personas, los procesos y la comunicación que

predominan en dos unidades administrativas distintas (desarrollo y operaciones) y, sin ninguna

duda, puede beneficiarse de la automatización. Del mismo modo que las organizaciones han

descubierto que volver a compilar el código en distintos entornos provoca resultados diferentes

en las versiones (y muchos problemas en los entornos posteriores), cada vez más usuarios se

dan cuenta de que una implantación no unificada en los distintos entornos también ocasiona

problemas y retos de gran importancia . La automatización, tanto de la implantación e instalación

de aplicaciones como de la configuración de los sistemas, sirve para garantizar que el entorno

es completamente uniforme . Gracias a ella, es posible repetir la implantación siempre que

sea necesario y realizar y seguir auditorías completas en cualquier momento para ver con

exactitud qué versión de qué elemento se ha implementado en cada entorno . Generalmente,

la automatización también hace que se reduzca el tiempo de implantación y que aumente la

confianza en la calidad de entrega (las máquinas no comenten errores ni se olvidan de ejecutar

comandos) . También brinda la posibilidad de demostrar con exactitud que los resultados han

ido según lo planeado, lo que permite garantizar que se cumplen los requisitos de auditoría

importantes de las entregas .

Implantar una aplicación no suele ser tan fácil como mover archivos de una ubicación a otra .

Puede implicar la creación o ampliación de infraestructuras para que sea compatible con

nuevas funciones, tenga una mayor capacidad de almacenamiento o se puedan implantar

nuevas funcionalidades en ella . Todo esto se traduce en complejas rutinas de instalación .

La automatización de infraestructuras y aplicaciones son características ligeramente diferentes

que hay que definir mejor.

¿Qué es la automatización de infraestructuras?

La automatización de infraestructuras es la creación y administración de entornos, y en ella

se incluyen tanto la instalación de sistemas operativos como la instalación y configuración de

servidores en instancias físicas, virtuales o en la nube, así como la configuración del modo que

tienen las instancias y el software de comunicarse entre ellos . Suele conocerse como “provisión”,

“infraestructura basada en guiones”, “infraestructura como código” o incluso “gestión de

configuraciones” (aunque este último término puede resultar confuso, ya que tiene varios

significados diferentes según la parte del ciclo de vida de la que se esté hablando). El principio

es simple: definir la configuración del sistema a través de un guion o un conjunto de guiones que

permitan a los usuarios crear o recrear entornos de la manera más fácil y rápida posible al mismo

tiempo que se garantiza una menor cantidad de errores y un tiempo de respuesta más rápido .

_______________________________________________________________

5www.microfocus.com

¿Qué es la automatización del lanzamiento de aplicaciones?

La automatización del lanzamiento de aplicaciones es la gestión de aplicaciones basada en

guiones que se produce dentro de los entornos. En ella se incluye la instalación, la configuración

y la implantación de aplicaciones en entornos físicos, virtuales o en la nube . De hecho, estos

entornos de destino pueden haberse creado mediante la automatización de infraestructuras .

La automatización del lanzamiento de aplicaciones incluye la configuración de la instalación e

implantación de las aplicaciones, así como los ajustes realizados en la forma en la que los distintos

niveles de una aplicación interactúan entre ellos durante el tiempo de ejecución . También

se denomina “automatización de aplicaciones” o “AA”, “automatización de implantaciones”,

“implantación ágil” o incluso “gestión de lanzamientos” . El término “guion” se usa con frecuencia

para englobar herramientas declarativas, personalizadas o basadas en procesos o paquetes,

La automatización del lanzamiento de aplicaciones incluye la configuración de la instalación e implantación de las aplicaciones, así como los ajustes realizados en la forma en la que los distintos niveles de una aplicación interactúan entre ellos durante el tiempo de ejecución.

Fig. 2

Automatización de infraestructuras

_______________________________________________________________

6

Informe oficialLa automatización del lanzamiento de aplicaciones frente a la automatización de infraestructuras

cuenten o no con características de definición de interfaces de usuario. Se basan en un principio

sencillo: definir un modelo a través de un guion o un conjunto de guiones que permitan a los

usuarios crear o implantar aplicaciones de la manera más fácil y rápida posible al mismo tiempo

que se garantiza una menor cantidad de errores y un menor tiempo de respuesta .

_______________________________________________________________

La automatización del lanzamiento de aplicaciones también se conoce como “automatización de aplicaciones” o “AA”, “automatización de implantaciones”, “implantación ágil” o incluso “gestión de lanzamientos”.

Fig. 3

Automatización del lanzamiento de aplicaciones

_______________________________________________________________

7www.microfocus.com

La automatización de aplicaciones y la automatización de infraestructuras se pueden considerar complementarias en el contexto más amplio de DevOps, la entrega continua y la implantación continua.

__________

4 La entrega continua (CD) consiste en mantener la aplicación en un estado que siempre permita implantarla en la fase de producción. Martin Fowler, visto el 24 de febrero de 2015, http://martinfowler.com/delivery.html

5 La implantación continua consiste en implantar cambios en la fase de producción, cada día o incluso por períodos de tiempo inferiores. Martin Fowler, visto el 24 de febrero de 2015, http://martinfowler.com/delivery.html

Rasgos comunes

Tanto la automatización de aplicaciones como la de infraestructuras pueden considerarse

procesos complementarios en el contexto más amplio de DevOps (es decir, de los procesos y

prácticas que implican la alineación de los equipos de desarrollo y operaciones), así como en los

de entrega continua4 o implantación continua5 . Como estos dos tipos de herramientas tienen

objetivos comunes (por ejemplo, aumentar la capacidad de respuesta; reducir los errores; mejorar

las auditorías, la rendición de cuentas y la capacidad de seguimiento, y utilizar guiones para todos

los procesos) suelen considerarse como competidoras directas o como opciones alternativas .

La verdad es que ambos conjuntos de herramientas tienen un objetivo bien definido y un punto

óptimo . Si bien es posible utilizar una herramienta para realizar determinadas funciones de la

otra, es preferible elegir la más adecuada para el trabajo .

_______________________________________________________________

Automatización del lanzamiento de aplicaciones

Automatización de infraestructuras

Implantaciones centradas en procesos ● ● Implantación de aplicaciones ● ● Instalación de aplicaciones ● ● Soporte de canal ● ● Gestión del entorno ● ● Provisión de infraestructuras ● ● Modificación de infraestructuras ● ● Provisión desde cero ● ● Automatización de pila completa (basada en cadena de herramientas)

● ●

Fig. 4

La automatización del lanzamiento de aplicaciones frente a la automatización de infraestructuras

_______________________________________________________________

8

Informe oficialLa automatización del lanzamiento de aplicaciones frente a la automatización de infraestructuras

Deployment Automation frente a Puppet para automatizar la infraestructura

Deployment Automation puede utilizarse para realizar un subconjunto de tareas de

automatización de infraestructuras mediante guiones o complementos existentes para

herramientas de terceros; en determinadas circunstancias, esto puede ser todo lo necesario para

automatizar una infraestructura . Entre los ejemplos de dichas actividades se incluyen la provisión

virtual o la basada en la nube, en las que una imagen existente predefinida y configurada se utiliza

para proporcionar capacidad adicional, ya sea virtual o en la nube . La creación de infraestructuras

basadas en una imagen predefinida y configurada se le suele conocer como la provisión de una

“imagen maestra”, ya que, una vez que se ha creado la nueva infraestructura, tan solo hace

falta realizar algunos cambios adicionales en la configuración. Este modelo de provisión de

infraestructuras es adecuado cuando las organizaciones quieren ampliar su infraestructura de

aplicaciones existente de forma horizontal o vertical para proporcionar capacidad o características

adicionales . En este caso, la provisión de la infraestructura virtual se realiza mediante

complementos para VMware ESX, ESXi o la estación de trabajo . De este modo, se suministran

nuevas imágenes virtuales . Una vez creada la instancia, las nuevas imágenes actualizarán la

configuración de propiedades del agente, lo que permitirá que los nuevos agentes se registren

automáticamente en los grupos de repositorios de agentes adecuados del servidor de Deployment

Automation . La provisión de infraestructura de nube se lleva a cabo a través de los complementos

para Amazon, Azure o vCloud, y se suministran nuevas imágenes de nube . Una vez creada la

instancia, las nuevas imágenes actualizarán la configuración de propiedades del agente, lo que

permitirá que los nuevos agentes se registren automáticamente en los grupos de repositorios de

agentes adecuados del servidor de Deployment Automation .

La automatización de infraestructuras que se lleva a cabo desde cero o a nivel de máquina

física requiere características mucho más exhaustivas . Además, como es una herramienta de

automatización de aplicaciones, no es el proceso adecuado para Deployment Automation . En

estas circunstancias, es recomendable utilizar una herramienta de terceros como Puppet y

dejar que la herramienta de automatización Deployment Automation se encargue de controlar

el proceso de provisión de la infraestructura . Para poder utilizar una herramienta de provisión

de infraestructura como Puppet, es necesario contar con un experto . Aunque hay una gran

cantidad de módulos y manifiestos predefinidos en la comunidad de desarrollo, los conocimientos

necesarios para crear, modificar y actualizar dichos manifiestos suelen encontrarse en usuarios

con experiencia en operaciones . Saber qué parámetros del kernel, la memoria, el sistema

y la configuración hay que ajustar en el momento de crear la instancia, conocer la manera

de implantar un sistema operativo correctamente con los parámetros de seguridad y redes

adecuados, y entender los requisitos de E/S de disco de los conjuntos de almacenamiento de datos

adjuntos a la hora de crear instancias de nuevas infraestructuras en el contexto de un centro de

datos mucho mayor son requisitos fundamentales para proporcionar una infraestructura de base

adecuada en la que implantar aplicaciones .

Para poder utilizar una herramienta de provisión de infraestructura como Puppet, es necesario contar con un experto. Aunque hay una gran cantidad de módulos y manifiestos predefinidos en la comunidad de desarrollo, los conocimientos necesarios para crear, modificar y actualizar dichos manifiestos suelen encontrarse en usuarios con experiencia en operaciones.

9www.microfocus.com

Las recetas, los cookbooks y otros scripts de definición suelen escribirse normalmente en el

lenguaje específico del dominio, por lo que es necesario contar con conocimientos de creación

de guiones para configurar y realizar despliegues de infraestructuras. La implantación de

aplicaciones en esta “pila”, ya sea predefinida o personalizada, es la extensión lógica de la

provisión de la infraestructura: está implantando un nuevo equipo de hardware por algún

motivo. Definir el proceso de implantación para la provisión de la infraestructura, utilizar los

módulos y manifiestos correctos para crear la nueva infraestructura física, implantar la nueva

infraestructura virtual y las aplicaciones, y garantizar que todas las aplicaciones de la nueva pila

están configuradas correctamente son los objetivos finales. Mediante el uso de complementos

para herramientas de provisión como Puppet, las organizaciones obtienen los beneficios de las

mejores tecnologías disponibles del mercado para crear la infraestructura y las funciones de

proceso para la herramienta de automatización, junto con la capacidad de implantar aplicaciones

a la perfección en el nuevo entorno mediante un proceso sencillo y definido por los gráficos sin

renunciar a unas capacidades de auditoría y de seguimiento completas .

_______________________________________________________________

Mediante el uso de complementos para herramientas de provisión como Puppet, las organizaciones obtienen los beneficios de las mejores tecnologías disponibles del mercado para crear la infraestructura y las funciones de proceso para la herramienta de automatización, junto con la capacidad de implantar aplicaciones a la perfección en el nuevo entorno mediante un proceso sencillo y definido por los gráficos sin renunciar a unas capacidades de auditoría y de seguimiento completas.

Fig. 5

Provisión de pila completa

_______________________________________________________________

10

Informe oficialLa automatización del lanzamiento de aplicaciones frente a la automatización de infraestructuras

Deployment Automation frente a Puppet en la automatización del lanzamiento de aplicaciones

Como vimos cuando hablamos sobre la automatización de infraestructuras, las áreas conjuntas

de la automatización proporcionan las características necesarias para implantar los principios de

DevOps dentro de una organización . Sin embargo, como también ocurría con la automatización

de las infraestructuras, hay algunas áreas específicas fundamentales a las que le gustaría dirigir

la automatización de aplicaciones . Si la implantación de su aplicación consiste simplemente en

ejecutar un lote o guion de shell para copiar archivos en la ubicación correcta, las herramientas

de automatización de infraestructuras pueden proporcionarle la capacidad (si no la trazabilidad)

que necesita . Desgraciadamente, estas implantaciones de aplicaciones tan sencillas son muy

poco habituales en el mundo del software empresarial . Normalmente, el enfoque de simplemente

copiar un archivo y ejecutar un guion no es suficiente para implantar una aplicación en n niveles,

ya que puede contener dependencias entre diferentes áreas de componentes de aplicación,

usar diversos sistemas operativos en varios entornos y depender de pasos manuales para

complementar los guiones . Cuando se deben implantar varios componentes de una aplicación

e, incluso, varias aplicaciones, en serie o en paralelo, las capacidades de las herramientas de

automatización de infraestructuras no dan abasto, por lo que puede terminar usando guiones

encadenados muy complicados, que acaban siendo difíciles de gestionar y de entender . Incluso

para realizar implantaciones de aplicaciones sencillas en los servidores de aplicaciones que

se suelen utilizar, como Tomcat, se necesitan guiones detallados y complejos . Por ejemplo, la

implantación de un simple archivo WAR en Tomcat con Puppet necesita más de 800 líneas de

código. Mantener actualizados estos guiones o modificarlos para que se adapten a los requisitos

de la organización puede convertirse en la única responsabilidad de un recurso bien pagado y

altamente cualificado. En comparación, utilizar Deployment Automation para implantar un

archivo WAR en un servidor de aplicaciones Tomcat es un proceso de un solo paso que se muestra

gráficamente al usuario final. Las personalizaciones o cambios en la configuración entre entornos

se incorporan como parámetros en este paso, lo que asegura que todo el proceso pueda repetirse,

desde los entornos de desarrollo a la producción .

El valor de los canales

Uno de los principios básicos de cualquier tipo de automatización es que se conozca el estado

final y que este se pueda alcanzar repetidas veces. La uniformidad en los entornos es primordial

para evitar errores durante las implantaciones . Es frecuente que los encargados de versiones

y los ingenieros de calidad y operaciones tengan dificultades para implantar aplicaciones en

los entornos que eligen . Y, por si fuera poco, sus homólogos de ingeniería se burlan de ellos

diciéndoles que en sus entornos sí funciona. Si el objetivo o el estado final de destino no son

Normalmente, el enfoque de simplemente copiar un archivo y ejecutar un guion no es suficiente para implantar una aplicación en n niveles, ya que puede contener dependencias entre diferentes áreas de componentes de aplicación, usar diversos sistemas operativos en varios entornos y depender de pasos manuales para complementar los guiones.

11www.microfocus.com

uniformes, la automatización se convierte en un ejercicio trivial que no aporta ningún valor

viable. Naturalmente, el estado final de destino de cualquier iniciativa de DevOps o de entrega

continua es proporcionar aplicaciones en un entorno de producción, en cualquier momento

y de forma automatizada, simple, reproducible y conforme a las auditorías . Sin embargo, de

la misma manera que la planificación previa de las actividades garantiza terminar a tiempo y

con éxito, es fundamental conocer los mecanismos, etapas y niveles de validación requeridos

para llevar nuestra aplicación a la producción . Cada vez es menos realista limitarse a esperar

que el código producido en entornos de desarrollo funcione perfectamente en un entorno de

producción con diferentes configuraciones, parámetros en tiempo de ejecución, configuración de

infraestructura y conjuntos de datos, sobre todo cuando, durante las implantaciones, nos topamos

con la complejidad de la aplicación y las dependencias entre aplicaciones . Para muchos clientes

empresariales, el simple hecho de definir las dependencias entre aplicaciones y conocer el impacto

de cambiar de una aplicación a otra supone una actividad muy compleja en la que pierden mucho

tiempo. El objetivo final de muchas empresas de entrega de aplicaciones consiste en implantar las

aplicaciones correctamente en el momento y el entorno adecuados .

Para garantizar que este objetivo se cumpla, es clave contar un canal o ruta de implantación

hasta la producción . Los canales de implantación han existido en muchas formas a lo largo de los

años, desde el SDLC tradicional, donde al desarrollo le seguían las pruebas y la producción, hasta

las vías dinámicas y definidas visualmente que llegan hasta la producción y que pueden variar

dependiendo de la aplicación y del riesgo potencial de la implantación de dicha aplicación .

Una de las muchas preguntas que plantean los clientes a la hora de definir uno o varios canales

es si todas sus aplicaciones necesitan los mismos canales . Una respuesta sencilla pasaría por

mirar las aplicaciones en cuestión y definir los requisitos de conformidad y auditoría de cada una

de ellas . ¿Necesita un sitio de la intrarred el mismo nivel de rigor y validación que un sistema

bancario o de comercio en línea orientado al cliente? Para la mayoría de empresas, la respuesta

es un rotundo “no” . Es indispensable que debe mantenerse el rigor y el control en las aplicaciones

orientadas al cliente que están sometidas a un uso intenso y tienen una alta visibilidad . Sin

embargo, es excesivo usar el mismo enfoque en las aplicaciones internas de pruebas, en los sitios

de la intrarred o en las aplicaciones de baja prioridad . Aplicar distintos canales a diferentes

aplicaciones es fundamental para que la adopción de la automatización sea un éxito .

Cada vez es menos realista limitarse a esperar que el código producido en entornos de desarrollo funcione perfectamente en un entorno de producción con diferentes configuraciones, parámetros en tiempo de ejecución, configuración de infraestructura y conjuntos de datos, sobre todo cuando, durante las implantaciones, nos topamos con la complejidad de la aplicación y las dependencias entre aplicaciones.

12

Informe oficialLa automatización del lanzamiento de aplicaciones frente a la automatización de infraestructuras

Los canales son el componente fundamental a la hora de definir el carácter repetible de las

implantaciones en varios entornos, lo que demuestra la adherencia y el cumplimiento de los

estándares . Es fácil conseguir la implantación de las mismas aplicaciones con los mismos

procesos para varios entornos si se define y aplica un canal. Los canales también permiten

detectar discrepancias entre entornos .

Deployment Automation proporciona una capacidad gráfica completa de canales, con la opción de

exigir el uso de los canales e, incluso, promover las aplicaciones automáticamente de un entorno

a otro (siempre que la implantación anterior se completara correctamente) . Puppet no incluye

el concepto de canales, aunque se pueden usar los guiones encadenados para enlazar las tareas

de automatización. En este caso le recomendaríamos que impulsara gráficamente las tareas de

Puppet a través de un proceso gráfico en SDA y siguiera el proceso gráfico que se define para el

canal de implantación .

Implantaciones controladas por modelos

Entender cómo se pueden implantar aplicaciones de destino es un factor primordial a la hora de

adoptar cualquier herramienta de automatización . Es imposible automatizar las implantaciones

de aplicaciones si se desconocen los pasos necesarios para realizar realizarlas . Con las

implantaciones basadas en modelos, como las que utiliza Deployment Automation, los usuarios

finales pueden definir gráficamente todo el proceso de implantación de aplicaciones, incluidas

las dependencias de las aplicaciones y las interacciones de sistema a sistema . La capacidad

de adaptar los procesos y los canales de implantación de manera gráfica supone una ventaja

significativa sobre las aplicaciones de tipo declarativo, donde el conocimiento y la comprensión

del proceso proviene de un entendimiento implícito del código utilizado para realizar cualquier

implantación . Imagine el caso sencillo de un usuario, por ejemplo, al implantar una aplicación

en un servidor de aplicaciones como Tomcat. Con un sistema basado en modelos, la definición

de la actividad que se va a realizar se dibuja gráficamente en un lienzo, en el que se indica el paso

y el proceso que se debe llevar a cabo . Con un sistema declarativo, en esta misma actividad hará

falta modificar el código, lo que supone cambiar un elemento que contiene cerca de 1000 líneas

de código. Naturalmente, es mucho más fácil que los nuevos usuarios entiendan una definición

de proceso gráfica que entender un nuevo lenguaje de programación con varios cientos de líneas

de código. También se simplifican las modificaciones futuras, ya que cualquier personalización

se puede ver fácilmente en el proceso de implementación, en lugar de tener que revisar bases

complejas de código .

Es imposible automatizar las implantaciones de aplicaciones si se desconocen los pasos necesarios para realizar realizarlas.

13www.microfocus.com

Una simple cuestión de capacidad de ampliación

Las empresas son entornos complejos . Nunca es sencillo ejecutar versiones de software más

recientes y de mayor calidad en la infraestructura más reciente y de mayor calidad . En la mayoría

de organizaciones empresariales de larga trayectoria, las aplicaciones legadas deben coexistir con

nuevas aplicaciones, distintas versiones de lenguajes de programación, componentes de tiempo

de ejecución y capas de abstracción . Para muchas organizaciones, la migración a nuevas versiones

de aplicaciones implica la migración de infraestructuras y escritorios de usuario final, así como la

actualización de interfaces de datos existentes . La diferencia entre las versiones de aplicaciones

que se deben actualizar en el momento de la implantación requiere el uso de una interfaz

compleja y difícil de actualizar entre la tecnología de automatización y el sistema de terceros, lo

que sitúa a su empresa en una posición de gran desventaja . Deployment Automation proporciona

multitud de integraciones de uso inmediato para muchos sistemas comunes de terceros, desde

bases de datos a middleware o servidores de aplicaciones, e incluso herramientas de prueba . El

modelo de complementos con capacidad de ampliación utilizado por la aplicación permite crear

rápidamente nuevos complementos para sistemas de terceros, lo que incrementa la capacidad de

la plataforma de automatización para ampliarse a todas las áreas de la empresa. Los manifiestos

de Puppet permiten definir fácilmente una infraestructura como código e impulsar la creación,

actualización y destrucción de infraestructura como parte de la provisión de una “pila completa”

predefinida o de un proceso de implantación.

Lo mejor de ambos mundos

Como se ha indicado, la provisión de una “pila completa” puede abarcar toda la pila

de aplicaciones e infraestructuras . Las implantaciones de aplicaciones, la provisión de

infraestructuras y los procesos para mantener todo lo anterior sincronizado son componentes

clave para las organizaciones que desean disfrutar de los beneficios de la entrega continua y la

tecnología de transición, así como para todos los usuarios y procesos relacionados con DevOps .

Las herramientas de provisión de infraestructura realizan una labor crucial para asegurar que

la infraestructura de base está preparada para la implantación posterior de aplicaciones . El

uso de procesos uniformes para la implantación de aplicaciones e infraestructuras garantiza

la conformidad, la capacidad de auditoría, el carácter repetible y la información sobre

implantaciones, a la vez que reduce el tiempo de implantación y elimina los riesgos asociados a

las implantaciones manuales . Automatizar la infraestructura mediante la automatización de las

implantaciones es el primer paso hacia la transformación de la organización, la simplificación de

procesos y la reducción del tiempo de comercialización . Avance rápido sin inconvenientes .

Las implantaciones de aplicaciones, la provisión de infraestructuras y los procesos para mantener todo lo anterior sincronizado son componentes clave para las organizaciones que desean disfrutar de los beneficios de la entrega continua y la tecnología de transición, así como para todos los usuarios y procesos relacionados con DevOps.

162-ES0085-002 | S | 04/17 | © 2017 Micro Focus. Reservados todos los derechos. Micro Focus y el logotipo de Micro Focus, entre otros, son marcas comerciales o marcas comerciales registradas de Micro Focus o sus compañías subsidiarias y filiales en Reino Unido, Estados Unidos y en otros países. El resto de marcas son propiedad de sus respectivos propietarios.

Argentina+54 11 5258 8899

Chile+56 2 2864 5629

Colombia+57 1 622 2766

México+52 55 5284 2700

Panamá+507 2 039291

España+34 91 781 5004

Venezuela+58 212 267 6568

Micro FocusSedes corporativasReino Unido+44 (0) 1635 565200

www.microfocus.com

www.microfocus.com