Hora de eu voar… de renderizar

O ciclo do hype do Gartner , ilustrado abaixo, pode ser aplicado à maioria dos aspectos da tecnologia:

À 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 os pagers (ou bipes), que eram comuns antes que os telefones/dispositivos móveis atingissem o platô da produtividade.

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 anúncio recente me fez pensar se era hora de considerar outras opções.

Como tive uma experiência positiva com o Render 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:

• 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 modo de manutenção . Isso proibirá qualquer consumidor de acessar os aplicativos ou serviços.

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 projeto anterior meu.

Para o banco de dados, precisei converter de MySQL para PostgreSQL. Meu objetivo era usar o Heroku Migrator do Render para migrar facilmente o Heroku Postgres para o Render Postgres, mas primeiro eu precisava converter do MySQL para o PostgreSQL.

Inicialmente, comecei pelo caminho do pgloader , 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.

Em vez disso, optei por usar o NMIG para converter MySQL em PostgreSQL. Para obter mais informações, consulte a seção “ Destaques da conversão do banco de dados ” abaixo.

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 estas instruções 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.

Por fim, criei as variáveis de ambiente necessárias no Render Dashboard para o serviço Spring Boot RESTful API e o agente de mensagens RabbitMQ.

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 o GitLab CI/CD para implantar no Heroku no meu repositório de origem.

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 o NMIG , que é um utilitário de conversão de banco de dados baseado em Node.js.

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 pgAdmin para importar o backup para uma instância Postgres recém-criada no Heroku.

Com a instância Postgres em execução e os dados validados, criei um novo banco de dados Postgres no Render PaaS. Então tudo que eu tinha que fazer era emitir o seguinte comando:

 pg_restore --verbose --no-acl --no-owner -d postgres://username:[email protected]/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 ex-colega 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 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!