Proponho falar sobre quando são necessários microsserviços e quando não. Spoiler: depende do projeto.

Nós, desenvolvedores de software, temos uma profissão bastante interessante. Podemos codificar com segurança por dias e, em seguida, ler um artigo sobre algo - e isso questiona todo o nosso trabalho, porque alguns Netflix disseram à XYZ.

Assim, devido à opinião de uma pessoa ou empresa, você começa a duvidar de tudo o que faz há muitos anos, mesmo que tudo funcione perfeitamente.

Você não é o Google (a menos que seja o Google)

Quando lemos o HackerNews e outros sites de notícias, geralmente vemos mensagens técnicas do Google, Netflix, Amazon e Facebook, e eles gostam de falar sobre quantas centenas ou milhares de serviços lançam. Eles falam sobre os benefícios de fazer as coisas do seu jeito. Esta é uma tendência dos últimos anos.

Mas vamos enfrentá-lo. É improvável que você tenha 1000 desenvolvedores que estão trabalhando em um projeto massivo com mais de 10 anos de história.

Só porque o Google faz isso, não significa que você deva fazê-lo também.

Trabalhamos em uma galáxia completamente diferente. O Google enfrenta problemas que provavelmente nunca encontraremos, mas, ao mesmo tempo, podemos fazer coisas que o Google não pode.

Como a maioria dos projetos de software é iniciada?

Muitos projetos começam com uma pessoa que faz todo o trabalho. Existem milhões de exemplos, mas vamos dar uma olhada no Shopify. Inicialmente, o serviço codificava Tobias Lyutke (era baseado no Ruby on Rails e ainda, aliás, trabalha nos trilhos).

Você acha que Tobias estava hesitante, pensando meticulosamente na arquitetura ideal para microsserviços, antes de escrever a primeira linha de código?

Inferno não. Eu não estava presente ao desenvolver a primeira versão do Shopify, que originalmente era apenas uma loja on-line para snowboard, mas se Tobias se parece comigo (um desenvolvedor típico), o processo se parece com o seguinte:

1. Aprenda novas tecnologias enquanto escreve o produto original.
2. Escreva um código não padronizado (desagradável), mas totalmente funcional.
3. Veja como tudo funciona junto e fique animado.
4. Refatore como "queimando com fogo" e melhore o código quando ocorrer um problema.
5. Repita esse ciclo ao adicionar novos recursos e iniciar em um ambiente de produção.

Pode parecer um ciclo muito simples, mas levei cerca de 20 anos de programação para descobrir o quão profundo é.

Você não se torna melhor como programador, pensando teoricamente nas configurações ideais antes de escrever a primeira linha de código. Você se torna melhor escrevendo muito código com a intenção absoluta e explícita de substituir quase tudo o que escreve por um código melhor, assim que começa a ter problemas reais.

O código original que você substituiu não desperdiça tempo ou esforço. Com o tempo, isso ajuda muito a melhorar seu nível. Este é um ingrediente secreto.

Fale sobre abstrações de código

Como desenvolvedores, todos já ouvimos a frase "SECO: não se repita" e, no geral, é um conselho razoável não fazer o trabalho novamente. Mas muitas vezes vale a pena fazer.

Vale a pena repetir quando você tenta abstrair algo sem entendimento completo e cria o que é chamado de abstração com vazamento.

Eu costumo fazer o trabalho três vezes antes de pensar em refatorar algum código e remover duplicatas. Muitas vezes, somente após a quarta ou quinta vez eu tomo algumas medidas.

Você realmente precisa ver várias vezes como duplicar o código em diferentes situações antes de ficar claro o que exatamente converter em variáveis ​​e remover de locais onde esse código foi originalmente escrito.

Níveis de abstração, do código incorporado às bibliotecas externas:

1. Escreva código embutido.
2. Duplique o código em vários lugares diferentes.
3. Extrair código duplicado na função, etc.
4. Use essas abstrações por um tempo.
5. Veja como esse código interage com outro código.
6. Extraia a funcionalidade geral na biblioteca interna.
7. Por um longo tempo, use a biblioteca interna.
8. Realmente entenda como todas as peças se juntam.
9. Crie uma biblioteca externa (código aberto, etc.), se isso fizer sentido.

O ponto é que você não pode "inventar" uma boa biblioteca ou estrutura. Quase todas as ferramentas de muito sucesso que usamos hoje vêm de projetos do mundo real. Lá, nossa ferramenta favorita é extraída de casos reais de uso interno.

Rails é um ótimo exemplo. DHH (autor do Rails) não acordou um dia e disse: “Oh! Está na hora de criar os modelos /, controladores / e visualizações /! Diretórios. ”

Não. Ele desenvolveu o Basecamp (o produto real), então alguns modelos apareceram, e esses modelos foram generalizados e extraídos do Basecamp no Rails. Esse processo ainda está em andamento hoje e, na minha opinião, esta é a única razão pela qual o Rails permanece tão bem-sucedido.

Esta é uma tempestade ideal de abstrações muito bem geridas (leia-se: não desenvolvidas teoricamente) combinadas com uma linguagem de programação que permite escrever um código atraente. Isso também explica por que quase todas as estruturas, como “Rails, apenas em XYZ”, não funcionam. Eles pulam os principais componentes da cadeia de abstração e pensam que podem simplesmente duplicar o Rails.

Das abstrações aos microsserviços

Para mim, os microsserviços são apenas outro nível de abstração. Isso não é necessariamente a etapa 10 da lista acima, porque nem todas as bibliotecas são projetadas para microsserviços, mas em um nível conceitual, parece que sim.

Os microsserviços não estão onde você inicia, assim como você não tentaria criar imediatamente a biblioteca externa de código aberto perfeita antes de escrever pelo menos uma linha de código. Neste momento, você nem sabe o que está desenvolvendo.

Uma arquitetura baseada em microsserviço é o que um projeto pode se transformar ao longo do tempo quando você se deparar com problemas reais.

Talvez você nunca encontre esses problemas, e muitos deles podem ser resolvidos de maneira diferente. Dê uma olhada no Basecamp e no Shopify. Ambos funcionam bem como aplicativos monolíticos.

Acho que ninguém as chamará de pequenas, embora não funcionem na escala do Google.

Shopify ganha US $ 17 milhões por mês em monólito

Em meados de 2018, o Shopify anunciou publicamente que mais de 600.000 lojas online operam em sua plataforma.

O Shopify é um aplicativo SaaS que tem a taxa mais barata de US $ 29 por mês, e tenho a sensação de que muitas empresas escolhem a taxa de US $ 79 por mês. De qualquer forma, mesmo que 600.000 clientes usassem o plano mais barato por US $ 29, isso representa uma receita de US $ 17,4 milhões por mês apenas na linha SaaS de seus negócios.

O aplicativo Basecamp é outro ótimo aplicativo monolítico. O interessante do Basecamp é que eles têm apenas cerca de 50 funcionários e apenas alguns deles são desenvolvedores de software que trabalham no produto principal.

Quero dizer que você pode ir MUITO longe sem descer pela toca do coelho dos microsserviços. Não crie microsserviços assim.

Quando os microsserviços devem ser usados?

Tudo depende da sua decisão. Essa é apenas uma daquelas coisas em que você não buscará no Google "microsserviços contra monólito". Se você realmente precisa de microsserviços, já o saberá.

Mas pode haver uma situação em que você tenha vários desenvolvedores mais adequados para trabalhar em partes individuais do aplicativo. A presença de dezenas de equipes trabalhando em vários componentes do produto isoladamente é um dos motivos razoáveis ​​para usá-lo em microsserviços.

Lembre-se de que, se você tiver uma equipe pequena que cresce lentamente ao longo do tempo, pode começar com um ou dois microsserviços. Em tal situação, você provavelmente não deve dividir o monólito de uma só vez em 100 microsserviços, a partir de uma pedreira.

O jogo vale a pena?

Também vale ressaltar que a transição para microsserviços é acompanhada por seu próprio conjunto de problemas. Como você muda um problema por outro, é necessário avaliar os prós e os contras de se o jogo vale a pena especificamente para o seu projeto.

Um dos principais problemas é o monitoramento. De repente, você obtém vários serviços que podem ser escritos em diferentes pilhas de tecnologia, executados em várias máquinas - e você precisa de uma maneira de rastreá-los em detalhes.

Essa é uma tarefa difícil, porque, idealmente, gostaríamos que todos os microsserviços usassem um único serviço de monitoramento.

Você provavelmente não deseja desenvolver suas próprias ferramentas, porque isso por si só pode se transformar em um trabalho completo. Esta é a razão do sucesso de empresas como a LightStep . Este é um dos serviços de monitoramento mais interessantes que já encontrei.

O produto deles é mais focado em aplicativos de larga escala (é compreensível o porquê), mas também funciona para pequenos projetos. Recentemente, ouvi falar deles porque foram apresentados no dia 4 do Cloud Field .

De qualquer forma, o monitoramento é apenas uma das muitas dificuldades, mas decidi mencioná-lo porque é um dos problemas mais dolorosos.

Considerações finais

Basicamente, escrevi este artigo por dois motivos:

Primeiramente , há duas semanas, visitei o Cloud Field Day 4 e participei acidentalmente de um podcast em grupo sobre um tópico relacionado. Ele deve ser lançado em alguns meses, mas aqui eu queria me concentrar em alguns pontos.

Em segundo lugar , como autor de cursos on-line, recebo muitas perguntas sobre como criar meus próprios aplicativos.

Muitos desenvolvedores "congelam", tentando dividir seus aplicativos em serviços isolados, mesmo antes de escreverem a primeira linha de código. Chega ao ponto que, desde o início, eles tentam usar vários bancos de dados para componentes de aplicativos.

Esse momento os impede de avançar e, como colega de desenvolvimento, sei como é difícil ficar preso na indecisão (eu tinha!).

A propósito, atualmente estou trabalhando em um aplicativo SaaS bastante grande - uma plataforma para hospedar cursos personalizados. No momento, estou trabalhando sozinho em um projeto, e você pode ter certeza de que acabei de abrir o editor e comecei a escrever código no primeiro dia.

Vou salvar o projeto como um aplicativo completamente monolítico, até que faça sentido implementar microsserviços, mas meu instinto me diz que esse momento nunca chegará.

O que você acha disso? Deixe-me saber nos comentários.