El   , que se ilustra a continuación, se puede aplicar a la mayoría de los aspectos de la tecnología:  ciclo de exageración de Gartner 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   (o beepers), que eran comunes antes de que los teléfonos/dispositivos móviles alcanzaran la meseta de productividad.  los buscapersonas 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   me hizo preguntarme si era hora de considerar otras opciones. anuncio reciente  Dado que tuve una experiencia positiva con   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: Render  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   . Esto prohibirá que los consumidores accedan a las aplicaciones o servicios. modo de mantenimiento  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   de Render para migrar fácilmente Heroku Postgres a Render Postgres, pero primero necesitaba convertir MySQL a PostgreSQL. Heroku Migrator  Inicialmente, comencé por la ruta   , 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. pgloader  En cambio, opté por usar   para convertir MySQL a PostgreSQL. Para obtener más información, consulte la sección "   " a continuación. NMIG Aspectos destacados de la conversión de la base de datos  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í   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.  estas instrucciones Finalmente, creé las   necesarias en Render Dashboard para el servicio Spring Boot RESTful API y el agente de mensajes RabbitMQ. variables de entorno  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   en mi repositorio de origen. GitLab CI/CD para implementar en Heroku  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é   , que es una utilidad de conversión de base de datos basada en Node.js. NMIG  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   para importar la copia de seguridad a una instancia de Postgres recién creada en Heroku. pgAdmin  Con la instancia de Postgres en ejecución y los datos validados,   en Render PaaS. Entonces todo lo que tenía que hacer era emitir el siguiente comando: creé una nueva base de datos de Postgres   pg_restore --verbose --no-acl --no-owner -d postgres://username:password@hostname.zone-postgres.render.com/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   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   . antiguo colega 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!

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 audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Make resilience your competitive advantage

Hora de volar… de renderizar

Hora de volar… de renderizar

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Telegram: el puente de Crypto Island hacia el continente

Una breve introducción a la teoría del cerebro de Boltzmann

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Telegram: el puente de Crypto Island hacia el continente

Una breve introducción a la teoría del cerebro de Boltzmann

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps