Hora de volar… de renderizar

El ciclo de exageración de Gartner , que se ilustra a continuación, se puede aplicar a la mayoría de los aspectos de la tecnología:

A medida que las nuevas innovaciones ingresan a sus respectivos ciclos, las expectativas finalmente se cumplen, lo que lleva a cierto nivel de adopción.

El objetivo de cada innovación es alcanzar la meseta de productividad donde los consumidores han determinado que la recompensa de adoptar la innovación supera con creces cualquier riesgo conocido.

Al mismo tiempo, hay un punto en el que la meseta de productividad comienza a disminuir, lo que lleva a un éxodo que se aleja de esa innovación. Un ejemplo simple serían los buscapersonas (o beepers), que eran comunes antes de que los teléfonos/dispositivos móviles alcanzaran la meseta de productividad.

Como tecnólogos, nos esforzamos por ofrecer funciones, marcos, productos o servicios que aumenten el nivel de productividad. Lo mismo ocurre con los que usamos.

Recientemente, sentí que mi plataforma de hospedaje actual comenzó a caer del nivel de productividad. De hecho, un anuncio reciente me hizo preguntarme si era hora de considerar otras opciones.

Dado que tuve una experiencia positiva con Render PaaS, quería ver con qué facilidad podía convertir una de mis aplicaciones Heroku, adoptar PostgreSQL y migrar a Render. Estoy describiendo ese viaje en esta serie de dos partes:

• Parte 1: Nos centraremos en migrar mis servicios backend (Spring Boot y ClearDB MySQL).
• Parte 2: Nos centraremos en portar y migrar mi cliente Angular frontend.

Por qué elegí renderizar

Si nunca antes ha oído hablar de Render, consulte algunas de mis publicaciones anteriores:

• Dedique cero tiempo a DevOps con Render PaaS

• La nube perfecta: AWS, GCP y Azure todo en uno

• Diseño de microservicios con propósito

• Lanza tu idea de inicio en un día

• Cómo utilicé Render para escalar mi aplicación de microservicios con facilidad

Lo que me parece emocionante de Render es que continúan escalando la pendiente de la iluminación mientras brindan activamente una solución sólida para los usuarios que reconocen la meseta de la productividad.

Como he señalado en mis artículos, Render ofrece una promesa de "Cero DevOps". Esto se alinea perfectamente con mis necesidades, ya que no tengo tiempo para concentrarme en las tareas de DevOps.

La plataforma Heroku tiene varias cosas que no me gustan mucho:

• Los reinicios diarios provocaron un tiempo de inactividad inesperado para uno de mis servicios.

• Postgres de nivel de entrada (todo lo que realmente necesito) en Heroku permite cuatro horas de tiempo de inactividad por mes.

• Los niveles de precios, desde la perspectiva del consumidor, no escalan bien.

Desde una perspectiva de precios, espero ver un ahorro de costos significativo después de migrar todas mis aplicaciones y servicios de Heroku a Render. Lo que es más sorprendente es que obtengo una mejor memoria y CPU por ese precio, con escalado lineal a medida que la huella de mi aplicación necesita crecer.

Conversión de un solo servicio

Como señalé anteriormente, esta es la primera parte de una serie de dos partes, y me centraré en el nivel de servicio en este artículo. El servicio que quiero convertir tiene los siguientes atributos:

• Servicio API RESTful Spring Boot

• Agente de mensajes Heroku CloudAMQP (RabbitMQ)

• Base de datos Heroku ClearDB (MySQL) (esquema único)

• Integración Okta

En el lado de Render PaaS, el nuevo diseño del servicio se verá así:

• Servicio web de procesamiento que aloja el servicio API RESTful de Spring Boot (a través de Docker)

• Prestar servicio privado que aloja RabbitMQ Message Broker (a través de Docker)

• Renderizar Postgres con la capacidad de que existan múltiples esquemas

• Integración Okta

A continuación se muestra una comparación lado a lado de los dos ecosistemas:

Mi plan de ataque de alto nivel para la conversión es el siguiente:

Prepara a Heroku para la conversión

Antes de comenzar, se recomienda poner todos los servicios existentes de Heroku en modo de mantenimiento . Esto prohibirá que los consumidores accedan a las aplicaciones o servicios.

Si bien el código fuente ya debe tener una copia de seguridad y almacenarse en un repositorio basado en git, es una buena idea asegurarse de que se haya creado correctamente una copia de seguridad de la base de datos.

Conversión de los servicios de Heroku

Desde la perspectiva de la conversión, tenía dos elementos para convertir: el servicio en sí y la base de datos ClearDB (MySQL).

La conversión de mi servicio Spring Boot RESTful no implicó mucho trabajo. De hecho, pude aprovechar el enfoque que usé para un proyecto mío anterior .

Para la base de datos, necesitaba convertir de MySQL a PostgreSQL. Mi objetivo era usar Heroku Migrator de Render para migrar fácilmente Heroku Postgres a Render Postgres, pero primero necesitaba convertir MySQL a PostgreSQL.

Inicialmente, comencé por la ruta pgloader , que parecía ser un enfoque común para la conversión de la base de datos. Sin embargo, el uso de mi MacBook Pro con chip M1 provocó algunos problemas inesperados.

En cambio, opté por usar NMIG para convertir MySQL a PostgreSQL. Para obtener más información, consulte la sección " Aspectos destacados de la conversión de la base de datos " a continuación.

Crear servicios en Render

Después de convertir la base de datos y el servicio Spring Boot RESTful que se ejecuta dentro de Docker, el siguiente paso fue crear un servicio web de procesamiento para el servicio API RESTful de Spring Boot.

Esto fue tan fácil como crear el servicio, darle un nombre y apuntar al repositorio apropiado para mi código en GitLab.

Como también necesitaba un servicio RabbitMQ, seguí estas instrucciones para crear un servicio privado RabbitMQ que se ejecuta en Render. Esto incluyó establecer una pequeña cantidad de almacenamiento en disco para conservar los mensajes que no se han procesado.

Finalmente, creé las variables de entorno necesarias en Render Dashboard para el servicio Spring Boot RESTful API y el agente de mensajes RabbitMQ.

Inicializar y validar los servicios

El siguiente paso fue iniciar mis servicios. Una vez que se estaban ejecutando y las API se validaron con mi colección de Postman, actualicé mi aplicación cliente para señalar la nueva ubicación del servicio Render.

Una vez que todo estuvo en funcionamiento, mi panel de procesamiento apareció como se muestra a continuación:

Próximos pasos

Todo lo que quedaba en este punto era eliminar las bases de datos que aún se ejecutan en Heroku y eliminar los servicios migrados del ecosistema de Heroku.

Cuando usaba Heroku, cada vez que fusionaba código en la rama maestra de mi repositorio de servicios, el código se implementaba automáticamente, siempre que usara GitLab CI/CD para implementar en Heroku en mi repositorio de origen.

Sin embargo, no es necesario agregar código al repositorio de archivos fuente con Render. Simplemente necesitaba especificar la rama Build & Deploy en el Render Dashboard para el servicio:

Me encanta la promesa Zero DevOps.

Aspectos destacados de la conversión de la base de datos

Siguiendo los pasos anteriores, la conversión de Heroku a Render fue fluida y exitosa. El mayor desafío para mí fue la conversión de datos. En un nivel alto, esto se redujo principalmente a una serie de comandos ejecutados desde la terminal de mi MacBook Pro.

Primero, inicié una instancia local de Postgres a través de Docker:

 docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres

Luego, creé una base de datos llamada "ejemplo" usando el siguiente comando (o pgAdmin):

 createdb example

Para convertir mi instancia ClearDB (MYSQL) que se ejecuta en Heroku a mi base de datos Postgres de ejemplo que se ejecuta localmente, utilicé NMIG , que es una utilidad de conversión de base de datos basada en Node.js.

Después de instalar NMIG, configuré el archivo config.json con la información y las credenciales del extremo de la base de datos, y luego ejecuté:

 /path/to/nmig$ npm start

A continuación, hice una copia de seguridad de los datos en un archivo con el siguiente comando:

 pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump

En lugar de pasar por la molestia de crear una URL firmada en AWS, simplemente usé el cliente pgAdmin para importar la copia de seguridad a una instancia de Postgres recién creada en Heroku.

Con la instancia de Postgres en ejecución y los datos validados, creé una nueva base de datos de Postgres en Render PaaS. Entonces todo lo que tenía que hacer era emitir el siguiente comando:

 pg_restore --verbose --no-acl --no-owner -d postgres://username:[email protected]/example example.dump

Lecciones aprendidas en el camino

Mirando hacia atrás en mi conversión de Heroku a Render, aquí hay algunas lecciones que aprendí en el camino:

• Tuve un problema menor con la base de datos de Postgres al actualizar el valor de fecha/hora para incluir el desplazamiento de horario de verano. Esto puede haber sido un problema con el diseño de mi base de datos original, pero quería transmitirlo. En mi caso, la columna afectada solo se usa para los valores de Fecha, que no cambió para mí.

• Incluí una columna de base de datos llamada END en una de mis tablas, lo que causó un problema cuando Postgres o Hibernate intentaron devolver una consulta nativa. El servicio vio el nombre de la columna END y lo inyectó como una palabra clave de SQL. Simplemente cambié el nombre de la columna para solucionar este problema, lo que debería haber sabido que no debía hacer en primer lugar.

• Con Render, necesitaba convertir el servicio RabbitMQ en un servicio privado porque la opción del servicio web no expone el puerto esperado. Sin embargo, con este enfoque, perdí la capacidad de acceder a la interfaz de administración de RabbitMQ, ya que los servicios privados no están expuestos externamente. Parece que Render planea abordar esta solicitud de función .

En general, estos obstáculos menores no fueron lo suficientemente importantes como para afectar mi decisión de migrar a Render.

Conclusión

El aspecto más importante de la meseta de productividad de Gartner es proporcionar productos, marcos o servicios que permitan a los consumidores prosperar y alcanzar sus objetivos. La meseta de la productividad no pretende ser llamativa o de moda, en un sentido metafórico.

Cuando compartí esta conclusión con Ed, desarrollador defensor de Render, su respuesta fue algo que quería compartir:

“Render es bastante declarado que no intenta estar 'a la moda'. Estamos tratando de ser poco sorprendentes y confiables”.

La respuesta de Ed resonó profundamente en mí y me recordó un momento en que mi antiguo colega me dijo que mi código le parecía "aburrido". Su comentario resultó ser el mayor cumplido que pude haber recibido. Puedes leer más aquí .

En cualquier aspecto de la tecnología, la decisión sobre qué proveedor seleccionar siempre debe coincidir con su posición tecnológica. Si no está seguro, el ciclo de promoción de Gartner es un excelente punto de referencia y puede comenzar con una suscripción a su servicio aquí .

Me he centrado en la siguiente declaración de misión, que creo que se puede aplicar a cualquier profesional de TI:

“Concentre su tiempo en ofrecer características/funcionalidades que amplíen el valor de su propiedad intelectual. Aproveche los marcos, productos y servicios para todo lo demás”.

-J. Vester

Cuando miro el ecosistema Render PaaS, veo una solución que se adhiere a mi declaración de misión mientras reside dentro de mi preferencia de ciclo de publicidad.

Lo que mejora las cosas es que espero ver un ahorro del 44 % en mis gastos personales, incluso más, ya que mis servicios deben escalar verticalmente.

Para aquellos que estén considerando soluciones de hospedaje, recomiendo agregar Render a la lista de proveedores para su revisión y análisis. Puede comenzar de forma gratuita siguiendo este enlace .

La segunda parte de esta serie será emocionante. Demostraré cómo dejar de pagar por mi cliente estático escrito en Angular y aprovechar el servicio gratuito de sitios estáticos de Render usando Vue o Svelte. ¿Qué marco elegiré… y por qué?

¡Que tengas un gran día!