Walking the Microservices Path towards Loose coupling? Look out for these Pitfalls

Nesse post, Srinath Perera ataca algumas armadilhas ao usar microsserviços:

1. Como fazer se não pode haver banco de dados compartilhado entre serviços: usar mensagens assíncronas, usar transações ou juntar os serviços que precisam dos mesmos dados.

2. Como lidar com a consistência dos serviços nas atualizações: contenha as atualizações em um serviço, e evite atualizações que afetem vários de uma vez, e, em vez de transações, use compensações.

3. Como lidar com a segurança: use um servidor de autenticação e tokens assinados.

4. Como compor os microsserviços: deixe o cliente tratar com os vários serviços, ou trabalhe com orquestração ou tenha um servidor central.

5. Evite o “inferno das dependências”: use um gateway que sabe qual serviço pode tratar qual versão da API, ou use orquestração.

O texto também está cheio de links para algumas fontes mais detalhadas sobre cada assunto.

My views of the World and Systems

(image credit: Wiros from Barcelona, Spain)

Microservices are the new architecture style of building systems using simple, lightweight, loosely coupled services that can be developed and released independently of each other.

If you need to know the basics, read Martin Fowler’s Post. If you like to compare it with SOA, watch the Don Ferguson’s talk.). Also, Martin Fowler has written about “trade off of micro services” and “when it is worth doing microservices”, which let you decide when it is useful.

Let’s say that you heard, read, and got convinced about microservices. If you are trying to follow the microservices architecture, there are few practical challenges. This post discusses how you can handle some of those challenges.

No Shared Database(s)

Each microservice should have it’s own databases and Data MUST not be shared via a database. This rule removes a common case that leads…

Ver o post original 1.796 mais palavras

Anúncios

Arquitetura de Microsserviços e Tecnologia de Contêiner Explicadas

Para lutar por espaço no mundo dos serviços e aplicações baseados na web, é necessário ter um olho rápido e um braço forte de desenvolvimento de software, e as empresas em todo lugar buscam novas formas de aumentar a agilidade e encurtar o time-to-market.

Não comece com um monolito

...quando o seu objetivo é uma arquitetura de microsserviços. Nos últimos meses, ouvi repetidamente que a única forma de ter uma arquitetura bem sucedida de microsserviços é começando primeiro com um monolito. Como lembra Simon Brown: se você não consegue construir um monolito bem estruturado, o que o faz acreditar que será capaz de construir um conjunto bem estruturado de microsserviços? A mais recente, e como sempre convincente, interpretação desse argumento vem de Martin Fowler. Tomei algum tempo para pensar sobre isso. E fiz isso especialmente porque normalmente concordo com ele, e outras pessoas cujas visões eu compartilho também parecem concordar com ele.

Uma Cartilha Rápida sobre Microsserviços

Microsserviços são um tipo de arquitetura de software onde grandes aplicações são feitas de unidades pequenas trabalhando juntos por meio de APIs que não são dependentes em uma linguagem específica. Cada serviço tem um escopo limitado, se concentra em uma tarefa específica e é altamente independente. Esse arranjo permite que os gerentes de TI e desenvolvedores construam sistemas de forma modular. No seu livro "Construindo Microsserviços", Sam Newman disse que microsserviços são componentes pequenos e focados, construídos para fazer uma coisa muito bem.

Microsserviços – Parte VI

Desenhe para falhar Uma consequência de usar serviços como componentes é que as aplicações devem ser desenhadas para tolerar falhas nos serviços. Qualquer chamada de serviço pode falhar devido a indisponibilidade do fornecedor, o cliente tem que lidar com isso o mais graciosamente possível. É uma desvantagem comparado com o desenho monolítico porque introduz uma complexidade adicional. A consequência é que os times de microsserviços constantemente refletem sobre como as falhas dos serviços afetam a experiência do usuário. O Exército Símio do Netflix induz falhas de serviços e até de datacenters durante o expediente para testar a resiliência e o monitoramento das aplicações.

Microsserviços – Parte V

Gerenciamento de Dados Descentralizado Decentralização do gerenciamento de dados se apresenta de inúmeras formas diferentes. No nível mais abstrato, significa que um modelo conceitual do mundo será diferente entre sistemas. Isso é um problema comum ao integrar uma grande empresa, a visão de vendas de um cliente será diferente da visão de suporte. Algumas coisas chamadas de "clientes" na visão de vendas podem nem aparecer na visão de suporte. As coisas que existem em comum podem ter atributos diferentes, ou pior, atributos em comum mas com semânticas diferentes.