INTEGRACIÓN ÁGIL:

EL PLANO TÉCNICO PARA LA ARQUITECTURA

EMPRESARIAL

E-BOOK

de Steve Willmott y David Codelli

Editado por Deon Ballard

E-BOOK Enseñarle a bailar a un elefante 1

 ÍNDICE
LA PLANIFICACIÓN ESTÁ EXTINTA: LAS EMPRESAS Y LA AGILIDAD ........................ 4

LA INFRAESTRUCTURA DE LA AGILIDAD......................................................................... 6
Integración distribuida.................................................................................................................................. 7
Contenedores................................................................................................................................................... 9
API .................................................................................................................................................................... 10

LA ARQUITECTURA DE LA INTEGRACIÓN ÁGIL...............................................................12

Prácticas en equipo........................................................................................................................................12
La arquitectura de la infraestructura........................................................................................................12

LA CULTURA Y LAS EMPRESAS ÁGILES ..........................................................................14

CONCLUSIÓN: CÓMO OFRECER UNA INTEGRACIÓN ÁGIL .............................................18

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 2

LA PLANIFICACIÓN ESTÁ EXTINTA:
LAS EMPRESAS Y LA AGILIDAD
LA INFRAESTRUCTURA DE LA
AGILIDAD
Integración distribuida
Contenedores
API
LA ARQUITECTURA DE LA
INTEGRACIÓN ÁGIL
Prácticas en equipo
La arquitectura de la infraestructura
LA CULTURA Y LAS EMPRESAS ÁGILES
CONCLUSIÓN: CÓMO OFRECER UNA
INTEGRACIÓN ÁGIL
El éxito empresarial se basa cada vez más en su capacidad para reaccionar ante el cambio. A
medida que los agentes nuevos y revolucionarios ingresan al mercado, y la tecnología cambia
drásticamente las expectativas de los clientes, las empresas necesitan cada vez más cambiar
de planes en ciclos mucho más cortos que antes. Gracias a los procesos y las arquitecturas de
software modernos, las empresas pueden ser más eficientes a la hora de lidiar con este cambio y
salir triunfantes en los mercados a los que pertenecen.
Un marco arquitectónico nuevo denominado integración ágil reúne tres capacidades
arquitectónicas importantes: los contenedores, la integración distribuida y las interfaces
de programación de aplicaciones (API). Este marco aborda cómo estas capacidades clave
promueven la agilidad y potencian los procesos nuevos dentro de su empresa para crear una
ventaja competitiva.
Los sectores, como el turístico y el hotelero, se han transformado mediante formas nuevas
de hacer negocios: ahora, se ofrecen servicios nuevos, y los clientes interactúan con ellos
de manera distinta. Esta tendencia de cambios revolucionarios se extiende a otros sectores
importantes, desde los servicios financieros hasta el gobierno, impulsada por las tecnologías y
las mentalidades nuevas sobre la interacción entre las empresas y los clientes. Estos desafíos
impulsan a las empresas actuales a transformar sus propias tecnologías de TI de forma radical
para ofrecer estos servicios nuevos.

Para seguir siendo competitivas, las empresas deben tener la capacidad para planificar cambios e
implementarlos en los sistemas de software con rapidez.

Para poder distribuir sistemas de software a las velocidades actuales, las empresas necesitan
una base de infraestructura ágil. En este caso, el término "ágil" no hace referencia al desarrollo
ágil de software, sino al sentido más tradicional de la palabra: flexible, capaz de moverse con
rapidez.

ÁGIL

hábil ag•ile, ‘aj l/

e
acrobático
Adjetivo: que se puede
mover con rapidez
flexible y facilidad1 veloz

cimbreante SINÓNIMOS dinámico

elástico ligero

Figura 1. Definición de ágil

1 Oxford English Dictionary

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 3


" La demanda de
agilidad para ganar y
conservar clientes, y
prestarles los mejores
servicios de manera
continua, requiere
que las interfaces
entre los sistemas
de contratación y
los de registros sean
más ágiles. Esto
implica no solo que
sean escalables,
sino también que
puedan adaptarse
rápidamente, por
ejemplo, para agregar
un atributo nuevo a
las API actuales y para
brindar más contexto
en el futuro".
HENRY PEYRET
THE FORRESTER GROUP
Peyret, Henry. "TechRadarTM:
Integration Technologies,
segundo trimestre de 2015".
Forrester Research, Inc. 23 de
junio de 2015.
es.redhat.com
Hasta ahora, las metodologías ágiles se han centrado en el desarrollo de software y han
intentado mejorar y optimizar la forma en que se crean las aplicaciones. Las prácticas de
DevOps2 han intentado llevar esa metodología a la forma en que se implementan las aplicaciones.
Sin embargo, las prácticas de DevOps por sí solas suelen llegar hasta cierto punto, y en su
mayoría abordan aplicaciones de software nuevas que desarrolla la misma empresa.
La agilidad de la infraestructura da un paso más y crea un entorno que abarca todos los
sistemas de TI, incluido el software heredado. Una infraestructura ágil es un enfoque que toma
la complejidad de los sistemas actuales, los distintos tipos de datos, los flujos de datos y las
expectativas de los clientes, y busca la manera de unificarlos. En el fondo, esto representa un
problema de integración.
Una empresa que puede cambiar sus precios o lanzar productos nuevos al mercado de la noche a
la mañana tiene una ventaja enorme sobre aquella que requiere una implementación por etapas
de tres meses con una secuencia de pasos de verificación manual.
Este enfoque se denomina "integración ágil". La integración no se trata de un subconjunto de la
infraestructura, es un enfoque conceptual de ella que incluye datos y aplicaciones con hardware
y plataformas. Al alinear las tecnologías de integración con las ágiles y de DevOps, es posible
crear una plataforma que brinde a sus equipos la capacidad de cambiar con la rapidez que exige
el mercado.
LA PLANIFICACIÓN ESTÁ EXTINTA: LAS EMPRESAS Y LA AGILIDAD
"La planificación tal como la conocemos está extinta", afirmó Jim Whitehurst, director ejecutivo
de Red Hat, en su discurso en la Red Hat Summit de 2017. "La planificación en un entorno menos
conocido resulta ineficaz". 3 A medida los entornos empresariales se agilizan y los cambios se
tornan más estresantes, los planes se desmoronan con rapidez, y el hecho de quedar atascados
en un procedimiento puede ser muy costoso.
Esto significa que mientras menos información tenga, o menos estable sea su entorno, menos
valiosos serán sus planes.
No sabe lo que no sabe
Normalmente, la planificación de la infraestructura adopta un enfoque a largo plazo que suele
llevar años. Intentar crear un plan de varios años puede aniquilar la capacidad de innovar o
adaptarse a medida que el mercado cambia. La "extinción" de la planificación a la que se refiere
Jim Whitehurst se reduce a la capacidad de hacer planes con mayor rapidez y luego ejecutarlos.
Se trata de una expectativa de vida más corta para los planes y de un entorno que genera planes
nuevos.
Este cambio rápido puede implicar un desafío para los equipos acostumbrados a ciclos de
implementación de 6 o incluso 24 meses. El problema se agrava cuando las empresas con
una estructura más tradicional deben competir con las empresas emergentes que ingresan al
mercado de formas totalmente nuevas. Hay ejemplos claros como Netflix y Blockbuster, o Uber
y los servicios de taxi tradicionales, pero el efecto revolucionario de las empresas emergentes
se remonta al principio de la era de la información, que comienza con Amazon en 1993, o con las
computadoras personales en la década de 1980.
2 Acelere la innovación con DevOps https://www.redhat.com/es/insights/devops
3 Discurso de apertura de Jim Whitehurst en la Red Hat Summit de 2017.
https://www.cbronline.com/news/enterprise-it/software/red-hat-ceo-planning-know-dead/
E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 4
 TABLA 1: FACTORES REVOLUCIONARIOS EN CADA SECTOR

SECTOR SERVICIO FACTOR EFECTOS

TRADICIONAL REVOLUCIONARIO

Transporte Taxis, transporte Uber, Lyft Crean una experiencia

público uniforme del cliente que
resulta casi imposible de
igualar para las pequeñas
empresas locales

Gestión del Empresas de Fondos automatizados Cambian los diferenciadores

patrimonio inversiones de la gestión de fondos del
personal a los algoritmos

Minorista Compras en Amazon Cambia el hábito de comprar

persona en persona por las compras
en línea

Motores de Google, búsquedas Búsquedas por voz Afecta el canal principal de

búsqueda basadas en el Google al mercado y permite
explorador incorporaciones nuevas

La ventaja que tienen las empresas emergentes y los factores revolucionarios es la libertad
para estructurar su infraestructura, sus equipos, sus aplicaciones, su arquitectura e incluso sus
procesos de implementación. No solo tienen ideas innovadoras, sino que pueden ejecutarlas
porque no se ven limitados por una infraestructura heredada o, como dijo Rachel Laycock en
broma, por "personas heredadas"4. Pueden ser ágiles.

Además de la capacidad de innovación, estas empresas también diseñan sistemas que están
preparados para el cambio. La infraestructura de software es parte del poder que los diferencia,
y casi cualquier parte del sistema se puede intercambiar, actualizar o eliminar para responder
a las necesidades cambiantes del mercado. A medida que pasa el tiempo para las empresas
emergentes, algunas de ellas enfrentan una reducción de su capacidad de adaptación, pero las
mejores empresas se aseguran de proteger esta capacidad a toda costa.

A la altura del desafío

Para tener éxito en los entornos en constante cambio, toda la infraestructura de TI debe
funcionar de manera ágil.

Se debe generar un cambio en dos niveles:

• El respaldo empresarial y cultural de los procesos ágiles, desde el diseño de la arquitectura

hasta la comunicación en los equipos.

• La infraestructura técnica que permite actualizar, agregar y eliminar capacidades con rapidez.

El cambio técnico y cultural no genera agilidad, sino que crea la base para ella.

Marty Cagan, gerente de productos de eBay, aplica lo que él denomina un impuesto a cada
proyecto: se apartan ciertos recursos y tiempo de cada proyecto de rutina para trabajar en
proyectos de infraestructura nuevos5. Esto permite priorizar las innovaciones y los proyectos
nuevos.

4 Rachel Laycock, ("Continuous Delivery") Afternoon general session, Red Hat Summit – DevNation 2016. 1.º de julio
de 2016, San Francisco, California. https://youtube.com/watch?v=y87SUSOfgTY
5 Cagan, Marty, "Inspired: How to Create Products Customers Love". Wiley Press, 2017

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 5


" Si no puede
superarse en
experiencia y vencer
a los competidores
en agilidad y tiempo
de comercialización,
está perdido. Las
funciones son siempre
una apuesta. Si
tiene suerte, el 10 %
obtendrá los beneficios
que desea. Por lo tanto,
cuanto más rápido
pueda comercializar y
probar esas funciones,
mejor será su situación.
Por cierto, el negocio
también amortiza
más rápido el uso de
capital, lo que significa
que también empieza a
ganar dinero de forma
más rápida.
 G ENE KIM
THE PHOENIX PROJECT
Gene Kim, Kevin Behr y George
Spafford, The Phoenix Project:
A Novel about IT, DevOps, and
Helping Your Business Win.
Portland, Oregón: IT
Revolution Press, 2013.
es.redhat.com
LA INFRAESTRUCTURA DE LA AGILIDAD
Un torrente de nuevas tecnologías a menudo no suele ayudar a crear una infraestructura ágil, ya
que diferentes grupos avanzan en direcciones distintas para explorar opciones de mejora. Sin un
conjunto coherente de objetivos de primer nivel, es difícil determinar qué grupo de capacidades
nuevas marcará una diferencia real en el funcionamiento general de la empresa.
Los tres pilares de la integración ágil
Hay tres tecnologías principales que sustentan un enfoque de integración ágil.
INTEGRACIÓN API CONTENEDORES
DISTRIBUIDA
• Ligera • Extremos reutilizables, • Soluciones nativas de
• Basada en patrones bien definidos y bien la nube
• Artefactos eficaces que
• Orientada a eventos gestionados
se pueden implementar
• Originada en la • Accesibilidad a
comunidad ecosistemas de forma individual
• Escalabilidad y alta
disponibilidad basadas
en contenedores
FLEXIBILIDAD REUTILIZACIÓN ESCALABILIDAD
Herramientas y procesos
Figura 2. Los tres pilares de la integración ágil
1. Integración distribuida: algunas docenas de patrones de integración de primer nivel reflejan
los flujos de datos y el trabajo de la empresa. Cuando estos patrones de integración se
implementan en contenedores, pueden implementarse a la escala y en la ubicación necesarias
para aplicaciones y equipos específicos. Se trata de una arquitectura de integración
distribuida, en lugar de una centralizada tradicional, y permite que los equipos individuales
definan e implementen los patrones de integración que necesitan con agilidad.
2. API:las API estables y bien gestionadas tienen un gran impacto en la colaboración entre
los equipos, el desarrollo y las operaciones. Las API agrupan recursos clave en interfaces
estables y reutilizables, lo que les permite funcionar como componentes básicos para su
reutilización en toda la empresa, con partners y clientes. Las API se pueden implementar junto
con los contenedores en diferentes entornos, para que los usuarios puedan interactuar con
diferentes conjuntos de API.
3. Contenedores: los contenedores funcionan como la plataforma de implementación
subyacente tanto para las tecnologías de integración distribuida como para las de API.
Permiten que se implemente el servicio exacto en un entorno específico de una manera
que se pueda desarrollar, probar y mantener con facilidad y uniformidad. Debido a que los
contenedores son la plataforma dominante para los microservicios y los entornos de DevOps,
utilizarlos como plataforma de integración permite una relación mucho más transparente y
colaborativa entre los equipos de infraestructura y de desarrollo.
E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 6
 Estas tres tecnologías agilizan la infraestructura de TI, ya que cada una eleva el nivel de
abstracción en el que los distintos equipos pueden trabajar juntos. Utilizar una plataforma de
contenedores con API e integraciones distribuidas abstrae la implementación de la integración
de la integración en sí. Los equipos pueden ser más ágiles porque las API y los patrones de
integración distribuida contienen recursos específicos en un nivel que se puede comprender de
forma general, sin necesidad de entender o alterar la infraestructura subyacente.

Por separado, cada una de estas tecnologías aportará una agilidad significativa a los desafíos
de integración específicos. Cuando se utilizan en conjunto, producen un efecto multiplicador.
El énfasis en la tecnología está puesto en la cultura: los beneficios de la tecnología se
incrementan cuando se combinan con las prácticas de DevOps, especialmente en los procesos de
automatización y de implementación.

Integración distribuida
Uno de los mayores desafíos de los sistemas de TI actuales es que necesitan conectar
aplicaciones de todas las empresas. Las dificultades de los servicios de integración han dado
lugar a hubs de integración centralizados cada vez más complejos. Estos hubs, que generalmente
se implementan como buses de servicios empresariales (ESB), se han convertido en bloqueos
muy complejos que son demasiado rígidos como para permitir cambios rápidos.

La integración distribuida logra muchos de los objetivos técnicos que compartía con las
generaciones anteriores de ESB, pero de una forma que se adapta mejor a los equipos dentro de
una empresa. Al igual que sucede con los ESB, la tecnología de integración distribuida ofrece las
capacidades de transformación, enrutamiento, análisis, control de errores y alertas. La diferencia
está en la arquitectura de la integración.

En una arquitectura de integración distribuida, cada punto de integración se considera una

implementación única e independiente, en lugar de formar parte de una aplicación de integración
más grande y centralizada. De ese modo, es posible organizar la integración en contenedores
e implementarla de forma local para un proyecto o un equipo en particular, sin afectar ninguna
otra integración que se haya implementado en la empresa. Este enfoque distribuido brinda la
flexibilidad que requieren los proyectos ágiles. Además, usa la misma cadena de herramientas
que los equipos ágiles o de DevOps utilizando la plataforma subyacente de contenedores, lo
que aumenta la capacidad de los equipos para administrar sus propias integraciones con sus
herramientas y programas. Básicamente, la integración se considera como un microservicio6, lo
cual aumenta la velocidad de las integraciones de desarrollo y lanzamiento.

La alineación con los procesos y las herramientas del desarrollador es fundamental. Un aspecto
básico de la integración distribuida es que no se trata de una infraestructura de software
centralizada que un grupo de usuarios desarrolla y gestiona en un departamento, y que se
implementa independientemente del proceso de desarrollo de software. Por el contrario, la
distribución de la arquitectura de integración, con una plataforma y herramientas comunes,
permite que todos los desarrolladores a nivel de proyecto puedan acceder a ella y admite las
implementaciones ligeras en cualquier momento y lugar en el que sea necesaria la integración.

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 7


" En términos de
software, si una acción
causa molestias, la
forma de mitigarlas
es hacerla con más
frecuencia, no dejar
de hacerla".
 DAVID FARLEY
CONTINUOUS DELIVERY: RELIABLE
SOFTWARE RELEASES THROUGH
BUILD, TEST, AND DEPLOYMENT
AUTOMATION
David Farley y Jez Humble,
Continuous Delivery: Reliable
Software Releases Through
Build, Test, and Deployment
Automation. Addison-Wesley
Professional, 2010.
es.redhat.com
TABLA 2. UNA COMPARACIÓN DE LAS TECNOLOGÍAS DE INTEGRACIÓN PARA CADA
ETAPA DEL CICLO DE VIDA DE SOFTWARE
ETAPA DEL CICLO ESB, LA MAYORÍA DE TECNOLOGÍAS DE INTEGRACIÓN
DE VIDA LAS PLATAFORMAS DE DISTRIBUIDA RELACIONADAS
INTEGRACIÓN COMO
SERVICIO (IPAAS)
Control de versiones Propietario Github y otras
Creador Propietario Maven y otras
Implementación Propietario Contenedores y otras herramientas de
DevOps
Gestión y expansión Propietario Contenedores y otras herramientas de
DevOps
Para poder utilizar un ESB, el equipo se ve obligado a usar las herramientas de ese ESB para
todo el ciclo de vida, además de las herramientas que se utilizan en los entornos de desarrollo
y operaciones. Esta limitación da lugar a operaciones engorrosas, ineficientes y propensas a
errores.
La mensajería fortalece la integración
Desde el punto de vista de la arquitectura, la integración distribuida trata a las
integraciones como microservicios. Se pueden organizar en contenedores, son
fáciles de implementar a nivel local y tienen ciclos de lanzamiento rápidos.
La tecnología de integración debe ser capaz de admitir este tipo de arquitectura
ligera basada en microservicios. Red Hat® Fuse permite que los usuarios traten las
integraciones como códigos, que pueden ejecutarse en cualquier lugar, incluso en
un contenedor.
Además, con Red Hat JBoss AMQ se incluye Fuse para ofrecer una infraestructura
de mensajería. Una infraestructura de mensajería sólida garantiza el correcto
enrutamiento de los eventos y los datos entre sistemas. La mensajería es una
herramienta arquitectónica importante con microservicios, ya que su naturaleza
asíncrona no requiere ninguna dependencia.
Esta combinación de integraciones y mensajería mejora el rendimiento general
de la arquitectura de integración ofreciendo un enrutamiento más efectivo,
compatibilidad con varios idiomas y protocolos, productividad asíncrona y mejor
gestión de datos.
E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 8
 " Hay una nueva
rivalidad competitiva,
generalmente conocida
como transformación
digital, que genera la
necesidad de que las
empresas reconsideren
sus arquitecturas de
TI; redistribuyan las
cargas de trabajo en la
infraestructura local,
en la nube y en objetos;
e interactúen para
respaldar la estrategia
y las operaciones
empresariales.
Todos estos cambios
requieren un nuevo
enfoque para la
integración, al que
llamamos 'integración
híbrida'".
  C ARL LEHMANN
451 GROUP
Carl Lehman, 451 Research,
"The Disruptive Role of
Integration PaaS and APIs in the
New Hybrid Integration Platform
Market". Julio de 2017.
https://451research.com/
report-long?icid=3862.
es.redhat.com
Tras una tendencia
La adopción de los contenedores crece exponencialmente, pero ¿cuánto más? y
¿por qué motivo? 451 Research predice un crecimiento del mercado del 250 %7,
pero en inversión, no en implementación. Las implementaciones reales son un
poco más difíciles de medir. En una encuesta de Bain encargada por Red Hat, se
descubrió que, en la actualidad, alrededor del 20 % de los clientes implementan
contenedores en el entorno de producción, y casi la misma cantidad lo hace
en entornos de prueba y desarrollo. Sin embargo, más del 30 % se encontraba
evaluando los contenedores o ejecutando pruebas de concepto8.
Parte de la confusión radica en el significado del uso de contenedores. El proyecto
The Enterprisers Project hizo hincapié en cuatro patrones diferentes para la
adopción de contenedores: utilizarlos como una plataforma general de desarrollo
o implementación, utilizarlos como una plataforma nativa de la nube o de
microservicios, utilizarlos dentro de una nube híbrida o utilizarlos para proyectos
de innovación9. La forma en que utiliza los contenedores puede influir en la manera
de interpretar su adopción.
Para una integración ágil, la idea es crear una plataforma de infraestructura que
admita las operaciones actuales. La plataforma puede tomar elementos de los
patrones de implementación, pero, en esencia, trabaja como una plataforma: una
base tanto para proyectos nuevos como actuales.
Contenedores
La virtualización, la nube y los contenedores son tecnologías similares que persiguen objetivos
similares. Estas tecnologías separan el entorno operativo para el software del hardware físico,
de forma que sea posible apilar más instancias en el hardware y gestionar el uso, la expansión
y la implementación de forma más eficiente. Sin embargo, el desafío que se plantea se logra
abordar de diferentes maneras. La virtualización abstrae el sistema operativo. La nube elimina el
concepto de instancias de servidor exclusivas y permanentes. Los contenedores determinan una
versión del entorno operativo y de las bibliotecas suficiente para ejecutar una sola aplicación.
El enfoque más sencillo y prescriptivo de la tecnología de contenedores es lo que la convierte
en una herramienta ideal para los entornos de software modernos. Todas las instancias utilizan
una definición inmutable, desde el sistema operativo hasta la versión exacta de cada una de
las bibliotecas que se incluye. Gracias a ello, el entorno es altamente repetible y coherente con
cada instancia, lo que es ideal para los canales de integración y distribución continuas (CI/CD).
Además, debido a que una imagen de contenedor únicamente define lo que se necesita para
una sola aplicación, los contenedores se combinan con los microservicios, y la organización de
contenedores también permite coordinar la implementación y la gestión de infraestructuras de
microservicios de gran tamaño.
La combinación de ligereza y repetibilidad de los contenedores hace de ellos una plataforma de
tecnología ideal para la integración ágil.
7 Infografía de 451 Research basada en el informe Cloud-Enabling Technologies Monitor, enero de 2017.
https://451research.com/images/Marketing/press_releases/Application-container-market-will-reach-2-
7bn-in-2020_final_graphic.pdf
8 Encuesta de Bain: For Traditional Enterprises, the Path to Digital and the Role of Containers, noviembre de 2016.
https://www.redhat.com/es/resources/path-digital-containers
9 https://enterprisersproject.com/article/2017/8/4-container-adoption-patterns-what-you-need-know
E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 9
 Los enfoques de integración tradicionales tenían una estructura muy centralizada, en la que los
ESB se encontraban en los puntos más importantes de la infraestructura. Tanto la integración
distribuida como la gestión de API tienen una arquitectura descentralizada que solo implementa
las funcionalidades necesarias en una ubicación o un equipo específicos. Los contenedores
funcionan como la plataforma subyacente para ambos enfoques, gracias a que su naturaleza
inmutable mantiene la coherencia de las imágenes y las implementaciones en todos los entornos,
de modo que puedan implementarse o reemplazarse con rapidez y sin dependencias ni conflictos
confusos.

La clave de una arquitectura distribuida, ya sea con integraciones o con API, es que debe haber
una manera de diseñar e implementar servicios nuevos sin un proceso de aprobación complejo.

Los contenedores permiten que tanto las integraciones distribuidas como las API se traten
como microservicios. Estos ofrecen una herramienta común para los equipos de desarrollo y
operaciones, así como la posibilidad de utilizar procesos de desarrollo rápidos con procesos de
lanzamiento gestionados.

Los contenedores requieren organización

Cada contenedor representa una sola aplicación o servicio, así como un
microservicio representa una funcionalidad única y diferenciada. En una
arquitectura de microservicios, puede haber docenas o incluso cientos de servicios
distintos, que se duplican en los entornos de desarrollo, prueba y producción.
Para esa cantidad de instancias, la capacidad de organizar instancias y ejecutar
tareas avanzadas de administración es fundamental para que el entorno de
contenedores sea efectivo.
Red Hat OpenShift combina los contenedores Docker con el proyecto de
organización Kubernetes de Google e incluye una administración centralizada,
como la gestión de instancias, la supervisión, el registro, la gestión del tráfico
y la automatización, lo cual sería casi imposible en un entorno solamente con
contenedores.
Además, Red Hat OpenShift ofrece herramientas sencillas para desarrolladores,
como los catálogos de autoservicio, la agrupación de instancias en clústeres, la
persistencia de aplicaciones y el aislamiento a nivel de proyecto.
Esta combinación logra un equilibrio entre los requisitos de las operaciones, en
especial para la estabilidad y las pruebas, y las necesidades de los desarrolladores
con el objetivo de facilitar su uso y acelerar las distribuciones.

API
La mayoría de las infraestructuras de información contienen cientos o incluso miles de sistemas,
aplicaciones y recursos. Sin embargo, la interacción entre estos sistemas puede resultar
muy difícil, y es posible que los administradores de TI ni siquiera sepan cuáles de ellos están
disponibles.

Las API son las interfaces para todos los recursos que pueden conectarse utilizando la tecnología
de integración. Se trata de un conjunto de definiciones o reglas que establecen la forma de
comunicación entre las aplicaciones.

A medida que las empresas cambian su enfoque centralizado basado en centros de tecnología
de integración por un enfoque distribuido, el autoservicio se convierte en una prioridad clave.
Los equipos ágiles necesitan autoridad y autonomía para buscar, probar y utilizar servicios
desarrollados tanto dentro como fuera de sus empresas. Una capacidad de API sólida otorga esta
autoridad y autonomía a los equipos. Gracias a las API, los equipos obtienen la integración que
necesitan y, al mismo tiempo, las empresas pueden asegurarse de que se gestionen y apliquen las
políticas de uso, seguridad y autorización. Las API ofrecen a los equipos referencias sobre cómo
se deben diseñar las integraciones.

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 10

 Una API no es lo mismo que una aplicación final. Las API determinan el modo en que las
aplicaciones interactuan y luego los desarrolladores individuales las utilizan como elementos
básicos en sus proyectos. Las API brindan a los desarrolladores y a los equipos un lenguaje
común. Las empresas pueden incluso utilizar sus API para incentivar a las comunidades que
comparten y cooperan con ellas a crear usos nuevos e innovadores para los servicios.

Diferentes API o diferentes subconjuntos de una API pueden estar disponibles para distintos
destinatarios. Las necesidades de un proveedor pueden no ser las mismas que las de los equipos
de desarrollo interno o las de los desarrolladores de la comunidad. La gestión de API incluye el
diseño de la API para la aplicación y el grupo de usuarios, así como la gestión del ciclo de vida
de ella. Las API se gestionan cada vez más como productos, en donde diferentes equipos se
encargan de cada API, pero es necesario garantizar la uniformidad y la facilidad de uso en todos
estos recursos.

Al igual que con la integración distribuida, los contenedores se pueden utilizar como una
plataforma para desarrollar, implementar y gestionar las API de manera que se alinee el
desarrollo de las API con herramientas y procesos de desarrollo y operaciones más grandes.

Una plataforma de API adecuada aumenta las capacidades de los

desarrolladores
El poder de las API proviene de la capacidad de otras personas para utilizarlas,
ya sean desarrolladores internos o usuarios externos. Red Hat 3scale API
Management Platform brinda las herramientas para ayudar a todos los usuarios.
Ofrece un portal para que los desarrolladores colaboren en la creación las API, y un
portal de administración para poder publicarlas.
Además, 3scale API Management Platform brinda autenticación, se integra con los
principales proveedores de nube y se ejecuta dentro de los contenedores para que
las API se puedan utilizar externamente.

Internet Nube pública Cualquier otro

Usuarios extremo de
de API Autorización y acceso público
generación
de informes

3scale

Portal de
Portal de
adminis-
desarrolladores
tradores

Desarrolladores Plataforma de Su equipo de API

gestión de API

Figura 3. Un vistazo a la gestión de las API, los extremos y la nube pública

La estrategia de API combina el diseño de la API con un modo de hacerla pública.

3scale API Management Platform, y especialmente 3scale sobre una plataforma de
contenedores, ofrece los medios para ejecutar esa estrategia.

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 11

 LA ARQUITECTURA DE LA INTEGRACIÓN ÁGIL
Prácticas en equipo
Las principales tecnologías de la integración ágil son más efectivas cuando se implementan y se
ponen a disposición de los equipos como capacidades reutilizables.

Cuando hablamos de capacidad, nos referimos a que los grupos autorizados pueden utilizar
las tecnologías de manera automática, seguir las pautas empresariales con facilidad y acceder
a la información sobre las prácticas recomendadas. Los arquitectos de la información o los
administradores de TI deben definir procesos claros para los diferentes equipos, como los
siguientes:

• Brindar pautas de uso disponibles para todos.

• Aplica normas de uso y prácticas recomendadas cuando corresponda, pero dando la libertad
de experimentación más allá de dichas normas.

• Contar con procesos bien definidos para pasar del prototipo a las pruebas, la puesta en
marcha, las actualizaciones y el retiro.

• Permitir el uso compartido de la información para implementaciones y desarrollos nuevos.

• Utilizar equipos de infraestructura como proveedores o facilitadores de capacidades de

autoservicio, en lugar de obligarlos a formar parte de cada proceso.

Por ejemplo, debería ser posible que un equipo de software desarrolle, pruebe y prepare una
API nueva para lanzarla de una forma totalmente automática, con procesos implementados
para actualizar otros grupos y documentación. Es posible que haya procesos y verificaciones
adicionales con otros equipos antes de la publicación o de la etapa de producción, pero la
infraestructura debe automatizar el proceso tanto como sea posible.

Arquitectura de la infraestructura

Apps a medida Apps móviles Apps de datos inteligentes

Apps de Apps impulsadas por procesos

retráctil

Integración

API

Contenedores

Figura 4. La forma en que las tecnologías de integración ágil atraviesan las pilas de aplicaciones

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 12

 Los contenedores, las API y la integración trabajan en conjunto para brindar capas de base
sólidas para los ecosistemas de software internos de una empresa y, en muchos casos, los puntos
de acceso para las integraciones externas.

Los diferentes tipos de sistemas exponen una variedad de extremos reutilizables, en donde
cada uno se ve como una API que se puede volver a utilizar y donde muchos se ejecutan dentro
de contenedores para lograr escalabilidad y facilidad de implementación. Las integraciones
proporcionan la transformación, la composición o la lógica empresarial integrada, siempre que
sea necesario, en todo el sistema mediante la integración de un grupo de servicios individuales o
la recopilación de resultados de diferentes partes de la organización.

Las aplicaciones integradas se pueden agrupar aún más antes de suministrar las
aplicaciones de usuario final.

Tecnología móvil Partners SaaS

API

Microservicios
compuestos

Basada en
contenedores

Microservicios
ligeros
expandibles

Uso de recursos
Soporte externos
para
sistemas
heredados SaaS
Capacidades de
autoservicio Heredado

Figura 5. Un diseño de infraestructura con contenedores, API e integración distribuida

No se presume que todos los sistemas se dividirán en piezas cada vez más pequeñas o que
atravesarán varias capas de abstracción de API. Esas operaciones pueden reducir la eficiencia,
aumentar la latencia o agregar una complejidad innecesaria propia. En algunas áreas, lo
adecuado puede ser mantener las funcionalidades actuales de ESB heredadas para conservar
las conexiones entre aplicaciones específicas. También es necesario rastrear y gestionar las
dependencias entre sistemas distribuidos utilizando las herramientas adecuadas.

Sin embargo, para el sistema en su totalidad, reestructurar la arquitectura en términos de

contenedores, API e integración significa poder tomar las decisiones correctas para cada
servicio, punto de integración e interacción con los clientes. Por ejemplo, se puede realizar una
verificación de seguridad de las solicitudes entrantes de gran volumen y, luego, enviarlas al
servicio de backend correspondiente, sin experimentar un solo bloqueo de ESB.

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 13

 En entornos híbridos de nube distribuida, muchos de los sistemas backend en cuestión pueden
residir en diferentes ubicaciones físicas. La integración de sistemas que se encuentran cerca
para satisfacer una necesidad local ofrece más seguridad y eficiencia que el enrutamiento de
todos los elementos a través de un único sistema de integración central que contiene la lógica
empresarial clave.

LA CULTURA Y LAS EMPRESAS ÁGILES

El ciclo de vida de la infraestructura es muy diferente del ciclo de vida del desarrollo de software
o de las operaciones. El ciclo del desarrollo consiste en completar un proyecto y luego avanzar
al siguiente. En este caso, el término eficiencia significa aumentar la rapidez con la que se puede
lanzar un producto o la cantidad de funciones que se pueden producir en un momento dado.
Incluso para las operaciones, que se centran más en el mantenimiento y la estabilidad, sigue
siendo beneficioso aplicar parches y actualizaciones de seguridad, implementar nuevos servicios
o hacer retroceder los cambios de forma más eficiente y rápida.

Sin embargo, la infraestructura tiene un enfoque muy diferente. Varios grupos altamente
especializados suelen trabajar en la infraestructura, a diferencia de los equipos interdisciplinarios
que se ocupan de los proyectos específicos de diseño de software, y suelen hacerlo durante
periodos más prolongados. En general, los proyectos de infraestructura son mucho más grandes
que los de software, lo cual significa que posiblemente los ciclos cortos de lanzamiento no sean
capaces de lograr mucho, o que podrían quedar operaciones incompletas. Como escribió Andrew
Froehlich, un profesional de TI empresarial, en InformationWeek: "la infraestructura tiene un
límite de punto de no retorno, en especial con el hardware y los centros de datos; sin embargo,
incluso con la nube pública, se llega a un punto en el que ya no es posible desechar un proyecto y
comenzar de nuevo10. La infraestructura es permanente". Sin embargo, sí es posible conciliar las
metodologías con el rendimiento de la infraestructura.

Los beneficios de los procesos iterativos y con capacidad de respuesta, como los ágiles o los
de DevOps, son evidentes para los equipos de operaciones o desarrollo, pero no tanto para los
de infraestructura. No obstante, el análisis de Froehlich sobre las ventajas y desventajas de la
agilidad para la infraestructura no tiene en cuenta un aspecto fundamental: el alineamiento de
los equipos de infraestructura con los de desarrollo y operaciones. Rohan Pearce escribió en la
revista CIO Magazine sobre convertir a los equipos de infraestructura en celdas de trabajo con un
estilo ágil, en lugar de equipos funcionales11. En los equipos de servicios empresariales de Telstra,
los grupos de desarrolladores simplemente ignoraban sus sistemas internos porque el proceso
de verificación de sistemas o diseño de actualizaciones era muy difícil y complejo. Al ajustar sus
grupos de trabajo, el ciclo se redujo de 212 días a 42 días12.

Este ejemplo demuestra la importancia del cambio de los procesos para que los equipos de
infraestructura aborden mejor las necesidades de sus grupos internos.

Las tecnologías de integración ágil sustentan una infraestructura más ágil. Las API, las imágenes
de contenedores y las integraciones distribuidas son los nuevos métodos de debate en las
conversaciones sobre infraestructuras de software.

10 Froehlich, Andrew, "Should IT go agile? The pros and cons". 6 de octubre de 2015.
http://www.informationweek.com/infrastructure/pc-and-servers/
should-it-go-agile-the-pros-and-cons/d/d-id/1322448
11 Pearce, Ronan, "Can infrastructure be agile?" 20 de junio de 2013.
https://www.cio.com.au/article/465436/can_infrastructure_agile_/
12 http://agilemanifesto.org/

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 14

 En el Manifiesto Ágil, se definen cuatro principios básicos para el desarrollo de software12.
En una infraestructura ágil basada en la integración, se pueden aplicar estos principios a
la estrategia de integración.

1
Individuos e interacciones sobre procesos y herramientas.
En cuanto a la infraestructura, el debate se centra en las interacciones entre los equipos. Estas incluyen
comunicaciones directas, con API, mensajería y patrones de tráfico; interdependencias a nivel de sistemas;
y procesos de prueba y de liberación, como los canales de CI/CD.

Software funcionando sobre documentación extensiva.

2 Por naturaleza, la infraestructura debe ser funcional las 24 horas del día, todos los días del año, y realizar
adaptaciones paulatinas en lugar de grandes cambios. Por eso, una infraestructura en funcionamiento es siempre
un requisito implícito. Como estrategia de infraestructura, "en funcionamiento" significa que la infraestructura
ofrece el comportamiento del usuario final esperado en el límite de rendimiento previsto.

Colaboración con el cliente sobre negociación contractual.

En cuanto a los sistemas de infraestructura, los contratos representan la forma en que los equipos de

3
infraestructura gestionan las dependencias de los sistemas, como las políticas de seguridad, los acuerdos de nivel
de servicio e incluso las API publicadas. Los clientes incluyen usuarios internos y externos de esos sistemas. La
agilidad brinda a esos usuarios la capacidad de participar en los cambios potenciales en las políticas y las interfaces
relacionadas con los sistemas, y les permite ver la ejecución de esos cambios en menos tiempo. El uso de
integraciones distribuidas extiende esa colaboración otorgando el control directamente a los equipos para que
desarrollen e implementen integraciones.

Respuesta ante el cambio sobre seguir un plan.

Este es un principio donde la tecnología respalda el proceso. En términos de infraestructura, los sistemas deben

4 permanecer estables, pero las tecnologías más nuevas, como los contenedores, ofrecen una plataforma que es
flexible. Es posible agregar y quitar instancias de forma dinámica en función de la demanda, automatizar las
implementaciones y las actualizaciones, y coordinar los cambios en varias instancias. Las definiciones de API
publicadas brindan herramientas reutilizables para que el desarrollo sea más uniforme. Este enfoque resulta en
una plataforma estable diseñada para adaptarse al cambio.

Figura 6. Principios básicos para el desarrollo de software, del Manifiesto Ágil

La integración ágil utiliza la tecnología para respaldar el cambio cultural dentro de los equipos
de infraestructura. Funciona como la base para la estrategia de infraestructura. Se encarga
de alinear estrechamente las tecnologías de infraestructura y sus equipos con las estrategias
empresariales y de desarrollo.

La metodología ágil identifica algunas piezas clave de un proyecto de software, como las
personas, los diseños y las dependencias, y luego define la relación entre estos elementos.
Si abordamos la infraestructura de integración como un proyecto ágil, es posible identificar
elementos y relaciones similares, que establecen un paralelismo con aquellos que se definen en
la metodología ágil, como los equipos, las imágenes de contenedores, las API y los puntos de
integración. En la tabla 3, se describen algunas de las similitudes.

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 15

 TABLA 3. COMPARACIÓN DE LOS ELEMENTOS DEL ENFOQUE ÁGIL DE SOFTWARE Y
EL ENFOQUE ÁGIL DE INFRAESTRUCTURA

PROYECTO DEL LIBRO DETALLES

Partes Equipos Los equipos están a cargo de partes específicas de la

individuales infraestructura. Esto identifica la información en torno a las
responsabilidades del equipo, como los sistemas o las API que
se encarga de gestionar, los líderes del equipo y sus objetivos.

Módulos API Las interfaces (API) bien definidas se mantienen estables

en el tiempo, tienen sus propias hojas de ruta, están a cargo
de equipos específicos y crean una capacidad particular
importante dentro de la empresa.

Diseños Imágenes de Los lanzamientos se basan en unidades fáciles de implementar,

contenedores que se han probado y etiquetado, y que cualquier equipo
con acceso puede implementar de manera confiable. Esto
reemplaza el código monolítico versionado.

Dependencias Integraciones Este elemento identifica las integraciones y las asignaciones

de compilación entre los diferentes elementos de los sistemas distribuidos.
Estos puntos de integración pueden gestionarse, encargarse,
retirarse, versionarse y probarse, al igual que cualquier otra
parte del sistema.

Pruebas de Automatización Se trata de una gestión completa del ciclo de vida, desde la
implementación de la capacidad para probar los diseños de software, el rendimiento
infraestructura y los requisitos del usuario hasta operar y supervisar varios
sistemas.

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 16

 Aplicación de los principios ágiles a la planificación de la infraestructura
La mayoría de los enfoques de gestión de cambios requieren una documentación
completa de todos los subsistemas. Esta documentación debe cubrir en detalle
cada aspecto del sistema, desde el método de supervisión, los parámetros de
rendimiento hasta los equipos responsables. Los principios ágiles requieren
colaboración y adaptabilidad, lo que entra en conflicto con la gestión de cambios
con mucha documentación.
En lugar de intentar definir las normas de todos los posibles cambios, elementos
del sistema y partes interesadas, defina un conjunto de pautas y estándares que se
puedan utilizar para evaluar la planificación y las solicitudes de cambio. Tenga en
cuenta las siguientes preguntas:
• ¿Cuál es la experiencia completa que se desea para el usuario?

• ¿De qué manera contribuye cada equipo, API y sistema a la mejora de esta experiencia
con el paso del tiempo?

• ¿Cómo se definirán las alertas y la supervisión para mantener los niveles de servicio?
¿y para qué parámetros?

• ¿Qué tipo de pruebas automatizadas se necesitan para verificar el comportamiento

esperado?

• ¿Cuál es el canal de lanzamiento para que los equipos prueben e implementen versiones
nuevas de sus propios subsistemas sin alterar la experiencia del usuario?

• ¿De qué manera afecta una falla en el servicio de elementos a los niveles de servicio del
sistema completo?

La gestión de cambios dentro de una infraestructura ágil no debería ser un

contrato, sino más bien una colaboración constante.

¿Están las probabilidades a su favor?

¿Qué probabilidades hay de que su proyecto de TI tenga éxito? En primer lugar,
depende de conocer sus criterios de éxito, ¿se trata de que cumpla con las
especificaciones, de aumentar su adopción por parte de los clientes o simplemente
de lanzarlo al mercado? Para el grupo de capacitación en gestión de proyectos
4PM, tener éxito es completar un proyecto sin salirse del presupuesto, dentro del
tiempo estimado y de conformidad con las especificaciones13. En función de esta
definición, estiman que el 70 % de los proyectos de TI fracasan13. Sin embargo,
esos números están comenzando a cambiar. En una encuesta reciente del Project
Management Institute, se descubrió que son más los proyectos que alcanzan sus
metas establecidas en la actualidad, en comparación con los últimos cinco años14.
Este repunte se atribuye a una alineación más sólida entre los equipos de TI y de
negocios, lo que resulta en mejor información sobre la estrategia y las necesidades
de los clientes8.
Uno de los motivos de esa alineación estratégica es la implementación de equipos
ágiles. La metodología ágil promueve la colaboración y los comentarios, una visión
integral de los problemas y los sistemas, y enfoques creativos.

13 4PM.com, "Why projects fail so often". 27 de septiembre de 2015.

http://4pm.com/2015/09/27/project-failure/
14 Florentine, Sharon, "IT project success rates finally improving". 27 de febrero de 2017.
https://www.cio.com/article/3174516/project-management/it-project-success-rates-finally-improving.html

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 17

 Al contar con una pila de tecnología compartida, el debate se centra en los sistemas y sus
interdependencias, en lugar de en el código independiente. Se trata de pensar a nivel de sistemas,
que trata toda la collección del sistema al conjunto completo de infraestructura de software,
incluido el software desarrollado internamente, los sistemas de proveedores y las conexiones
entre ellos como un único sistema. Los sistemas de mensajería y las API pueden abarcar toda la
infraestructura y trabajar para unificar los sistemas de software.

Debido a que tanto las API como las integraciones distribuidas se pueden desarrollar y
comprender dentro de los equipos individuales de operaciones o de desarrollo, el conocimiento
de las responsabilidades de los equipos respecto de las integraciones está mucho más claro.
Es posible comprender mejor las integraciones en sí porque los equipos que se encargan del
desarrollo y de la implementación reconocen las interdependencias entre los sistemas y las
aplicaciones.

El uso de la integración como base para la infraestructura, y luego la distribución de la

responsabilidad de esa integración entre los equipos, crea un entorno de infraestructura en el
que los enfoques ágiles cobran mayor relevancia.

CONCLUSIÓN: CÓMO OFRECER UNA INTEGRACIÓN ÁGIL

La agilidad es un proceso, no un proyecto.

Nunca ha sido tan importante para las empresas poder reaccionar ante los cambios en el
mercado y, en gran parte, son los sistemas de TI los que deben ofrecer la capacidad de lanzar
servicios nuevos o de actualizar los actuales con rapidez. En la actualidad, es fundamentalmente
importante reconsiderar la infraestructura de TI, ya que es la base de los servicios digitales.

Los equipos de infraestructura siempre han estado ligados a procesos modulados y muy
extensos, debido a la necesidad de mitigar los riesgos y mantener la estabilidad. Sin embargo, es
posible cambiar la mentalidad en materia de infraestructura, de una basada en la plataforma o
el hardware a una basada en la integración. La integración no se trata de un subconjunto de la
infraestructura, es más bien un enfoque conceptual de ella que incluye datos y aplicaciones con
hardware y plataformas.

Definimos este enfoque como integración ágil, una manera de utilizar tecnologías de integración
para crear una infraestructura más ágil y adaptable. Los pilares tecnológicos de la integración
ágil son tres:

• La integración distribuida, que utiliza los patrones de integración empresarial y de mensajería

para integrar datos y sistemas. Estos se desglosan en integraciones pequeñas impulsadas por
los equipos que se distribuyen en proyectos y puntos de contacto, según sea necesario.

• La gestión de API interna, que crea un conjunto reutilizable de interfaces para permitir que los
equipos de desarrollo se dediquen a las aplicaciones y los sistemas. Las API brindan las pautas
y la estructura para la interacción entre las aplicaciones.

• Los contenedores, que no solo permiten que los proyectos de integración se alineen
estrechamente con los de desarrollo y operaciones, sino también que las integraciones se
desarrollen, prueben y lancen de forma similar a los proyectos de software, utilizando los
métodos de DevOps.

es.redhat.com E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial 18

 E-BOOK  Integración ágil: El plano técnico para la arquitectura empresarial

La tecnología debe utilizarse para respaldar el cambio cultural, y esto implica trabajar para
que los equipos de infraestructura, y no solo su software, sean más ágiles. A medida que
los equipos de infraestructura trabajan para alinearse con los principios ágiles, se puede
introducir la tecnología de forma progresiva para respaldar esos cambios. No hay un
proyecto único capaz de rediseñar una empresa completa para que sea ágil. Puede ser más
efectivo implementar una tecnología de integración ágil o cambiar un área de la empresa y,
luego extender, esos cambios de manera progresiva.

Mejorar la capacidad de respuesta al cambio de la infraestructura de TI es un objetivo

estratégico a largo plazo. Para progresar, no es necesario realizar cambios radicales en toda
la empresa. Es posible que ni siquiera sea necesario realizar cambios de forma aislada y
luego implementarlos en otras áreas.

La integración ágil brinda un marco, tanto técnico como empresarial, para volver a diseñar la
infraestructura de TI.

ACERCA DE RED HAT

Red Hat es el proveedor líder de soluciones de software de open source para empresas, que
adopta un enfoque basado en la comunidad para ofrecer tecnologías confiables y de alto
rendimiento de Linux, nube híbrida, contenedores y Kubernetes. Red Hat ayuda a los clientes
a integrar aplicaciones de TI nuevas y existentes, desarrollar aplicaciones nativas de la nube,
estandarizar en nuestro sistema operativo líder del sector y automatizar, proteger y gestionar
entornos complejos. Sus servicios galardonados de soporte, capacitación y consultoría convierten
a Red Hat en un asesor de confianza para las empresas de Fortune 500. Como partner estratégico
de proveedores de nube, integradores de sistemas, proveedores de aplicaciones, clientes y
comunidades de open source, Red Hat puede ayudar a las organizaciones a prepararse para el
futuro digital.

ARGENTINA CHILE COLOMBIA

+54 11 4329 7300 +562 2597 7000 +571 508 8631
+52 55 8851 6400
facebook.com/redhatinc
@redhatla MÉXICO ESPAÑA
linkedin.com/company/red-hat +52 55 8851 6400 +34 914 148 800

es.redhat.com Copyright © 2019 Red Hat, Inc. Red Hat, Red Hat Enterprise Linux, el logotipo de Shadowman y JBoss son marcas comerciales
f11423_0518 o marcas comerciales registradas de Red Hat, Inc. o sus subsidiarias en Estados Unidos y en otros países. Linux® es la marca
comercial registrada de Linus Torvalds en EE.UU. y en otros países.