{"id":2707,"date":"2021-07-11T22:16:23","date_gmt":"2021-07-12T01:16:23","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=2707"},"modified":"2024-01-11T18:07:38","modified_gmt":"2024-01-11T21:07:38","slug":"projetando-sistemas-com-microsservicos-capitulo-14-v-1-0","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/projetando-sistemas-com-microsservicos-capitulo-14-v-1-0\/","title":{"rendered":"Projetando sistemas com microsservi\u00e7os \/ Cap\u00edtulo 14 v 1.0"},"content":{"rendered":"

Acoplamento \u00e9 a causa raiz de boa parte dos problemas relacionados a disponibilidade,\u00a0 manutenabilidade, performance e resili\u00eancia<\/strong>. Acoplamento n\u00e3o tratado \u00e9 fonte de custo tanto para o desenvolvimento quanto para a sustenta\u00e7\u00e3o de solu\u00e7\u00f5es.<\/p>\n

Conforme Conway, software com componentes acoplados \u00e9 resultado do trabalho de times acoplados. N\u00e3o raro, esses times tem “pontos de falha” e “gargalos” bem conhecidos<\/strong>. A correta organiza\u00e7\u00e3o dos times, permitindo que esses operem de maneira independente, inclusive disponibilizando seus produtos de maneira independente \u00e9 a ess\u00eancia para combater o acoplamento.<\/p>\n

H\u00e1 mais de uma d\u00e9cada, arquiteturas baseadas em microsservi\u00e7os tem permitido o estabelecimento de times com mais autonomia para entregar mais valor para o neg\u00f3cio. Tamb\u00e9m h\u00e1 mais de uma d\u00e9cada, implementa\u00e7\u00f5es infelizes desse estilo arquitetural tem destru\u00eddo valor.<\/p>\nMicrosservi\u00e7os n\u00e3o \u00e9 uma solu\u00e7\u00e3o “bala de prata”. Afinal, esse tipo de solu\u00e7\u00e3o n\u00e3o existe. Entretanto, tem m\u00e9ritos e dem\u00e9ritos que, se bem ponderados, tem poder de transformar organiza\u00e7\u00f5es para melhor.\n

Conceito fundamental<\/h2>\n

Microsservi\u00e7os \u00e9 um estilo arquitetural que preconiza o desenvolvimento de aplica\u00e7\u00f5es a partir de servi\u00e7os pequenos, cada um rodando em seu pr\u00f3prio processo, que se comunicam atrav\u00e9s de mecanismos leves.<\/p>\n

\r\n

REST (HTTP resource API) ou gRPC<\/p>\r\n<\/p>\n

Comunica\u00e7\u00e3o intensiva entre servi\u00e7os utilizando a combina\u00e7\u00e3o HTTP\/1.1 e JSON \u00e9 um “pedido” para problemas de performance. Seja pelas limita\u00e7\u00f5es do protocolo de comunica\u00e7\u00e3o ou pela “verbosidade” do formato JSON.<\/p>\n

Recentemente, t\u00eam ganho destaque a utiliza\u00e7\u00e3o de gRPC (que opera sobre HTTP\/2) combinada protocol buffers<\/em>.<\/p>\n

<\/div>\n

Estrategicamente, microsservi\u00e7os precisam ser constru\u00eddos para suportar\u00a0capabilities\u00a0<\/em>de neg\u00f3cio. Essa caracter\u00edstica \u00e9 essencial para que sejam desenvolvidos e tenham\u00a0deploys <\/em>independentes.<\/p>\n

\"\"<\/p>\n

Importante destacar que esse estilo arquitetural habilita tamanha independ\u00eancia autorizando, inclusive, que cada microsservi\u00e7o seja escrito em uma linguagem de programa\u00e7\u00e3o diferente com tecnologias de persist\u00eancia exclusivas.<\/p>\n

\r\n

API Layer<\/p>\r\n<\/p>\n

A maioria das arquiteturas baseadas em microsservi\u00e7os implementa alguma forma de “camada de API”, muitas vezes implementadas por um API Gateway, conectando usu\u00e1rios externos (interfaces ou sistemas de terceiros) aos microsservi\u00e7os. Trata-se de uma abordagem opcional, mas recomendada.<\/p>\n

Essa estrat\u00e9gia permite a cria\u00e7\u00e3o facilitada de APIs externas, facilitando a ado\u00e7\u00e3o, al\u00e9m de poder implementar\u00a0shared concerns\u00a0<\/em>como autentica\u00e7\u00e3o e localiza\u00e7\u00e3o. Entretanto, \u00e9 importante destacar que n\u00e3o devem ser atribu\u00eddas a essa camada responsabilidades de orquestra\u00e7\u00e3o.<\/p>\n

<\/div>\n

Rela\u00e7\u00e3o com Squads<\/em><\/h2>\nN\u00e3o \u00e9 recomend\u00e1vel formar squads\u00a0<\/em>em uma organiza\u00e7\u00e3o, sem revisar a arquitetura do software que ela produz. Tampouco \u00e9 respons\u00e1vel iniciar um projeto baseado em (micros)servi\u00e7os sem, antes, fazer uma revis\u00e3o da estrutura organizacional.\n
\n

A\u00a0lei de Conway \u00e9 categ\u00f3rica<\/a>\u00a0e suas implica\u00e7\u00f5es s\u00e3o \u00f3bvias:\u00a0Uma organiza\u00e7\u00e3o monol\u00edtica n\u00e3o consegue produzir microsservi\u00e7os. Empresas que produzem softwares monol\u00edticos n\u00e3o deveriam ter \u201csquads\u201d.<\/strong><\/p>\nSquads<\/em> s\u00e3o times multifuncionais, que conseguem desempenhar atividades organizacionais de ponta-a-ponta, com\u00a0autonomia e alinhamento<\/a>.\u00a0\u00a0Eles reduzem a burocracia da organiza\u00e7\u00e3o pois reduzem a necessidade de\u00a0documentos que nascem da falta de confian\u00e7a<\/a>.\u00a0<\/strong>Afinal, pessoas de um mesmo time costumam confiar mais umas nas outras.\n

\n

Para ter autonomia, as \u201centregas\u201d de um squad\u00a0<\/em>devem ocorrer de forma independente.\u00a0Se as entregas de um\u00a0squad\u00a0<\/em>precisarem ser feitas com as de outros, acordos s\u00e3o necess\u00e1rios e a burocracia-para-confian\u00e7a emerge.<\/p>\n

Apenas times realmente aut\u00f4nomos conseguem produzir (micros)servi\u00e7os com baixo acoplamento.\u00a0<\/strong>Microsservi\u00e7os com alto acoplamento n\u00e3o se justificam pois s\u00e3o, apenas, um pesadelo para a opera\u00e7\u00e3o.<\/p>\n

S\u00e3o necess\u00e1rios times realmente independentes para produzir (micros)servi\u00e7os que n\u00e3o compartilham banco de dados.<\/strong><\/p>\nA comunica\u00e7\u00e3o entre (micros)servi\u00e7os ser\u00e1 naturalmente ass\u00edncrona, se a comunica\u00e7\u00e3o entre os times que os produzem tamb\u00e9m for.\u00a0Comunica\u00e7\u00e3o s\u00edncrona entre (micros)servi\u00e7os revela, mais que poss\u00edvel falha de design de software, falha de design organizacional.<\/strong>\n

\n

Implica\u00e7\u00f5es para a reutiliza\u00e7\u00e3o<\/h2>\n

Uma das “fontes inocentes” para acoplamento \u00e9 a insist\u00eancia por alternativas para reutiliza\u00e7\u00e3o.<\/p>\n

O trade-off negativo da reutiliza\u00e7\u00e3o \u00e9 o acoplamento. Quando um arquiteto projeta um sistema favorecendo o reuso, ele tamb\u00e9m favorece ao acoplamento para permitir esse reuso, seja por heran\u00e7a ou composi\u00e7\u00e3o. (Neal Ford)<\/em><\/p>\n

Toda alternativa de reutiliza\u00e7\u00e3o faz emergir um componente com acoplamento aferente elevado que, mais cedo ou mais tarde, se converte em “gargalo” para o desenvolvimento.<\/p>\nSegundo Conway, componentes “gargalo” se traduzem em times gargalo, caso se d\u00ea atribui\u00e7\u00e3o de “propriedade” a algum, ou em pontos cr\u00edticos de falha devido a alta difus\u00e3o de responsabilidade.\n

\n

A emerg\u00eancia por alternativas para a gest\u00e3o de componentes deu origem a iniciativas de inner sourcing.<\/em><\/p>\n

Reutiliza\u00e7\u00e3o de recursos operacionais<\/h4>\n

A op\u00e7\u00e3o por duplica\u00e7\u00e3o frente a reutiliza\u00e7\u00e3o \u00e9 v\u00e1lida para artefatos funcionais, mas n\u00e3o para recursos operacionais (tais como\u00a0logging\u00a0<\/em>e monitoramento).\u00a0A abordagem comum \u00e9 manter recursos funcionais “dentro” dos microsservi\u00e7os, duplicados sempre que necess\u00e1rio, e recursos operacionais “fora”, em\u00a0sidecars.<\/em><\/p>\n

\"\"<\/p>\n

A “padroniza\u00e7\u00e3o” de um \u00fanico sidecar\u00a0<\/em>em dois ou mais microsservi\u00e7os permite a inclus\u00e3o de componentes para administra\u00e7\u00e3o.<\/p>\n

\"\"<\/p>\n

A “predomin\u00e2ncia” de um \u00fanico sidecar <\/em>habilita a forma\u00e7\u00e3o de service meshs<\/em>.<\/p>\n

\r\n

Istio<\/p>\r\n<\/p>\n

Uma das plataformas mais utilizadas para ado\u00e7\u00e3o de Service Mesh<\/em> \u00e9 o Istio.\u00a0 Ele estende o Kubernetes para estabelecer uma rede program\u00e1vel, usando o proxy<\/em> de servi\u00e7o Envoy. Ele oferece gerenciamento de tr\u00e1fego universal, telemetria e seguran\u00e7a para implanta\u00e7\u00f5es complexas.<\/p>\n

<\/div>\n

Arquitetura naturalmente distribu\u00edda<\/h2>\n

Em produ\u00e7\u00e3o, microsservi\u00e7os operam em forma naturalmente distribu\u00edda. Afinal, cada servi\u00e7o “roda” em um processo independente, originalmente, em um computador dedicado, mas, atualmente, em m\u00e1quinas virtuais ou cont\u00eaineres.<\/p>\n

Quando muitos servi\u00e7os compartilham recursos computacionais em demasia, rodando em uma \u00fanica plataforma operacional, t\u00eam-se, inicialmente, melhor aproveitamento da largura de banda da rede, mem\u00f3ria, discos, etc. Entretanto, na medida em que as demandas de cada servi\u00e7o crescem, ocorrem restri\u00e7\u00f5es que podem levar a problemas de disponibilidade e aumentam a import\u00e2ncia de adotar t\u00e1ticas de resili\u00eancia.<\/p>\n

Sem o devido cuidado, aplica\u00e7\u00f5es baseadas em microsservi\u00e7os podem ter, devido a natureza distribu\u00edda, problemas de performance. Afinal de contas, chamadas na rede s\u00e3o muito mais custosas que chamadas a m\u00e9todos, al\u00e9m de todo o overhead\u00a0<\/em>de seguran\u00e7a e governan\u00e7a.<\/p>\n

\r\n

Oito fal\u00e1cias da computa\u00e7\u00e3o distribu\u00edda<\/p>\r\n<\/p>\n

Em 1994, Peter Deutsch, que trabalhou na Sun Microsystems, consolidou uma lista de 7 fal\u00e1cias frequentemente associadas a sistemas distribu\u00eddos. Mais tarde, em 1997, James Gosling adicionou um item a essa lista, criando a comumente conhecida rela\u00e7\u00e3o das oito fal\u00e1cias da computa\u00e7\u00e3o distribu\u00edda. S\u00e3o elas:<\/p>\n