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:    A que horas sai o seu voo? Pessoa nº 1:    Ainda este ano. Pessoa # 2:  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  é 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.   Previsor de gênero chinês   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 __   __ nas seguintes publicações: Render   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  e queria ver como isso funciona também.   Especificação do projeto  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  , consegui criar rapidamente um Blueprint para meus serviços Spring Boot executados por meio de contêineres do Docker:   aqui   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   , em um arquivo chamado   . Depois de confirmar e mesclar essa alteração, o serviço estava pronto para implantação na plataforma Render. birth-predictor render.yaml  No Render Dashboard, selecionei o   Opção   :  New | 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   , o processo de implantação foi iniciado:  Aplicar 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!

Super

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Design de microsserviço orientado a propósito

Design de microsserviço orientado a propósito

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Uma breve introdução à teoria do cérebro de Boltzmann

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Modelo Bitcoin UTXO, alimentando um ecossistema único

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Uma breve introdução à teoria do cérebro de Boltzmann

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

Modelo Bitcoin UTXO, alimentando um ecossistema único

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps