Uma Cartilha Rápida sobre Microsserviços

Este texto é de Omed Habib, e está disponível em:
https://blog.appdynamics.com/devops/a-quick-primer-on-microservices/


Microsserviços são um tipo de arquitetura de software onde grandes aplicações são feitas de unidades pequenas trabalhando juntos por meio de APIs que não são dependentes em uma linguagem específica. Cada serviço tem um escopo limitado, se concentra em uma tarefa específica e é altamente independente. Esse arranjo permite que os gerentes de TI e desenvolvedores construam sistemas de forma modular. No seu livro “Construindo Microsserviços“, Sam Newman disse que microsserviços são componentes pequenos e focados, construídos para fazer uma coisa muito bem.

O “Microsserviços – Uma Definição Desse Novo Termo Arquitetural“, do Martin Fowler, é uma das publicações pioneiras sobre microsserviços. Ele descreve algumas características chave de microsserviços:

  • Componentização: os microsserviços são unidades independentes que são facilmente trocadas ou atualizadas. As unidades usam serviços para se comunicar com coisas como procedimentos remotos ou requisições de webservices.
  • Capacidades de negócio: o desenvolvimento de aplicações legadas normalmente divide os times em áreas como “equipe de server-side” e “equipe de banco de dados.” O desenvolvimento de microsserviços é construído em torno das capacidades de negócio, com responsabilidade por toda a pilha de funções, como experiência do usuário e gerenciamento de projeto.
  • Produtos em vez de projetos: em vez de focar em um projeto de software que é entregue após pronto, os microsserviços tratam as aplicações como produtos dos quais são donos. Estabelecem um diálogo com o objetivo de continuamente encaixar o aplicativo na função do negócio.
  • Vias ignorantes, endpoints inteligentes: as aplicações de microsserviços contém a própria lógica. Os recursos são comumente e facilmente cacheados.
  • Governança descentralizada: As ferramentas são construídas e compartilhadas para lidar com problemas similares em outras equipes.

História dos Microsserviços

O termo “micro-webservices” foi usado pela primeira vez em uma conferência de computação por Dr. Peter Rodgers, em 2005, enquanto o termo “microsserviços” apareceu em uma conferência de arquitetos de software na primavera de 2011. Mais recentemente, ganhou popularidade porque consegue lidar com várias mudanças da computação moderna, como:

  • Dispositivos móveis
  • Aplicações web
  • Conterinerização de sistemas operacionais
  • RAM barata
  • Utilização de servidor
  • Servidores multi-core
  • Ethernet de 10 Gb

O conceito de microsserviços não é novo. Google, Facebook e Amazon aplicam essa abordagem em algum nível por mais de 10 anos. Uma simples busca no Google, por exemplo, chama mais de 70 microsserviços antes que você veja a página de resultados.

Além disso, outras arquiteturas foram desenvolvidas para lidar com os mesmos problemas que os microsserviços. Uma é chamada de Arquitetura Orientada a Serviço (SOA), que entrega serviços de componentes em uma rede, com cada serviço trocando dados com outro serviço no sistema. Uma desvantagem é a falta de comunicação assíncrona.

As diferenças entre microsserviços e SOA

A Arquitetura Orientada a Serviço (SOA) é um desenho de software onde os componentes entregam serviços por um protocolo de rede. Essa abordagem fez sucesso entre 2005 e 2007, mas desde então perdeu momento para os microsserviços. Quando os microsserviços surgiram alguns anos atrás, alguns engenheiros chamaram de “SOA refinado.” Outros ainda dizem que os microsserviços fazem o que SOA conseguiria fazer.

SOA tem uma forma de pensar diferente dos microsserviços. SOA favorece o WSDL (Web Services Definition Language), que define rigidamente os endpoints e é fortemente tipado, enquanto os microsserviços possuem conexões ignorantes e endpoints inteligentes. SOA é geralmente sem estado (stateless); microsserviços possuem estado (stateful)*e usam estruturas de programação orientada a objetos que mantêm os dados e a lógica juntos.

Algumas dificuldades com SOA são:

  • SOA é pesado, complexo e possui múltiplos processos que podem reduzir a velocidade.
  • Enquanto SOA originalmente ajudava a prevenir dependência do fornecedor, acabou não se movendo com a tendência à democratização da TI.
  • Assim como o CORBA foi desfavorecido quando as inovações da Internet ofereceram opções melhores para implementar aplicações para a web, SOA perdeu popularidade quando os microsserviços ofereceram formas melhores de incorporar webservices.

Problemas que os microsserviços resolvem

Grandes organizações encontram problemas quando as arquiteturas monolíticas não podem ser escaladas, atualizadas ou mantidas facilmente quando elas crescem. A arquitetura de microsserviços é uma resposta a esse problema. É um estilo de arquitetura de software onde tarefas complexas são quebradas em pequenos processos que operam independentemente e se comunicam por APIs independentes de linguagem.

As aplicações monolíticas são feitas de uma interface de usuário no cliente, uma aplicação no servidor e um banco de dados. A aplicação processa requisições HTTP, pega a informação do banco de dados, e envia de volta para o navegador. Os microsserviços lidam com requisições e respostas HTTP com APIs e mensagens. Eles respondem com JSON/XML ou HTML enviado para os componetnes de apresentação. Os defensores de microsserviços se rebelam contra padrões forçados de grupos de arquitetura de grandes empresas, mas se engajam entusiasmadamente com formatos abertos, como HTTP, ATOM e outros.

Quando a aplicação cresce, dependências e conexões intrincadas crescem. Falando de arquitetura monolítica ou de unidades menores, os microsserviços permitem dividir as coisas em componentes. Isso permite escalar horizontalmente, o que torna mais fácil gerenciar e manter componentes separados.

A relação de microsserviços e DevOps

Incorporar nova tecnologia é só parte do desafio. Talvez um grande obstáculo é desenvolver uma nova cultura que encoraja tomar riscos e tomar responsabilidade por um projeto inteiro “do berço à cova.” Os desenvolvedores acostumados a sistemas legados podem sentir um choque de cultura quando recebem mais autonomia que de costume. Comunicar claramente as expectativas pela prestação de contas e performance de cada membro da equipe é vital.

DevOps é crítico em determinar onde e quando os microsserviços devem ser usados. É uma decisão importante, porque tentar combinar microsserviços com pesados sistemas legados monolíticos nem sempre vai funcionar. Mudanças não podem ser feitas rápido o suficiente. Com microsserviços, os serviços são constantemente desenvolvidos e refinados em pleno vôo. DevOps deve garantir que componentes atualizados são colocados em produção, trabalhando lado-a-lado com stakeholders internos e fornecedores para incorporar as atualizações.

O movimento em direção a aplicações mais simples

Como Doug Sherman, da DreamWorks, disse em um painel na Conferência Appsphere 15, a produtora de filmes tentou a abordagem SOA vários anos antes, mas descobriu que é contraprodutivo. A visão de Sherman é que a TI está movendo em direção a aplicações mais simples. Algumas vezes, SOA pareceu mais complicado que deveria; os microsserviços foram vistos como uma solução mais fácil que SOA, assim como JSON foi visto como mais simples que XML, e como REST é visto como mais simples que SOAP. Estamos indo em direção a sistemas que são mais simples de construir, implantar e entender. Enquanto SOA foi originalmente desenhado com isso em mente, acabou sendo mais complexo que necessário.

Allan Naim, gerente de produto no Google, concorda. Ele explicou que SOA é bem voltado para sistemas corporativos porque você precisa de um registro de serviços, um repositório de serviços e outros componentes que são caros de comprar e manter. Os sistemas também são bem mais fechados entre si. Os microsserviços lidam com os problemas que SOA tentou resolver há mais de uma década, mas são muito mais abertos.

As diferenças dos microsserviços entre as plataformas

Os microsserviços são uma abordagem conceitual, e são manuseados de formas diferentes em cada linguagem. É um ponto forte da arquitetura, porque os desenvolvedores podem usar a linguagem que tiverem mais familiaridade. Linguagens mais antigas podem usar microsserviços usando uma estrutura única para sua plataforma. Aqui estão algumas características de microsserviços em cada plataforma:

Java:

  • Evita usar arquivos Web Archive (war) e Enterprise Archive (ear)
  • Componentes não são auto-implantáveis. Em vez disso, os contêiners Docker ou Imagens de Máquina da Amazon (IAM) são auto-implantáveis
  • Usa jars gordos que podem ser executados como um processo

PHP:

Microsserviços de PHP no estilo REST vem sendo implantados por vários anos porque são:

  • Altamente escaláveis no nível corporativo
  • Fáceis de testar rapidamente

Python:

  • É fácil criar um serviço Python que age como um serviço de front-end web para microsserviços em outras linguagens como ASP ou PHP
  • Há vários frameworks para escolher, incluindo Flask e Django
  • É importante para chegar a API correta para prototipagem rápida
  • Pode usar Pypy, Python, C++ ou Golang se for necessário mais velocidade ou eficiência

Node.js

Node.js é natural para microsserviços porque for criada para aplicações web modernas. Seus benefícios incluem:

  • Se aproveita do JavaScript de do motor V8 de alta performance e de código aberto do Google
  • O código de máquina é otimizado dinamicamente durante a execução
  • Os processos do servidor HTTP são leves
  • Entrada/saída orientadas a eventos sem bloqueio
  • Gerenciamento de pacotes de alta qualidade
  • Fácil para desenvolvedores criarem pacotes
  • Altamente escalável com entrada/saída assíncrona de ponta a ponta

.NET

No início dos anos 2000, .NET era uma das primeiras plataformas a criar aplicações como serviços usando Simple Object Access Protocol (SOAP), um objetivo parecido dos microsserviços modernos. Hoje, um dos pontos fortes do .NET é a presença profunda em instalações corporativas. Aqui estão dois exemplos do uso de microsserviços .NET:

Respondendo à Evolução do Mercado

A mudança para microsserviços é clara. A confluência de computação mobile, hardware barato, computação em nuvem e baixo custo de armazenamento está dirigindo a corrida para essa abordagem nova e emocionante. De fato, as empresas não têm escolha. O artigo de Matt Miller no The Wall Street Journal soou o alarme; “Inove ou Morra: A Ascenção dos Microsserviços” explica que o software se tornou o maior diferenciador entre os negócios em todas as indústrias. Os programas monolíticos comuns a várias empresas não podem mudar rápido o suficiente para se adaptar a novas realidades e demandas de um mercado competitivo.

A arquitetura orientada a serviços tentou endereçar alguns desses desafios, mas falhou na decolagem. Os microsserviços entraram em cena logo que as influências chegaram a determinado ponto; eles são ágeis, resilientes e eficientes, qualidades que muitos sistemas legados não possuem. Empresas como Netflix, Paypal, Airbnb e Goldman Sachs atenderam ao alarme e se adiantaram com microsserviços em um passo rápido.


*Acredito que foi um equívoco do autor, uma vez que microsserviços usam comumente REST stateless (sem estado), e por outro lado é comum ver SOAP stateful (com estado)

Anúncios
Marcado com: , , ,
Publicado em Microsserviços

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: