Microsserviços – Parte III

Este texto é de James Lewis e Martin Fowler, disponível em: http://martinfowler.com/articles/microservices.html.

Sugiro começar por aqui: Microsserviços – Parte I


Organizado em Torno de Capacidades de Negócio

Ao buscar a divisão de uma grande aplicação em partes, o gerenciamento se foca na camada de tecnologia, dividindo em equipes de interface com o usuário, equipes de lógica de negócio, e equipes de bancos de dados. Quando os times são separados seguindo essa linha, mesmo as mudanças mais simples podem se transformar em um projeto envolvendo vários equipes, que tomará tempo e que precisará de aprovação de orçamento. Um time esperto vai tentar otimizar e dar a volta, escolhendo a escolha menos pior – forçar a lógica na aplicação a que tiver acesso. Em outras palavras, a lógica se espalha por todo lugar. É um exemplo da Lei de Conway [5] em ação.

Qualquer empresa que projete um sistema (definido amplamente) vai produzir um desenho cuja estrutura é uma cópia da estrutura de comunicação da empresa.
— Melvyn Conway, 1967

A Lei de Conway em ação: equipes funcionais divididas em silos, levam a arquiteturas de aplicações divididas em silos.

A abordagem de microsserviços em relação à divisão é diferente, partindo a aplicação em serviços organizados de acordo com as capacidades de negócio. Tais serviços incluem uma grande implementação do software para a área de negócio, incluindo a interface do usuário, armazenamento persistente, e qualquer colaboração externa. Consequentemente, as equipes são multifuncionais, incluindo toda a gama de habilidades para o desenvolvimento: experiência do usuário, banco de dados e gerenciamento de projeto.

Uma empresa organizada dessa forma é http://www.comparethemarket.com. Equipes multifuncionais são responsáveis por construir e operar cada produto e cada produto é dividido em um número de serviços individuais se comunicando por mensagens.

Aplicações grandes e monolíticas podem ser modularizadas de acordo com as capacidades de negócio também, apesar de que não é comum. Certamente, teríamos uma equipe grande construindo uma aplicação monolítica se dividindo em torno das linhas de negócio. A questão principal que vemos é que tendem a ser organizados em muitos contextos. Se o monolito se espalha através de várias dessas fronteiras modulares, pode ser difícil para membros individuais de um time encaixá-lo na memória de curto prazo. Além disso, vemos que os limites dos módulos requerem uma grande disciplina para serem cumpridas. A separação mais explícita que os componentes de cada serviço exigem ajuda a manter as fronteiras da equipe mais claras.

Quão grande é um microsserviço?

Apesar de que “microsserviço” se tornou um nome popular para esse estilo arquitetural, o nome não leva para um foco no tamanho do serviço nem a argumentos sobre o que é “micro”. Nas conversas com praticantes de microsserviços, vemos uma faixa de tamanhos de serviços. Os maiores tamanhos seguem a noção da Amazon de um “equipe de duas pizzas” (ou seja, a equipe inteira pode ser alimentada com duas pizzas), significando até uma dúzia de pessoas. Na menor escala, vemos um time de meia dúzia cuidando de meia dúzia de serviços.

Parece que não há diferenças grandes o suficiente para desagrupar o serviço-por-dúzia e o serviço-por-pessoa. No momento, achamos que é melhor agrupá-los juntos em um só rótulo de microsserviços, mas é possível que mudemos de ideia quando explorarmos esse estilo profundamente.

Produtos, Não Projetos

A maioria dos esforços no desenvolvimento de softwares usam um modelo de projeto: onde o objetivo é entregar um pedaço de software que é então considerado completo. Na conclusão, o software é entregue para uma equipe de manutenção e a equipe do projeto que o construiu é desfeita.

Os proponentes de microsserviços tendem a evitar esse modelo, preferindo, em vez disso, a noção de que o time deve ser dono do produto por toda a vida do produto. Uma inspiração disso vem da Amazon: “você construiu, você roda”, onde o time de desenvolvimento tem toda a responsabilidade pelo software na produção. Isso trás os desenvolvedores para o contato diário com como o software se comporta em produção, e aumenta o contato com os usuários, já que devem receber pelo menos um pouco da carga de suporte.

A mentalidade de produto se amarra com as capacidades de negócio. Em vez de olhar para o software como um conjunto de funcionalidades a serem terminadas, há uma relação ocorrendo onde a questão é como o software auxilia os usuários a aprimorar as capacidades de negócio.

Não há razão porque a mesma abordagem não pode ser aplicada a aplicações monolíticas, mas a granularidade menor dos serviços pode tornar mais fácil criar relações pessoais entre os desenvolvedores e os usuários.


[5] O paper original pode ser encontrado no site de Melvyn Conway aqui.

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: