Compartilhe esta publicação
Práticas recomendadas para microsserviços
O ambiente de negócios atual é extremamente competitivo. Nenhuma empresa, independente do porte ou do setor a que pertence, está livre de interrupções. Nunca foi tão fácil para novos participantes entrarem no mercado, e os setores estão passando por transformações extremas.
A menos que as organizações possam inovar com a mesma agilidade que a concorrência, elas ficarão para trás. E as grandes organizações com seus processos e suas estruturas cristalizadas serão as mais atingidas.
Qualquer organização pode aproveitar as oportunidades que a transformação digital oferece; a única exigência é ter uma maior agilidade.
Atualmente, a capacidade da sua empresa de mudar rapidamente, inovar com facilidade e enfrentar a concorrência no momento certo é uma necessidade estratégica. Assim, você vai prosperar em um mercado em constante mudança e criará novas experiências para os clientes em novos contextos, usando novas tecnologias.
As organizações que estabeleceram uma base para inovação ágil e contínua adotaram arquiteturas de microsserviço a fim de responder rapidamente às demandas contínuas dos negócios.
Por que microsserviços?
Microsserviços são a evolução dos princípios de práticas recomendadas de arquitetura que moldam a entrega de soluções para os negócios na forma de serviços. Independente do setor em que atuem, todas as empresas devem se esforçar para proporcionar uma experiência ideal aos clientes, que estão cada vez mais exigentes e desistem de organizações que demoram muito para responder.
A TI deve oferecer soluções que possam ser adaptadas para oferecer uma experiência holística e uniforme em todos os canais de negócios.
Para conseguir isso, a arquitetura deve identificar e definir ativos digitais alinhados aos principais recursos de negócios. Eles dão a possibilidade de quebrar a conexão entre canais de negócios e os sistemas de registro de back-end que atendem a eles.
Um microsserviço que integre um recurso central de negócios e siga os princípios e metas de design descritos abaixo deve ser considerado um verdadeiro ativo digital. Ele pode agregar valor aos negócios porque pode ser adaptado para uso em vários contextos.
Os contextos de uso do serviço são os processos e transações de negócios e os canais pelos quais seu cliente, funcionário ou parceiro interage com eles.
Benefícios para os negócios
A arquitetura de microsserviço é alinhada aos negócios de tal forma que é possível lidar com qualquer tipo de mudança com agilidade. Processos e transações comerciais são automatizados com a composição dos microsserviços. Quando ocorrem alterações ou introdução de processos, a TI consegue responder redirecionando os serviços para as novas composições.
A facilidade e a velocidade com que sua empresa pode mudar determinará sua capacidade de reagir às tendências do seu setor e manter a vantagem competitiva. Com a lógica da solução na forma de serviços compostos, a TI pode acompanhar o ritmo dos negócios e dar uma resposta ágil às mudanças ao entregar a lógica da solução.
A inovação é o rosto dessa agilidade. Ela pode assumir a forma de novos canais de negócios, novos compromissos digitais com os clientes, produtos e serviços totalmente novos que podem exigir processos inovadores ou a simples modificação dos processos de negócios existentes.
Tudo isso aponta para a necessidade de mudanças. Deve ser possível para as empresas mudar de direção com base nas forças atuantes no mercado. A TI deve ser capaz de facilitar as mudanças, compondo os ativos digitais existentes em novos recursos de negócios.
Sua empresa pode oferecer lógica de solução de maneira descentralizada com a padronização de contratos de microsserviço na forma de APIs. Várias equipes de diferentes domínios podem implementar serviços com a tecnologia que preferirem, e, ainda assim, permanecerem alinhadas à finalidade dos negócios.
Isto representa a evolução do papel da TI, que deixa de ser provedora e passa a ser parceira, resultando na capacitação das equipes de linhas de negócios para se adaptarem às funcionalidades centrais criadas pela equipe principal para suas próprias necessidades particulares.
Microsserviços são capazes de se comunicar uns com os outros de forma nativa devido à adoção de padrões como HTTP e JSON em todo o setor. Em outras palavras, eles são intrinsecamente interoperáveis.
Eles facilitam a troca de informações independentemente de sua forma de implementação, pois sua a interface é definida de acordo com os padrões que já existem no nível do setor, também determinados pelas equipes da sua organização.
Sua empresa pode escolher os melhores produtos e plataformas de fornecedores graças à interoperabilidade que as interfaces padronizadas oferecem.
O que são microsserviços?
Tradicionalmente, as empresas entregavam aplicativos de software em silos, devido a demandas isoladas de departamentos individuais. O software era desenvolvido ou adquirido atendendo a esses escopos limitados. Por outro lado, os processos de negócios voltados para o cliente costumam abranger vários departamentos.
A falta de alinhamento entre essas duas realidades gerou esforços duplicados e soluções com informações insuficientes ou imprecisas. Essa última questão foi uma força importante por trás da integração empresarial.
O conceito de serviço evoluiu de tentativas de respeitar o processo de negócios como ponto focal dos requisitos da solução. A necessidade de modificar processos existentes ou inventar outros totalmente novos deve ser atendida com uma resposta ágil da TI a fim de se adaptar às mudanças.
Em vez de criar ou comprar “aplicativos” no sentido tradicional, uma abordagem de serviço estipula a criação de serviços como blocos modulares da lógica da solução, os quais são passíveis de composição com o objetivo de atender aos requisitos de automação dos processos de negócios.
Modos de consumo
Os microsserviços costumam ser invocados diretamente por chamadas de API HTTP REST. Padrões como RAML (Restful API Modeling Language) permitem a definição formal de APIs REST. O RAML pode definir todos os recursos e operações expostos pelo microsserviço.
É um padrão do setor que ganhou popularidade, por ser uma abordagem leve para a definição e publicação de interfaces de microsserviços.
Nos casos em que os microsserviços colaboram para a realização de uma transação ou processo comercial complexo, uma abordagem orientada por eventos também é adotada.
A composição dos microsserviços é realizada com uma mistura de chamadas diretas por meio de HTTP e indiretas por meio de um agente de mensagens.
API-led connectivity
Classificação de microsserviços
Com a convicção de que criar um recurso de negócios adaptável é muito melhor do que criar uma integração tática ponto a ponto, a TI deve se esforçar para disponibilizar ativos acessíveis por meio da invocação de API e assinatura de eventos de domínio, que possam agregar valor aos negócios em vários contextos.
Primariamente, o ativo é um encapsulamento de um recurso de entidade de negócios, como Cliente, Pedido ou Fatura. Essas APIs do sistema, ou microsserviços no nível do sistema, estão alinhadas ao conceito de um serviço autônomo projetado com abstração suficiente para ocultar os sistemas de registro subjacentes. Nenhum desses detalhes do sistema vazam pela API. A responsabilidade da API é específica e independente dos processos de negócios.
As APIs de sistema podem ser agrupadas com outras para formar APIs de processo agregadas. A composição das APIs de sistema pode assumir a forma de orquestração explícita da API (chamadas diretas) ou ocorrer pela coreografia mais confiável de API, na qual é conduzida por eventos de negócios relevantes ao contexto da composição (atendimento de pedidos, por exemplo).
O API gateway
As APIs de processo e de sistema devem ser personalizadas e expostas para atender às necessidades de cada canal de negócios e ponto de contato digital. A adaptação é moldada pela experiência digital desejada e é o que chamada de API de experiência.
Em todos esses casos, o padrão do API Gateway é uma boa abordagem, pois é onde as composições e os proxies da API são implementados. O API management facilita a aplicação administrativa de lógica recorrente, como segurança, limitação de taxa, auditoria e filtragem de dados, para as APIs de experiência no gateway.
O uso do API management para aplicar políticas que encapsulem a lógica personalizada torna a adaptação das APIs de sistema e processo relativamente rápida e fácil.
O “micro” em microsserviços
Escopo de responsabilidade
O candidato a microsserviço mais óbvio é uma entidade de negócios facilmente identificável em um processo de negócio ou transação — “Cliente”, por exemplo. É uma entidade que pode ser relevante em vários contextos, tanto na camada de processo quanto na de experiência. A responsabilidade não se limita à mera transmissão de dados. Um microsserviço não deve ser reduzido a um simples serviço CRUD.
“Específico” é a interpretação mais comum de “micro” com relação ao escopo de responsabilidade. Isso ajuda a garantir que o microsserviço no nível do sistema não assuma nenhuma responsabilidade que pertença ao microsserviço no nível do processo de negócios.
Os microsserviços no nível do sistema são independentes de qualquer processo de negócios específico e, portanto, podem ser usados em mais de uma composição.
O escopo de um processo de negócios também deve ser considerado. Alguns subdomínios têm seus próprios processos de negócios locais. Um microsserviço no nível do sistema pode ser adaptado para uso em vários processos dentro do domínio de remessa. Sempre que sua capacidade for necessária fora do domínio, ele poderá ser adaptado com um microsserviço no nível de experiência.
Organização e responsabilidades da equipe
A propriedade do microsserviço inclui tudo, desde o design até a implementação e o gerenciamento. A API é considerada um produto comercial, um ativo a ser entregue ao negócio. Não há transferência para outras equipes para gerenciamento da instância em execução. Todo o ciclo de vida pertence à equipe que o desenvolve.
Identificação de candidatos a microsserviços
É possível obter ajuda na identificação dos microsserviços que você precisa criar e o escopo de suas responsabilidades, considerando os tipos de informações trocados nas transações a que eles atendem.
Em um ambiente de saúde, os exemplos são paciente, encontro e solicitação de reembolso. Em um cenário de comércio eletrônico há: pedido, item, desconto ou cliente. Em uma solução bancária, é possível ver transferência, conta, beneficiário. A responsabilidade deve ser enxuta e focada.
Escopo do esforço
Microsserviços que atendem a necessidades de um subdomínio específico reconhecerão que certos conceitos de negócios são vistos de uma maneira particular ao subdomínio.
Nenhuma tentativa é feita para modelar uma solução universal, a menos que a entidade seja compartilhada naturalmente por toda a organização.
Facilidade de implementação
O custo da entrega à produção diminui bastante graças à combinação de equipes pequenas com propriedade completa, à responsabilidade específica do microsserviço e à infraestrutura que facilita a entrega contínua.
Princípios fundamentais do design de microsserviço
Os recursos de microsserviço são expressos formalmente com APIs orientadas por negócios. Elas encapsulam um recurso corporativo essencial e, por isso, são ativos para a empresa.
A implementação do serviço, que pode envolver integrações com sistemas de registro, fica completamente oculta, pois a interface é definida puramente em termos de negócios.
Por serem considerados ativos valiosos para os negócios os promovem, promove-se os serviços como implicitamente adaptáveis para uso em múltiplos contextos. O mesmo serviço pode disponibilizar recursos a mais de um processo corporativo ou a canais de negócios ou pontos de contato digitais diferentes.
Reutilização
A reutilização continua sendo um princípio do design de microsserviços. No entanto, o escopo da reutilização foi reduzido para domínios específicos dentro dos negócios.
Com a abordagem de “reutilização baseada no mérito”, prefere-se um modelo emergente a um predeterminado. As equipes podem concordar sobre modelos de comunicação para decidir como os microsserviços devem ser adaptados para uso fora dos contextos em que foram projetados.
Se uma API de microsserviço existente não se adequar ao seu domínio ou “grupo de negócios”, é melhor criar outro microsserviço.
Autonomia é uma medida de controle usada pela implementação do serviço sobre o ambiente de runtime e o esquema do banco de dados. Isso melhora o desempenho e a confiabilidade do serviço, oferecendo aos consumidores mais garantias sobre a qualidade do serviço. Com a ausência de estado, a autonomia também contribui para a disponibilidade e escalabilidade gerais do serviço.
Cada serviço é obrigatoriamente tolerante a falhas; assim, quando elas ocorrerem nos serviços colaboradores, afetarão o mínimo possível seu próprio SLA. Por serem independentes uns dos outros, os serviços podem interromper a comunicação com um serviço com falha.
Essa técnica, chamada de “circuit breaker” (disjuntor) por ser inspirada no componente elétrico de mesmo nome, impede a propagação de falhas de serviço individuais pelo sistema distribuído.
Todos esses princípios de design contribuem para o princípio de capacidade de composição, que permite ao serviço agregar valor ao negócio em contextos variados.
Orientação de domínio de negócios da arquitetura de microsserviço
É importante abordar o design de serviço de um domínio específico e não insistir em fazê-lo para todos os aspectos do negócio. O fracasso dos exercícios de modelagem canônica para toda a empresa realizados na última década comprova isso.
A realidade é que as entidades de negócios podem ser percebidas de maneiras profundamente diferentes nas unidades ou subdomínios de negócios.
À medida que os microsserviços se comunicam, especialmente aqueles projetados para domínios diferentes, talvez seja necessário negociar um contrato que atenda às necessidades do software consumidor.
Essa adaptação específica se manifestará como uma API de experiência personalizada, especificamente para esse cliente.
Microsserviços e o monolito
Os microsserviços são uma mudança fundamental em como a TI aborda o desenvolvimento de software. Os processos tradicionais de desenvolvimento de software (cascata, ágil etc.) geralmente resultam em equipes relativamente grandes que trabalham em um único artefato de implementação monolítico.
Existem, no entanto, alguns problemas à espreita nas abordagens tradicionais:
Aplicações monolíticas podem levar a uma situação em que nenhum desenvolvedor entende o aplicativo em sua totalidade. Esse problema é agravado quando os desenvolvedores seniores implementam um projeto e são substituídos por recursos juniores ou externos para a manutenção.
A reutilização limitada é realizada em aplicativos monolíticos. Aplicativos monolíticos, por definição, ocultam seus componentes internos. Embora as APIs possam obter alguma capacidade de reutilização na “extremidade” do monolito, as chances de reutilização de componentes internos são limitadas.
O dimensionamento de aplicativos monolíticos pode ser complicado. Geralmente, é impossível identificar e ajustar isoladamente aspectos específicos da funcionalidade do aplicativo para obter desempenho, já que todas as funcionalidades são agrupadas em um único artefato de implementação.
A agilidade operacional raramente é alcançada na implementação repetida de artefatos de aplicativos monolíticos. Embora a automação operacional possa aliviar a maioria dos problemas manuais da implantação desses aplicativos, ainda há um ponto no qual os desenvolvedores são bloqueados pela equipe de operações que espera a conclusão dessas atividades.
Por definição, os aplicativos monolíticos são implementados usando uma única pilha de desenvolvimento (por exemplo, JEE ou .NET). Além de limitar a reutilização de aplicativos não implementados na pilha, isso também tira a oportunidade de usar a ferramenta certa para o trabalho.
Como evitar o monolito distribuído
Uma estratégia de microsserviços deve adotar uma abordagem cuidadosa para obter o máximo de benefícios; é recomendado que você projete e crie microsserviços que reúnam recursos para domínios de negócios específicos. Caso contrário, você criará um pacote monolítico de microsserviços.
Em outras palavras: um monolito distribuído com todas as desvantagens do monolito, mais a complexidade da distribuição e uma redução no retorno geral do seu investimento. Também é indicado que você estabeleça uma rigorosa disciplina de entrega contínua e tenha as ferramentas necessárias para a automação do pipeline de liberação.
A falta de coordenação e automação da equipe de DevOps pode levar sua iniciativa de microsserviços a trazer mais desvantagens do que benefícios.
Por outro lado, essa flexibilidade adiciona maior complexidade. O gerenciamento de uma infinidade de serviços distribuídos em escala é difícil:
› As equipes de projeto precisam descobrir facilmente os serviços como possíveis candidatos à reutilização. Esses serviços devem fornecer documentação, consoles de teste etc. para que a reutilização seja consideravelmente mais fácil do que a criação do zero.
› As interdependências entre serviços precisam ser monitoradas com atenção. Downtime, interrupções e atualizações de serviços podem ter um efeito cascata, e esse impacto deve ser analisado proativamente.
Padrões de implementação de microsserviço
Segregação de responsabilidade de consulta de comando
A classificação dos microsserviços em tipos de sistema, processo e experiência pode ser subdividida de acordo com os requisitos de escalabilidade. A maioria das solicitações para microsserviços serve para recuperar informações para fins de apresentação.
Um número menor de solicitações serve para executar uma função comercial de mudança de estado, como alterações em perfis pessoais ou envio de pedidos por parte de clientes.
Estes tipos de solicitações são distinguidas como consultas para a recuperação de informações e comandos para a função comercial de mudança de estado.
Origem do evento
O princípio de autonomia do design de microsserviço estipula que cada um tenha seu próprio datastore. O compartilhamento de banco de dados é evitado. Isso cria um problema quando se considera essa abordagem para a automação de uma transação comercial.
Recomenda-se microsserviços do tipo processo de negócios, cuja responsabilidade é compor microsserviços do tipo sistema por meio da orquestração e da coreografia.
Naturalmente, a troca de informações para qualquer transação comercial está relacionada, mas cada microsserviço de sistema executa sua parte na colaboração, independentemente do restante. O estado final da composição inteira deve deixar todos os dados em um estado consistente.
Para resolver esse problema, o setor está deixando de lado as transações distribuídas. Portanto, pode-se ver que o fato de cada microsserviço ter seu próprio datastore com informações que, em última análise, são as mesmas, pode resultar em inconsistências a qualquer momento.
Entrega contínua de aplicativos compostos
Fazer as equipes lançarem continuamente software é algo que se alinha aos princípios de desenvolvimento ágil. A entrega contínua de software permite que as partes interessadas da empresa verifiquem, em tempo real, se um aplicativo está atingindo o objetivo final do negócio.
Em termos de aplicativos compostos de microsserviço, entrega contínua também significa integração contínua. Em aplicativos compostos por muitos serviços, é fundamental garantir que a composição realmente funcione após a criação do software.
Ter ciclos de lançamento curtos, feedback rápido sobre falhas de compilação e recursos de implementação automatizada são fundamentais na implementação da entrega contínua.
Consumo de autoatendimento de microsserviços
Todo departamento de uma empresa precisa de tecnologia para criar novos aplicativos para funções ou clientes específicos. A TI precisa sair de sua função tradicional de única fornecedora de tecnologia para se tornar uma organização adaptável e ágil, capaz de acompanhar o ritmo da era digital e de aproveitar as oportunidades oferecidas por um ambiente de mudanças.
Essa transformação pode ocorrer apenas se a TI se transformar em uma facilitadora estratégica de negócios, em vez de ter uma função tecnológica centralizada.
Para atuar como facilitadora, a TI precisa descentralizar e democratizar o desenvolvimento de aplicativos e o acesso aos dados para as diferentes linhas de negócios (LoBs) e parceiros de negócios funcionais. Dessa forma, a TI pode se concentrar em uma parceria com a empresa — ou seja, fornecer um conjunto de ativos e tecnologia estratégico e consistente.
No entanto, essa abordagem acaba por gerar uma proliferação de serviços. O gerenciamento desses serviços em escala gera vários desafios:
› Descoberta e documentação de serviço
› Tolerância a falhas
› Qualidade do serviço
› Segurança
› Rastreabilidade de solicitações
› Triagem de falhas
É imperativo que você possa gerenciar facilmente seus microsserviços de forma a facilitar o acesso de autoatendimento a eles em todas as linhas de negócios da sua empresa.
O API Management representa a evolução da governança de serviço que permite a você fazer o seguinte:
› Publique suas APIs para que os desenvolvedores de software de consumo tenham tudo o que precisam para o autoatendimento das próprias necessidades e para entender claramente a finalidade, o escopo e a interface de seu microsserviço
› Adapte suas APIs por meio de políticas injetáveis de lógica que cubram segurança, qualidade do serviço, auditoria, dados dinâmicos, filtragem etc.
› Supervisionar suas APIs para que você possa criar estratégias de escalabilidade de acordo com os níveis de tráfego e medir o impacto de seus ativos.
› Personalize suas APIs de acordo com as necessidades específicas de linhas de negócios diferentes, para que o API management se torne um exercício descentralizado ou federado em colaboração entre os LoBs e a TI central.
Ciclo de vida do microsserviço de ponta a ponta
Ciclo de vida de um microsserviço
Diferente dos apps tradicionais, o desenvolvimento ideal de microsserviços começa com uma abordagem de cima para baixo, começando pela API. Ou seja, há etapas adicionais em comparação com os ciclos de vida de desenvolvimento de software (SDLC) tradicionais.
Por exemplo, o aspecto do design costuma ser um processo iterativo que inclui:
› Modelagem da sua API usando especificações padrão, como RAML.
› Convém simular suas especificações com um ponto de extremidade de API simulado, com o qual você pode solicitar feedback dos consumidores da API.
› Também é indicado validar com código real, para poder ter uma melhor percepção da API e fornecer feedback.
› Após a ratificação do design da API, crie-a usando sua linguagem favorita, com um código que inclua lógica de negócios e conectividade com os sistemas de back-end apropriados.
› Em seguida, crie scripts de teste “if” seguindo a abordagem recomendada do design orientado por testes.
› Depois que o microsserviço é implementado, normalmente convém publicar a documentação para sua API usando um portal que será seu nível de envolvimento com os usuários do microsserviço.
› Finalmente, após a operacionalização, você quer gerenciar o runtime do microsserviço e suas APIs (por exemplo, aplicar políticas de segurança e estrangulamento) e obter análises de uso do seu microsserviço. O Analytics pode ser usado para fins de gerenciamento/monitoramento ou para medição e chargeback.
Lembre-se: Instituir microsserviços para criar vantagem competitiva e ajudar sua empresa a inovar mais rapidamente vai além da simples seleção de produtos e software.
*texto adaptado do whitepaper Práticas recomendadas para microsserviços
Este artigo foi escrito por Matthew Cameron e publicado originalmente em Prensa.li.