Tomar decisões implica, ou deveria implicar, em conhecimento prévio somado ao discernimento e ponderação a respeito dos impactos e reflexos de cada decisão. Se você não está ponderando sobre suas próprias decisões, alguém está fazendo por você. Direta ou indiretamente. Nos resta saber se estamos falando de influência ou manipulação.

Assim com base em uma nova página, que data de de 21/Agosto/2019, no site do Martin Fowler temos algumas coisas muito interessantes à diante:

Não vou traduzir a página toda, só partes importantes para a minha narrativa. Mas o texto seguirá com original e tradução.

Microservices Guide

Fonte: Martin Fowler – https://martinfowler.com/microservices/

We wrote the article to provide a firm definition for the microservices style, which we did by listing the common characteristics of microservice architectures that we saw in the field. * Componentization via Services * Organized around Business Capabilities * Products not Projects * Smart endpoints and dumb pipes * Decentralized Governance * Decentralized Data Management * Infrastructure Automation * Design for failure * Evolutionary Design

Escrevemos o artigo para fornecer uma definição firme para o estilo de microsserviços , o que fizemos listando as características comuns das arquiteturas de microsserviços que vimos em campo. * Componentização via Serviços * Organizado em torno dos recursos de negócios * Produtos não Projetos * Terminais inteligentes e tubos burros * Governança descentralizada * Gerenciamento de dados descentralizado * Automação de infraestrutura * Design para falha * Design Evolucionário

When should we use Microservices?

Fonte: Martin Fowler – https://martinfowler.com/microservices/

Any architectural style has trade-offs: strengths and weaknesses that we must evaluate according to the context that it’s used. This is certainly the case with microservices. While it’s a useful architecture – many, indeed most, situations would do better with a monolith. Microservices provide benefits… Strong Module Boundaries: Microservices reinforce modular structure, which is particularly important for larger teams. Independent Deployment: Simple services are easier to deploy, and since they are autonomous, are less likely to cause system failures when they go wrong. Technology Diversity: With microservices you can mix multiple languages, development frameworks and data-storage technologies. …but come with costs Distribution: Distributed systems are harder to program, since remote calls are slow and are always at risk of failure. Eventual Consistency: Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency. Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly. (from Microservice Trade-Offs)

Qualquer estilo arquitetônico tem vantagens e desvantagens: pontos fortes e fracos que devemos avaliar de acordo com o contexto em que é usado. Este é certamente o caso dos microsserviços.  Embora seja uma arquitetura útil – muitas, na verdade a maioria, situações se sairiam melhor com um monólito. Os microsserviços oferecem benefícios … Fortes limites de módulo : Os microsserviços reforçam a estrutura modular, o que é particularmente importante para equipes maiores. Implantação independente : serviços simples são mais fáceis de implantar e, como são autônomos, são menos propensos a causar falhas no sistema quando ocorrerem erros. Diversidade tecnológica : Com microsserviços, você pode misturar vários idiomas, estruturas de desenvolvimento e tecnologias de armazenamento de dados. … mas vem com custos Distribuição : Os sistemas distribuídos são mais difíceis de programar, pois as chamadas remotas são lentas e sempre correm risco de falha. Consistência Eventual : Manter uma consistência forte é extremamente difícil para um sistema distribuído, o que significa que todos precisam gerenciar uma consistência eventual. Complexidade operacional : você precisa de uma equipe de operações madura para gerenciar muitos serviços, que estão sendo reimplantados regularmente. (de compensações de microsserviço )

Microservice Premium

Fonte: Martin Fowler – https://martinfowler.com/bliki/MicroservicePremium.html

The microservices architectural style has been the hot topic over the last year. At the recent O’Reilly software architecture conference, it seemed like every session talked about microservices. Enough to get everyone’s over-hyped-bullshit detector up and flashing. One of the consequences of this is that we’ve seen teams be too eager to embrace microservices, not realizing that microservices introduce complexity on their own account. This adds a premium to a project’s cost and risk – one that often gets projects into serious trouble.

O estilo arquitetônico dos microsserviços tem sido o tema principal do último ano. Na recente conferência de arquitetura de software O’Reilly , parecia que todas as sessões falavam sobre microsserviços. O suficiente para fazer com que o detector de besteiras exageradas de todo mundo fique aceso. Uma das conseqüências disso é que vimos equipes ansiosas demais para adotar microsserviços, sem perceber que eles introduzem complexidade por conta própria. Isso adiciona um prêmio aos custos e riscos de um projeto – um que geralmente coloca os projetos em sérios problemas.

Monolith First

Fonte: Martin Fowler – https://martinfowler.com/bliki/MonolithFirst.html

As I hear stories about teams using a microservices architecture, I’ve noticed a common pattern. Almost all the successful microservice stories have started with a monolith that got too big and was broken up Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. This pattern has led many of my colleagues to argue that you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile. .

Ao ouvir histórias sobre equipes que usam uma arquitetura de microsserviços , notei um padrão comum. Quase todas as histórias de microsserviços bem-sucedidas começaram com um monólito muito grande e dividido Quase todos os casos em que ouvi falar de um sistema que foi construído como um sistema de microsserviço do zero, acabaram em sérios problemas. Esse padrão levou muitos de meus colegas a argumentar que você não deve iniciar um novo projeto com microsserviços, mesmo que tenha certeza de que seu aplicativo será grande o suficiente para fazer valer a pena. .

Microservice Prerequisites

Fonte: Martin Fowler – https://martinfowler.com/microservices/

As I talk to people about using a microservices architectural style I hear a lot of optimism. Developers enjoy working with smaller units and have expectations of better modularity than with monoliths. But as with any architectural decision there are trade-offs. In particular with microservices there are serious consequences for operations, who now have to handle an ecosystem of small services rather than a single, well-defined monolith. Consequently if you don’t have certain baseline competencies, you shouldn’t consider using the microservice style.

Enquanto converso com as pessoas sobre o uso de um estilo arquitetural de microsserviços, ouço muito otimismo.  Os desenvolvedores gostam de trabalhar com unidades menores e têm expectativas de melhor modularidade do que os monólitos.  Mas, como em qualquer decisão de arquitetura, existem trade-offs.  Em particular nos microsserviços, há sérias conseqüências para as operações, que agora precisam lidar com um ecossistema de pequenos serviços, em vez de um único monólito bem definido.  Consequentemente, se você não possui determinadas competências de linha de base, não deve considerar o uso do estilo de microsserviço.

Todos os textos acima são do Martin Fowler, ele assina todos. O próximo texto é do Stefan Tilkov, que se ancora no texto Monolith First para expor sua opinião contraria, e com a ajuda do Fowler montam um texto incrível.

Don’t start with a monolith

Fonte: Stefan Tilkov – https://martinfowler.com/articles/dont-start-monolith.html

In the last few months, I’ve heard repeatedly that the only way to get to a successful microservices architecture is by starting with a monolith first.  To paraphrase Simon Brown: If you can’t build a well-structured monolith, what makes you think you can build a well-structured set of microservices? The most recent – and, as usual, very convincing – rendering of this argument comes from Martin Fowler on this very site. As I had a chance to comment on an earlier draft, I had some time to think about this. And I did, especially because I usually find myself in agreement with him, and some others whose views I typically share seemed to agree with him, too. I’m firmly convinced that starting with a monolith is usually exactly the wrong thing to do.

Nos últimos meses, ouvi várias vezes que a única maneira de obter uma arquitetura de microsserviços bem-sucedida é começando primeiro com um monólito.  Parafraseando Simon Brown : Se você não pode construir um monólito bem estruturado, o que faz você pensar que pode criar um conjunto bem estruturado de microsserviços?  A versão mais recente – e, como sempre, muito convincente – desse argumento vem de Martin Fowler neste mesmo site.  Como tive a chance de comentar um rascunho anterior, tive tempo para pensar sobre isso.  E sim, especialmente porque geralmente me encontro de acordo com ele, e alguns outros cujas opiniões eu normalmente compartilho também parecem concordar com ele. Estou firmemente convencido de que começar com um monólito geralmente é exatamente a coisa errada a se fazer.

In the majority of cases, it will be awfully hard, if not outright impossible, to cut up an existing monolith this way. (That doesn’t mean it’s always impossible, but that’s a topic for a future post.) There is some common ground in that I agree you should know the domain you’re building a system for very well before trying to partition it, though: In my view, the ideal scenario is one where you’re building a second version of an existing system. If you are actually able to build a well-structured monolith, you probably don’t need microservices in the first place. Which is OK! I definitely agree with Martin: You shouldn’t introduce the complexity of additional distribution into your system if you don’t have a very good reason for doing so.

Na maioria dos casos, será muito difícil, se não totalmente impossível, reduzir um monólito existente dessa maneira.  (Isso não significa que é sempre impossível, mas esse é um tópico para uma publicação futura.) Há alguns pontos em comum em que concordo que você deve saber o domínio para o qual está construindo um sistema muito bem antes de tentar particioná-lo. : Na minha opinião, o cenário ideal é aquele em que você está construindo uma  segunda versão de um sistema existente. Se você é realmente capaz de construir um monólito bem estruturado, provavelmente não precisa de microsserviços em primeiro lugar. O que é bom! Eu definitivamente concordo com Martin : você não deve introduzir a complexidade da distribuição adicional em seu sistema se não tiver um bom motivo para fazê-lo.

But if you start with a monolith, the parts will become extremely tightly coupled to each other.  That’s the very definition of a monolith. The parts will rely on features of the platform they all use. They’ll communicate based on abstractions that are shared because they all use the same libraries. They’ll communicate using means that are only available when they are hosted in the same process. And these are only the technical aspects! Far worse than that, the parts will (almost) freely share domain objects, rely on the same, shared persistence model, assume database transactions are readily available so that there’s no need for compensation … Even the very fact that it’s easy to refactor things and move them around – all in the convenience of your IDE’s view of a single project – is what makes it extremely hard to cut things apart again. It’s extremely hard to split up an existing monolith into separate pieces. I strongly believe – and experience from a number of our recent projects confirms this – that when you start out, you should think about the subsystems you build, and build them as independently of each other as possible. Of course you should only do this if you believe your system is large enough to warrant this. If it’s just you and one of your co-workers building something over the course of a few weeks, it’s entirely possible that you don’t. But starting with an approach where you carve up your system into smaller parts, and treat each of them as a clearly separated, individual system with its own development, deployment, and delivery cycle, and (the possibility of) its own internal architecture, is a very powerful concept that can help you to deliver a system in the first place.

Mas se você começar com um monólito, as peças ficarão extremamente fortemente acopladas umas às outras.  Essa é a própria definição de um monólito.  As peças contarão com os recursos da plataforma que todos usam.  Eles se comunicam com base em abstrações compartilhadas porque todos usam as mesmas bibliotecas.  Eles se comunicam usando meios disponíveis apenas quando estão hospedados no mesmo processo.  E estes são apenas os aspectos técnicos!  Muito pior do que isso, as partes compartilharão (quase) livremente objetos de domínio, confiarão no mesmo modelo de persistência compartilhada, assumirão que as transações do banco de dados estão prontamente disponíveis para que não haja necessidade de compensação … Mesmo o fato de ser fácil refatorar as coisas e movê-los – tudo na conveniência da visão do seu IDE de um único projeto – é o que torna extremamente difícil separar as coisas novamente.  É extremamente difícil dividir um monólito existente em partes separadas. Acredito firmemente – e a experiência de vários de nossos projetos recentes confirma isso – que, quando você começar, deve pensar nos subsistemas que construir e construí-los da maneira mais independente possível .  Obviamente, você só deve fazer isso se acreditar que seu sistema é grande o suficiente para justificar isso.  Se for apenas você e um de seus colegas de trabalho construindo algo ao longo de algumas semanas, é perfeitamente possível que não. Mas começando com uma abordagem na qual você divide seu sistema em partes menores e trata cada um deles como um sistema individual claramente separado, com seu próprio ciclo de desenvolvimento, implantação e entrega e (a possibilidade de) sua própria arquitetura interna. um conceito muito poderoso que pode ajudá-lo a fornecer um sistema em primeiro lugar.

But there is another lesson to be learned from this discussion, in my view – and it’s a more general one: Beware of architectural recipes that are too simple and too obvious. This one – start by carving up your domain into separate, independent parts – is no exception. Sometimes a monolith is preferable, sometime it’s not. If you decide to build things using a microservices approach, you need to be aware that while it will be a lot easier to make localized decisions in each individual part, it will be much harder to change the very boundaries that enable this. Refactoring in the small becomes easier, refactoring in the large becomes much harder. As is always the case with architecture discussions, there is no way to get around the fact that you need to make that decision on your own, in each and every individual case.

Mas há outra lição a ser aprendida com essa discussão, na minha opinião – e é mais geral: cuidado com as receitas arquitetônicas muito simples e óbvias demais.  Este – comece dividindo seu domínio em partes separadas e independentes – não é uma exceção.  Às vezes, um monólito é preferível, às vezes não é.  Se você decidir criar coisas usando uma abordagem de microsserviços, precisará estar ciente de que, embora seja muito mais fácil tomar decisões localizadas em cada parte individual, será muito mais difícil alterar os limites que permitem isso.  A refatoração no pequeno se torna mais fácil, a refatoração no grande se torna muito mais difícil. Como sempre acontece com as discussões de arquitetura, não há como contornar o fato de que você precisa tomar essa decisão por conta própria, em todos os casos individuais.

Conclusão

Assim concluo com frases que não são minhas:

Sobre Microsserviços é necessário estar ciente de que embora seja muito mais fácil tomar decisões localizadas em cada parte individual, será muito mais difícil alterar os limites que permitem isso. A refatoração no pequeno se torna mais fácil, a refatoração no grande se torna muito mais difícil.

Às vezes, um monólito é preferível, às vezes não é. 

Cuidado com as receitas arquitetônicas muito simples e óbvias demais. 

Há alguns pontos em comum em que concordo que você deve saber o domínio para o qual está construindo um sistema muito bem antes de tentar particioná-lo. : Na minha opinião, o cenário ideal é aquele em que você está construindo uma 
segunda versão de um sistema existente.

Se você é realmente capaz de construir um monólito bem estruturado, provavelmente não precisa de microsserviços em primeiro lugar. O que é bom! Eu definitivamente concordo com Martin : você não deve introduzir a complexidade da distribuição adicional em seu sistema se não tiver um bom motivo para fazê-lo.

Por hora vou evitar comentários, eles podem ser ácidos demais, ou direcionados demais. Vamos nos ater às ideias!

A origem

Essa é uma resposta às discussões recentes que rolaram no grupo de Arquitetura do Facebook:

A primeira sobre o post do Andre Secco, onde a discussão tomou um rumo muito ruim.

Thread 1 – https://www.facebook.com/groups/arquiteturadotnet/permalink/2379931582082472/

MONOLITOS NÃO ESCALAM?

A segunda tem a ver com a discussão adjacente que rolou no post do Stephany Batista também no grupo de arquitetura do facebook.

Thread 2 – https://www.facebook.com/groups/arquiteturadotnet/permalink/2389301551145475/

O tema Micro-Serviços é igual sexo na adolescência, todos falam com autoridade e ao mesmo tempo a maioria tem dúvida.

Próximos passos

Até então, com os inúmeros textos explicando microsserviços ou aspectos de sua implementação, considerei o assunto crowded, e portanto me propus a fazer o papel de contra-ponto e mostrar uma perspectiva mais sóbria e menos apaixonada sobre a questão, principalmente servindo de alerta contra afirmações descabidas, que vão completamente contra o que foi dito por Fowler e Tilkov.

Afirmações, como “Monolito é passado”, “Microsserviços é o futuro”, “Microsserviços serve pra tudo”…

Afirmações assim são, além de descabidas, são no mínimo imprudentes.

Quando influenciadores negligentes encontram uma audiência esperançosa e igualmente negligente, podemos esperar uma safra de caos pelos próximos 10 anos. Eu achava que alguém tinha de jogar uma pá de cal nessa dinâmica, para que pudessem buscar o conteúdo adequado para que pudessem olhar essa jornada com a devida atenção. Mas não! O buraco é mais embaixo e o conteúdo sério não está sendo pulverizado da forma que devia. Os discursos e discussões continuam rasos, não estamos progredindo como comunidade, pelo menos não na direção de debatermos os desafios e obviamente as soluções para os desafios da arquitetura de microsserviços.

Onde antes eu achava que estava crowded, hoje esperançoso vejo muito espaço para discussões que vão além do básico.

Bom, para não parecer que sou contra microsserviços, e entenda, nunca fui contra, vou começar uma série dedicada a essa jornada. Se chamará The Microservices Journey.