automatización de infraestructuras y del lanzamiento de ... · la transición de las disciplinas...
Post on 14-Mar-2020
5 Views
Preview:
TRANSCRIPT
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
top related