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


104

O seguinte comentarista escreve :

Os microsserviços mudam sua disfunção organizacional de um problema de tempo de compilação para um problema de tempo de execução.

Este comentarista expande a questão dizendo:

Recurso não bug. Problema no tempo de execução => questões de produtos => feedback mais forte e rápido sobre a disfunção para os responsáveis

Agora eu entendo isso com microsserviços :

  • potencialmente aumentar a latência do throughput - que é uma preocupação de produção e tempo de execução.
  • aumente o número de "interfaces de rede" no seu código, onde pode haver erros potenciais de tempo de execução da análise.
  • potencialmente pode fazer implantações azul esverdeado. Esses podem ser mantidos por incompatibilidades de interface (consulte interfaces de rede). Mas se as implantações azul esverdeado funcionarem, será mais uma preocupação em tempo de execução.

Minha pergunta é: O que significa mudar para microsserviços cria um problema de tempo de execução?


13
Se A fala com B em um monólito, pelo menos, a interface real pode ser comprovadamente compatível (por meio de digitação estática), o que torna mais provável que ela também esteja correta. Normalmente microservices comunicar através de algo sem esses controlos tempo de compilação
Richard Tingle

Se você estiver estudando os problemas que envolvem o uso de microsserviços, o artigo da Fowler é uma leitura obrigatória. martinfowler.com/articles/microservices.html Eu acredito que não é apenas um caso de tempo de compilação versus tempo de execução, como disse Richard Tingle. E realmente não concordo que ter um problema de produção é melhor que um em desenvolvimento. Mas os microsserviços podem ajudar a dimensionar grandes projetos de outras maneiras. (E são um exagero para a maioria dos pequenos projetos)
Borjab

2
Esse comentarista é míope. Problema no tempo de execução => problemas de prod = = usuários insatisfeitos => dinheiro perdido.
Philipp

@ Philipp: Esse é o ponto. Problemas em tempo de compilação causados ​​por disfunção organizacional => ninguém se importa. A perda de dinheiro causada pela disfunção organizacional => machuca exatamente os responsáveis ​​pela referida disfunção organizacional. A esperança: a disfunção organizacional é corrigida mais rapidamente.
Jörg W Mittag 05/09

Respostas:


194

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

Dividir seu sistema em componentes encapsulados, coesos e dissociados é uma boa idéia. Ele permite que você lide com diferentes problemas separadamente. Mas você pode fazer isso perfeitamente bem em uma implantação monolítica (consulte Fowler: Microservice Premium ). Afinal, é isso que a OOP ensina há muitas décadas! Se você decidir transformar seus componentes em microsserviços, não terá nenhuma vantagem arquitetural. Você ganha alguma flexibilidade em relação à escolha de tecnologia e, possivelmente (mas não necessariamente!), Alguma escalabilidade. Mas você tem uma certa dor de cabeça decorrente da (a) natureza distribuída do sistema e (b) da comunicação entre os componentes. Escolher microsserviços significa que você tem outros problemas tão urgentes que deseja usar os microsserviços, apesar desses problemas.

Se você não conseguir projetar um monólito que esteja claramente dividido em componentes, 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 microsserviços, cada serviço pode ser desenvolvido separadamente, possivelmente até em idiomas diferentes. Quaisquer problemas na interação dos componentes não serão evidentes até você integrar seus componentes e, nesse ponto, já é tarde demais para corrigir a arquitetura geral.

A fonte número 1 de erros é 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 pré-condição antes de chamar um método. A digitação estática detecta esses problemas o mais cedo possível: no seu IDE e no compilador, antes que o código seja executado. Os sistemas dinâmicos não têm esse luxo. Ele não explodirá até que esse código com defeito seja executado.

As implicações para os microsserviços são aterradoras. Os microsserviços são inerentemente dinâmicos. A menos que você mude para um idioma formal de descrição de serviço, não poderá verificar nenhum tipo de correção do 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 possam existir problemas na produção. Quando esse problema se tornará aparente? Somente quando esse caminho defeituoso é percorrido, em tempo de execução, na produção. A noção de que questões de produtos levariam a um feedback mais rápido éhilariamente perigosamente errado, a menos que você se divirta com a possibilidade de perda de dados.


13
@ JacquesB Estou confiante de que a “disfunção organizacional” se refere à incapacidade de desenvolver um sistema. A maior parte da minha resposta é um contexto para ilustrar como alguém pode chegar a essa conclusão, mas é a minha opinião profissional e não tirada do tweet.
amon

10
"monólito que está claramente dividido em componentes" - o que diabos isso significa?

10
E para não falar em versionamento de interfaces (as interfaces mudam com o tempo).
Peter Mortensen

12
@mobileink Monolith não é um termo ideal aqui, pois sugere “sem arquitetura”. Mas o que estou tentando transmitir é um sistema que é desenvolvido e implantado como um sistema único, em contraste com uma arquitetura orientada a serviços em que partes do sistema podem ser implantadas independentemente. Por favor, edite a publicação se você souber um termo melhor ...
am

7
@amon Ouvir a palavra Monolith não evoca imediatamente a idéia de "nenhuma arquitetura". A maioria dos edifícios são monólitos, assim como as grandes pirâmides do Egito e muitos outros itens. Claramente eles foram arquitetados e entregues como um todo. Muitos sistemas de software carecem de boa arquitetura; mas a falta de boa arquitetura parece ser independente de como elas são implantadas. Você pode pegar emprestado parte do andaime de outro projeto e chamá-lo de arquitetura (3 camadas, 2 camadas, n camadas, microsserviços, etc.), mas isso não garante que você tenha feito bem.
Edwin Buck

215

O primeiro tweet foi meu, então eu vou expandir:

Suponha que você tenha 100 desenvolvedores trabalhando em um aplicativo monolítico. São pessoas demais para se comunicar efetivamente entre si; portanto, 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, discordam de prioridades etc. - como resultado, leva uma eternidade para enviar algo. É um "problema de tempo de compilação" no sentido de que a disfunção é óbvia antes do software ser produzido. O projeto provavelmente é uma marcha da morte ou nunca será lançado ("compilar").

Eu acho que muitas pessoas são atraídas por microsserviços e estão se mudando para eles, não por causa dos 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 ter pequenas equipes trabalhando em silos, cada uma focada em seu próprio pequeno micro serviço. Se você está em uma organização tão disfuncional, isso é muito atraente: oferece uma permissão muito maior para evitar pessoas de quem você não gosta, para não se comunicar.

Infelizmente, isso se torna um "problema de tempo de execução" porque, uma vez que o software está em produção, uma boa comunicação se torna tão importante. Os problemas com a organização - as equipes e como eles estão alinhados e se comunicam - se manifestam no "tempo de execução".

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


67
+1. Isso é muito melhor como resposta do Stack Exchange do que como um tweet. :-)
ruakh 01/01

3
O mesmo vale para qualquer sistema dinâmico, na verdade. A digitação dinâmica é muito útil, mas somente se você tiver as pessoas certas. Os "bancos de dados de forma livre" são muito úteis, mas somente se você tiver as pessoas certas. Se você não tem as pessoas certas, está apenas delegando os problemas, não resolvendo-os.
Luaan

2
Eu acho que isso é uma tautologia. Quando as pessoas são o problema, os problemas podem se manifestar em todos os lugares. Não consigo imaginar enviar uma solução em execução como um conjunto de microsserviços sem os testes de integração adequados. Não há como enviar uma solução com um fluxo de trabalho suportado nesse caso. Se alguém se muda para microsserviços sem teste de fluxo, especialmente para ocultar problemas, eles são o problema. Também pode enviar binários não testados / quebrados. Isso eleva o problema dos programadores de nível superior, onde eles pertencem.
Luk32

10
@ luk32 Em parte, sim, mas a essência dos microsserviços que o tornam atraente para equipes ruins é que você faz com que seu déficit de habilidades e comunicação passe despercebido por um longo período de tempo. Não se trata de ter ou não problemas, é sobre quando eles aparecerão
T. Sar

18
Resposta muito boa. Obrigado por confirmar minha opinião do Twitter como totalmente inútil para qualquer coisa, exceto estimular as pessoas.
Robert Harvey

43

Minha pergunta é: O que significa mudar para microsserviços cria um problema de tempo de execução?

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

E eles colocam uma restrição contextual em suas afirmações, a saber, que sua organização é disfuncional.

Então, o que o primeiro tweet está basicamente dizendo é duas coisas:

  • "se sua organização não puder projetar sistemas complexos agora sem microsserviços, ela não poderá magicamente projetar 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, a cotação se restringe organizações disfuncionais, que provavelmente possuem um regime de teste abaixo do padrão)

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

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


6
@ Michael Se você não consegue ver como eles afetam a qualidade do código, talvez considere o impacto - se houver - do gerenciamento sobre qualquer parte da qualidade dos produtos que seus negócios criam.
Wjl

30
@ Michael: Tudo é causado por um gerenciamento de nível superior. A baixa qualidade do código é causada por prazos impossíveis? Quem define esses prazos? Quem diz a quem define esses prazos para definir esses prazos? A baixa qualidade do código é causada por desenvolvedores incompetentes? Quem contratou esses desenvolvedores incompetentes? Quem contratou aqueles que contrataram esses desenvolvedores incompetentes? É causado por ferramentas inadequadas? Quem compra essas ferramentas? Quem aprova o orçamento para comprar essas ferramentas? É causado por arquitetura estúpida? Quem contratou o arquiteto? Quem o colocou no comando? Os tweets foram especificamente no contexto ...
Jörg W Mittag

13
... disfunção organizacional. Bem, fazendo a função de organização é muito bonito O trabalho de gerenciamento de nível superior. Isso é o que é gerenciamento .
Jörg W Mittag 01/01

4
Embora provavelmente funcione a longo prazo, a idéia de resolver os problemas da sua empresa fazendo com que eles impactem os clientes não parece correta.
Stijn de Witt

1
@ JörgWMittag Não acho razoável afirmar que o código incorreto escrito por desenvolvedores ruins é culpa das pessoas que contrataram esses desenvolvedores ruins e não dos próprios desenvolvedores ruins. Em última análise, pode ser de responsabilidade do gerenciamento, mas é causado pelos desenvolvedores.
Route de milhas

9

Ele cria um problema de tempo de execução em oposição a um problema de tempo de compilação .

Um aplicativo monolítico é difícil e caro de compilar. Mas uma vez compilado, você pode ter certeza razoável de que não existem incompatibilidades extremamente estúpidas entre os componentes, porque o sistema de tipos pode detectá-los. O mesmo erro em um sistema de microsservivos pode não aparecer até que dois componentes específicos realmente interajam de uma maneira específica.


9
Isso parece assumir que aplicativos "monolíticos" são sempre digitados estaticamente. E quanto aos idiomas de tipo dinâmico? E o que dizer de interfaces de serviço estaticamente tipadas?
precisa saber é o seguinte

1
@ JacquesB OTOH, posso pensar em exatamente zero linguagens compiladas de tipo dinâmico.
precisa saber é o seguinte

2
@JacquesB JavaScript e Python não são compilados. A menos que você conte estruturas internas de intérpretes como um destino de compilação, nesse caso, todos os idiomas serão compilados.
precisa saber é o seguinte

3
@immibis: toda implementação existente do ECMAScript atualmente possui pelo menos um compilador. A V8, por exemplo, possui dois compiladores e exatamente zero intérpretes, nunca interpreta, sempre compila com código de máquina nativo binário. O SpiderMonkey possui quatro compiladores, acredito eu, e um intérprete, mas esse intérprete não interpreta o ECMAScript. O SpiderMonkey nunca interpreta o ECMAScript, ele sempre o compila primeiro no código de código SpiderMonkey, que pode ser compilado ainda mais para o código de máquina nativo binário. Todas as implementações atualmente existentes em Python, Ruby e PHP possuem compiladores.
Jörg W Mittag

12
@LieRyan Você está seriamente confuso se acha que a inferência de tipo é a mesma que digitada dinamicamente e / ou que Haskell é digitado dinamicamente.
Derek Elkins

2

Tanto em sistemas monolíticos quanto em microsserviços, é necessário definir interfaces entre os subsistemas. As interfaces devem ser bem projetadas, bem documentadas e o mais estável possível. É o mesmo que em OOP.

Se sua organização não conseguir fazer isso, os microsserviços também não resolverão o problema. Nos microsserviços, você possui interfaces públicas da Web. Então você precisa gastar mais esforço no design de 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. A chamada de uma interface da Web é bastante lenta, para que você possa ter problemas de desempenho.

Acho que produzir problemas de tempo de execução não é o caminho certo para comunicar problemas organizacionais àqueles que são responsáveis.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.