Integración siempre ha sido una palabra de cuatro letras en el sentido de que evoca el crujir de dientes y las lamentaciones de quienes languidecen en proyectos dedicados a su implementación. De hecho, el 59% de los responsables de TI caracterizaron la integración como el 'talón de Aquiles' de su organización ( Informe Connected Business Integration 2018 ).
A primera vista, la integración comienza con una premisa simple: ¿cómo compartimos datos entre aplicações? Porque ninguna aplicação –ni siquiera un monolito– es una isla. Aún no he conocido una aplicação que no compartiera al menos un dato con otra aplicação.
Nosotros (como en la industria) hemos pasado por varias eras de integración. Desde los modelos de concentrador y radio hasta el bus empresarial (de servicio) y las colas de mensajes, la integración es siempre un componente integral de una estrategia de aplicação empresariales.
Ya no lo llamamos Integración de Aplicação Empresariales (EAI) —principalmente porque pienso que asusta a los jóvenes y nos provoca a los veteranos ataques de apoplejía— pero todavía utilizamos la palabra "integración". Y lo utilizamos cada vez más fuera del mundo del desarrollo de aplicação . CI, después de todo, significa integración continua. También consideramos que la integración es importante para el aspecto de implementación (producción) del mundo. Y vemos tanta frustración como nuestros colegas desarrolladores de aplicaciones, como lo señalan aquellos que están frustrados por la falta de herramientas integradas cuando se enfrentan a la automatización de la red.
Las operaciones necesitan integración. Sin ella, no podemos automatizar procesos (que es lo que es la orquestación) porque los procesos necesariamente abarcan múltiples sistemas, servicios y dispositivos, cada uno de los cuales probablemente tiene su propio dominio operativo y conjunto de herramientas. Sin integración, no se puede crear un pipeline y, sin un pipeline, las operaciones se verán abrumadas por el creciente requerimiento de implementaciones frecuentes a pedido.
Aquí es donde la infraestructura como código y los repositorios pueden brindar alivio. Los repositorios son más que un lugar donde puedes almacenar prácticamente cualquier tipo de artefacto, desde archivos de configuración hasta programas Python, scripts y plantillas. Pueden ser un participante activo en su proceso de implementación (integrado).
Los repositorios no son sólo un lugar para almacenar artefactos. Quiero decir, sí, ese es su propósito principal, pero han evolucionado hasta convertirse en mucho más que un simple depósito de almacenamiento. Hoy en día, repositorios como GitLab y GitHub pueden ser un componente clave del proceso de automatización. Al utilizar activadores y eventos, los repositorios actúan no solo como un lugar para almacenar artefactos, sino como herramientas en una cadena de herramientas más grande. La confirmación inicia un trabajo que, cuando finaliza, invoca un webhook que activa el siguiente paso en el proceso.
Un webhook, a veces llamado "API inversa", permite que una aplicação (como un repositorio) envíe datos en tiempo real a aplicação mediante una URL/API. Por ejemplo, al confirmar una nueva configuración para el balanceador de carga, el repositorio activa un webhook que, a su vez, envía la configuración o la URI de la configuración a una aplicación (o directamente al balanceador de carga), que a su vez carga la nueva configuración.
Básicamente, utilizamos repositorios de la misma forma que solíamos utilizar un bus de servicio empresarial para compartir datos e iniciar acciones en diferentes aplicações y servicios para completar un "proceso". En el mundo empresarial, ese proceso podría ser completar un pedido de un cliente e involucrar el sistema de información del cliente (CIS), un sistema de cumplimiento de pedidos, facturación y elementos de la cadena de suministro.
En el mundo de las operaciones, ese proceso abarca la infraestructura, la red y los servicios de seguridad involucrados en el cumplimiento de la implementación de una aplicação o política.
Aún más emocionante para aquellos que citaron las "habilidades" como su principal desafío es que los repositorios se pueden controlar casi exclusivamente desde la línea de comandos. Sí, utilizando las mismas habilidades que ya poseen la mayoría de los NetOps. ¡Un poco de bash y algo de PERL*, una API vía curl y listo!
Ahora bien, eso no aborda la necesidad más profunda de integración a nivel de dispositivo, que se expresa en la frustración por la falta de soluciones de los proveedores. Porque, en última instancia, la configuración o los cambios en la configuración que se almacenan en el repositorio y se activan mediante un webhook todavía tienen que traducirse al lenguaje del dispositivo.
Y aquí es donde entran en juego la estandarización y las soluciones.
La automatización es algo en lo que muchos de nosotros en F5 estamos centrados en este momento. Una de las soluciones que hemos ideado es nuestra cadena de herramientas de automatización F5 . Incluye la extensión F5 Aplicação Services 3 (AS3), F5 Declarative Onboarding (DO), F5 Telemetry Streaming y F5 API Services Gateway. Junto con un repositorio, pueden permitir a las organizaciones desarrollar el flujo de trabajo que necesitan para implementar los servicios de aplicação que una aplicação (y el negocio) necesita para mantener las aplicaciones rápidas, seguras y disponibles.
Pero Lori, estarás pensando que eso no me ayuda con todos los demás dispositivos y servicios que necesito automatizar e integrar.
Verdadero. Esta es una de las formas en que la estandarización en una plataforma de servicios de aplicação común puede ayudar. Dado que la plataforma (BIG-IP) es la misma para un amplio conjunto de servicios de aplicação , puede utilizar la cadena de herramientas de automatización para implementar un WAF, un balanceador de carga y control de acceso, así como protección DDoS, entre otros. La estandarización en la menor cantidad de plataformas posible agrega valor al reducir la carga de integración en todas las operaciones: red, infraestructura y seguridad.
Esto es cierto dentro de los confines del centro de datos y en un escenario de múltiples nubes. La estandarización en una única plataforma para todos los servicios de aplicação y entornos de nube significa un tiempo más rápido para obtener valor al implementar aplicaciones en cualquier lugar.
Puede encontrar la cadena de herramientas de automatización F5 (totalmente gratuita) en varios lugares:
Así que recuerda, los repositorios no son sólo un lugar para almacenar cosas. Son una herramienta valiosa en su conjunto de herramientas de automatización que puede utilizar para ayudar a automatizar todas las partes dispares de su canalización. La estandarización de un repositorio junto con una plataforma de servicios de aplicação puede contribuir en gran medida a reducir la carga operativa impuesta por esa palabra de cuatro letras: integración.
*interpretar "PERL" como Python o algún lenguaje de programación que sea realmente utilizable. PERL es el único que rima con curl y no he encontrado nada bueno que rime con wget .