Design de microsserviço orientado a propósito

Chavões não são algo que eu esperava quando comecei minha carreira. Naquela época, a maioria das notícias sobre tecnologia chegava em publicações semanais em papel, como InformationWeek e Network World. Lembro-me de pensar comigo mesmo: “Cara, eles estão usando essas mesmas palavras repetidamente a cada semana”.

Isso se traduziu em pessoas usando chavões... o tempo todo. Naquela época, minhas duas palavras-chave favoritas eram referências à internet como a “world wide web” e a “superestrada da informação”. Sempre me perguntei se haveria uma super-duper-rodovia em algum momento.

No entanto, recentemente, notei que as palavras-chave são usadas como espaços reservados onde não fazem muito sentido. Termos como microsserviços, arquitetura orientada a eventos, IA e ML são usados em contextos que me levam a concluir que muitas pessoas não entendem bem esses termos. Eu também não esperava isso…

Imagine esta conversa simples relacionada a uma pergunta mal compreendida:

Pessoa nº 1: A que horas sai o seu voo?

Pessoa # 2: Ainda este ano.

Embora a pessoa nº 2 forneça uma resposta que não está incorreta, a resposta realmente não fornece nenhum valor à pergunta da pessoa nº 1.

Nessa mesma linha, a busca pela migração para microsserviços tem enfrentado desafios semelhantes. Na maioria das vezes, trabalhei com clientes e corporações cujo design de “microsserviço” resultou em um único monosserviço. Basicamente, um aplicativo monolítico foi substituído por uma API RESTful realmente grande.

Para esta publicação, achei que seria divertido mostrar um exemplo de criação de um design de microsserviço orientado a um propósito... da maneira certa.

O design de microsserviço orientado a propósitos

Um microsserviço orientado a propósito é um serviço que pode ser independente e pode incluir um armazenamento de persistência dedicado quando necessário. Por ser direcionado a um propósito, o microsserviço fornecerá um conjunto focado de informações e será o sistema de registro dos dados regidos pelas APIs associadas.

Ao adotar a abordagem de microsserviço orientada por finalidade, os usuários podem adicionar nós adicionais e reduzir os nós existentes para atender às necessidades da API naquele momento.

Por exemplo, um microsserviço direcionado a um propósito focado em um aspecto do imposto de renda pode ter o maior uso durante a primeira parte do ano e exigir menos instâncias em execução no segundo semestre.

Vamos nos concentrar na criação de um design de microsserviço orientado a propósito usando um exemplo muito simples.

Criando um microsserviço baseado em Docker

o Previsor de gênero chinês é um sistema de grade usado para prever o sexo de um bebê no nascimento. Isso é feito fornecendo o mês da concepção e a idade atual da mãe no momento da concepção.

Há rumores de que a família imperial da Dinastia Qing dependia dessa mesma grade para a seleção de gênero dos filhos, que eram favorecidos pelo trabalho e dinheiro que poderiam fornecer para suas famílias, bem como para continuar a linhagem familiar.

Abaixo está uma ilustração da grade do Previsor de Gênero Chinês:

Por exemplo, uma mãe de 18 anos que concebeu um filho em janeiro produziria um bebê do sexo feminino.

Para esta publicação, criaremos um microsserviço orientado a propósito que retorna uma previsão de gênero com base nos mesmos critérios. A carga útil resultante para o exemplo acima apareceria como mostrado abaixo:

 { "month": 1, "age": 18, "gender": "female", "errorMessage": null }

O microsserviço utilizará Java e Spring Boot e empregará um Dockerfile de vários estágios para compilar o serviço e construir uma imagem Docker que pode hospedar as APIs de previsão de nascimento.

O código do serviço pode ser encontrado no GitLab no seguinte endereço:

https://gitlab.com/johnjvester/birth-predictor

Criando um padrão reproduzível usando esquemas de renderização

Escrevi sobre a plataforma __ Render __ nas seguintes publicações:

• Gaste tempo zero em DevOps com Render PaaS
• A nuvem perfeita: AWS, GCP e Azure tudo em um

Para minhas instâncias pessoais em execução no Render, usei a linguagem de programação Go, sites estáticos e uma instância do Postgres. Desta vez, escrevi o serviço em Java/Spring Boot. Embora o suporte nativo para Java ainda não exista, a plataforma Render inclui suporte para qualquer coisa executada em um contêiner Docker.

Como o serviço de previsão de nascimento inclui um Dockerfile de vários estágios, eu queria ver como é fácil implantar um serviço baseado em Docker na plataforma Render. No entanto, notei o Especificação do projeto e queria ver como isso funciona também.

O que é um Blueprint?

Um Blueprint é a implementação de Infraestrutura como Código (IaC) do Render. IaC também é algo que agrupo em um conceito maior chamado “* como código”. As organizações que precisam gerenciar uma implantação de vários serviços ou que possuem serviços que exigem muitas opções podem definir sua infraestrutura de renderização (serviços, bancos de dados e grupos de ambiente) como código em um arquivo render.yaml.

Usando o Render Blueprint

Com base no exemplo do Blueprint fornecido aqui , consegui criar rapidamente um Blueprint para meus serviços Spring Boot executados por meio de contêineres do Docker:

 services: - type: web name: restful-api-spring-boot env: docker region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443

A partir daí, personalizei os dados YAML para o serviço de previsão de nascimento para atualizar a propriedade name e adicionar uma propriedade repo, conforme observado abaixo:

 services: - type: web name: birth-predictor env: docker repo: https://gitlab.com/johnjvester/birth-predictor region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443

Essas informações foram armazenadas na raiz do repositório birth-predictor , em um arquivo chamado render.yaml . Depois de confirmar e mesclar essa alteração, o serviço estava pronto para implantação na plataforma Render.

No Render Dashboard, selecionei o New | Opção de planta :

Em seguida, selecionei o repositório do preditor de nascimento, que conectei à minha conta do GitLab usando as instruções encontradas aqui .

Como estava usando um Blueprint, tudo o que precisava fazer era fornecer um nome de grupo de serviço para meu novo serviço:

Depois de pressionar o botão Aplicar , o processo de implantação foi iniciado:

Alguns minutos depois, o serviço foi implantado sem problemas:

Previsor de Nascimento em Ação

Com o serviço de previsão de nascimento em execução, posso emitir o seguinte comando cURL para obter uma nova previsão:

 curl --location --request POST 'https://birth-predictor.onrender.com/predict' \ --header 'Content-Type: application/json' \ --data-raw '{ "conceptionMonth" : 11, "conceptionAge" : 43 }'

A carga de resposta resultante se parece com esta:

 { "month": 11, "age": 43, "gender": "male", "errorMessage": null }

Essa informação coincide com o mês da concepção e a idade de minha esposa na época em que nosso filho (Finny) foi concebido. Em agosto de 2017, ele chegou!

Assim como fizeram durante a Dinastia Qing, pudemos confiar no Previsor de Gênero Chinês para prever com sucesso o sexo de nosso filho.

Conclusão

Desde 2021, tento viver de acordo com a seguinte declaração de missão, que sinto que pode ser aplicada a qualquer profissional de TI:

“Concentre seu tempo em fornecer recursos/funcionalidades que ampliem o valor de sua propriedade intelectual. Aproveite estruturas, produtos e serviços para todo o resto.”

-J. Vester See More

A especificação Blueprints da Render adere à minha declaração de missão, permitindo que as equipes de recursos e serviços se concentrem na entrega de metas e objetivos estabelecidos, sem se preocupar com nada relacionado ao DevOps.

Depois que o serviço, componente ou aplicativo estiver pronto, as equipes precisam apenas incluir o arquivo render.yaml na raiz do repositório e criar um novo serviço na plataforma Render usando a opção Blueprint. No futuro, todas as atualizações no repositório conectado serão implantadas automaticamente minutos após a confirmação do código na ramificação indicada.

A plataforma Render vive de uma mentalidade Zero DevOps, que se evidencia na origem do conceito Blueprint. Os desenvolvedores de recursos e serviços desejam - e devem - se concentrar em fornecer atualizações e funcionalidades que forneçam o máximo de valor aos seus interessados. Render realmente entende essa realidade.

Tenho certeza de que as buzzwords sempre farão parte do universo da tecnologia. No entanto, entender e adotar a verdadeira intenção por trás dessas palavras-chave é algo que espero que os tecnólogos busquem.

Se você estiver interessado no código-fonte desta publicação, poderá encontrá-lo no GitLab no seguinte endereço:

https://gitlab.com/johnjvester/birth-predictor

Tenha um ótimo dia!