Inglês
Espanhol
Continuando a série de posts “Automatize qualquer processo, em qualquer lugar!”, hoje vamos falar sobre microservices.
Apesar dos microservices serem construídos para serem integrados, ainda trazem uma complexidade grande de entendimento de todos os ativos de software pelas áreas de negócio (e muitas vezes pelas próprias equipes de TI):
- Quem são os donos do serviço?
- Quais são os atuais clientes de um serviço?
- Como os processos estão sendo executados?
Esta falta de visão de como os microservices são integrados e de como os processos funcionam (passando de serviço a serviço e também pelas pessoas através dos front-ends), se dá porque o processo automatizado está oculto em códigos-fonte espalhados dentro destes microservices ou mesmo no front-end. Para o usuário do sistema, antes de clicar no botão “Confirmar”, poderá lhe vir aquele pensamento de “Seja o que Deus quiser!”, fecha os olhos e clica.
Para a equipe de sustentação, quando recebe um chamado, fica aquela pergunta “O que eu faço agora?”, e vai gastar extensas horas minerando mensagens de erros nos diversos logs distribuídos nos diversos microservices.
Outro problema dos microservices é, uma vez que os serviços estão distribuídos, como posso garantir as transações de negócio? E se uma exceção ocorrer no meio do caminho de um processo, o que uma squad deve fazer para resolver? Guardar tudo em um banco de dados ou desfazer tudo o que foi processado até aqui? Como enviar uma necessidade de rollback se o que foi executado foi desenvolvido por outra squad? Estas interligações furtivas entre o microservices pode tornar a comunicação entre squads intensa e atrasar a cadência dos projetos. Na pressa, acaba-se quebrando um dos princípios da filosofia Unix que motivou a criação do design de microservices: “Faça uma coisa e faça-a bem”.
A filosofia Unix foi documentada por Doug McIlroy [1] no Bell System Technical Journal de 1978:
1. Faça com que cada programa faça bem uma coisa. Para fazer um novo trabalho, crie de novo, em vez de complicar os programas antigos, adicionando novos “recursos”.
2. Espere que a saída de cada programa se torne a entrada de outro programa ainda desconhecido. Não sobrecarregue a saída com informações estranhas. Evite formatos de entrada estritamente colunares ou binários. Não insista em informações interativas.
3. Projete e construa software, até mesmo sistemas operacionais, para serem testados o quanto antes, de preferência dentro de semanas. Não hesite em jogar fora as peças desajeitadas e reconstruí-las.
4. Use ferramentas em vez de ajuda não especializada para aliviar uma tarefa de programação, mesmo se você tiver que desviar para construir as ferramentas e esperar jogar algumas delas fora depois de terminar de usá-las.
Não há como contestar que filosofia Unix traz grandes benefícios aos microservices “da porta para dentro”, e concordamos que os microservices devam ser construídos desta maneira, mas nota-se que não há um compromisso claro com os processos de negócio. O segundo item desta filosofia deixa isto muito claro. Com isso muitos desenvolvedores de software fazem seu trabalho sem ter a visão do todo, contrapondo a filosofia Lean que, empaticamente, bota todo foco na experiência do cliente. De forma que, os microservices, assim como os monolíticos, também não resolvem os processos de uma forma elegante. Não fica claro na arquitetura de microservices de quem é a responsabilidade de cuidar dos processos, e pensar que construir funcionalidades unívocas elimina a necessidade de orquestração é uma ilusão. Por isso preferimos um design orientado a Workflow Orchestration em conjunto com microservices, como demonstrado na figura abaixo:
Com este design podemos obter todos os benefícios dos microservices, sem perder de vista o fluxo de informação. Porém, não apoiamos a utilização de uma plataforma de processos monolítica, como ocorre com os antigos BPMS. Camunda trabalha muito bem com Human Workflow e com Technical Workflow, permitindo a construção de microprocess distribuídos, sem perder os benefícios da orquestração, além de aproveitar o ativo de TI já investido. Abaixo uma tabela comparativa de cada design de software:
| MONOLITHIC | MICROSERVICES | WORKFLOW ORQUESTRATION | |
| Arquitetura auto contida | ✔ | ✔ | ✔ |
| Arquitetura distribuída | ✔ | ✔ | ✔ |
| Realiza tarefas completas de ponta-a-ponta | ✔ | ✔ | ✔ |
| Acoplamento | Auto | Baixo | Baixo |
| Integração das informações | Interno, compromissada com o fluxo de informações. | Distribuído, com pouco compromisso com o fluxo de informações. | Distribuído, compromissado com o fluxo de informações. |
| Desenvolvimento e Manutenção | Geralmente dificultosa, mudanças podem afetar várias partes do sistema, compilação de toda a plataforma é necessária. | Facilitada e distribuída em squads. Manutenções não impactam em toda a plataforma, somente em partes da mesma. | |
| Escalabilidade | Baixa. Processamento de informações centralizado. | Alta. Processamento distribuído em servidores implantados em contêineres. | |
| User Interface | Em alguns casos é feita instalação desktop para melhorar a performance, retirando do servidor o processamento de interface de usuário. | Micro-front-ends web, Apps mobile e APIs Gateways internas ou públicas. | |
| Instalação | Quando desktop, é preciso distribuir o pacote de instalação e reinstalar o aplicativo inteiro, o que pode se tornar uma tarefa bastante onerosa a depender da quantidade de estações cliente. | Via DevOps. | |
Assim, as características de automatizar qualquer processo em qualquer lugar da Camunda permitem aproveitar todo o potencial dos microservices, sem perder os benefícios da integração de informações dos antigos monolithics.
Quer saber mais sobre como Camunda pode alavancar a inovação na sua empresa? Deixe seus dados abaixo e em breve nós entraremos em contato com você! Vamos agregar valor ao seu negócio!
Autor: Rodrigo Carlstrom
Sobre: consultor BPM há 18 anos, tendo trabalhado com análise, automação, operação e melhoria de processos de negócio e como Gerente de Projetos e Gestor de Mudanças em grandes empresas do mercado. Certificado Black Belt, PMP e Camunda Engineer.
