Posted on: April 25, 2023 07:44 PM
Posted by: Renato
Categories: Monolith microservices api microservice Architecture
Views: 284
MonolithFirst
.
Martin Fowler é um autor conhecido na área de arquitetura de software, especializado em análise orientada a objetos, UML, padrão de projeto de software e metodologias de desenvolvimento ágil de software, incluindo Programação extrema. Wikipédia
Nascimento: 18 de dezembro de 1963 (idade 59 anos), Walsall, Reino Unido
Formação: University College London (1983–1986), Queen Mary's Grammar School
Ao ouvir histórias sobre equipes usando uma arquitetura de microsserviços , notei um padrão comum.
- Quase todas as histórias bem-sucedidas de microsserviços começaram com um monólito que ficou muito grande e foi quebrado
- Quase todos os casos em que ouvi falar de um sistema que foi construído como um sistema de microsserviços 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 se tiver certeza de que seu aplicativo será grande o suficiente para valer a pena. .
Os microsserviços são uma arquitetura útil, mas mesmo seus defensores dizem que usá-los gera um MicroservicePremium significativo , o que significa que eles só são úteis com sistemas mais complexos. Esse prêmio, essencialmente o custo de gerenciamento de um conjunto de serviços, desacelerará uma equipe, favorecendo um monolito para aplicativos mais simples. Isso leva a um argumento poderoso para uma estratégia monolítica primeiro, em que você deve criar um novo aplicativo como um monólito inicialmente, mesmo que ache provável que ele se beneficie de uma arquitetura de microsserviços mais tarde.
A primeira razão para isso é o clássico Yagni . Quando você inicia um novo aplicativo, qual é sua certeza de que ele será útil para seus usuários? Pode ser difícil dimensionar um sistema de software mal projetado, mas bem-sucedido, mas ainda é um lugar melhor para se estar do que o inverso. Como agora estamos reconhecendo, geralmente a melhor maneira de descobrir se uma ideia de software é útil é criar uma versão simplista dela e ver como ela funciona. Durante esta primeira fase, você precisa priorizar a velocidade (e, portanto, o tempo de ciclo para feedback), portanto, o premium dos microsserviços é um empecilho que você deve dispensar.
O segundo problema de começar com microsserviços é que eles só funcionam bem se você criar limites bons e estáveis entre os serviços - que é essencialmente a tarefa de elaborar o conjunto correto de BoundedContexts . Qualquer refatoração de funcionalidade entre serviços é muito mais difícil do que em um monólito. Mas mesmo arquitetos experientes que trabalham em domínios familiares têm grande dificuldade em definir os limites logo no início. Ao construir um monólito primeiro, você pode descobrir quais são os limites corretos, antes que um design de microsserviços passe uma camada de melaço sobre eles. Também lhe dá tempo para desenvolver os pré-requisitos de microsserviço necessários para serviços mais refinados.
Guia de microsserviços
Já ouvi diferentes maneiras de executar uma estratégia monolítica primeiro. A maneira lógica é projetar um monólito com cuidado, prestando atenção à modularidade dentro do software, tanto nos limites da API quanto em como os dados são armazenados. Faça isso bem e será uma questão relativamente simples mudar para microsserviços. No entanto, eu me sentiria muito mais confortável com essa abordagem se tivesse ouvido um número decente de histórias em que funcionou dessa maneira. [1]
Uma abordagem mais comum é começar com um monólito e remover gradualmente os microsserviços nas bordas. Essa abordagem pode deixar um monólito substancial no centro da arquitetura de microsserviços, mas com a maioria dos novos desenvolvimentos ocorrendo nos microsserviços enquanto o monólito é relativamente inativo.
Outra abordagem comum é apenas substituir o monólito inteiramente. Poucas pessoas veem isso como uma abordagem da qual se orgulhar, mas há vantagens em construir um monólito como uma Arquitetura de Sacrifício . Não tenha medo de construir um monólito que você descartará, principalmente se um monólito puder levá-lo ao mercado rapidamente.
Outra rota que encontrei é começar com apenas alguns serviços de baixa granularidade, maiores do que aqueles que você espera obter. Use esses serviços granulares para se acostumar a trabalhar com vários serviços, aproveitando o fato de que essa granularidade grosseira reduz a quantidade de refatoração entre serviços que você precisa fazer. Então, à medida que os limites se estabilizam, divida-se em serviços mais refinados. [2]
Embora a maior parte dos meus contatos se incline para a abordagem monolítica, não é de forma unânime. O contra-argumento diz que começar com microsserviços permite que você se acostume com o ritmo de desenvolvimento em um ambiente de microsserviços. É preciso muita disciplina, talvez até demais, para construir um monólito de maneira suficientemente modular para que possa ser facilmente dividido em microsserviços. Ao começar com microsserviços, você acostuma todos a desenvolver em pequenas equipes separadas desde o início, e ter equipes separadas por limites de serviço torna muito mais fácil escalar o esforço de desenvolvimento quando necessário. Isso é especialmente viável para substituições de sistema, nas quais você tem mais chances de criar limites suficientemente estáveis com antecedência. Embora as evidências sejam escassas, acho que você não deve começar com microsserviços, a menos que tenha uma experiência razoável na construção de um sistema de microsserviços na equipe.
Acho que ainda não tenho anedotas suficientes para ter um controle firme sobre como decidir se devo usar uma estratégia monolítica primeiro. Estamos nos primeiros dias em microsserviços e há relativamente poucas anedotas para aprender. Portanto, os conselhos de qualquer pessoa sobre esses tópicos devem ser vistos como provisórios, por mais confiantes que sejam.
Leitura adicional
Sam Newman descreve um estudo de caso de uma equipe que está pensando em usar microsserviços em um projeto totalmente novo.
Notas
1: Você não pode presumir que pode pegar um sistema arbitrário e dividi-lo em microsserviços. A maioria dos sistemas adquire muitas dependências entre seus módulos e, portanto, não pode ser separada de forma sensata. Já ouvi falar de muitos casos em que uma tentativa de decompor um monólito acabou rapidamente em uma confusão. Também ouvi falar de alguns casos em que uma rota gradual para microsserviços foi bem-sucedida - mas esses casos exigiam um design modular relativamente bom para começar.
2: Suponho que estritamente você deva chamar isso de "duólito", mas acho que a abordagem segue a essência da estratégia do primeiro monólito: comece com granularidade grosseira para obter conhecimento e divida depois.
Reconhecimentos
Roubei muito desse pensamento de meus colegas: James Lewis, Sam Newman, Thiyagu Palanisamy e Evan Bottcher. Os comentários de Stefan Tilkov sobre um rascunho anterior desempenharam um papel fundamental para esclarecer meus pensamentos. Chad Currie criou os adoráveis dragões glyphy. Steven Lowe, Patrick Kua, Jean Robert D'amore, Chelsea Komlo, Ashok Subramanian, Dan Siwiec, Prasanna Pendse, Kief Morris, Chris Ford e Florian Sellmayr discutiram rascunhos em nossa lista de discussão interna.
## Mais informações que pode ser util.
Microsserviços vs API – saiba o que é certo para o seu negócio
Você está confuso entre os termos “Microservices"E"API” em discussões técnicas? É mais geral do que você pensa. É razoável confundir os conceitos, mas entender a diferença entre os dois ajuda a resolver problemas de negócios existentes, encontrar soluções práticas e realizar reuniões mais produtivas em geral.
Este Blog fornecerá a você o conhecimento sobre o que são APIs e o que são Microsserviços. A seguir, você verá como os dois termos funcionam juntos e como eles diferem.
Ao projetar um aplicativo móvel, você deve decidir como conectá-lo ao restante dos serviços. As opções típicas são criar um microsserviço ou usar uma API. Cada um deles tem suas vantagens e desvantagens. Mas, como podemos ver, às vezes os microsserviços funcionam melhor em alguns casos e as APIs funcionam melhor em outros casos.
Então, qual você deve escolher, Microsserviços vs API? Vamos ver:
O que é uma API?
Antes de tudo, antes de iniciar a discussão de Microsserviços vs API, você deve entender o significado básico de ambos os termos. API ou você diz Application Programming Interface tem muitos tipos ou vem em muitas formas.
Quando alguém diz “API“, eles podem dizer qualquer coisa, desde APIs privadas até APIs públicas, ou APIs SOAP para APIs RESTful. Agora você pode perceber e entender por que tantas pessoas confundem isso?
Basicamente, a API permite que dois componentes de software enviem e recebam mensagens e dados de forma estruturada sem a necessidade de intervenção humana ou entrada manual de dados. Quando falamos de integração de software, geralmente usamos APIs para permitir que esse software se comunique.
Para facilitar o entendimento, vamos falar sobre as APIs mais usadas no contexto de APIs REST e como eles são usados em arquiteturas de microsserviços. Ao falar sobre APIs típicas de transferência de estado (REST) ou APIs RESTful, elas se referem a estilos de API específicos.
O API REST fornece um caminho de mensagens sem estado entre aplicativos. Essa arquitetura requer que todas as mensagens transmitidas entre os aplicativos sejam completamente autocontidas.
O API do Google Maps e API do Twitter são exemplos de APIs REST disponíveis publicamente. Outra ideia é que a API seja uma forma de sua aplicação se comunicar com serviços externos como Google Maps e Twitter usando um conjunto de comandos e métodos bem definidos. Isso permite que você adicione facilmente recursos específicos que outros usuários criaram para seu aplicativo ou software.
Vamos explicar a API usando a analogia. Pense no fabricante da lâmpada. Você não precisa saber como fazer uma tomada ou como gerar e transmitir eletricidade. Eles sabem que basta fazer uma lâmpada com o cabo de alimentação correto (de acordo com as especificações padrão da indústria) e a tomada fornecerá a energia necessária para que a lâmpada funcione corretamente. É o cabo de alimentação com o qual a tomada e a lâmpada podem interagir.
A API é o cabo de alimentação para seu aplicativo. Essa é a conexão que permite que seu aplicativo receba os dados e mensagens de que precisa para funcionar corretamente.
Aqui está um exemplo mais específico. Suponha que você queira criar o seguinte aplicativo de compartilhamento de viagens que requer o uso de um cartão. Você tem várias opções: Você e alguns de seus melhores amigos podem criar algo semelhante ao Google Maps do zero e mudar a si mesmos sempre que precisar. Você também pode usar a API do Google Maps. O Google abstrai todos os detalhes necessários para implementar o serviço por trás da API e fornece a funcionalidade necessária para o aplicativo. A última opção permite que os desenvolvedores de software se concentrem na criação de valor específico do aplicativo, em vez de criar a roda (ou mapa, neste caso) do zero.
Agora que temos uma compreensão mais profunda do que é a API, e os microsserviços?
O que são Microsserviços?
Microservices são um estilo de arquitetura que divide um aplicativo em serviços ou componentes independentes menores (geralmente voltados para funções de negócios). Esses serviços normalmente usam APIs para se comunicarem.
Ou seja, o API conecta cada serviço dentro da arquitetura de microsserviços para fornecer um serviço ou aplicativo totalmente funcional. Nesse contexto, a funcionalidade da API é um pouco diferente.
Suponha que um novo aplicativo de compartilhamento de viagens precise fornecer recursos de mapa e faturamento. Você pode implementar cada recurso como um microsserviço separado e incorporar todas as regras de negócios, lógica e dados necessários para cada serviço de maneira relativamente independente.
Isso não apenas facilita a manutenção de seus serviços, mas também melhora a tolerância a falhas de seu aplicativo. Quando um único serviço falha, o aplicativo como um todo não necessariamente fica inativo.
Conexão entre microsserviços e APIs (REST)
Agora que sabemos mais sobre microsserviços e como eles diferem dos monólitos, vamos para a primeira pergunta. Como os microsserviços são diferentes das APIs?
Se a forma como os aplicativos se comunicam é a API REST, a arquitetura de microsserviços é o local de conversa e prática social.
Cada componente da arquitetura de microsserviços possui sua própria API para comunicação com outros componentes. Cada componente da arquitetura se baseia nos recursos de outros componentes para fornecer aos usuários finais uma experiência de aplicativo coesa e agregar valor aos seus negócios.
Microsserviços e APIs continuará a desempenhar um papel importante no desenvolvimento e integração de software até 2022, transformando as soluções de software de negócios. As empresas que buscam alavancar os recursos digitais em seus processos de negócios precisam saber a diferença entre os dois conceitos.
No entanto, a arquitetura de microsserviços não é uma panacéia para problemas de software corporativo. Mudar para microsserviços requer grandes mudanças culturais e design consciente para que o software possa atingir todo o seu potencial.
Conclusão
Esses debates sobre microsserviços versus API geralmente giram em torno de conversas sobre as grandes mudanças que estão ocorrendo no mundo da tecnologia. Independentemente da situação, se algum tipo de desenvolvimento está tentando determinar se sua nova função utilizaria APIs ou se dois desenvolvedores estão apenas interessados em expressar suas opiniões sobre o assunto, é importante ser educado sobre o assunto. Os desenvolvedores devem saber o que amam e odeiam e para onde estão indo enquanto continuam suas carreiras. Tendo isso em mente, esperamos que nossa pesquisa sobre componentes de Microservices vs API tenha sido um recurso útil para você.
Fonte:
- https://martinfowler.com/bliki/MonolithFirst.html
- https://cynoteck.com/pt/blog-post/microservices-vs-api/
Martin Fowler (Walsall, 1963) é um autor conhecido na área de arquitetura de software, especializado em análise orientada a objetos, UML, padrão de projeto de software e metodologias de desenvolvimento ágil de software, incluindo Programação extrema (XP). Ele começou a trabalhar com desenvolvimento de software no início dos anos 80 e escreveu vários livros populares sobre desenvolvimento, alguns deles já traduzidos para português.
Livros (em Português)
- Refatoração para Padrões, ISBN 8577802449, Ed. Bookman, 2008
- Padrões de Arquitetura de Aplicações Corporativas, ISBN 8536306386, Ed. Bookman, 2006
- Refatoração: Aperfeiçoando o projeto de código existente, ISBN 8536303956, Ed. Bookman, 2004
- UML Essencial, ISBN 8536304545, Ed. Bookman, 2004
- NoSQL Essencial,ISBN 9788575223383, Ed. Novatec, 2013
Donate to Site
Renato
Developer