Introdução
Já faz algum tempo que microsserviços foram uma alternativa para arquitetura monolítica de aplicações. Eles traziam um novo modo de se desenvolver com seus próprios riscos e recompensas. Agora, chegamos a um ponto onde a questão não é mais a necessidade de migrar, mas como fazer isso. No entanto, a migração é um processo desafiador que pode causar problemas caso seja mal executado. Este post explicará por que microsserviços são necessários, os desafios de migrar para microsserviços e como elaborar um plano de migração.
Razões para Migrar
Muito da sabedoria convencional acerca de microsserviços sugere começar com uma aplicação monolítica e migrar para microsserviços quando ela chegar a um tamanho incontrolável. No entanto, quanto maior uma aplicação monolítica se torna, mais difícil é decompô-la. Por isso, empresas devem considerar se planejar com antecedência para se certificar de estarem preparadas tanto para seu próprio crescimento quanto para as mudanças da infraestrutura móvel.
O crescimento da sua empresa
Os microsserviços são particularmente importantes à medida que as aplicações crescem e escalam. Para aplicações monolíticas, escalar pode ser extremamente caro, necessitando de uma abordagem de “tamanho único” que não consegue lidar com gargalos específicos sem acumular recursos subutilizados.
Além disso, quando há mudanças em aplicações monolíticas, é necessário reconstruí-las para poder implementá-las. Isso pode impedir inovações, limitando que novas funcionalidades sejam apresentadas e dificultando o processo de consertar bugs, o que resulta em inatividade e descuidos que levam a custos técnicos.
Em um artigo do TechBeacon, os executivos da Wix.com, Best Buy e Cloud Elements apontaram como razões para migrar para microsserviços:
- dificuldade para escalar;
- lentidão para implementar novas funcionalidades;
- custos técnicos;
- tempo de inatividade; e
- grandes dependências.
Além disso, enquanto as redes móveis de 5G se tornam cada vez mais universais, um modelo de microsserviços não é apenas vantajoso, mas crucial para empresas de qualquer tamanho.
Prontidão do 5G
A adoção do 5G já está se espalhando pelo mundo, com serviços mobile que oferecem atualização de redes LTE com tecnologias de 5G New Radio, além de criarem novas implementações de infraestrutura com arquitetura 5G. O 5G moderniza o LTE à medida que impulsiona princípios de arquitetura que demandam microsserviços, incluindo a separação de planos de controle e de usuário (CUPS) e slicing de redes.
Esses princípios requerem design modular para que a entrega seja o mais ágil possível. O slicing de redes cria múltiplas redes virtuais agrupadas por SLAs para priorizar serviços críticos e garantir uma variedade de métricas de desempenho. O slicing de redes é apoiado por CUPS, que permite que planos de controle e de usuários fiquem em locais diferentes e sejam escalados independentemente.
Para alcançar as demandas e eficiência da arquitetura 5G, no entanto, John Lenns, VP da Oracle, apontou em uma entrevista que “operadoras estão pedindo por implementações de microsserviços” para que apenas “certos microsserviços para aquela oferta em particular sejam melhorados.”
Desafios da Migração
Apesar dos benefícios da migração para microsserviços, esse processo pode apresentar alguns desafios empresariais e técnicos. Durante a transição da empresa, podem haver sobreposições, criando dores de cabeça enquanto a equipe descobre como lidar com aplicações monolíticas paralelamente aos microsserviços. Além disso, podem ocorrer problemas como mudança cultural da empresa, escolha da plataforma correta e questões técnicas como problemas em bancos de dados.
Cultura da empresa
Um princípio de longa data conhecido como Lei de Conway mostra que as aplicações tendem a seguir a mesma organização da empresa que as construiu. Isso significa que alterar a organização dos funcionários de uma aplicação monólito para reorganizá-los ao redor de funções específicas dentro da empresa exige algumas mudanças dentro da empresa também.
Além disso, a diversidade técnica dos microsserviços pode trazer eficiência para as equipes, que podem trabalhar com linguagens de programação e bancos de dados diferentes. Kristen Womack, ex-gerente de produto sênior da Best Buy, falou da dificuldade dessa mudança em uma entrevista com o TechBeacon, apontando que “resistência cultural à forma como softwares são construídos e implementados deve ser esperada”, e observando que é “especialmente desafiador quando se muda a forma como as pessoas trabalham”.
Encontrando uma plataforma
Os microsserviços oferecem mais flexibilidade às empresas em relação à tecnologia que usam para implementar módulos diferentes, mas isso pode acarretar dificuldades. Apesar de muitas empresas preferirem usar Kubernetes para orquestração de soluções baseadas em contêiner, pesquisa da Forrester de fevereiro de 2020 aponta Kubernetes como plataforma não coesa.
Em vez disso, é mais como “uma enorme caixa de Lego para construir qualquer plataforma de aplicação que você precise”. O resultado disso é que, por fim, muitas empresas podem usar múltiplas plataformas feitas sob medida para as necessidades específicas de microsserviços, que podem evoluir com o tempo enquanto serviços são adicionados, alterados ou substituídos.
Desafios Técnicos
Além de considerações de negócios inerentes à transição para microsserviços, também há certos desafios técnicos. Desarticular uma aplicação monolítica geralmente significa desarticular um banco de dados monolítico para que haja um banco de dados por micro serviço.
Um artigo recente da IBM afirma que isso é uma tarefa complicada porque bancos de dados monolíticos não têm limites claros entre mapas de objetos para funções diferentes. Além disso, desmembrar um banco de dados envolve lidar com transações distribuídas e complicações para reportar entre diferentes serviços.
Por causa dos desafios inerentes à migração, é importante que as empresas se dêem conta de seus recursos e necessidades para que possam organizar uma estratégia de migração. Essa estratégia deve incluir planos de modernização de longo e curto prazo, além de escolher um parceiro que possa assistí-los nessa jornada.
Elaborando um Plano de Migração
Em longo prazo
Um relatório de outubro de 2020 sobre modernização de aplicações da Forrester resume bem as mudanças em longo prazo que uma empresa precisa fazer em decorrência desse processo. Além de mudar a cultura da empresa e reestruturar equipes em função dos diferentes produtos que usam microsserviços, o relatório sugere que o processo de modernização pode precisar contratar novos talentos, utilizar novas métricas para acessar os valores da empresa; adotar novos processos como CI/CD, e abraçar novas tecnologias para automação de infraestruturas.
A enormidade dessa tarefa torna ainda mais necessário evitar fazer tudo de uma só vez. Um artigo recente da InfoQ sobre migração lista isso entre os maiores aprendizados: perceber que tratar a modernização como um projeto com prazos estabelecidos é perigoso, já que pode impedir o avanço de novas implementações. Em vez disso, é recomendado que a empresa “descubra onde estão seus pontos de crise, seus maiores gargalos e outros desafios e trabalhe em cima desses, um por vez.”
Em curto prazo
Mesmo sendo amplamente aceito que a migração deve ser um processo progressivo, conselhos sobre “por onde começar” variam muito, já que dependem bastante da aplicação em questão. No entanto, alguns fatores podem influenciar essa decisão, como a base de usuários, o código e os recursos da empresa.
Avaliando a aplicação
Uma das considerações mais importantes acerca de qual serviço deve ser o ponto de partida da sua empresa é descobrir qual deles é mais fácil. Já que as equipes vão modificar o código, além de ajustarem-se às mudanças culturais da empresa e à estrutura organizacional, começar com um processo simples pode ser benéfico. Serviços mais fáceis de separar de um monólito:
- têm poucas dependências;
- se separam com facilidade do banco de dados;
- são fáceis de testar; e
- não são críticos para a missão da empresa.
Avaliando os usuários
Um relatório da Forrester de março de 2020 sobre arquitetura de referência de microsserviços resume bem a necessidade de levar os usuários em consideração na hora de escolher como decompor uma aplicação, além de pensar apenas no código. A Forrester percebeu que “os microsserviços não variam apenas em concepção, mas em conjuntos específicos de características de qualidade de serviço, padrões de uso e considerações de negócios que podem ser exclusivas de cada domínio comercial.”
Como resultado, pode ser necessário às empresas cederem em questão de QoS, segurança, disponibilidade e escalabilidade. Também deveriam considerar o seguinte:
- quais são as exigências de segurança da sua área?
- quanta flexibilidade de inatividade sua empresa tem?
- quais são os padrões de uso do seu app? e
- que qualidade de serviço seus usuários esperam?
Responder a essas perguntas pode ajudar a determinar quais serviços podem agregar mais valor às suas aplicações, garantindo que o tempo investido traga os melhores retornos possíveis.
Avaliando os recursos
Dois recursos necessários para a transição de microsserviços são dinheiro e talento. Em termos de custos, as empresas devem estar preparadas para lidar com custos de novas ferramentas e softwares de monitoramento, além de horas extras que vai levar para os desenvolvedores aprenderem a usar aquelas ferramentas, sem contar o tempo gasto na própria migração.
Quanto mais tempo gasto na migração, menos tempo sobra para desenvolver novas funcionalidades. Além disso, novos membros da equipe precisam ser contratados para preencher as lacunas de expertise. Assim, empresas podem avaliar quais recursos precisam estar disponíveis para a jornada de seus microsserviços considerando:
- níveis de habilidade dos seus desenvolvedores e quais suas áreas de expertise;
- novas habilidades sua equipe precisa aprender;
- ferramentas sua empresa precisa adquirir; e
- custos totais em termos de horas de desenvolvedores, ferramentas e novas contratações.
As empresas têm de levar esses custos em consideração para evitar serem pegas de surpresa no meio do projeto. Além disso, considerar os custos totais do desenvolvimento de novos microsserviços pode ajudar empresas a escolher um parceiro para ajudar no processo de migração.
Encontrando um parceiro
Há diversas ferramentas de código aberto que ajudam a trabalhar com microsserviços, mas montar uma plataforma (ou múltiplas plataformas) de cada um dos elementos pode ser dispendioso devido ao tempo e habilidades necessários para implementá-los. Encontrar o parceiro certo para ajudar com a transição pode ajudar empresas a superar desafios e garantir que os microsserviços agreguem o máximo de valor possível às suas aplicações.
O Azion Edge Functions simplifica o processo de migração por meio de uma abordagem serverless que reduz complexidades operacionais; como provedor serverless, cuidamos da segurança do servidor, escalada e gestão de infraestrutura, permitindo que você foque no desenvolvimento front-end. O cliente paga apenas pelo tempo em que suas funções são executadas, reduzindo custos antecipados e evitando desperdício de recursos.
O próximo post dessa série abordará a modernização de apps mais detidamente, examinando várias estratégias de modernização de métodos minimamente invasivos, como rehosting “lift and shift”, até métodos mais intensivos como reconstrução e substituição.
