End of Life sem fim com MuleSoft

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

O modelo de licenciamento é caro, com suporte e manutenção que também consome parte do bottom line. Treinar (ou contratar) pessoas para trabalhar com a tecnologia é outro dificultador, com certificações especiais e cursos , consumindo os orçamentos de TI. De acordo com a nossa pesquisa anual, manutenção e treinamento estão no topo da lista dos orçamentos de integração non-iPaaS, consumindo quase 40% dos gastos. Portanto, não estamos falando de pouca coisa.

A tecnologia, em seu auge, era incrível, oferecendo recursos de integração para SaaS, software local, 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, a integração empresarial é um facilitador de inovação e agilidade. Se está restringindo os negócios, não está exercendo a sua função.

>> Agende uma demonstração personalizada com nossa equipe de especialistas e veja como o iPaaS da Digibee trará eficiência ao seu negócio. 

Um ponto de inflexão da MuleSoft: End of Life

Um grande motivador para as empresas que estão saindo da MuleSoft é a experiência desorganizada e cara de end of life (EOL). Por exemplo, o Mule Runtime Engine V4.3, que recentemente retornou do suporte padrão para o estendido.

Embora o suporte estendido para o Runtime Engine possa parecer razoável como uma etapa final na jornada do fim da vida útil, você precisa ler as letras miúdas. Depois que uma versão entra no suporte estendido, a funcionalidade empresarial de linha de base é negada até que o cliente atualize para a nova versão. E não estamos falando de um pequeno inconveniente. Estamos falando da capacidade de reiniciar aplicativos ou criar novos no CloudHub, a plataforma de integração MuleSoft. Quão bem sua empresa funcionaria se essas atividades de aplicativos fossem suspensas?

Un-Appy Apps

Atualizar para a próxima versão do Runtime Engine não é uma experiência perfeita, principalmente ao gerenciar seus aplicativos existentes.

Quando um aplicativo Mule é criado, o desenvolvedor seleciona o Runtime Engine no qual o aplicativo será executado, também conhecido como a versão Mule de destino. Cada aplicativo é criado dessa maneira e, como os aplicativos são criados ao longo do tempo, não é incomum que as versões de destino do Mule sejam diferentes por aplicativo. Você pode ver onde estamos indo com isso.

O MuleSoft fornece um mecanismo de sinalização de recurso. 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 ele foi criado. Confuso? Aqui está o artigo MuleSoft para lhe fornecer ainda mais detalhes.

Esse recurso destina-se a oferecer compatibilidade com versões anteriores, mas é complicado. Embora anunciado como “automático”, ainda é necessário muito trabalho manual, pois cada aplicativo precisará de um sinalizador de recurso individual. 

Uma vez identificados os aplicativos que precisam alterar a versão do Mule de destino, um desenvolvedor deve tocar em cada um, importando o aplicativo para o Anypoint Studio como um projeto do Mule e alterando a versão do Mule manualmente, selecionando-a no menu Server Runtime. Isso aumenta muito o tempo para desenvolvedores certificados e caros gastarem na limpeza manual da casa EOL.

Um conflito de compatibilidade

Certamente ajudaria se a compatibilidade fosse garantida. Mas isso nunca é um dado. Na verdade, raramente é garantido se a nova versão for considerada principal (por exemplo, Runtime 4.x a 5.x). 

Embora MuleSoft prometa “compatibilidade potencial” em versões menores, não há certeza e pouca percepção, dificultando o planejamento e os recursos para o próximo ciclo.

Os altos custos do MuleSoft EOL

Com um modelo tão complicado e trabalhoso, não é surpresa que a experiência Mule Runtime EOL tenha um custo. Algumas considerações:

1. Recursos: Já cobrimos o custo e o tempo necessários para certificar parte ou toda a sua força de trabalho para aprender a usar o MuleSoft. Designar essas pessoas para trabalhar em tarefas básicas de manutenção diminui um ROI já oscilante.
2. Capacidade organizacional: Enquanto times experientes estão ocupados executando aplicações, um código de cada vez, o trabalho mais importante fica ocioso e as pendências de TI continuam a crescer. Os backlogs de TI fora de controle são um dos principais motivadores para os clientes MuleSoft avançarem para o Digibee.
3. Ciclos repetitivos de trabalho: Os ciclos de vida de lançamento estão ficando mais curtos, forçando os clientes da MuleSoft a fazer tudo de novo em uma cadência cada vez mais rápida. Por exemplo, o Runtime V4.3 encerrou 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 um complemento completo de desenvolvedores MuleSoft sentados procurando trabalho, é provável que você não atualize no primeiro dia. A incapacidade de reiniciar e implantar novos aplicativos apresenta riscos reais para sua operação, aumentando o potencial de tempo de inatividade e interrupções nos negócios.

O diferencial da Digibee

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

Aqui estão apenas alguns dos pontos chaves:

• Não há atualizações para você se preocupar. Para sempre.
• Não há necessidade de engenheiros e desenvolvedores investirem de 8 a 10 semanas para aprender e obter certificação. Com a Digibee, a curva de aprendizado é de dias. Habilidades especializadas não são necessárias, além disso, é gratuito. Nossos clientes nunca pagarão para aprender.
• A fácil de usar interface de arrastar e soltar é acessível para os profissionais juniores e experientes, permitindo que todos contribuam com menos erros e um tempo mais rápido para geração de valor.
• Não há dependência de integrações personalizadas e outros suportes. O modelo de precificação low code para pro-codificadores permite que equipes internas dimensionem, monitorem e criem integrações do zero, tudo em um só lugar.
• A Digibee é nativo da nuvem, baseado em mecanismo e desenvolvido em Kubernetes, deixando a arquitetura local da MuleSoft para trás.

Para saber mais sobre as vantagens da tecnologia iPaaS da Digibee versus MuleSoft, reserve um tempo para contacte-nos.