O que são microservices?

Microservices, também conhecido como arquitetura de microservices ou microsserviços, são um método de desenvolvimento de software que estrutura um aplicativo como uma coleção combinada de serviços. Essencialmente, esse conjunto de aplicativos é implantado como um aplicativo completo por si só, e todos esses serviços trabalham juntos para compor o aplicativo inteiro. Todos os microsserviços seguem esses padrões: eles são organizados em torno dos recursos de negócios, são acoplados de forma flexível, são implantáveis de forma independente e são testáveis. Por serem fracamente acoplados, os microsserviços podem ser criados, implantados e dimensionados de forma independente.

Diagrama de microsserviços

Cada serviço se comunica com os outros por meio de interfaces de programação de aplicativos (APIs) padronizadas, permitindo que sejam escritos em diferentes linguagens ou em diferentes tecnologias. Isso difere completamente dos sistemas construídos como estruturas monolíticas onde os serviços estão inextricavelmente interligados e só podem ser dimensionados juntos.

Como cada serviço tem uma funcionalidade limitada, geralmente singular, é muito menor em tamanho e complexidade. O termo microsserviço vem desse design de funcionalidade independente.

Ao decompor o aplicativo em serviços separados que implementam funções de negócios específicas, os microsserviços oferecem aos desenvolvedores modernos uma maneira de projetar aplicativos altamente escaláveis e flexíveis.

Por que microsserviços?

Os microsserviços aumentaram em popularidade porque suas características modulares levam a flexibilidade, escalabilidade e esforço de desenvolvimento reduzido. Sua flexibilidade de implantação e o aumento das opções de implantação nativas da nuvem serverless e de função como serviço (como AWS Lambda e Microsoft Azure Cloud Functions) criaram o ambiente perfeito para que os microsserviços se expandissem no cenário de TI atual. Essas plataformas de nuvem permitem que microsserviços e funções sejam dimensionados da inatividade para alto volume e vice-versa, enquanto os clientes pagam apenas pela capacidade de computação que usam.

Como as empresas buscam continuamente ser mais ágeis, reduzir gargalos e melhorar os tempos de entrega de aplicativos, a popularidade da arquitetura de microsserviços continua crescendo.

No passado, as empresas desenvolviam aplicativos empresariais especializados que tinham três componentes principais:

  • Uma interface voltada para o cliente, geralmente páginas HTML executadas na máquina de um usuário
  • Um banco de dados, normalmente muitas tabelas em um sistema de gerenciamento de banco de dados relacional
  • Um aplicativo do lado do servidor que lidava com todas as solicitações, como recuperação de dados, solicitações HTTP e preenchimento de navegadores HTML.

Para o usuário, tudo parecia passar por um único ponto de contato. Desenvolvimento, teste e implantação usavam um pipeline de implantação e você podia escalar horizontalmente executando várias instâncias.

No entanto, eles eram bastante caros para desenvolver, quaisquer alterações exigiam redesenho, reconstrução e reimplantação completos do sistema, era difícil manter uma estrutura limpa e modular à medida que a organização crescia e mudava e a escalabilidade horizontal exigia que o aplicativo completo fosse testado, dimensionado e reimplantado novamente para qualquer alteração, não importando quão pequena fosse a revisão. Todos esses problemas levavam a um sistema caro e não ágil que o cenário tecnológico em rápida mudança superou rapidamente.

Uma maneira de pensar nesses sistemas monolíticos tradicionais são como casas de bonecas prontas. Embora você possa editar a estrutura ou o layout, isso não é fácil, e você está limitado no tamanho geral a menos que compre outra casa de bonecas e a anexe à casa de bonecas inicial.

Com os microsserviços, o aplicativo inteiro não precisa ser reimplantado, apenas os serviços que precisam dele. Em vez de uma entidade estrutural singular, como uma casa de bonecas, pense em microsserviços como uma pilha de peças de Lego. Tecnicamente, eles são todos independentes, mas quando colocados juntos, eles formam uma aplicação estrutural inteira. Se você deseja adicionar um compartimento ou encerrar algo, ele pode ser facilmente removido, adicionado, ampliado e editado para atender às necessidades de mudança de forma rápida e eficiente, sem ter que desligar todo o aplicativo.

Desenvolvimento de microsserviços flexíveis para AWS
Desenvolvimento de microsserviços flexíveis para AWS
Aprenda como sua empresa pode aumentar a agilidade e atender às demandas criando aplicativos baseados em microsserviços para a AWS.

Benefícios de uma arquitetura de microsserviços

Há uma série de benefícios significativos para as empresas que desejam adotar microsserviços e integrá-los em suas ofertas, que serão explorados em mais detalhes abaixo.

Tempo de colocação no mercado mais rápido

Ser capaz de adicionar e remover funções rapidamente significa que o negócio pode se tornar incrivelmente ágil. A adição de novas funcionalidades pode ser feita rapidamente, acompanhando o crescimento dos negócios. Ao contrário do software monolítico tradicional, as alterações no código em uma parte do sistema não afetarão outros módulos, portanto, não há necessidade de testes extras, desligamento de todo o aplicativo ou reimplantação de tudo.

Maior funcionalidade e menores custos operacionais

Como os módulos nos microsserviços são todos separados, há um risco muito menor de possíveis bugs ou erros que causem a falha de todo o aplicativo. Ao contrário dos sistemas de software tradicionais, em que uma alteração em uma parte da funcionalidade pode causar uma falha ou bug em outra parte, o isolamento e o acoplamento flexíveis permitem a implementação de atualizações e aprimoramentos compartimentados. Os microsserviços também permitem o uso de opções de implantação de função como serviço nativas da nuvem, o que pode reduzir significativamente os custos operacionais.

Aplicativos facilmente escaláveis

As decisões de dimensionamento para microsserviços são feitas em um nível granular, permitindo as decisões mais eficientes para a otimização do sistema. Ao adotar microsserviços, quando chegar a hora de expandir, as organizações podem fazer as escolhas que são melhores para elas no momento.

Integração contínua

Os microsserviços são desenvolvidos usando fluxos individuais de desenvolvimento e implantação contínuos. Esses fluxos podem ser sustentados para que não haja interrupção em outro serviço quando uma equipe implementa uma mudança com base no feedback do cliente, o que significa maior satisfação do usuário final.

Equipes de desenvolvedores dedicadas

Ao contrário dos sistemas monolíticos, que não podem sustentar várias equipes de desenvolvimento, os microsserviços têm a capacidade de dar suporte a equipes dedicadas a determinadas partes específicas do sistema. Como os módulos de software não interagem entre si, não há risco de bugs ou sobreposição de trabalho entre equipes, portanto, as equipes de microsserviços podem ter desenvolvedores de software especializados, bem como equipes trabalhando em diferentes prazos ou localizações geográficas.

Todos esses benefícios se somam talvez àquele mais significativo: a agilidade nos negócios. Pequenas e simples mudanças podem ser feitas rapidamente, permitindo a experimentação de processos. A capacidade de dar um grande salto nos negócios, ou pelo menos falhar rapidamente e reagir em tempo real, torna-se possível com os microsserviços. Além disso, estudos descobriram que, meses após a implantação da arquitetura de microsserviços, um terço das organizações começa a obter vantagens. Isso significa que os prazos de desenvolvimento são reduzidos e, com menos erros no código e com recursos aprimorados, o impacto positivo nas operações de negócios pode ser sentido quase imediatamente.

Características dos microsserviços

  • Acoplamento fraco
  • Componentes implementáveis de forma independente
  • Implantação automatizada
  • Controle descentralizado de dados e linguagem
  • Altamente sustentável
  • Facilmente testável
  • Organizado em torno das necessidades e capacidades de uma empresa ou organização
  • Cada serviço tende a ser de propriedade de uma pequena equipe

Desafios com microsserviços

Embora os microsserviços resolvam vários problemas, ainda existem algumas dificuldades e problemas que podem ser encontrados com a arquitetura, bem como com a adoção inicial.

Gerenciamento de dados descentralizado

Ao contrário dos sistemas monolíticos, os microsserviços geralmente não contam com um banco de dados que atua como uma única fonte de verdade de seus dados para a empresa. Os dados do cliente podem estar em um lugar, enquanto os dados do fornecedor estão em outro. Talvez as informações de estoque sejam armazenadas no portal de vendas online, mas o sistema de pedidos é mantido em um banco de dados separado. Isso pode criar problemas com a qualidade e a consistência dos dados, a menos que você faça um planejamento específico para isso.

Cultura corporativa e desafios da organização interna

Pode ser difícil fazer com que as empresas aceitem e se adaptem a novos sistemas de software. Muitas vezes, a administração pode ter relutância em abrir mão do controle, ou um departamento tentará defender seus silos. Seja qual for o motivo da resistência das equipes que precisam aceitar novos sistemas, o resultado final é que, às vezes, as pessoas simplesmente não gostam de mudanças.

Para que os microsserviços sejam adotados em toda a organização, é fundamental reconhecer que a introdução de novos sistemas e processos pode ser disruptiva, mas também é importante lembrar que os benefícios valem a pena. Ao iniciar a transição para microsserviços, é melhor envolver as equipes afetadas ao planejar a arquitetura. Tenha um plano para avaliar as soluções disponíveis e garantir que a melhor opção seja escolhida para os requisitos do negócio.

Microsserviços podem trazer complexidade para a arquitetura

Embora os serviços individuais que compõem os microsserviços possam ser pequenos e simples, quando combinados, o aplicativo geral pode acabar tendo muitas partes que podem se tornar difíceis de gerenciar. Com centenas ou milhares de interconexões, os microsserviços podem aumentar rapidamente em complexidade.

Recomenda-se que, ao implementar microsserviços, uma quantidade significativa de premeditação e planejamento entre no design e na implementação básica. Muitas complexidades podem ser evitadas com um bom projeto de arquitetura básica que permita crescimento e mudanças no futuro.

Exemplos de casos de uso da arquitetura de microsserviços

Adote opções de implantação nativas da nuvem: aproveite o serverless e a função como serviço para operações mais eficientes e escaláveis.

Migre a funcionalidade de aplicativos legados: decomponha serviços de grandes aplicativos monolíticos para que possam ser mantidos e dimensionados de forma independente.

Aproveite a arquitetura moderna de aplicativos: adote padrões de aplicativos de microsserviços orientados a eventos e fracamente acoplados, com a capacidade de alavancar diferentes linguagens de programação, dependendo das necessidades do caso de uso. Por exemplo, vá para funções computacionalmente pesadas, Node.js para aplicativos da Web rápidos etc.

O que é DevOps e por que ele costuma estar associado a microservices?

O DevOps pode ser explicado como uma ideologia centrada em ferramentas. Essencialmente, é um conjunto de práticas que combina ferramentas e tecnologia para simplificar o trabalho que precisa ser feito pelos desenvolvedores. Juntamente com ferramentas aprimoradas, a cooperação entre as equipes de operações e de desenvolvimento ajuda a levar os projetos à conclusão de forma mais rápida e eficiente.

Por exemplo, digamos que você esteja criando um aplicativo que permite que os usuários verifiquem os saldos de suas contas. Muitas vezes, no passado, o ciclo de desenvolvimento de aplicativos fazia com que os desenvolvedores criassem o aplicativo e o entregassem à equipe de operações sem responsabilidade pelo resultado final. Era o trabalho da equipe de operações fazer o aplicativo funcionar. Em um ambiente de DevOps mais coeso, os dois lados trabalham juntos. Um desenvolvedor possui o ciclo de vida do aplicativo do início ao fim, o que significa estar de plantão durante o lançamento. A comunicação consistente entre os dois grupos é necessária para garantir que tudo seja bem-sucedido e obter todos os benefícios do DevOps, como velocidade de lançamento no mercado, ciclo de desenvolvimento mais fácil e mais responsabilidade.

O novo modelo de fluxo de trabalho DevOps cria uma grande mudança cultural. Apenas usar novas ferramentas não torna um plano de DevOps bem-sucedido. No mínimo, novas ferramentas podem inibir o sucesso se fizerem com que você acredite indubitavelmente que tudo será implementado de maneira adequada.

Devido à natureza dos microsserviços, geralmente é necessário ter processos de DevOps fortes para a implantação. O aumento do uso de ferramentas e práticas compartilhadas mais fortes evita que as equipes sejam sobrecarregadas por todas as pequenas partes. Você reduz a interrupção ou o fardo dessa mudança enquanto continua a receber os benefícios.

Teste de software de microsserviços
Experimente o TIBCO Cloud Integration - Teste Grátis
Deixe o TIBCO Cloud Integration capacitar seus negócios com uma integração mais fácil e rápida baseada em API. É integração - simplificada.

O futuro: microservices orientados a eventos, computação sem servidor e FaaS

Quando as pessoas começam a experimentar microsserviços, geralmente usam técnicas familiares, como APIs RESTful. O REST opera em um tipo de comunicação de solicitação-resposta. O problema com essa abordagem síncrona é que, como você precisa aguardar uma resposta, os serviços se tornam dependentes uns dos outros. Isso significa que, se um serviço estiver mais lento ou não responder, o serviço que o chamou ficará mais lento ou falhará. Esse acoplamento pode significar a perda de alguns dos benefícios de uma arquitetura de microsserviços, criando uma estrutura mais interdependente semelhante a um estilo de arquitetura orientada a serviços (SOA).

Se você projetar seus serviços usando um modelo além do REST ou um modelo orientado a eventos, poderá garantir que partes de seu aplicativo continuem funcionando, enquanto outras partes podem não estar envolvidas, em vez de todo o aplicativo não responder. A Netflix funciona como um exemplo perfeito disso. Ocasionalmente, você pode notar que o botão “continuar assistindo” não aparece. Isso ocorre porque esse serviço específico não está disponível. No entanto, isso não significa que todo o serviço da Netflix parou. Os usuários ainda podem procurar programas e assistir a trailers, ou seja, outros aspectos do serviço Netflix continuam funcionais e disponíveis para uso, mesmo que um serviço não esteja.

Os desenvolvedores que adotam totalmente uma abordagem de microsserviços percebem que a verdadeira escalabilidade é habilitada com acoplamento flexível e arquitetura orientada a eventos . Um serviço pode ser assíncrono, executando uma ação, transmitindo uma mensagem e continuando com sua função principal sem ter que esperar por uma resposta de outro serviço.

Como funcionam os microsserviços?

Microsserviços não são uma ideia nova. Mais de três décadas atrás, o Unix desenvolveu um SOA que usava um princípio de design semelhante, mas era caro para implementar e falhava com muita frequência para ser considerado uma boa opção para as empresas. Vinte anos depois, os microsserviços chegaram com uma consistência muito melhor entre os serviços e a adoção desde então tem sido muito mais bem-sucedida.

Quanto à forma como os microsserviços realmente funcionam, primeiro, a funcionalidade do software é dividida em módulos pequenos e isolados. Esses módulos têm tarefas definidas e independentes. Em seguida, o sistema funciona vinculando esses pequenos pedaços de software usando interfaces de programação de aplicativos (APIs).

APIs são segmentos de código que fazem com que dois programas não relacionados 'falem' um com o outro. Um exemplo de API em ação seria um aplicativo ou site que tenha o Google Maps incorporado. Uma API fica entre o Google Maps e o aplicativo enviando informações entre eles e permitindo que os usuários vejam seus mapas em tempo real, recebam instruções para o motorista e também alertem um contato confiável sobre sua localização. Embora o Google Maps permaneça uma entidade separada, a API permite a comunicação entre o mapa e o aplicativo. Então, em vez de uma casa de bonecas pré-fabricada, onde tudo é planejado, rígido e difícil de mudar, você tem aquelas pequenas peças úteis de Lego que se encaixam usando APIs como conectores. Plataformas de tecnologia padronizadas podem ser restritivas, mas nem todo problema é um prego, nem toda solução um martelo. Os microsserviços proporcionam a ferramenta certa para o trabalho.

Existem certos benefícios para os microsserviços, e as empresas que os adotaram com sucesso como um modelo de arquitetura colheram os benefícios de estruturas de TI de negócios mais rápidas e ágeis. No entanto, algumas organizações descobriram que o sistema pode matar a produtividade e ser um fardo para operar. A diferença entre o sucesso e o fracasso está em duas partes: a cultura da organização e sua disposição de aceitar e usar os microsserviços, e o planejamento e a premeditação destinados ao mapa dos microsserviços.

Muitas vezes, os verdadeiros benefícios ou custos de um novo sistema não são percebidos por muitos anos. A arquitetura monolítica às vezes já foi superada ou começou a decair nesses anos. Há menos oportunidades para esse declínio nos microsserviços, e corrigir um problema é uma questão muito mais simples.

Uma solução para uma variedade desses problemas potenciais é começar com um monólito. Isso proporciona um software de base ao qual anexar outros elementos à medida que você cresce, criando uma espécie de casa de bonecas com extensões de Lego. Embora essa possa não ser a abordagem mais elegante, é uma maneira de uma empresa prosseguir, especialmente com um banco de dados ou programa existente no centro das operações.