Entrando no Mundo de Microsserviços: Parte 1

O assunto sobre microsserviços vem ganhando rapidamente um grande espaço em mídias sociais, blogs, discussões, conferências e meio corporativo. Nesta série de posts,vamos entender como essa arquitetura funciona, seu design, construção, deploy e também construir uma pequena aplicação de e-commerce para exemplificar e demonstrar o funcionamento básico de uma arquitetura baseada em micros serviços.

Nossa série sobre microsserviços está divida em 4partes:

Parte 1 - Conceitos

Parte 2 - Design Patterns e melhores práticas

Parte 3 - Projeto ecommerce

Parte 4 - Deploy

Parte 5 - Monitoramento

Hoje vamos tratar sobre os conceitos em micros serviços. Mas antes de entrarmos no assunto de micros serviços, temos que entender primeiro os motivos pelos quais elevaram seu crescimento bem como os fatores que motivaram a comunidade a criação deste estilo de arquitetura.

Sistemas Monolíticos

Bom, não precisamos nem voltar muito no passado, mas se olharmos para algumas soluções existentes hoje no mercado, conseguimos notar grandes aplicações que são chamadas de "monolíticas":

"Monolithic, in information technology, means eithervery large (and possibly imposing) or composed all in one piece, depending onthe particular context; the term is used in different ways to describe integrated circuits, organizations, applications and storage systems, amongother things."

Basicamente são aplicações onde todos os seus componentes e funcionalidades estão combinados dentro de uma única aplicação e arquitetura.

Aplicações monolíticas começaram pequenas e com o passar do tempo, naturalmente foram crescendo e recebendo novas features, alterações para atendimento às legislações, novos módulos, sem contar o time de devs aumentando e ficando cada vez mais difícil de manter, dar manutenção e evoluir essa aplicação bem como escalar para que atenda satisfatoriamente a todos os usuários.

Isso é natural, mas em determinado momento, dependendo de como a aplicação monolítica foi sendo evoluída, podemos nos deparar com algumas dificuldades como por exemplo:

• Escalar     verticalmente para atender vários usuários ao mesmo tempo de forma     elástica;
• Aplicação     é muito grande e complexa para o correto entendimento;
• Adição     de mudanças rápidas e corretas são mais difíceis;
• Disponibilidade,     em casos de falhas, toda a aplicação poderá ficar indisponível;
• Velocidade de startup time;
• Versionamento     e atualização da solução precisa ser realizada como um todo;
• Adoção     e experimentação de novas tecnologias.

Claro que existem também pontos positivos, principalmente em aplicações pequenas, legada se que possuem pouca demanda:

• Simples de desenvolver;
• Fácil de testar;
• Deploy da aplicação descomplicado;
• Monitoramento simplificado.

Não podemos esquecer também que, várias empresas de sucesso como Netflix, Spotfy, Twitter,Amazon ou Linkedin iniciaram seus negócios com soluções baseadas em monolitos,essa abordagem é chamada de "Monolith first", onde a idéia principal é que, segundo Martin Fowler, você deve começar um sistema deforma monolítica para que, a medida em que a aplicação for crescendo, poderáser dividida em micro serviços, desta forma, temos uma melhor percepção da necessidade de decomposição da aplicação.

Arquitetura de Microsserviços

A arquitetura de microsserviços entra como uma forma de resolver esses grandes problemas, consiste basicamente na separação de uma estrutura monolítica emmicro partes ou microsserviços que funcionam de forma independente se comunicando entre si.

Mas antes mesmo da entrada de micros serviços, aplicações monolíticas foram sendo"quebradas" em partes para uma arquitetura distribuída, essas que eram importantes para o negócio e se tinha a necessidade que funcionassem de uma maneira sustentável e escalável a medida do necessário. Essa abordagem começou na época da entrada do SOA (Service Oriented Architecture), ondepodemos dizer que essa fragmentação era feita em mini serviços.

Um dos grandes percursores também foi o cloud computing, em que foi possível aplicar toda essa estrutura de uma forma mais simplificada, rápida e sem a necessidade de custo inicial com infra on premise. Assim, empresas foram experimentando e tendo a percepção dos benefícios que esse conjunto entregava,percebemos nessa mesma época também um grande crescimento de serviços sob demanda como Netflix, Spotfy, AWS.

A medida emque novas demandas computacionais foram surgindo, principalmente a necessidade de arquiteturas que fossem elásticas, e que permitissem aos usuários gerenciarde forma principalmente econômica e sob-demanda seus recursos existentes,micros serviços se mostrava como algo muito promissor, combinado com a adoção decloud e de um rico ferramental, começou a ficar mais fácil distribuir aplicações em pequenas estruturas e executá-las em paralelo.

Martin Fowler, define micros serviços sendo, "The microservice architectural pattern is an approach to developing a single application as a suite of small services, each running inits own process and communicating with lightweight mechanisms, often an HTTPresource API" - Martin Fowler.

Nessa figura, podemos notar que o sistema monolíto foi fragmentado em partes, sendo que cada microsserviço possui suacamada de negócio independente. Para o usuário final isso é imperceptível,sendo que a arquitetura trabalha como um ecossistema entregando ao negócio uma solução única.

Muitos profissionais principalmente os que estão iniciando na área, se deparam com algumas dúvidas, como por exemplo:

Devo utilizar micros serviços?

Depende muito do problema que você quer resolver, também se sua empresa está preparada para implementar essa arquitetura que embora seja ágil, depende de uma equipe com um bom conhecimento teórico e prático. Além de vários benefícios que essa arquitetura entrega, também existem alguns trade-offs, estes que também devem ser avaliados cuidadosamente. O fato é que não existe certo ou errado,muito menos uma receita de bolo para adoção de microsserviços.

Micros serviços seria um SOA melhorado?

Não, apesar de ambas serem uma arquitetura orientada a serviços, existem muitas diferenças.

SOA possui um foco em ESBs que são usados para integrar aplicações monolíticas, onde estas aplicações são expostas através de Web Services que geralmente utilizam XML sobo protocolo http para comunicação. Já Microsserviços possui um estilo totalmente diferente, onde poderão ser combinadas diferentes linguagens deprogramação, frameworks de desenvolvimento e tecnologias de data-storage.

Quais as vantagens e desvantagens dessa arquitetura?

Vantagens de Micros serviços

• Permite     a entrega contínua e implantação de aplicativos grandes e complexos -     Equipes multifuncionais trabalham para lidar com todo o ciclo de vida de     uma aplicação e um modelo de entrega contínua.
• Melhora     da manutenibilidade - Cada serviço é relativamente pequeno e assim se     torna fácil de entendê-lo e alterá-lo;
• Melhor     testabilidade - serviços são menores a mais rápidos de testar;
• Deploy     - Serviços podem ser implantados independentes sem prejudicar o     funcionamento de toda a aplicação;
• Diversidade     de tecnologia - Cada micros serviço poderá ser desenvolvido com diferentes     stacks;
• Aumento     da Resiliência - Em caso de falhas de um microsserviço, partes da     aplicação ainda continuarão funcionando;
• Escalabilidade     - Aspecto chave dos micros serviços, permitindo a expansão de uma única     função ou serviço sem ter que redimensionar toda a aplicação. Serviços que     são mais críticos para o negócio podem ser implantados em vários     servidores, aumentando a disponibilidade e desempenho sem impactar em     outros serviços;

Desvantagens de Microsserviços

• Desenvolvedores     precisaram lidar com uma complexidade adicional para criação e     distribuição dos sistemas;
• Comunicação     entre serviços - Desenvolvedores precisam escolher e implementar um     mecanismo de comunicação inter-serviços;
• Testes     de integração entre serviços assim como os testes end-to-end são     mais difíceis e importantes como jamais foram;
• Complexidade     no deploy - Principalmente em ambientes produtivos podem ser mais     complexos e delicados, uma implantação rápida e segura exige um custo     maior;
• Particionamento     dos databases - Você precisa atualizar múltiplos databases que são     mantidos por diferentes serviços, desafio grande onde precisa-se pensar em     escalabilidade, resiliência e disponibilidade.
• Monitoramento     robusto - Como você está orquestrando vários serviços, um monitoramento     robusto é obrigatório para saber quando um serviços falhar ou até mesmo     uma máquina cair;
• Aumento     do consumo de infra - A medida em que novos serviços vão sendo implantados     ou escalados, estes que são executados em sua própria VM (ou equivalente,     o qual é necessário para isolamento das instâncias), necessitam de mais     recursos de memória, processador e HD;

E sobre o custo?

O custo para desenvolver uma solução baseada em microsserviços é mais alto comparado a um monolito, você tem mais complexidades, vai precisar de um time mais preparado tecnicamente, um conhecimento e uma infraestrutura mais avançada. Entretanto, o custo para manutenção é mais barato, em alguns cenários é até mesmo a única forma de se dar uma boa manutenção.

Qual o tamanho de um microsserviço?

Não existe um limite de quão grande ou pequeno deve ser um microsserviço, a palavra 'micro' é alvo de constantes definições do que a constitui. Mas uma abordagem interessante sobre o tamanho de cada microsserviço é a regra da Amazon sobre o"two time pizza", onde todo o time consegue ser alimentado por duas pizzas. O fato é que, a decomposição deve ser pensada levando em consideração o que uma arquitetura de microsserviços propõe, por exemplo:

• Cada     serviço tem uma única responsabilidade;
• Cada     serviço é pequeno o suficiente para ser criado por uma pequena equipe     trabalhando de forma independente;
• Não     devem estar acoplados de forma forte e podem evoluir independente;
• Se a     comunicação entre duas funcionalidades de serviços diferentes gerar     excesso de mensagens, isso poderá ser um sintoma de que essas funções     pertencem ao mesmo serviço;
• Os     limites entre cada serviço não podem criar problemas de consistência e     integridade dos dados.

Quais as principais ferramentas e frameworks usados em microsserviços?

Existe atualmente um ferramental bem rico que nos ajudam a lidar com essa arquitetura(alguns inclusive open source), tornando-a cada vez mais fácil e intuitiva, cada uma com uma proposta diferente para um determinado contexto,por exemplo:

Banco de Dados: Não somente em microsserviços, mas em qualquer projeto deve ser aplicado e avaliado o Teorema de CAP, criado para tratar sobre os comportamentos de bancos de dado sem sistemas distribuídos. Um dos mais populares para uso com microsserviços é o MongoDB, noSQL apresenta uma boa performance além de uma boa capacidade de escalonamento horizontal.

API Gateway:LinkApi, NgInx, Kong, Tyk.io.

Logs e Monitoramento: Elastic, Logstash, Kibana.

Containers: Dockere Kubernates.

Deploy: RapidDeploy, Code Deploy, Elastic Box.

Mensageria: RabbitMQ,Kafka.

Segurança: OAuth2,SAML, 2Factor, SonarQube, Veracode.

Gerenciamentode Configuração: Ansible, Chef, Puppet.

Posso usar microsserviços on premise?

Sim, apesar do cloud ter sido um dos grandes precursores para a evolução dos microsserviços sem contar a facilidade de uso, é possível sim fazer o uso de microsserviços on premise.‍

Claro que dessa forma você terá uma complexidade maior de gerenciamento, por exemplo gerenciar a escalabilidade, onde em cloud já existem recursos prontos para identificar um número X de requisições e escalam os serviços proporcionalmente a demanda.

Em breve lançaremos a sequência dessa série sobre microsserviços. Enquanto isso,aproveite para aprender mais sobre APIs e integrações em nosso blog, confira esse artigo dicas para melhorar a experiência de consumo de APIs.

‍