O FIM DO FIM DA VIDA SEM FIM COM MULESOFT

Às vezes não é fácil ser um cliente MuleSoft. Embora nunca tenhamos estado lá, muitos dos nossos clientes estiveram.

O modelo de licenciamento é caro, com o suporte e a manutenção também consumindo uma parte significativa do orçamento. Treinar (ou contratar) pessoas para trabalhar com a tecnologia é outro obstáculo, com certificações e cursos especiais consumindo o orçamento de TI e afastando as únicas pessoas capazes de fazer o MuleSoft funcionar. De acordo com nossa pesquisa anual, manutenção e treinamento estão no topo da lista para orçamentos de integração que não utilizam iPaaS, consumindo quase 40% do gasto. Ou seja, não estamos falando de uma quantia pequena.

A tecnologia, no auge de sua popularidade, era realmente incrível, oferecendo capacidades de integração para SaaS, softwares locais, sistemas legados e outras plataformas. Mas a tecnologia do início dos anos 2000 não é suficiente para organizações que precisam de mudanças significativas. Hoje em dia, a integração empresarial é um facilitador de inovação e agilidade. Se ela estiver restringindo o negócio, então não está cumprindo seu papel.

>> Agende uma demonstração personalizada com nossa equipe de especialistas e veja como a iPaaS da Digibee pode trazer mais eficiência para o seu negócio.

Um Ponto de Ruptura do MuleSoft: Fim de Vida

Um grande motivador para as empresas que estão deixando o MuleSoft é a experiência caótica e cara do fim de vida (EOL). Por exemplo, o Mule Runtime Engine V4.3, que recentemente passou de suporte padrão para suporte estendido.

Embora o suporte estendido para o Runtime Engine possa parecer razoável como uma última etapa no ciclo de vida, é preciso ler as letras miúdas. Quando uma versão entra em suporte estendido, a funcionalidade básica da empresa é negada até que o cliente atualize para a nova versão. E não estamos falando de um pequeno incômodo. Estamos falando da capacidade de reiniciar aplicativos ou criar novos na CloudHub, a plataforma de integração do MuleSoft. Como o seu negócio funcionaria se essas atividades de aplicativos fossem suspensas?

Aplicativos Não Funcionando

Atualizar para a próxima versão do Runtime Engine não é uma experiência tranquila, especialmente quando se trata de gerenciar seus aplicativos existentes.

Quando um aplicativo Mule é criado, o desenvolvedor seleciona o Runtime Engine sobre o qual o aplicativo será executado, ou seja, a versão do Mule alvo. Cada aplicativo é construído dessa forma e, como os aplicativos são criados ao longo do tempo, não é incomum que as versões alvo do Mule variem de um aplicativo para outro. Você pode imaginar onde queremos chegar com isso.

A MuleSoft oferece um mecanismo de “flagging” de funcionalidades. Ele ajuda a identificar aplicativos e alterar o comportamento da instância Mule dependendo da versão mínima do Mule atribuída ao aplicativo quando foi criado. Confuso? Aqui está o artigo da MuleSoft que fornece mais detalhes.

Essa capacidade foi criada para dar suporte à compatibilidade retroativa, mas é complexa. Embora seja promovida como “automática”, ainda há muito trabalho manual necessário, já que cada aplicativo precisará de uma flag de funcionalidade individual.

Uma vez identificados os aplicativos que precisam ter a versão do Mule alterada, um desenvolvedor deve tocar em cada um, importando o aplicativo para o Anypoint Studio como um projeto Mule e alterando a versão do Mule manualmente, selecionando-a no Menu de Runtime do Servidor. Isso resulta em muito tempo sendo gasto por desenvolvedores certificados e caros em tarefas manuais de “limpeza” no EOL.

Um Conflito de Compatibilidade

Seria muito útil se a compatibilidade fosse garantida. Mas isso nunca é uma certeza. De fato, raramente é garantido quando a nova versão é considerada maior (por exemplo, de Runtime 4.x para 5.x).

Embora a MuleSoft prometa “potencial compatibilidade” entre versões menores, não há certeza nem muitos insights, o que torna difícil planejar e alocar recursos para o próximo ciclo.

Os Custos Reais do MuleSoft EOL

Com um modelo tão complicado e intensivo em trabalho, não é surpresa que a experiência de EOL do Mule Runtime tenha um custo. Aqui estão algumas considerações:

1. Recursos: Já cobrimos o custo e o tempo necessários para certificar alguns ou todos os membros da sua equipe para aprender a usar o MuleSoft. Atribuir essas pessoas a tarefas básicas de manutenção reduz ainda mais o ROI, que já está em risco.
2. Largura de banda: Enquanto essas mãos treinadas estão ocupadas editando os aplicativos um por um, trabalhos mais importantes ficam parados e os backlogs de TI continuam crescendo. Os backlogs de TI fora de controle são um dos principais motivadores para que os clientes do MuleSoft migrem para o Digibee.
3. Ciclos repetitivos de trabalho: Os ciclos de vida das versões estão ficando mais curtos, forçando os clientes do MuleSoft a fazer tudo de novo em um ritmo cada vez mais rápido. Por exemplo, o Runtime V4.3 terminou o suporte padrão em 7 de junho de 2023, enquanto o 4.4 terminará em 7 de fevereiro de 2024.
4. Interrupções nos negócios: Se você não tem uma equipe completa de desenvolvedores MuleSoft disponível, é improvável que você faça a atualização no primeiro dia. A incapacidade de reiniciar e implantar novos aplicativos apresenta riscos reais para sua operação, aumentando a possibilidade de tempo de inatividade e interrupções nos negócios.

A Diferença Digibee

A melhor atualização do MuleSoft para muitas empresas é quando elas migram para a plataforma moderna de integração como serviço (iPaaS) da Digibee.

Aqui estão apenas alguns dos pontos altos:

• Sem upgrades para você se preocupar. Nunca.
• Não há necessidade de engenheiros e desenvolvedores investirem 8-10 semanas para aprender e ser certificados. Com a Digibee, a curva de aprendizado é de apenas alguns dias. Habilidades especializadas não são necessárias, além de ser gratuito. Nossos clientes nunca pagarão para aprender.
• A interface de arrastar e soltar fácil de usar é acessível para trabalhadores júnior e experientes, permitindo que todos contribuam com menos erros e mais rapidez na entrega de resultados.
• Não há dependência de integrações personalizadas e outros suportes. A plataforma de baixo código da Digibee permite que equipes internas escalem, monitorem e construam integrações do zero, tudo em um só lugar.
• Digibee é nativa da nuvem, baseada em engine e construída sobre Kubernetes, deixando a arquitetura local do MuleSoft para trás.

Para saber mais sobre as vantagens da tecnologia iPaaS da Digibee em comparação com o MuleSoft, agende um horário para conversar conosco.