O   , ilustrado abaixo, pode ser aplicado à maioria dos aspectos da tecnologia:  ciclo do hype do Gartner À medida que novas inovações entram em seus respectivos ciclos, as expectativas acabam sendo realizadas – levando a algum nível de adoção.  O objetivo de toda inovação é atingir o patamar de produtividade em que os consumidores determinaram que a recompensa de adotar a inovação supera em muito quaisquer riscos conhecidos.  Ao mesmo tempo, chega um ponto em que o patamar de produtividade começa a diminuir, levando a um êxodo dessa inovação. Um exemplo simples seriam   (ou bipes), que eram comuns antes que os telefones/dispositivos móveis atingissem o platô da produtividade.  os pagers Como tecnólogos, nos esforçamos para fornecer recursos, estruturas, produtos ou serviços que aumentam o nível de produtividade. O mesmo vale para os que usamos.  Recentemente, senti que minha plataforma de hospedagem atual começou a cair do patamar de produtividade. Na verdade, um   me fez pensar se era hora de considerar outras opções. anúncio recente  Como tive uma experiência positiva com o   PaaS, queria ver com que facilidade poderia converter um dos meus aplicativos Heroku, adotar o PostgreSQL e migrar para o Render. Estou descrevendo essa jornada nesta série de duas partes: Render  Parte 1: Vamos nos concentrar na migração de meus serviços de back-end (Spring Boot e ClearDB MySQL).  Parte 2: Vamos nos concentrar em portar e migrar meu cliente Angular front-end.  Por que escolhi renderizar  Se você nunca ouviu falar de Render antes, confira algumas de minhas publicações anteriores:   Gaste tempo zero em DevOps com Render PaaS   A nuvem perfeita: AWS, GCP e Azure tudo em um   Design de microsserviço orientado a propósito   Lance sua ideia de startup em um dia   Como usei a renderização para dimensionar meu aplicativo de microsserviços com facilidade  O que eu acho interessante sobre o Render é que eles continuam a subir a encosta da iluminação enquanto fornecem ativamente uma solução sólida para os adotantes que reconhecem o platô da produtividade.  Como observei em meus artigos, o Render oferece uma promessa de “Zero DevOps”. Isso se alinha perfeitamente com minhas necessidades, pois não tenho tempo para me concentrar nas tarefas de DevOps.  A plataforma Heroku tem várias coisas que não gosto muito:  As reinicializações diárias levaram a um tempo de inatividade inesperado para um dos meus serviços.  Postgres de nível básico (tudo que eu realmente preciso) no Heroku permite quatro horas de inatividade por mês.  Os níveis de preços, do ponto de vista do consumidor, não escalam bem.  Do ponto de vista do preço, espero ver economias de custo significativas após migrar todos os meus aplicativos e serviços do Heroku para o Render. O que é mais surpreendente é que estou obtendo memória e CPU melhores por esse preço, com dimensionamento linear à medida que meu aplicativo precisa crescer.  Convertendo um único serviço  Como observei acima, esta é a primeira parte de uma série de duas partes e focarei na camada de serviço neste artigo. O serviço que desejo converter possui os seguintes atributos:  Serviço de API RESTful do Spring Boot  Agente de mensagens Heroku CloudAMQP (RabbitMQ)  Banco de dados Heroku ClearDB (MySQL) (esquema único)  Integração Okta  No lado do Render PaaS, o novo design de serviço ficará assim:  Serviço Web de renderização que hospeda o Spring Boot RESTful API Service (via Docker)  Render Private Service hosting RabbitMQ Message Broker (via Docker)  Renderizar Postgres com a capacidade de existirem vários esquemas  Integração Okta  Abaixo está uma comparação lado a lado dos dois ecossistemas:   Meu plano de ataque de alto nível para a conversão é o seguinte:   Preparar Heroku para conversão  Antes de começar, é recomendável colocar todos os serviços Heroku existentes no   . Isso proibirá qualquer consumidor de acessar os aplicativos ou serviços. modo de manutenção  Embora o código-fonte já deva ser copiado e armazenado em um repositório baseado em git, é uma boa ideia certificar-se de que um backup do banco de dados foi criado com sucesso.  Conversão de Serviços Heroku  Do ponto de vista da conversão, eu tinha dois itens para converter: o próprio serviço e o banco de dados ClearDB (MySQL).  A conversão do meu serviço Spring Boot RESTful não envolveu muito trabalho. Na verdade, consegui aproveitar a abordagem que usei em um   meu. projeto anterior  Para o banco de dados, precisei converter de MySQL para PostgreSQL. Meu objetivo era usar   do Render para migrar facilmente o Heroku Postgres para o Render Postgres, mas primeiro eu precisava converter do MySQL para o PostgreSQL. o Heroku Migrator  Inicialmente, comecei pelo caminho do   , que parecia ser uma abordagem comum para a conversão do banco de dados. No entanto, usar meu MacBook Pro com chip M1 levou a alguns problemas inesperados. pgloader  Em vez disso, optei por usar   para converter MySQL em PostgreSQL. Para obter mais informações, consulte a seção “   ” abaixo. o NMIG Destaques da conversão do banco de dados  Criar Serviços no Render  Após converter o banco de dados e o serviço Spring Boot RESTful rodando dentro do Docker, o próximo passo foi criar um Render Web Service para o serviço Spring Boot RESTful API.  Isso foi tão fácil quanto criar o serviço, dar um nome a ele e apontar para o repositório apropriado para meu código no GitLab.  Como eu também precisava de um serviço RabbitMQ, segui   para criar um RabbitMQ Private Service rodando no Render. Isso incluiu o estabelecimento de uma pequena quantidade de armazenamento em disco para manter as mensagens que não foram processadas.  estas instruções Por fim, criei as   necessárias no Render Dashboard para o serviço Spring Boot RESTful API e o agente de mensagens RabbitMQ. variáveis de ambiente  Inicializar e validar os serviços  O próximo passo foi iniciar meus serviços. Depois que eles estavam em execução e as APIs foram validadas usando minha coleção Postman, atualizei meu aplicativo cliente para apontar para o novo local do serviço Render.  Depois que tudo estava funcionando, meu Render Dashboard apareceu como mostrado abaixo:   Próximos passos  Tudo o que restava neste ponto era excluir os bancos de dados que ainda estavam em execução no Heroku e remover os serviços migrados do ecossistema Heroku.  Ao usar o Heroku, sempre que eu mesclava o código na ramificação principal do meu repositório de serviço, o código era implantado automaticamente, desde que eu usasse   no meu repositório de origem. o GitLab CI/CD para implantar no Heroku  No entanto, não há necessidade de adicionar código ao repositório de arquivos de origem com Render. Eu simplesmente precisava especificar a ramificação Build & Deploy no Render Dashboard para o serviço:  Eu amo a promessa Zero DevOps.  Destaques da conversão do banco de dados  Seguindo as etapas acima, a conversão de Heroku para Render foi tranquila e bem-sucedida. O maior desafio para mim foi a conversão de dados. Em alto nível, isso se resumia principalmente a uma série de comandos executados no terminal do meu MacBook Pro.  Primeiro, iniciei uma instância local do Postgres via Docker:   docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres  Em seguida, criei um banco de dados chamado “exemplo” usando o seguinte comando (ou pgAdmin):   createdb example  Para converter minha instância ClearDB (MYSQL) em execução no Heroku para meu exemplo de banco de dados Postgres em execução local, usei   , que é um utilitário de conversão de banco de dados baseado em Node.js. o NMIG  Depois de instalar o NMIG, configurei o arquivo config.json com informações e credenciais do endpoint do banco de dados e executei:   /path/to/nmig$ npm start  Em seguida, fiz backup dos dados em um arquivo usando o seguinte comando:   pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump  Em vez de criar uma URL assinada na AWS, usei apenas o cliente   para importar o backup para uma instância Postgres recém-criada no Heroku. pgAdmin  Com a instância Postgres em execução e os dados validados,   no Render PaaS. Então tudo que eu tinha que fazer era emitir o seguinte comando: criei um novo banco de dados Postgres   pg_restore --verbose --no-acl --no-owner -d postgres://username:password@hostname.zone-postgres.render.com/example example.dump  Lições aprendidas ao longo do caminho  Olhando para trás em minha conversão de Heroku para Render, aqui estão algumas lições que aprendi ao longo do caminho:  Tive um pequeno problema com o banco de dados Postgres atualizando o valor de data/hora para incluir o deslocamento do horário de verão. Isso pode ter sido um problema com meu design de banco de dados original, mas eu queria passar isso adiante. No meu caso, a coluna impactada é usada apenas para valores de data, o que não mudou para mim.  Incluí uma coluna de banco de dados chamada END em uma de minhas tabelas, o que causou um problema quando o Postgres ou o Hibernate tentaram retornar uma consulta nativa. O serviço viu o nome da coluna END e o injetou como uma palavra-chave SQL. Eu simplesmente renomeei a coluna para corrigir esse problema, o que eu deveria saber que não deveria fazer em primeiro lugar.  Com o Render, precisei tornar o serviço RabbitMQ um Private Service porque a opção Web Service não expõe a porta esperada. No entanto, com essa abordagem, perdi a capacidade de acessar a interface administrativa do RabbitMQ, pois os serviços privados não são expostos externamente. Parece que o Render planeja atender a essa   . solicitação de recurso  Em suma, esses pequenos obstáculos não foram significativos o suficiente para impactar minha decisão de migrar para o Render.  Conclusão  O aspecto mais importante do platô de produtividade do Gartner é fornecer produtos, estruturas ou serviços que permitam aos consumidores prosperar e atingir seus objetivos. O platô da produtividade não pretende ser chamativo ou elegante – em um sentido metafórico.  Quando compartilhei essa conclusão com Ed, um Developer Advocate da Render, sua resposta foi algo que eu queria compartilhar:   “O Render declaradamente não está tentando estar 'na moda'. Estamos tentando ser surpreendentes e confiáveis.”  A resposta de Ed ressoou profundamente em mim e me lembrou de uma época em que meu   me disse que meu código parecia “chato” para ele. Seu comentário acabou sendo o maior elogio que eu poderia ter recebido. Você pode ler mais   . ex-colega aqui  Em qualquer aspecto da tecnologia, a decisão sobre qual provedor selecionar deve sempre corresponder à sua posição tecnológica. Se você não tiver certeza, o ciclo de hype do Gartner é um ótimo ponto de referência e você pode começar com uma assinatura do serviço   . aqui  Concentrei-me na seguinte declaração de missão, que acredito poder 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  Quando olho para o ecossistema Render PaaS, vejo uma solução que adere à minha declaração de missão enquanto reside na minha preferência de ciclo de hype.  O que torna as coisas melhores é que espero ver uma economia de 44% em meus custos diretos pessoais - ainda mais porque meus serviços precisam escalar verticalmente.  Para aqueles que consideram soluções de hospedagem, recomendo adicionar Render à lista de provedores para revisão e análise. Você pode começar gratuitamente seguindo   . este link  A segunda parte desta série será emocionante. Vou demonstrar como deixar de pagar pelo meu cliente estático escrito em Angular e aproveitar o serviço gratuito de sites estáticos do Render usando Vue ou Svelte. Qual framework vou escolher… e por quê?  Tenha um ótimo dia!

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

Hora de eu voar… de renderizar

Hora de eu voar… de renderizar

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

De fóruns a feeds: como os algoritmos de mídia social moldam a interação digital

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

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

De fóruns a feeds: como os algoritmos de mídia social moldam a interação digital

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

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps