Como a mudança para microservices cria um problema de tempo de execução?

Eu tenho um problema. Vamos usar microsserviços! Agora eu tenho 13 problemas distribuídos.

Dividir seu sistema em componentes encapsulados, coesos e desacoplados é uma boa ideia. Ele permite que você resolva problemas diferentes separadamente. Mas você pode fazer isso perfeitamente em uma implantação monolítica (consulte Fowler: Microservice Premium ). Afinal, é isso que a OOP vem ensinando há muitas décadas! Se você decidir transformar seus componentes em microsserviços, não obterá nenhuma vantagem arquitetônica. Você ganha alguma flexibilidade em relação à escolha de tecnologia e possivelmente (mas não necessariamente!) Alguma escalabilidade. Mas você tem alguma dor de cabeça garantida (a) pela natureza distribuída do sistema e (b) pela comunicação entre os componentes. Escolher microsserviços significa que você tem outros problemas que são tão prementes que você está disposto a usar microsserviços apesar desses problemas.

Se você não for capaz de projetar um monolito que seja dividido em componentes, você também não poderá projetar um sistema de microsserviço. Em uma base de código monolítica, a dor será bastante óbvia. Idealmente, o código simplesmente não será compilado se estiver terrivelmente quebrado. Mas com microservices, cada serviço pode ser desenvolvido separadamente, possivelmente em diferentes idiomas. Quaisquer problemas na interação dos componentes não se tornarão aparentes até que você integre seus componentes e, nesse momento, já é tarde demais para corrigir a arquitetura geral.

A fonte No 1 de bugs é a incompatibilidade de interface. Pode haver erros flagrantes, como um parâmetro ausente, ou exemplos mais sutis, como esquecer de verificar um código de erro ou esquecer de verificar uma condição prévia antes de chamar um método. A tipagem estática detecta tais problemas o mais cedo possível: no seu IDE e no compilador, antes o código já é executado. Sistemas dinâmicos não têm esse luxo. Não vai explodir até que o código defeituoso seja executado.

As implicações para os microservices são assustadoras. Os microsserviços são inerentemente dinâmicos. A menos que você mude para uma linguagem formal de descrição de serviço, não é possível verificar qualquer tipo de correção no uso da interface. você tem que testar, testar, testar! Mas os testes são caros e geralmente não exaustivos, o que deixa a possibilidade de que ainda existam problemas na produção. Quando esse problema se tornará aparente? Somente quando esse caminho defeituoso é executado, em tempo de execução, em produção. A noção de que os problemas de produção levariam a um feedback mais rápido está perigosamente errada, a menos que você se divirta com a possibilidade de perda de dados.

O primeiro tweet foi meu, então vou expandi-lo:

Suponha que você tenha 100 desenvolvedores, trabalhando em um aplicativo monolítico. Muitas pessoas se comunicam efetivamente entre si, então a empresa precisa trabalhar duro para dividi-las em equipes menores e criar bons padrões de comunicação entre elas. Quando a organização é "disfuncional", as equipes provavelmente não estão conversando entre si, não estão alinhadas com um objetivo maior, não concordam com as prioridades, etc. - como resultado, elas demoram uma eternidade para enviar algo. É um "problema de tempo de compilação" no sentido de que a disfunção é óbvia antes que o software seja produzido. O projeto é provavelmente uma marcha da morte ou nunca será enviado ("compile").

Eu acho que muitas pessoas são atraídas por serviços de micro, e estão se movendo para eles, não por causa de benefícios técnicos / arquitetônicos inerentes, mas porque lhes permite ignorar a disfunção organizacional. Em vez de tentar alinhar 100 desenvolvedores, eles esperam que eles possam ter equipes minúsculas trabalhando em silos, cada uma concentrada em seu próprio pequeno micro serviço. Se você está em uma organização tão disfuncional, isso é tão atraente: dá-lhe uma permissão muito maior para evitar pessoas que você não gosta, para não se comunicar.

Infelizmente, isso se torna um "problema de tempo de execução" porque, quando o software é executado na produção, a boa comunicação torna-se tão importante quanto. Os problemas com a organização - as equipes e como eles estão alinhados e se comunicam - se manifestam em "tempo de execução".

O ponto do meu tweet foi: se o que você tem é um problema pessoas , uma nova arquitetura não vai ajudar. Isso apenas atrasará os efeitos do problema. Acho que a atratividade de micro serviços para muitas pessoas é a esperança de que isso resolva magicamente esses problemas.

My question is: What does it mean that shifting to microservices creates a run-time problem?

Isso não é o que esses tweets estão dizendo! Eles não dizem nada sobre mudar para microservices , nem dizem nada sobre criar problemas. Eles só dizem algo sobre problemas de mudança .

E eles colocam uma restrição contextual em suas asserções, ou seja, que sua organização é disfuncional.

Então, o que o primeiro tweet basicamente diz é duas coisas:

• "se a sua organização não for capaz de projetar sistemas complexos agora sem microsserviços, não será capaz de projetar magicamente sistemas complexos com microsserviços" e
• "os problemas causados por essa incapacidade que agora aparecem durante o tempo de compilação, ou seja, durante o desenvolvimento, aparecerão durante o tempo de execução, ou seja, na produção" (tecnicamente, eles também podem aparecer durante o teste, mas lembre-se, citação restringe-se a organizações disfuncionais, que provavelmente têm um regime de testes abaixo do padrão)

O tweet segundo diz que o fato de que os problemas só se manifestam na produção, ou seja, onde os clientes os veem, é uma característica, não um bug, porque quando os clientes reclamam, isso tende a ser ouvido em lugares diferentes do que quando uma construção quebra, ou seja, em locais que são capazes de fazer algo sobre a disfunção organizacional (por exemplo, gestão de alto nível). Como a disfunção organizacional geralmente é uma falha do gerenciamento de alto nível, isso significa que os clientes insatisfeitos refletem mal aqueles que são responsáveis por essa insatisfação, enquanto a baixa qualidade do código causada por falhas de gerenciamento geralmente reflete mal os desenvolvedores, que são , no entanto, não a culpa e incapaz de fazer algo sobre isso.

Assim, o primeiro tweet diz que os microsserviços movem problemas causados pelo mau gerenciamento do tempo de compilação, onde apenas os desenvolvedores os vêem, para o tempo de execução, onde os clientes os veem. O segundo tweet diz que é uma coisa boa, porque, então, os problemas prejudicam aqueles que são responsáveis por eles.

Cria um problema em tempo de execução, em oposição a um problema compile -time.

Um aplicativo monolítico é difícil e caro de compilar. Mas uma vez compilado, você pode estar razoavelmente seguro de que não existem incompatibilidades extremamente estúpidas entre os componentes, porque o sistema de tipos pode capturá-los. O mesmo erro em um sistema de microservives pode não aparecer até dois componentes específicos na verdade interagem de uma maneira específica.

Tanto em sistemas monolíticos quanto em microservices, você precisa definir interfaces entre os subsistemas. As interfaces devem ser bem projetadas, bem documentadas e tão estáveis quanto possível. Isso é o mesmo que em OOP.

Se a sua organização não conseguir fazer isso, os microsserviços também não resolverão o problema. Em microservices, você tem interfaces da Web públicas. Então você precisa gastar mais esforço no design da interface.

Se a interface não for projetada corretamente, você terá dois tipos de problemas de tempo de execução:

1. Se a interface não for usada corretamente, você receberá um erro no tempo de execução, não no tempo de compilação.
2. Chamar uma interface da Web é muito lento, para que você possa ter problemas de desempenho.

Acho que produzir problemas de tempo de execução não é o caminho certo para problemas organizacionais de comunicação para os responsáveis.