Integração Assíncrona Slack-jira Via “Middleware” de Filas: Comparação de Soluções de “Cloud Computing”

Julia Cabral Diniz Braz; Marcos Jardel Henriques

DOI: 10.22167/2675-6528-202603094

Artigo derivado de Trabalho de Conclusão de Curso (TCC), com conteúdo baseado no trabalho original do aluno e adaptado ao formato editorial da Revista E&S com apoio da ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege para síntese e organização textual.

Resumo

A latência e a interoperabilidade entre sistemas corporativos distribuídos constituíram o problema investigado, motivado pelos custos e fragilidades das integrações manuais entre plataformas de colaboração e gestão de projetos. Desenvolveu-se e validou-se um “middleware” de integração assíncrona entre Slack e Jira, com o objetivo de reduzir o tempo de resposta percebido pelo usuário e garantir a estabilidade do sistema sob carga. A metodologia consistiu na construção de uma arquitetura de software orientada a eventos em Python, utilizando os padrões “producer-consumer” e “adapter” para isolar a interface do usuário do processamento de “backend”. A solução evoluiu para uma arquitetura agnóstica de nuvem, baseada em funções “serverless”, e foi submetida a testes de estresse em ambientes local, de rede real e de produção em duas nuvens. A arquitetura reduziu o tempo de espera do usuário de uma estimativa síncrona de 2.000 milissegundos para uma média local de 8,96 milissegundos. Sob carga de 50 requisições simultâneas, ambos os provedores de nuvem mostraram-se viáveis: a Amazon Web Services registrou menor latência média na camada de recepção (951,35 ms) e o dobro da vazão, enquanto a Microsoft Azure executou o processamento em segundo plano com mediana de 113 ms. A aplicação de “optimistic UI” assegurou fluidez de uso, e o nivelamento de carga por filas dispensou o sobredimensionamento de infraestrutura. O “middleware” consolidou-se como um modelo de referência corporativa escalável, resiliente e protegido contra o aprisionamento tecnológico.

Palavras-chave: Arquitetura orientada a eventos; Desacoplamento temporal; Eficiência operacional; Gestão de serviços de tecnologia da informação; Interoperabilidade de sistemas.

1. Introdução

No ambiente de uma empresa de tecnologia, a integração entre ferramentas de comunicação e de gestão de projetos mostrou-se essencial para garantir produtividade, rastreabilidade e eficiência operacional. O Slack, amplamente utilizado como plataforma de mensageria corporativa para comunicação ágil entre equipes, e o Jira, reconhecido sistema de gerenciamento de projetos, ocupam posição central nas rotinas de desenvolvimento e de gestão de software, atividades cuja coordenação depende diretamente da qualidade dos fluxos de informação que atravessam as fronteiras entre produtos (Sommerville, 2019).

Apesar da importância, a latência e a interoperabilidade entre sistemas corporativos distribuídos constituem um problema recorrente. As integrações manuais entre plataformas de colaboração e ferramentas de gestão de projetos são frequentemente onerosas e frágeis. As integrações nativas entre essas plataformas, especificamente entre Slack e Jira, apresentam limitações significativas e acarretam custos adicionais, uma fragilidade que a literatura de integração corporativa atribui à ausência de um intermediário de mensagens dedicado entre as aplicações (Hohpe e Woolf, 2012).

Em uma empresa de tecnologia analisada, por exemplo, as mensagens do Slack eram transferidas para uma planilha no Google Sheets, e um script encarregava-se de criar os cards no Jira. Embora funcional, essa abordagem apresentava limitações de escalabilidade, segurança e manutenção, deficiências características das integrações ponto a ponto construídas sem uma camada de desacoplamento (Newman, 2015).

Diante desse cenário, propôs-se o desenvolvimento de um middleware orientado a eventos, baseado em sistemas de filas de mensagens. Essa solução visa intermediar e gerenciar a comunicação entre o Slack e o Jira de maneira eficiente, segura e escalável, abstraindo a complexidade da integração entre interfaces de programação de aplicações. O objetivo é promover um fluxo automatizado e monitorável de dados entre os sistemas, garantindo maior fluidez e confiabilidade operacional.

Além de resolver um problema prático, este projeto contribui para o aprimoramento de competências em integração de sistemas, arquiteturas orientadas a eventos, filas de mensagens e computação em nuvem, temas de grande relevância na engenharia de software contemporânea. A literatura recente evidencia a importância de análises comparativas entre provedores de nuvem para fundamentar escolhas tecnológicas (Al-Sayyed et al., 2019; Kaushik et al., 2021; Palumbo et al., 2021; Madhuri e Sowjanya, 2016; Gupta et al., 2021). Nesse contexto, a comparação entre os serviços de fila gerenciada das duas nuvens, proposta neste trabalho, não apenas fundamenta a escolha arquitetural mais adequada, mas também contribui para o avanço do conhecimento sobre soluções de mensageria em nuvem sob distintas perspectivas de custo, confiabilidade e desempenho.

A relevância do estudo reside, portanto, na sua capacidade de oferecer uma solução robusta para um problema comum em ambientes corporativos, ao mesmo tempo em que aprofunda a discussão acadêmica sobre as melhores práticas em integração de sistemas distribuídos e computação em nuvem. O objetivo geral deste trabalho foi desenvolver e validar um “middleware” de integração assíncrona entre Slack e Jira, capaz de reduzir o tempo de resposta percebido pelo usuário e de garantir a estabilidade do sistema sob carga.

2. Material e Métodos

A pesquisa caracterizou-se como aplicada e de natureza tecnológica, focada no desenvolvimento e validação de um “middleware” de integração assíncrona entre Slack e Jira. A metodologia adotou uma arquitetura de software orientada a eventos (Gil, 2002), visando reduzir o tempo de resposta percebido pelo usuário e garantir a estabilidade do sistema sob carga.

O desenvolvimento ocorreu em quatro etapas: implementação de microsserviços desacoplados em Python; aplicação de interface otimista (“optimistic UI”); execução de testes de estresse para mensurar latência e vazão; e comparação de desempenho e portabilidade do sistema entre processamento local e infraestruturas de mensageria em nuvem pública.

A arquitetura baseou-se na decomposição em microsserviços independentes, seguindo o padrão Produtor-Consumidor (Newman, 2015). O “producer” foi projetado para recepção de requisições HTTP, e o “worker” refatorado para abordagem “serverless” e funções orientadas a eventos. Essa segregação de responsabilidades evitou bloqueios (Hohpe e Woolf, 2012). Para interoperabilidade e independência de provedor, aplicou-se o padrão “adapter” (Gamma et al., 1995), unificando métodos de comunicação entre filas locais e serviços de fila gerenciados em nuvem. O uso de filas para nivelamento de carga (“queue-based load leveling”) evitou o sobredimensionamento de recursos (Armbrust et al., 2010).

A solução foi implementada em módulos distintos, com camadas de recepção e processamento. A camada de recepção utilizou frameworks e bibliotecas para absorver interatividades do usuário e transferir execuções pesadas para a fila de mensagens, retornando um código de sucesso imediato para contornar o tempo limite do Slack (Slack Technologies, 2025). A camada de processamento consumiu mensagens da fila e executou transações via interface de programação do Jira (Atlassian, 2025).

A abstração da infraestrutura assegurou a agnóstica da aplicação ao ambiente de implantação. O mapeamento de canais evoluiu para funções “serverless” e persistência em serviços NoSQL gerenciados na nuvem. Pontos de entrada nativos integraram a solução “serverless” em provedores como AWS e Azure. A interface gráfica para gestão do sistema foi desenvolvida em HTML5 e Bootstrap, fornecendo um painel visual para a vinculação das configurações de canal. A lógica do sistema foi documentada por pseudocódigos, e a validação funcional por capturas de tela, registrando a eficácia da interface do usuário.

A validação da arquitetura realizou-se por testes de estresse, utilizando um “script” de automação em Python com a biblioteca `concurrent.futures`. Três cenários experimentais foram definidos para a coleta de dados. No primeiro, de linha de base, cem requisições paralelas foram disparadas em dez linhas de execução, com a camada de recepção e o “worker” operando na mesma máquina física, eliminando a latência de rede externa.

No segundo cenário, de rede real, cem requisições foram disparadas em dez linhas de execução por meio de um túnel HTTP seguro, forçando o tráfego a percorrer a rede pública. O terceiro cenário, de produção, executou o teste em infraestruturas “serverless” reais, com carga de cinquenta requisições simultâneas em dez linhas de execução contra as instâncias dos dois provedores de nuvem.

Os dados de resposta, incluindo a situação da requisição HTTP e o tempo de latência em milissegundos, foram extraídos localmente para arquivos CSV nos dois primeiros cenários e diretamente das ferramentas oficiais de monitoramento das nuvens no terceiro. Para a análise quantitativa, aplicaram-se métodos de estatística descritiva, utilizando a biblioteca `statistics` da linguagem Python, calculando-se a média aritmética simples, a mediana e a vazão para sintetizar o comportamento da latência do sistema.

3. Resultados e Discussão

Os resultados obtidos demonstraram a viabilidade técnica e a eficiência operacional da arquitetura orientada a eventos aplicada à integração de sistemas ofertados como serviço. Os dados coletados permitiram avaliar a solução sob três perspectivas distintas: o desempenho computacional, o comportamento em rede e a integridade funcional. A pesquisa validou a hipótese de que um “middleware” assíncrono pode mitigar a latência e garantir a estabilidade em sistemas distribuídos, um desafio comum em ambientes corporativos que dependem da interoperabilidade entre plataformas como Slack e Jira.

A análise de desempenho do sistema foi conduzida em duas etapas distintas, com o propósito de isolar o tempo de processamento computacional da latência imposta pela infraestrutura de rede. Em ambos os cenários, utilizou-se o protocolo de testes de estresse com disparo de cem requisições simultâneas, simulando o comportamento de múltiplos usuários. Essa abordagem permitiu uma avaliação robusta da capacidade da solução de lidar com picos de demanda, um requisito crítico para sistemas de integração em tempo real.

No primeiro cenário experimental, caracterizado como linha de base, a arquitetura proposta apresentou alta eficiência no processamento de ingestão de dados. Das cem requisições disparadas simultaneamente pelo “script”, registrou-se uma taxa de sucesso de cem por cento, sem ocorrência de erros ou de estouros de tempo limite. A latência média de resposta da camada de recepção foi de 8,96 milissegundos, com tempo mínimo de 5,28 milissegundos e máximo de 26,08 milissegundos. A vazão do sistema ultrapassou a marca de 1.000 requisições por segundo.

Tais valores indicaram que o desacoplamento por filas eliminou o tempo de espera de processamento do “backend” e devolveu o controle ao cliente de forma quase instantânea. A estabilidade do sistema durante o teste de carga foi notável, com a linha de latência mantendo-se constante, em torno de sete milissegundos, após as dez primeiras requisições. Isso demonstrou que a aplicação não sofreu degradação de desempenho mesmo sob concorrência de múltiplas linhas de execução, validando a robustez do design assíncrono.

No segundo cenário, que simulou condições reais de acesso remoto por túnel seguro, a média de tempo de resposta subiu para 605,93 milissegundos. Esse aumento foi atribuído ao tempo de transporte dos pacotes pela rede, conhecido como “round trip time”, uma vez que o processamento interno da aplicação manteve-se inalterado. Mesmo com a latência de rede adicionada, o sistema preservou a integridade dos dados e processou a carga total em 6,13 segundos, o que validou a robustez da solução para ambientes em nuvem.

Apesar da flutuação natural da rede, a estabilidade do sistema manteve-se inalterada, evidenciando que, mesmo sob condições de latência variável, a aplicação preservou a consistência do serviço, sem falhas. Esse comportamento é crucial para garantir uma experiência de usuário fluida e confiável em integrações que dependem de infraestruturas de rede externas, como é o caso de sistemas distribuídos que interagem com serviços de nuvem.

A comparação dos resultados obtidos com os tempos médios de resposta de uma arquitetura síncrona tradicional, estimados de forma conservadora em 2.000 milissegundos para operações na plataforma Jira, somados à latência de rede, evidenciou um ganho substancial de desempenho da solução desenvolvida. No cenário de linha de base, a solução assíncrona mostrou-se aproximadamente 223 vezes mais rápida na perspectiva da resposta ao usuário, um avanço significativo na eficiência operacional.

No cenário com latência de rede, a resposta de 605,93 milissegundos representou uma redução de cerca de 77% no tempo de espera total, quando comparada à soma hipotética da latência de rede com o tempo de processamento síncrono, de aproximadamente 2.600 milissegundos. Esse ganho é um testemunho da eficácia do desacoplamento temporal e da aplicação de interfaces otimistas (“optimistic UI”), que minimizam a percepção de latência pelo usuário (Hohpe e Woolf, 2012).

Sob a ótica da gestão financeira da nuvem, esse comportamento validou a aplicação do padrão de nivelamento de carga por filas, conforme descrito por Hohpe e Woolf (2012). O componente consumidor operou com capacidade computacional linear, independentemente dos picos de requisições na camada de recepção, o que sugeriu compatibilidade com modelos de computação por funções e evitou o desperdício de recursos por sobredimensionamento (“over-provisioning”). Esse mecanismo de elasticidade é uma das principais vantagens econômicas da computação em nuvem, conforme identificado por Armbrust et al. (2010).

Para validar a eficiência e o comportamento da arquitetura agnóstica em ambiente de produção real, conduziu-se uma análise comparativa de desempenho entre as instâncias “serverless” dos dois provedores de nuvem. Os testes concentraram-se na mensuração da latência das operações críticas do sistema, com as instâncias operando em planos de consumo sob demanda, sob carga de estresse de cinquenta requisições simultâneas distribuídas em dez linhas de execução.

As métricas de tempo de resposta da camada de recepção HTTP extraídas das ferramentas oficiais de monitoramento de cada plataforma revelaram diferenças notáveis. O tempo total do teste foi de 4,84 segundos na Amazon Web Services e 10,57 segundos na Microsoft Azure, indicando maior velocidade global de recepção na AWS. A vazão global da AWS foi de 10,33 requisições por segundo, o dobro da Azure, que registrou 4,73 requisições por segundo.

A latência média na AWS foi de 951,35 milissegundos, enquanto na Azure foi de 2.011,73 milissegundos, demonstrando um menor tempo de espera percebido pelo usuário na AWS. A latência mediana também favoreceu a AWS, com 319,33 milissegundos, em comparação com 1.151,65 milissegundos na Azure, o que sugere maior estabilidade na resposta da AWS. O tempo mínimo de latência foi de 288,06 milissegundos na AWS e 644,04 milissegundos na Azure, indicando um piso de latência mais baixo na AWS.

Ambas as nuvens registraram picos de “cold start” nas primeiras interações, com a AWS atingindo valores da ordem de 3.400 milissegundos e a Azure ultrapassando a marca de 5.000 milissegundos no tempo máximo. A infraestrutura da AWS adaptou-se mais rapidamente à carga e estabilizou-se, após cerca de dez requisições, em uma faixa basal próxima de 300 milissegundos, com variação de atraso (“jitter”) muito baixa. A Microsoft Azure, mesmo após o aquecimento inicial, exibiu uma curva mais errática, com flutuações recorrentes entre 644 milissegundos e 4.672 milissegundos ao longo do restante do teste.

Essa variabilidade converge com o que Palumbo et al. (2021) observaram ao caracterizar a latência entre nuvem e usuário nos dois provedores, e com a vantagem da AWS em métricas de resposta de serviços web relatada por Al-Sayyed et al. (2019) e Gupta et al. (2021). A concentração interquartil da AWS mostrou-se consideravelmente menor e mais densa em torno da mediana de 319,33 milissegundos, o que confirmou a capacidade do serviço de porta de entrada gerenciado de absorver requisições massivas de forma previsível e em isolar a interface do usuário de atrasos de processamento.

A amplitude interquartil da Azure, cerca de nove vezes maior, traduziu-se em uma experiência de uso menos previsível, resultado alinhado às diferenças de desempenho entre provedores documentadas por Kaushik et al. (2021). Esses achados ressaltam a importância de uma análise detalhada das características de desempenho de cada provedor de nuvem, especialmente em cenários de carga elevada e para aplicações que exigem baixa latência na camada de recepção.

A avaliação da eficiência da arquitetura proposta não se limitou à camada de entrada HTTP. A análise detalhada dos registros brutos de monitoramento revelou um trânsito de fila substancialmente distinto entre os provedores e retratou o tempo computacional real exigido pelas funções consumidoras para processar os dados em segundo plano. Esse comportamento de ponta a ponta é fundamental para compreender a fluidez da transação completa.

Na perspectiva do processamento interno, a Microsoft Azure demonstrou um comportamento acentuadamente otimizado e superou o desempenho de sua própria camada HTTP. Nas cinquenta amostras executadas com sucesso, registraram-se tempo mínimo de 10,43 milissegundos e pico de 449,11 milissegundos, com mediana de 113 milissegundos. Essa eficiência decorreu do modelo de gatilhos assíncronos do plano de consumo, auxiliado por um componente nativo de controle de escala que, ao detectar picos de carga, realizou consultas muito frequentes à fila de armazenamento (Microsoft, 2025).

O resultado prático foi um trânsito da camada de recepção até a função consumidora em cerca de 113 milissegundos, o que tornou a latência assíncrona imperceptível para a criação do chamado no Jira. Em contraste, a Amazon Web Services, que apresentou tempos curtos e previsíveis no recebimento HTTP, evidenciou um gargalo considerável na resolução assíncrona. Nos mesmos cinquenta eventos bem-sucedidos, o menor tempo de processamento interno foi de 1.078,81 milissegundos e o maior pico, influenciado pelo “cold start” da linguagem Python, atingiu 4.106,20 milissegundos, com mediana de 2.359,94 milissegundos.

Essa latência na AWS decorreu da mecânica do modelo sob demanda: os nós da fila associados a gatilhos da função operaram sob regime de janela de lote e de controle de consulta, de modo que a nuvem aguardou deliberadamente o acúmulo de lotes de mensagens antes de instanciar um contêiner aquecido para executar o código (Amazon Web Services [AWS], 2025). Tratou-se de uma estratégia nativa do provedor que sacrificou latência em favor da redução de custo para tarefas de segundo plano, evidenciando uma contrapartida técnica entre desempenho e custo.

Os dados experimentais comprovaram, portanto, a tese subjacente à arquitetura em múltiplas nuvens. A Microsoft Azure apresentou maior lentidão inicial em chamadas web, enquanto a AWS dominou a velocidade de processamento HTTP na camada de interface. Para os processos distribuídos de fila em segundo plano, contudo, a AWS impôs um estrangulamento de infraestrutura orientado aos custos operacionais, que gerou demoras assíncronas com mediana de 2.359,94 milissegundos e picos superiores a quatro segundos.

Em contrapartida, a arquitetura da Microsoft processou as filas de eventos em aproximadamente 113 milissegundos, sem restrição temporal aparente. A leitura conjunta dos dois recortes matizou os achados de Madhuri e Sowjanya (2016), que compararam os provedores sobretudo pela camada de serviços web. A inversão de vantagem entre as duas camadas indicou que a preferência entre provedores para soluções “serverless” dependeu da forma como a organização desenhou seus microsserviços e dos requisitos não funcionais prioritários, isto é, latência percebida na interface, com vantagem da AWS, ou fluidez na transação de ponta a ponta, com vantagem da Azure.

Configuração e gerenciamento do “middleware”

Antes da execução dos fluxos de trabalho, validou-se o módulo de gerenciamento da aplicação. A interface gráfica foi desenvolvida em HTML5 com a biblioteca Bootstrap, permitindo a parametrização do sistema de forma visual e eliminando a necessidade de alteração direta no código-fonte para ajustes de mapeamento. Essa abordagem simplificou a gestão e a manutenção do sistema, tornando-o acessível a usuários sem conhecimento técnico aprofundado em programação.

O painel possibilitou o mapeamento dinâmico entre os canais de origem do Slack e os projetos de destino do Jira. A interface forneceu ainda mecanismos de depuração, ao exibir a validação dos campos obrigatórios para o cadastro, o que facilitou a identificação de inconsistências nos dados de entrada antes da execução dos testes. Essa funcionalidade é crucial para prevenir erros e garantir a integridade dos dados que transitam entre as plataformas, aumentando a confiabilidade da integração.

Validação funcional e evidências visuais

Além da análise quantitativa, documentou-se a validação funcional da integração entre as plataformas por meio de capturas de tela, o que comprovou a eficácia da interface do usuário em todas as etapas do fluxo de trabalho. Essa validação visual é essencial para demonstrar a usabilidade e a aderência da solução às necessidades operacionais dos usuários.

Inicialmente, validou-se o mecanismo de entrada de dados. Quando o usuário acionou o comando inicial, a aplicação renderizou corretamente a janela modal de formulário. Essa etapa confirmou que a camada de recepção recebeu o gatilho do usuário e retornou a estrutura de dados correspondente aos campos de preenchimento sem latência perceptível, garantindo uma interação inicial rápida e responsiva.

Na sequência, demonstrou-se o mecanismo de retorno instantâneo implementado. No momento exato da submissão do formulário, o sistema retornou uma mensagem provisória de confirmação. Esse comportamento, característico de interfaces otimistas (“optimistic UI”), assegurou ao usuário que a solicitação havia sido recebida com sucesso e eliminou a incerteza durante o período de processamento assíncrono, melhorando a experiência geral do usuário.

A atualização dinâmica da interface foi apresentada. Após o processamento pelo “worker”, a mensagem provisória foi substituída automaticamente por um cartão interativo com o identificador da tarefa e botões de ação. A renderização correta desses elementos confirmou a capacidade do sistema de atualizar o estado da conversa em tempo real, fornecendo feedback imediato e relevante ao usuário sobre o status da solicitação.

A efetivação da transação no sistema de destino foi comprovada. A tarefa foi criada corretamente na plataforma Jira e preservou a fidelidade de todas as informações inseridas no formulário inicial. Isso garantiu que os dados fossem transferidos com precisão e integridade, um aspecto fundamental para a rastreabilidade e a confiabilidade dos processos de gestão de projetos.

Em síntese, o desenvolvimento do “middleware” de integração assíncrona entre Slack e Jira demonstrou ser uma estratégia eficaz para reduzir a latência percebida pelo usuário e garantir a estabilidade do sistema sob carga. A arquitetura orientada a eventos, com desacoplamento temporal e uso de filas de mensagens, superou as limitações das integrações síncronas tradicionais. A análise comparativa entre provedores de nuvem revelou que, embora ambos sejam viáveis, a escolha ideal depende dos requisitos específicos de latência em cada camada do sistema, consolidando um modelo de referência corporativa escalável, resiliente e agnóstico de nuvem.

4. Conclusão

O presente estudo buscou desenvolver e validar um middleware de integração assíncrona entre Slack e Jira, visando a redução do tempo de resposta percebido pelo usuário e a garantia da estabilidade do sistema sob carga. Verificou-se que a arquitetura orientada a eventos, com desacoplamento temporal e o uso de filas de mensagens, mitigou significativamente os problemas de latência inerentes aos sistemas distribuídos. Os testes demonstraram uma redução expressiva no tempo de espera do usuário, passando de uma estimativa síncrona de 2.000 milissegundos para uma média local de 8,96 milissegundos. Sob carga de cinquenta requisições simultâneas, a solução manteve a estabilidade, com a Amazon Web Services apresentando menor latência média na camada de recepção e o dobro da vazão, enquanto a Microsoft Azure se destacou no processamento eficiente em segundo plano, com mediana de 113 milissegundos. A aplicação de interfaces otimistas assegurou fluidez de uso, e o nivelamento de carga por filas dispensou o sobredimensionamento de infraestrutura. Essa abordagem consolidou um modelo de referência corporativa escalável, resiliente e protegido contra o aprisionamento tecnológico, oferecendo uma solução robusta para a automação de fluxos de trabalho em ambientes corporativos.

Apesar dos ganhos de desempenho e estabilidade, observou-se que o fenômeno de “cold start” impactou as primeiras interações em ambos os provedores de nuvem, resultando em picos de latência inicial. Adicionalmente, a estratégia de processamento de filas da Amazon Web Services, que prioriza a redução de custos por meio do acúmulo de lotes de mensagens, introduziu latências assíncronas mais elevadas no processamento em segundo plano, evidenciando uma contrapartida técnica entre desempenho e custo. Tais achados sugerem que a escolha do provedor ideal para soluções serverless depende dos requisitos não funcionais prioritários de cada organização, seja a latência percebida na interface ou a fluidez da transação de ponta a ponta. Para estudos futuros, recomenda-se aprofundar a análise de estratégias híbridas ou multicloud que otimizem o desempenho em ambas as camadas, explorando a combinação de provedores para mitigar as limitações observadas e maximizar a eficiência operacional e financeira em cenários de alta demanda.

Referências 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.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy