Integración Asíncrona Slack-jira Vía “Middleware” de Colas: Comparación de Soluciones de “Cloud Computing”

Julia Cabral Diniz Braz; Marcos Jardel Henriques

DOI: 10.22167/2675-6528-202603094

Artículo derivado del Trabajo de Conclusión de Curso (TCC), con contenido basado en el trabajo original del alumno y adaptado al formato editorial de la Revista E&S con el apoyo de la herramienta ResumeAI, solución de inteligencia artificial desarrollada por el Instituto Pecege para síntesis y organización textual.

Resumen

La latencia y la interoperabilidad entre sistemas corporativos distribuidos constituyeron el problema investigado, motivado por los costos y fragilidades de las integraciones manuales entre plataformas de colaboración y gestión de proyectos. Se desarrolló y validó un “middleware” de integración asíncrona entre Slack y Jira, con el objetivo de reducir el tiempo de respuesta percibido por el usuario y garantizar la estabilidad del sistema bajo carga. La metodología consistió en la construcción de una arquitectura de software orientada a eventos en Python, utilizando los patrones “producer-consumer” y “adapter” para aislar la interfaz del usuario del procesamiento de “backend”. La solución evolucionó hacia una arquitectura agnóstica de nube, basada en funciones “serverless”, y fue sometida a pruebas de estrés en entornos local, de red real y de producción en dos nubes. La arquitectura redujo el tiempo de espera del usuario de una estimación síncrona de 2.000 milisegundos a una media local de 8,96 milisegundos. Bajo carga de 50 peticiones simultáneas, ambos proveedores de nube se mostraron viables: Amazon Web Services registró menor latencia media en la capa de recepción (951,35 ms) y el doble de rendimiento, mientras que Microsoft Azure ejecutó el procesamiento en segundo plano con una mediana de 113 ms. La aplicación de “optimistic UI” aseguró fluidez de uso, y la nivelación de carga por colas dispensó el sobredimensionamiento de infraestructura. El “middleware” se consolidó como un modelo de referencia corporativa escalable, resiliente y protegido contra el aprisionamiento tecnológico.

Palabras clave: Arquitectura orientada a eventos; Desacoplamiento temporal; Eficiencia operativa; Gestión de servicios de tecnología de la información; Interoperabilidad de sistemas.

1. Introducción

En el entorno de una empresa de tecnología, la integración entre herramientas de comunicación y de gestión de proyectos ha demostrado ser esencial para garantizar la productividad, la trazabilidad y la eficiencia operativa. Slack, ampliamente utilizado como plataforma de mensajería corporativa para la comunicación ágil entre equipos, y Jira, reconocido sistema de gestión de proyectos, ocupan una posición central en las rutinas de desarrollo y gestión de software, actividades cuya coordinación depende directamente de la calidad de los flujos de información que atraviesan las fronteras entre productos (Sommerville, 2019).

A pesar de su importancia, la latencia y la interoperabilidad entre sistemas corporativos distribuidos constituyen un problema recurrente. Las integraciones manuales entre plataformas de colaboración y herramientas de gestión de proyectos son frecuentemente onerosas y frágiles. Las integraciones nativas entre estas plataformas, específicamente entre Slack y Jira, presentan limitaciones significativas y acarrean costos adicionales, una fragilidad que la literatura de integración corporativa atribuye a la ausencia de un intermediario de mensajes dedicado entre las aplicaciones (Hohpe y Woolf, 2012).

En una empresa de tecnología analizada, por ejemplo, los mensajes de Slack se transferían a una hoja de cálculo en Google Sheets, y un script se encargaba de crear las tarjetas en Jira. Aunque funcional, este enfoque presentaba limitaciones de escalabilidad, seguridad y mantenimiento, deficiencias características de las integraciones punto a punto construidas sin una capa de desacoplamiento (Newman, 2015).

Ante este escenario, se propuso el desarrollo de un middleware orientado a eventos, basado en sistemas de colas de mensajes. Esta solución tiene como objetivo intermediar y gestionar la comunicación entre Slack y Jira de manera eficiente, segura y escalable, abstraendo la complejidad de la integración entre interfaces de programación de aplicaciones. El objetivo es promover un flujo automatizado y monitorizable de datos entre los sistemas, garantizando mayor fluidez y confiabilidad operativa.

Además de resolver un problema práctico, este proyecto contribuye a la mejora de competencias en integración de sistemas, arquitecturas orientadas a eventos, colas de mensajes y computación en la nube, temas de gran relevancia en la ingeniería de software contemporánea. La literatura reciente evidencia la importancia de análisis comparativos entre proveedores de nube para fundamentar elecciones tecnológicas (Al-Sayyed et al., 2019; Kaushik et al., 2021; Palumbo et al., 2021; Madhuri y Sowjanya, 2016; Gupta et al., 2021). En este contexto, la comparación entre los servicios de cola administrada de las dos nubes, propuesta en este trabajo, no solo fundamenta la elección arquitectónica más adecuada, sino que también contribuye al avance del conocimiento sobre soluciones de mensajería en la nube bajo distintas perspectivas de costo, confiabilidad y desempeño.

La relevancia del estudio reside, por lo tanto, en su capacidad de ofrecer una solución robusta para un problema común en entornos corporativos, al mismo tiempo que profundiza la discusión académica sobre las mejores prácticas en integración de sistemas distribuidos y computación en la nube. El objetivo general de este trabajo fue desarrollar y validar un “middleware” de integración asíncrona entre Slack y Jira, capaz de reducir el tiempo de respuesta percibido por el usuario y de garantizar la estabilidad del sistema bajo carga.

2. Material y Métodos

La investigación se caracterizó por ser aplicada y de naturaleza tecnológica, enfocada en el desarrollo y validación de un “middleware” de integración asíncrona entre Slack y Jira. La metodología adoptó una arquitectura de software orientada a eventos (Gil, 2002), con el objetivo de reducir el tiempo de respuesta percibido por el usuario y garantizar la estabilidad del sistema bajo carga.

El desarrollo se realizó en cuatro etapas: implementación de microsservicios desacoplados en Python; aplicación de interfaz optimista (“optimistic UI”); ejecución de pruebas de estrés para medir latencia y rendimiento; y comparación de rendimiento y portabilidad del sistema entre procesamiento local e infraestructuras de mensajería en la nube pública.

La arquitectura se basó en la descomposición en microservicios independientes, siguiendo el patrón Productor-Consumidor (Newman, 2015). El “producer” fue diseñado para la recepción de peticiones HTTP, y el “worker” refactorizado para el enfoque “serverless” y funciones orientadas a eventos. Esta segregación de responsabilidades evitó bloqueos (Hohpe y Woolf, 2012). Para interoperabilidad e independencia de proveedor, se aplicó el patrón “adapter” (Gamma et al., 1995), unificando métodos de comunicación entre colas locales y servicios de cola gestionados en la nube. El uso de colas para nivelación de carga (“queue-based load leveling”) evitó el sobredimensionamiento de recursos (Armbrust et al., 2010).

La solución se implementó en módulos distintos, con capas de recepción y procesamiento. La capa de recepción utilizó frameworks y bibliotecas para absorber interactividades del usuario y transferir ejecuciones pesadas a la cola de mensajes, devolviendo un código de éxito inmediato para sortear el tiempo límite de Slack (Slack Technologies, 2025). La capa de procesamiento consumió mensajes de la cola y ejecutó transacciones a través de la interfaz de programación de Jira (Atlassian, 2025).

La abstracción de la infraestructura aseguró la agnóstica de la aplicación al entorno de implementación. El mapeo de canales evolucionó a funciones “serverless” y persistencia en servicios NoSQL gestionados en la nube. Puntos de entrada nativos integraron la solución “serverless” en proveedores como AWS y Azure. La interfaz gráfica para la gestión del sistema se desarrolló en HTML5 y Bootstrap, proporcionando un panel visual para la vinculación de las configuraciones de canal. La lógica del sistema fue documentada por pseudocódigos, y la validación funcional por capturas de pantalla, registrando la eficacia de la interfaz de usuario.

La validación de la arquitectura se realizó mediante pruebas de estrés, utilizando un “script” de automatización en Python con la biblioteca `concurrent.futures`. Se definieron tres escenarios experimentales para la recopilación de datos. En el primero, de línea base, se dispararon cien solicitudes paralelas en diez hilos de ejecución, con la capa de recepción y el “worker” operando en la misma máquina física, eliminando la latencia de red externa.

En el segundo escenario, de red real, se dispararon cien solicitudes en diez hilos de ejecución a través de un túnel HTTP seguro, forzando el tráfico a recorrer la red pública. El tercer escenario, de producción, ejecutó la prueba en infraestructuras “serverless” reales, con una carga de cincuenta solicitudes simultáneas en diez hilos de ejecución contra las instancias de los dos proveedores de nube.

Los datos de respuesta, incluyendo la situación de la petición HTTP y el tiempo de latencia en milisegundos, se extrajeron localmente a archivos CSV en los dos primeros escenarios y directamente de las herramientas oficiales de monitorización de las nubes en el tercero. Para el análisis cuantitativo, se aplicaron métodos de estadística descriptiva, utilizando la biblioteca `statistics` del lenguaje Python, calculándose la media aritmética simple, la mediana y el rendimiento para sintetizar el comportamiento de la latencia del sistema.

3. Resultados y Discusión

Los resultados obtenidos demostraron la viabilidad técnica y la eficiencia operativa de la arquitectura orientada a eventos aplicada a la integración de sistemas ofertados como servicio. Los datos recopilados permitieron evaluar la solución desde tres perspectivas distintas: el rendimiento computacional, el comportamiento en red y la integridad funcional. La investigación validó la hipótesis de que un “middleware” asíncrono puede mitigar la latencia y garantizar la estabilidad en sistemas distribuidos, un desafío común en entornos corporativos que dependen de la interoperabilidad entre plataformas como Slack y Jira.

El análisis de rendimiento del sistema se llevó a cabo en dos etapas distintas, con el propósito de aislar el tiempo de procesamiento computacional de la latencia impuesta por la infraestructura de red. En ambos escenarios, se utilizó el protocolo de pruebas de estrés con el disparo de cien solicitudes simultáneas, simulando el comportamiento de múltiples usuarios. Este enfoque permitió una evaluación robusta de la capacidad de la solución para manejar picos de demanda, un requisito crítico para sistemas de integración en tiempo real.

En el primer escenario experimental, caracterizado como línea base, la arquitectura propuesta presentó alta eficiencia en el procesamiento de ingesta de datos. De las cien solicitudes disparadas simultáneamente por el “script”, se registró una tasa de éxito del cien por cien, sin ocurrencia de errores o de tiempos de espera excedidos. La latencia media de respuesta de la capa de recepción fue de 8,96 milisegundos, con un tiempo mínimo de 5,28 milisegundos y máximo de 26,08 milisegundos. El rendimiento del sistema superó la marca de 1.000 solicitudes por segundo.

Tales valores indicaron que el desacoplamiento por colas eliminó el tiempo de espera de procesamiento del “backend” y devolvió el control al cliente de forma casi instantánea. La estabilidad del sistema durante la prueba de carga fue notable, con la línea de latencia manteniéndose constante, en torno a siete milisegundos, después de las diez primeras solicitudes. Esto demostró que la aplicación no sufrió degradación de rendimiento incluso bajo concurrencia de múltiples hilos de ejecución, validando la robustez del diseño asíncrono.

En el segundo escenario, que simuló condiciones reales de acceso remoto por túnel seguro, la media de tiempo de respuesta aumentó a 605,93 milisegundos. Este aumento se atribuyó al tiempo de transporte de los paquetes por la red, conocido como “round trip time”, ya que el procesamiento interno de la aplicación se mantuvo inalterado. Incluso con la latencia de red añadida, el sistema preservó la integridad de los datos y procesó la carga total en 6,13 segundos, lo que validó la robustez de la solución para entornos en la nube.

A pesar de la fluctuación natural de la red, la estabilidad del sistema se mantuvo inalterada, evidenciando que, incluso bajo condiciones de latencia variable, la aplicación preservó la consistencia del servicio, sin fallos. Este comportamiento es crucial para garantizar una experiencia de usuario fluida y confiable en integraciones que dependen de infraestructuras de red externas, como es el caso de sistemas distribuidos que interactúan con servicios en la nube.

La comparación de los resultados obtenidos con los tiempos medios de respuesta de una arquitectura síncrona tradicional, estimados de forma conservadora en 2.000 milisegundos para operaciones en la plataforma Jira, sumados a la latencia de red, evidenció una ganancia sustancial de rendimiento de la solución desarrollada. En el escenario de línea base, la solución asíncrona se mostró aproximadamente 223 veces más rápida desde la perspectiva de la respuesta al usuario, un avance significativo en la eficiencia operacional.

En el escenario con latencia de red, la respuesta de 605,93 milisegundos representó una reducción de aproximadamente el 77% en el tiempo de espera total, en comparación con la suma hipotética de la latencia de red y el tiempo de procesamiento síncrono, de aproximadamente 2.600 milisegundos. Esta ganancia es un testimonio de la eficacia del desacoplamiento temporal y la aplicación de interfaces optimistas (“optimistic UI”), que minimizan la percepción de latencia por parte del usuario (Hohpe y Woolf, 2012).

Desde la perspectiva de la gestión financiera de la nube, este comportamiento validó la aplicación del patrón de balanceo de carga por colas, según lo descrito por Hohpe y Woolf (2012). El componente consumidor operó con capacidad computacional lineal, independientemente de los picos de solicitudes en la capa de recepción, lo que sugirió compatibilidad con modelos de computación por funciones y evitó el desperdicio de recursos por sobreaprovisionamiento (“over-provisioning”). Este mecanismo de elasticidad es una de las principales ventajas económicas de la computación en la nube, según lo identificado por Armbrust et al. (2010).

Para validar la eficiencia y el comportamiento de la arquitectura agnóstica en un entorno de producción real, se realizó un análisis comparativo de rendimiento entre las instancias “serverless” de los dos proveedores de nube. Las pruebas se centraron en la medición de la latencia de las operaciones críticas del sistema, con las instancias operando en planes de consumo bajo demanda, bajo una carga de estrés de cincuenta solicitudes simultáneas distribuidas en diez hilos de ejecución.

Las métricas de tiempo de respuesta de la capa de recepción HTTP extraídas de las herramientas oficiales de monitoreo de cada plataforma revelaron diferencias notables. El tiempo total de la prueba fue de 4,84 segundos en Amazon Web Services y 10,57 segundos en Microsoft Azure, lo que indica una mayor velocidad global de recepción en AWS. El rendimiento global de AWS fue de 10,33 solicitudes por segundo, el doble que el de Azure, que registró 4,73 solicitudes por segundo.

La latencia media en AWS fue de 951,35 milisegundos, mientras que en Azure fue de 2.011,73 milisegundos, demostrando un menor tiempo de espera percibido por el usuario en AWS. La latencia mediana también favoreció a AWS, con 319,33 milisegundos, en comparación con 1.151,65 milisegundos en Azure, lo que sugiere mayor estabilidad en la respuesta de AWS. El tiempo mínimo de latencia fue de 288,06 milisegundos en AWS y 644,04 milisegundos en Azure, indicando un piso de latencia más bajo en AWS.

Ambas las nubes registraron picos de “cold start” en las primeras interacciones, con AWS alcanzando valores del orden de 3.400 milisegundos y Azure superando la marca de 5.000 milisegundos en el tiempo máximo. La infraestructura de AWS se adaptó más rápidamente a la carga y se estabilizó, tras unas diez solicitudes, en un rango basal cercano a los 300 milisegundos, con una variación de latencia (“jitter”) muy baja. Microsoft Azure, incluso después del calentamiento inicial, exhibió una curva más errática, con fluctuaciones recurrentes entre 644 milisegundos y 4.672 milisegundos a lo largo del resto de la prueba.

Esta variabilidad converge con lo que Palumbo et al. (2021) observaron al caracterizar la latencia entre la nube y el usuario en los dos proveedores, y con la ventaja de AWS en métricas de respuesta de servicios web reportada por Al-Sayyed et al. (2019) y Gupta et al. (2021). La concentración intercuartílica de AWS resultó considerablemente menor y más densa alrededor de la mediana de 319,33 milisegundos, lo que confirmó la capacidad del servicio de puerta de enlace administrado de absorber solicitudes masivas de forma predecible y de aislar la interfaz de usuario de retrasos de procesamiento.

La amplitud intercuartílica de Azure, aproximadamente nueve veces mayor, se tradujo en una experiencia de uso menos predecible, un resultado alineado con las diferencias de rendimiento entre proveedores documentadas por Kaushik et al. (2021). Estos hallazgos resaltan la importancia de un análisis detallado de las características de rendimiento de cada proveedor de nube, especialmente en escenarios de alta carga y para aplicaciones que requieren baja latencia en la capa de recepción.

La evaluación de la eficiencia de la arquitectura propuesta no se limitó a la capa de entrada HTTP. El análisis detallado de los registros brutos de monitoreo reveló un tránsito de cola sustancialmente distinto entre los proveedores y retrató el tiempo computacional real exigido por las funciones consumidoras para procesar los datos en segundo plano. Este comportamiento de extremo a extremo es fundamental para comprender la fluidez de la transacción completa.

Desde la perspectiva del procesamiento interno, Microsoft Azure demostró un comportamiento marcadamente optimizado y superó el rendimiento de su propia capa HTTP. En las cincuenta muestras ejecutadas con éxito, se registraron un tiempo mínimo de 10,43 milisegundos y un pico de 449,11 milisegundos, con una mediana de 113 milisegundos. Esta eficiencia se debió al modelo de disparadores asíncronos del plan de consumo, asistido por un componente nativo de control de escala que, al detectar picos de carga, realizó consultas muy frecuentes a la cola de almacenamiento (Microsoft, 2025).

El resultado práctico fue una transición de la capa de recepción a la función consumidora en aproximadamente 113 milisegundos, lo que hizo que la latencia asíncrona fuera imperceptible para la creación de la llamada en Jira. En contraste, Amazon Web Services, que presentó tiempos cortos y predecibles en la recepción HTTP, evidenció un cuello de botella considerable en la resolución asíncrona. En los mismos cincuenta eventos exitosos, el menor tiempo de procesamiento interno fue de 1.078,81 milisegundos y el pico más alto, influenciado por el “cold start” del lenguaje Python, alcanzó los 4.106,20 milisegundos, con una mediana de 2.359,94 milisegundos.

Esta latencia en AWS se debió a la mecánica del modelo bajo demanda: los nodos de la cola asociados a los desencadenadores de funciones operaron bajo un régimen de ventana de lote y control de consulta, de modo que la nube esperó deliberadamente la acumulación de lotes de mensajes antes de instanciar un contenedor precalentado para ejecutar el código (Amazon Web Services [AWS], 2025). Se trató de una estrategia nativa del proveedor que sacrificó la latencia en favor de la reducción de costos para tareas en segundo plano, evidenciando una contrapartida técnica entre rendimiento y costo.

Los datos experimentales comprobaron, por lo tanto, la tesis subyacente a la arquitectura en múltiples nubes. Microsoft Azure presentó mayor lentitud inicial en llamadas web, mientras que AWS dominó la velocidad de procesamiento HTTP en la capa de interfaz. Para los procesos distribuidos de cola en segundo plano, sin embargo, AWS impuso un estrangulamiento de infraestructura orientado a los costos operacionales, que generó demoras asíncronas con mediana de 2.359,94 milisegundos y picos superiores a cuatro segundos.

En contrapartida, la arquitectura de Microsoft procesó las colas de eventos en aproximadamente 113 milisegundos, sin restricción temporal aparente. La lectura conjunta de los dos recortes matizó los hallazgos de Madhuri y Sowjanya (2016), quienes compararon los proveedores sobre todo por la capa de servicios web. La inversión de ventaja entre las dos capas indicó que la preferencia entre proveedores para soluciones “serverless” dependió de la forma en que la organización diseñó sus microservicios y de los requisitos no funcionales prioritarios, es decir, latencia percibida en la interfaz, con ventaja de AWS, o fluidez en la transacción de extremo a extremo, con ventaja de Azure.

Configuración y gestión del “middleware”

Antes de la ejecución de los flujos de trabajo, se validó el módulo de gestión de la aplicación. La interfaz gráfica se desarrolló en HTML5 con la biblioteca Bootstrap, permitiendo la parametrización del sistema de forma visual y eliminando la necesidad de alteración directa en el código fuente para ajustes de mapeo. Este enfoque simplificó la gestión y el mantenimiento del sistema, haciéndolo accesible a usuarios sin un conocimiento técnico profundo en programación.

El panel permitió el mapeo dinámico entre los canales de origen de Slack y los proyectos de destino de Jira. La interfaz proporcionó además mecanismos de depuración, al exhibir la validación de los campos obligatorios para el registro, lo que facilitó la identificación de inconsistencias en los datos de entrada antes de la ejecución de las pruebas. Esta funcionalidad es crucial para prevenir errores y garantizar la integridad de los datos que transitan entre las plataformas, aumentando la confiabilidad de la integración.

Validación funcional y evidencias visuales

Además del análisis cuantitativo, se documentó la validación funcional de la integración entre las plataformas mediante capturas de pantalla, lo que demostró la eficacia de la interfaz de usuario en todas las etapas del flujo de trabajo. Esta validación visual es esencial para demostrar la usabilidad y la adherencia de la solución a las necesidades operativas de los usuarios.

Inicialmente, se validó el mecanismo de entrada de datos. Cuando el usuario activó el comando inicial, la aplicación renderizó correctamente la ventana modal del formulario. Esta etapa confirmó que la capa de recepción recibió el disparador del usuario y devolvió la estructura de datos correspondiente a los campos de llenado sin latencia perceptible, garantizando una interacción inicial rápida y receptiva.

A continuación, se demostró el mecanismo de retorno instantáneo implementado. En el momento exacto de la sumisión del formulario, el sistema devolvió un mensaje provisional de confirmación. Este comportamiento, característico de interfaces optimistas (“optimistic UI”), aseguró al usuario que la solicitud había sido recibida con éxito y eliminó la incertidumbre durante el período de procesamiento asíncrono, mejorando la experiencia general del usuario.

La actualización dinámica de la interfaz fue presentada. Después del procesamiento por el “worker”, el mensaje provisional fue sustituido automáticamente por una tarjeta interactiva con el identificador de la tarea y botones de acción. La correcta renderización de estos elementos confirmó la capacidad del sistema de actualizar el estado de la conversación en tiempo real, proporcionando feedback inmediato y relevante al usuario sobre el estado de la solicitud.

La efectividad de la transacción en el sistema de destino se ha comprobado. La tarea se creó correctamente en la plataforma Jira y conservó la fidelidad de toda la información introducida en el formulario inicial. Esto garantizó que los datos se transfirieran con precisión e integridad, un aspecto fundamental para la trazabilidad y la fiabilidad de los procesos de gestión de proyectos.

En resumen, el desarrollo del “middleware” de integración asíncrona entre Slack y Jira demostró ser una estrategia eficaz para reducir la latencia percibida por el usuario y garantizar la estabilidad del sistema bajo carga. La arquitectura orientada a eventos, con desacoplamiento temporal y uso de colas de mensajes, superó las limitaciones de las integraciones síncronas tradicionales. El análisis comparativo entre proveedores de nube reveló que, si bien ambos son viables, la elección ideal depende de los requisitos específicos de latencia en cada capa del sistema, consolidando un modelo de referencia corporativa escalable, resiliente y agnóstico de nube.

4. Conclusión

El presente estudio buscó desarrollar y validar un middleware de integración asíncrona entre Slack y Jira, con el objetivo de reducir el tiempo de respuesta percibido por el usuario y garantizar la estabilidad del sistema bajo carga. Se verificó que la arquitectura orientada a eventos, con desacoplamiento temporal y el uso de colas de mensajes, mitigó significativamente los problemas de latencia inherentes a los sistemas distribuidos. Las pruebas demostraron una reducción expresiva en el tiempo de espera del usuario, pasando de una estimación síncrona de 2.000 milisegundos a un promedio local de 8,96 milisegundos. Bajo una carga de cincuenta solicitudes simultáneas, la solución mantuvo la estabilidad, con Amazon Web Services presentando menor latencia promedio en la capa de recepción y el doble de rendimiento, mientras que Microsoft Azure se destacó en el procesamiento eficiente en segundo plano, con una mediana de 113 milisegundos. La aplicación de interfaces optimistas aseguró fluidez de uso, y la nivelación de carga por colas dispensó el sobredimensionamiento de infraestructura. Este enfoque consolidó un modelo de referencia corporativa escalable, resiliente y protegido contra el aprisionamiento tecnológico, ofreciendo una solución robusta para la automatización de flujos de trabajo en entornos corporativos.

A pesar de las ganancias de rendimiento y estabilidad, se observó que el fenómeno de “arranque en frío” impactó las primeras interacciones en ambos proveedores de nube, resultando en picos de latencia inicial. Adicionalmente, la estrategia de procesamiento de colas de Amazon Web Services, que prioriza la reducción de costos mediante la acumulación de lotes de mensajes, introdujo latencias asíncronas más elevadas en el procesamiento en segundo plano, evidenciando una contrapartida técnica entre rendimiento y costo. Tales hallazgos sugieren que la elección del proveedor ideal para soluciones serverless depende de los requisitos no funcionales prioritarios de cada organización, ya sea la latencia percibida en la interfaz o la fluidez de la transacción de extremo a extremo. Para estudios futuros, se recomienda profundizar el análisis de estrategias híbridas o multicloud que optimicen el rendimiento en ambas capas, explorando la combinación de proveedores para mitigar las limitaciones observadas y maximizar la eficiencia operativa y financiera en escenarios de alta demanda.

Referencias Bibliográficas

Al-Sayyed, R.M.H.; Hijawi, W.A.; Bashiti, A.M.; Aljarah, I.; Obeid, N.; Adwan, O.Y. 2019. An investigation of Microsoft Azure and Amazon Web Services from users’ perspectives. International Journal of Emerging Technologies in Learning 14(10): 110-116.

Amazon Web Services [AWS]. 2025. Amazon Simple Queue Service Developer Guide. Disponível em: <https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/>. Acesso em: 26 out. 2025.

Armbrust, M.; Fox, A.; Griffith, R.; Joseph, A.D.; Katz, R.; Konwinski, A.; Lee, G.; Patterson, D.; Rabkin, A.; Stoica, I.; Zaharia, M. 2010. A view of cloud computing. Communications of the ACM 53(4): 50-58.

Atlassian. 2025. Jira Cloud Platform REST API. Disponível em: <https://developer.atlassian.com/cloud/jira/platform/rest/>. Acesso em: 26 out. 2025.

Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. 1995. Design Patterns: Elements of reusable object-oriented software. Addison-Wesley, Boston, MA, EUA.

Gil, A.C. 2002. Como Elaborar Projetos de Pesquisa. 4.ed. Atlas, São Paulo, SP, Brasil.

Gupta, B.; Mittal, P.; Mufti, T. 2021. A review on Amazon Web Service (AWS), Microsoft Azure and Google Cloud Platform (GCP) services. In: International Conference on ICT for Digital, Smart and Sustainable Development, 2020, Nova Délhi, Índia. Anais… European Alliance for Innovation, Gante, Bélgica.

Hohpe, G.; Woolf, B. 2012. Enterprise Integration Patterns: Designing, building, and deploying messaging solutions. Addison-Wesley, Boston, MA, EUA.

Kaushik, P.; Rao, A.M.; Singh, D.P.; Vashisht, S.; Gupta, S. 2021. Cloud computing and comparison based on service and performance between Amazon AWS, Microsoft Azure, and Google Cloud. In: International Conference on Technological Advancements and Innovations, 2021, Tashkent, Uzbequistão. Anais… Institute of Electrical and Electronics Engineers, Piscataway, NJ, EUA. p. 268-273.

Madhuri, T.; Sowjanya, P. 2016. Microsoft Azure v/s Amazon AWS cloud services: a comparative study. International Journal of Innovative Research in Science, Engineering and Technology 5(3): 3904-3908.

Microsoft. 2025. Azure Queue Storage Documentation. Disponível em: <https://learn.microsoft.com/azure/storage/queues/>. Acesso em: 26 out. 2025.

Newman, S. 2015. Building Microservices: Designing fine-grained systems. O’Reilly Media, Sebastopol, CA, EUA.

Palumbo, F.; Aceto, G.; Botta, A.; Ciuonzo, D.; Persico, V.; Pescapé, A. 2021. Characterization and analysis of cloud-to-user latency: the case of Azure and AWS. Computer Networks 186: 107693.

Slack Technologies. 2025. Slack Web API Documentation. Disponível em: <https://api.slack.com/web>. Acesso em: 26 out. 2025.

Sommerville, I. 2019. Engineering Software Products: An introduction to modern software engineering. Pearson, New York, NY, EUA.

Artículo originario del Trabajo de Conclusión de Curso de la Especialización en Ingeniería de Software del MBA USP/Esalq

Para saber más sobre el curso, haga clic aquí y acceda a la plataforma MBX Academy