Na natureza, o maior nem sempre é o melhor. Embora um grande tubarão branco possa ser o terror dos oceanos, há muitos casos em que um cardume de peixes é mais capaz de sobreviver e prosperar como um grupo do que qualquer organismo isolado. Na verdade, o sucesso da colaboração é um tema comum em todo o reino animal: colônias de formigas, colmeias, alcateias etc., todos se beneficiam do trabalho dentro de sistemas com conexão fraca para distribuir o controle e alcançar objetivos comuns. E se um membro da colônia, colmeia ou da alcateia perecer, o resto do grupo pode prosseguir e superar a perda.
Os microsserviços usam essa abordagem e a aplicam ao desenvolvimento de software e à arquitetura do sistema. A ideia é que é muitas vezes mais rápido, mais fácil, mais seguro e mais eficiente construir uma série de funções ou serviços de componentes separadamente do que instalar a mesma funcionalidade em um sistema autônomo e totalmente interconectado. Vamos analisar mais detalhadamente os microsserviços, juntamente com seus atributos, benefícios e desafios.
Talvez a melhor abordagem para entender o que são microsserviços é primeiro identificar o que eles não são. Há diversas distinções entre microsserviços e outras abordagens organizacionais. Comparamos microsserviços à arquitetura monolítica tradicional, bem como à SOA (service-oriented architecture, arquitetura orientada a serviços) mais recente.
Como o nome sugere, monólitos são aplicativos grandes e unificados nos quais cada componente é amplamente interconectado e dependente de componentes vizinhos. Os monólitos são a abordagem tradicional para o desenvolvimento, com todas as funções gerenciadas e entregues em um só lugar, e tudo compilado em uma única base de código. Qualquer mudança que os desenvolvedores possam querer implementar em estruturas monolíticas mudará obviamente toda a pilha. Atividades como testes também se aplicam a toda a pilha e, por isso, as mudanças são agrupadas em um grande lançamento, o que pode levar um tempo relativamente longo do início ao fim. Os microsserviços são distintos dos monólitos, pois são compostos por uma série de componentes menores, independentes e com interconexão fraca. As mudanças podem ser implementadas nos componentes individuais sem afetar outros serviços no aplicativo.
A distinção entre microsserviços e SOA é mais sutil. No entanto, embora ambos dependam de componentes reutilizáveis que podem ser aplicados de forma modular a diferentes aplicativos, a SOA não é tão granular. Quando os microsserviços são conteinerizados até o ponto em que cada serviço executa apenas uma única função, cada componente da SOA pode ser um subsistema completo responsável por diversas funcionalidades de negócios. Além disso, a SOA otimiza o compartilhamento e as dependências de componentes, enquanto os microsserviços apenas tentam minimizar esses aspectos o máximo possível.
Normalmente, os microsserviços apresentam os recursos a seguir.
Como os microsserviços são projetados como uma coleção de serviços individuais e independentes, eles podem ser facilmente testados como componentes autônomos. Os problemas nos componentes podem ser isolados com rapidez em vez de precisar testar sistemas e aplicativos inteiros e depois investir muito tempo na tentativa de isolar falhas específicas.
Para operar em conjunto, os microsserviços precisam manter a comunicação uns com os outros. Dito isso, essa é uma conexão fraca, em que as alterações implementadas em um serviço não afetam diretamente outros serviços.
Em vez de compartilhar armazenamentos de dados entre serviços, cada componente constituinte mantém seu próprio armazenamento de dados. Isso ajuda a evitar o acoplamento acidental de diferentes serviços e garante que as mudanças não afetem inadvertidamente outros serviços independentes.
Os serviços individuais são alterados e implantados no ambiente de produção sem a necessidade de empregar outros serviços. Todas as implantações no sistema são gerenciadas dessa maneira, tornando muito rápido o aprimoramento de um microsserviço.
Os microsserviços usam equipes multifuncionais, organizadas em torno de um único objetivo de negócio. Essas equipes geralmente são formadas por desenvolvedores, engenheiros de banco de dados, testadores, engenheiros de infraestrutura e outros, com o objetivo de desenvolver produtos específicos com base em vários serviços independentes.
Em microsserviços, cada serviço independente é capaz de receber, processar e responder a solicitações. Isso é bastante simplificado em relação a muitos dos sistemas tradicionais, em que as camadas complexas de aplicativos de regra de negócios e roteamento podem acabar desacelerando o processo.
Para que um sistema de microsserviços falhe completamente, todos os seus serviços independentes devem falhar ao mesmo tempo. Ao contar com serviços conectados de forma fraca, um sistema pode continuar funcionando próximo da capacidade ideal mesmo em caso de falha de um de seus serviços. Como os serviços são descentralizados, a perda de um terá pouco ou nenhum impacto nos serviços próximos.
Como os microsserviços são de natureza modular, é relativamente fácil adicionar novos serviços quando necessário. Isso possibilita que as organizações adaptem os sistemas atuais a novos usos e dimensionem os sistemas para mais ou para menos para atender à demanda em constante mudança.
Ao desenvolver um novo serviço, as organizações podem escolher entre várias pilhas de tecnologia. Ao mesmo tempo, novas pilhas de tecnologia também podem ser empregadas ao fazer mudanças nos serviços existentes.
A abordagem modular e conteinerizada usada no desenvolvimento de microsserviços faz dele um parceiro natural para DevOps e CI/CD (integração contínua/entrega contínua). Como cada serviço é abordado como uma unidade própria, várias equipes podem trabalhar de forma separada para desenvolver funcionalidades simultaneamente, aplicando princípios de DevOps e movendo projetos rapidamente por meio de pipelines de CI/CD.
Embora seja possível que os microsserviços se comuniquem diretamente entre si, muitas empresas preferem integrar gateways de API para atuarem como camadas intermediárias para ajudar a encaminhar solicitações, fornecer autenticação adicional e melhorar a segurança. A comunicação da API pode ser particularmente eficaz quando os microsserviços estão estabelecendo o estado pela primeira vez.
Os microsserviços representam uma mudança da arquitetura de desenvolvimento tradicional e oferecem diversas vantagens em relação às abordagens organizacionais mais convencionais. Esses benefícios incluem os itens a seguir.
Os microsserviços permitem que equipes pequenas e independentes atuem dentro de contextos claramente definidos. Isso permite que elas consigam mais em menos tempo e respondam com mais agilidade a mudanças imprevistas.
Os microsserviços dividem aplicativos e sistemas complexos em componentes menores e mais simples. Os desenvolvedores podem ver mais facilmente as distinções entre os serviços e fazer as atualizações e melhorias necessárias.
Em vez de ficarem presos a uma única linguagem ou pilha de tecnologia, os desenvolvedores podem selecionar as melhores soluções, ferramentas ou recursos para cada função individual, sem ter que se preocupar se a comunicação entre os serviços será afetada.
Como os aplicativos baseados em microsserviços são altamente modulares, eles podem ser desenvolvidos e implantados com relativa facilidade. As equipes podem se coordenar para trabalhar simultaneamente em componentes individuais e pequenos, e cada componente pode ser implantado de forma independente.
Na arquitetura de aplicativos tradicional, atender à demanda em constante mudança significa, muitas vezes, dimensionar todo o aplicativo. Os microsserviços permitem que os desenvolvedores redirecionem recursos para dimensionar apenas os serviços e componentes aplicáveis, melhorando as velocidades de dimensionamento e reduzindo os custos associados.
No caso de falha de um microsserviço, os microsserviços próximos permanecem inalterados. Isso significa que os aplicativos baseados em microsserviços não tendem a falhar; se um ou mais componentes falharem, o próprio aplicativo continuará a operar com funcionalidade reduzida até que o serviço afetado possa ser reparado.
Já que cada serviço é autocontido e projetado para desempenhar independentemente uma função específica, os desenvolvedores podem reutilizar e reciclar serviços para uso em vários aplicativos diferentes. Os componentes podem funcionar como “elementos de base”, reduzindo significativamente a necessidade de criar um novo código do zero para cada novo projeto.
Maior agilidade, maior capacidade de reutilização e implantação simplificada promovem ciclos de desenvolvimento mais curtos e menor tempo para disponibilização ao mercado. Isso tem o potencial de melhorar os retornos dos negócios e proporcionar uma experiência de usuário mais satisfatória.
As vantagens representadas pelos microsserviços também têm algumas dificuldades. A seguir, analisamos com mais detalhes alguns dos desafios que as organizações podem enfrentar ao implementar uma abordagem de microsserviços.
Mudar para microsserviços significa identificar e catalogar todas e quaisquer dependências entre os serviços. Devido às dependências, a conclusão de uma única compilação pode levar diretamente à necessidade de implementar várias outras, o que pode ser frustrante e demorado.
Um fator importante nos microsserviços é que cada componente tem seu próprio banco de dados isolado. No entanto, com cada novo banco de dados, aumenta a complexidade no gerenciamento. Quanto mais serviços e mais bancos de dados estiverem sendo empregados, menos conveniente será gerenciar os dados em si.
Ao atualizar aplicativos para novas versões usando microsserviços, há a chance de que a compatibilidade com versões anteriores possa ser afetada. As soluções, desenvolvidas em lógica condicional ou com várias versões ativas para diferentes clientes, podem ser muito complexas em termos de manutenção e gerenciamento.
Os microsserviços são projetados para simplificar a implantação. Contudo, a complexidade de trabalhar com um grande número de componentes independentes pode ser alta. A automação pode ajudar a resolver esse problema.
O registro em log pode se tornar difícil quando cada serviço usa seu próprio banco de dados. Pode ser necessário definir soluções de registro centralizado. Da mesma forma, o monitoramento e o gerenciamento de cada serviço podem ser inviáveis sem uma visão centralizada e uma única fonte de verdade.
Com potencialmente centenas de microsserviços incorporados em um único aplicativo, a depuração tradicional não é uma opção.
Embora a arquitetura de microsserviços proporcione às equipes um nível razoável de independência, os problemas que abrangem mais de um serviço em um aplicativo podem exigir comunicação e coordenação detalhadas entre equipes.
Como os aplicativos de microsserviços são sistemas distribuídos, é possível que as equipes dupliquem tarefas sem saber disso, o que pode resultar em desperdício de esforço e em aplicativos ineficientes.
Além dos desafios abordados acima, há certas armadilhas que as organizações devem conhecer ao considerar adotar uma arquitetura de microsserviços, listadas a seguir.
Embora seja uma abordagem muito popular para a arquitetura de desenvolvimento, os microsserviços costumam ser mais adequados para reparar e revisar aplicativos existentes que ficaram muito complexos e difíceis de manter. Eles não são tão eficazes quando usados como ponto de partida. Se a abordagem tradicional não tiver atingido níveis incontroláveis, não é de fato um monólito precisando ser reestruturado.
Como ocorre com tudo, um serviço sempre pode ser dividido em partes menores. E embora os microsserviços devam ser granulares, consistindo em funções limitadas projetadas para oferecer suporte a um todo maior, é possível levar as coisas longe demais. Em vez disso, muitas empresas observam que começar com serviços maiores e, em seguida, apenas separá-los em microsserviços quando esses serviços se tornam lentos para implantação ou muito complexos para gerenciamento ajuda a garantir que a solução não elimine os possíveis ganhos.
Um sistema grande e distribuído pode facilmente sair do controle. Para garantir a eficácia dos microsserviços, as organizações devem incorporar a implantação avançada e a automação de monitoramento, junto a serviços em nuvem gerenciados. Isso pode ajudar a aliviar grande parte da carga da transição para microsserviços.
A ServiceNow pode ajudar nos aspectos de gerenciamento de serviços desenvolvidos aproveitando microsserviços, bem como fazendo a conexão às metodologias e ferramentas usadas nas fases de criação, como CI/CD e outras soluções de DevOps.
Por conta do potencial para um grande número de microsserviços e sua natureza transitória, a ServiceNow fornece opções para popular automaticamente o CMDB e o Service Graph para ajudar a rastrear relacionamentos e manter a definição dos serviços. Faz parte da nossa oferta do IT Operations Management, que também tem habilidades mais amplas de gerenciamento de nuvem.
Assim como qualquer código desenvolvido com práticas de DevOps, a velocidade é um objetivo comum ao manter microsserviços, ou seja, fornecer o caminho mais rápido possível entre um desenvolvedor e um sistema de produção. Porém, organizações maiores ou regulamentadas devem manter controles de mudança sólidos, por isso, o IT Service Management Professional inclui nosso recurso DevOps Change Velocity, que se conecta ao pipeline de CI/CD, reúne informações durante o processo de desenvolvimento e as utiliza junto a políticas previamente definidas para automatizar o processo de gerenciamento de mudanças.
Por fim, a ServiceNow é uma fonte rica de habilidades que podem ser utilizadas por aplicativos internos e externos de maneira semelhante a microsserviços, além de oferecer suporte à integração com microsserviços externos como parte dos fluxos de trabalho da ServiceNow.
A Now Platform inclui habilidades essenciais que permitem digitalizar fluxos de trabalho de modo rápido e eficiente e executá-los em escala.