La integración siempre ha sido una palabra maldita, en el sentido de que evoca el rechinar de dientes y los lamentos de quienes se consumen trabajando en proyectos dedicados a su implementación. De hecho, el 59 % de los responsables de la toma de decisiones de TI calificó «la integración como el 'talón de Aquiles' de su organización». (Informe de 2018 sobre la integración de empresas conectadas)
A primera vista, la integración parte de una premisa sencilla: ¿cómo compartimos datos entre aplicaciones? Porque ninguna aplicación —ni siquiera una monolítica— es una isla. Todavía no he encontrado ninguna aplicación que no comparta al menos un dato con otra.
Nosotros (es decir, el sector) hemos atravesado varias etapas en materia de integración. Desde los modelos de concentrador y radios hasta el bus de servicios empresariales y las colas de mensajes, la integración siempre es un componente esencial de la estrategia de aplicaciones empresariales.
Ya no lo llamamos Integración de Aplicaciones Empresariales (EAI), principalmente porque creo que eso asusta a los jóvenes y provoca ataques de apoplejía a los más veteranos, pero seguimos utilizando la palabra «integración». Y cada vez la usamos más fuera del ámbito del desarrollo de aplicaciones. Al fin y al cabo, CI significa integración continua. También consideramos que la integración es importante en el ámbito del despliegue (producción). Y observamos tanta frustración como entre nuestros homólogos del desarrollo de aplicaciones, como ponen de manifiesto quienes se sienten frustrados por la falta de herramientas integradas al abordar la automatización de la red.
Las operaciones necesitan integración. Sin ella, no podemos automatizar los procesos (que es precisamente en lo que consiste la orquestación), porque estos abarcan necesariamente múltiples sistemas, servicios y dispositivos, cada uno de los cuales probablemente tenga su propio dominio operativo y conjunto de herramientas. Sin integración, no se puede crear un flujo de trabajo y, sin él, los equipos de operaciones se verán desbordados por la creciente necesidad de realizar despliegues frecuentes bajo demanda.
Aquí es donde la infraestructura como código y los repositorios pueden resultar de gran ayuda. Los repositorios son mucho más que un lugar donde almacenar prácticamente cualquier tipo de artefacto, desde archivos de configuración y programas en Python hasta scripts y plantillas. Pueden participar activamente en su canalización de despliegue (integrada).
Los repositorios son más que simples cofres de almacenamiento
Los repositorios no son solo un lugar donde almacenar artefactos. Sí, esa es su función principal, pero han evolucionado hasta convertirse en mucho más que un simple almacén. Hoy en día, repositorios como GitLab y GitHub pueden ser un componente clave de un flujo de trabajo automatizado. Mediante desencadenadores y eventos, los repositorios no solo sirven para almacenar artefactos, sino que también funcionan como herramientas dentro de una cadena de herramientas más amplia. Un commit inicia una tarea que, al finalizar, invoca un webhook que desencadena el siguiente paso del flujo de trabajo.
¿Qué es un webhook?
A veces denominado «API inversa», un webhook permite que una aplicación —como un repositorio— envíe datos en tiempo real a otra aplicación 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 su URI a una aplicación (o directamente al balanceador de carga), que carga la nueva configuración.
Básicamente, utilizamos los repositorios de forma muy similar a como antes utilizábamos un bus de servicios empresariales para compartir datos e iniciar acciones en distintas aplicaciones y servicios con el fin de completar un «proceso». En el ámbito empresarial, ese proceso podría consistir en completar el pedido de un cliente e implicar al sistema de información de clientes (CIS), un sistema de gestión de pedidos, la facturación y diversos elementos de la cadena de suministro.
En el ámbito de las operaciones, ese proceso abarca los servicios de infraestructura, red y seguridad necesarios para llevar a cabo el despliegue de una aplicación o una política.
Y lo que resulta aún más interesante para quienes señalaron las «competencias» como su principal reto es que los repositorios pueden controlarse casi exclusivamente desde la línea de comandos. Sí, utilizando las mismas competencias que ya posee la mayoría de los profesionales de NetOps. Un poco de bash y algo de PERL*, una API mediante curl y ¡listo!
Ahora bien, esto no resuelve la necesidad más profunda de integración en la capa de dispositivos, que se refleja en la frustración provocada por la falta de soluciones de los proveedores. Porque, en última instancia, la configuración o los cambios de configuración almacenados en el repositorio y activados mediante un Webhook todavía tienen que traducirse al lenguaje de los dispositivos.
Y ahí es donde entran en juego la estandarización y las soluciones.
La estandarización reduce la carga de la integración operativa
La automatización es algo en lo que muchos de nosotros en F5 estamos centrados actualmente. Una de las soluciones que hemos desarrollado es nuestro conjunto de herramientas de automatización de F5. Está compuesto por F5 Application Services 3 Extension (AS3), F5 Declarative Onboarding (DO), F5 Telemetry Streaming y F5 API Services Gateway. Junto con un repositorio, estas herramientas permiten a las organizaciones crear el flujo de trabajo que necesitan para implementar los servicios de aplicaciones que requieren tanto una aplicación como la empresa 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.
Es cierto. Esta es una de las formas en que la estandarización en una plataforma común de servicios de aplicaciones puede resultar útil. Dado que la plataforma (BIG-IP) es la misma para una amplia gama de servicios de aplicaciones, puede utilizar la cadena de herramientas de automatización para implementar, entre otros, un WAF, un equilibrador de carga, controles de acceso y protección contra DDoS. Estandarizar en el menor número posible de plataformas aporta valor al reducir la carga de integración en todas las áreas operativas: redes, infraestructura y seguridad.
Esto es cierto tanto dentro del centro de datos como en un entorno multinube. La estandarización en una única plataforma para los servicios de aplicaciones y los entornos de nube permite obtener valor más rápidamente al implementar aplicaciones en cualquier lugar.
Puede encontrar la cadena de herramientas de automatización de F5 (totalmente gratuita) en varios lugares:
Así que recuerde: los repositorios no son solo un lugar donde almacenar cosas. Son una herramienta muy valiosa en su arsenal de automatización que puede utilizarse para ayudar a automatizar todos los componentes dispares de su canalización. La estandarización en torno a un repositorio y una plataforma de servicios de aplicaciones puede contribuir en gran medida a reducir la carga operativa que impone esa palabra de cuatro letras: integración.
*interpreta «PERL» como Python o algún lenguaje de scripting que sea realmente útil. PERL es simplemente el único que rima con curl y no he encontrado nada que rime bien con wget.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.