Пора мне летать… Визуализировать

Цикл ажиотажа Gartner, показанный ниже, можно применить к большинству аспектов технологии:

По мере того, как новые инновации входят в соответствующие циклы, ожидания в конечном итоге реализуются, что приводит к определенному уровню внедрения.

Целью каждой инновации является достижение уровня продуктивности, при котором потребители считают, что выгода от внедрения инновации намного перевешивает любые известные риски.

В то же время есть точка, где плато производительности начинает снижаться, что приводит к оттоку от этой инновации. Одним из простых примеров могут быть пейджеры (или биперы), которые были широко распространены до того, как мобильные телефоны/устройства достигли плато производительности.< /p>

Как технологи, мы стремимся предоставлять функции, платформы, продукты или услуги, которые повышают продуктивность. То же самое относится и к тем, которые мы используем.

Недавно я почувствовал, что моя текущая хостинговая платформа начала падать с плато производительности. Фактически, недавнее объявление заставило меня задуматься, не пора ли рассмотреть другие варианты.

Поскольку у меня был положительный опыт использования Render PaaS, я хотел проверить, насколько легко я могу преобразовать одно из моих приложений Heroku, внедрить PostgreSQL и перейти на рендер. Я описываю это путешествие в этой серии из двух частей:

* Часть 1. Мы сосредоточимся на переносе моих серверных служб (Spring Boot и ClearDB MySQL). * Часть 2. Мы сосредоточимся на портировании и переносе моего внешнего клиента Angular.

Почему я выбрал рендеринг

Если вы никогда раньше не слышали о Render, ознакомьтесь с некоторыми из моих предыдущих публикаций:

* Нулевые затраты времени на DevOps с помощью Render PaaS

* Идеальное облако: AWS, GCP и Azure "все в одном"< /а>

* Целевая разработка микросервисов

* Запустите идею стартапа за день

* Как я использовал рендеринг для легкого масштабирования моего приложения с микросервисами

Что я нахожу захватывающим в Render, так это то, что они продолжают подниматься по склону просвещения, активно предлагая надежное решение для пользователей, признающих плато производительности.

Как я уже отмечал в своих статьях, Render обещает «Нулевой DevOps». Это идеально соответствует моим потребностям, поскольку у меня нет времени, чтобы сосредоточиться на задачах DevOps.

На платформе Heroku есть несколько вещей, которые мне не очень нравятся:

* Ежедневные перезапуски приводили к неожиданному простою одной из моих служб.

* Начальный уровень (все, что мне действительно нужно) Postgres на Heroku допускает четыре часа простоя в месяц.

*Уровни цен с точки зрения потребителя плохо масштабируются.

С точки зрения ценообразования я ожидаю значительной экономии средств после переноса всех моих приложений и сервисов с Heroku на Render. Что еще более удивительно, так это то, что я получаю лучшую память и ЦП по этой цене с линейным масштабированием по мере необходимости роста моего приложения.

Преобразование одной службы

Как я уже отмечал выше, это первая часть из двух частей, и в этой статье я сосредоточусь на уровне служб. Служба, которую я хочу преобразовать, имеет следующие атрибуты:

* Служба Spring Boot RESTful API

* Брокер сообщений Heroku CloudAMQP (RabbitMQ)

* База данных Heroku ClearDB (MySQL) (одна схема)

* Интеграция Окта

Со стороны Render PaaS новый дизайн сервиса будет выглядеть следующим образом:

* Визуализация веб-службы, на которой размещена служба Spring Boot RESTful API (через Docker)

* Render Private Service, размещающий брокер сообщений RabbitMQ (через Docker)

* Рендеринг Postgres с возможностью существования нескольких схем

* Интеграция Окта

Ниже представлено параллельное сравнение двух экосистем:

Мой высокоуровневый план действий по конверсии выглядит следующим образом:

Подготовить Heroku к конверсии

Перед началом работы рекомендуется перевести все существующие службы Heroku в режим обслуживания. Это запретит любым потребителям доступ к приложениям или службам.

Хотя резервная копия исходного кода уже должна быть зарезервирована и сохранена в репозитории на основе git, рекомендуется убедиться, что резервная копия базы данных была успешно создана.

Конверсия сервисов Heroku

С точки зрения преобразования мне нужно было преобразовать два элемента: саму службу и базу данных ClearDB (MySQL).

Преобразование моего сервиса Spring Boot RESTful не потребовало много работы. На самом деле, я смог использовать подход, который использовал для моего предыдущего проекта.

Для базы данных мне нужно было преобразовать MySQL в PostgreSQL. Моя цель состояла в том, чтобы использовать Render's Heroku Migrator, чтобы легко перенести Heroku Postgres на Render Postgres, но мне нужно было преобразовать MySQL сначала в PostgreSQL.

Сначала я пошел по пути pgloader, который мне показался обычным подходом к преобразованию базы данных. Однако использование моего MacBook Pro с чипом M1 привело к неожиданным проблемам.

Вместо этого я решил использовать NMIG для преобразования MySQL в PostgreSQL. Дополнительные сведения см. в разделе «Основные моменты преобразования базы данных». ниже.

Создание сервисов в рендеринге

После преобразования базы данных и службы Spring Boot RESTful, работающей внутри Docker, следующим шагом было создание веб-службы рендеринга для службы Spring Boot RESTful API.

Это было так же просто, как создать сервис, дать ему имя и указать соответствующий репозиторий для моего кода в GitLab.

Поскольку мне также нужна была служба RabbitMQ, я следовал этим инструкциям, чтобы создать частную службу RabbitMQ, работающую на Render. Это включало установку небольшого объема дискового хранилища для хранения необработанных сообщений.

Наконец, я создал необходимые переменные среды на панели Render Dashboard как для службы Spring Boot RESTful API, так и для брокер сообщений RabbitMQ.

Инициализация и проверка служб

Следующим шагом был запуск моих сервисов. После того, как они были запущены и API были проверены с помощью моей коллекции Postman, я обновил свое клиентское приложение, чтобы оно указывало на новое расположение службы рендеринга.

После того, как все было настроено и запущено, моя панель рендеринга выглядела так, как показано ниже:

Дальнейшие шаги

На этом этапе осталось только удалить базы данных, все еще работающие в Heroku, и удалить перенесенные службы из экосистемы Heroku.

При использовании Heroku каждый раз, когда я сливал код в основную ветку моего сервисного репозитория, код автоматически развертывался, при условии, что я использовал GitLab CI/CD для развертывания на Heroku в моем исходном репозитории.

Однако нет необходимости добавлять код в репозиторий исходных файлов с помощью Render. Мне просто нужно было указать Build & Разверните ветвь на панели визуализации для службы:

Мне нравится обещание Zero DevOps.

Основные моменты преобразования базы данных

Следуя описанным выше шагам, переход с Heroku на Render прошел гладко и успешно. Самой большой проблемой для меня было преобразование данных. На высоком уровне это в основном сводилось к серии команд, выполняемых с терминала моего MacBook Pro.

Сначала я запустил локальный экземпляр Postgres через Docker:

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

Затем я создал базу данных под названием «example» с помощью следующей команды (или pgAdmin):

createdb example

Для преобразования моего экземпляра ClearDB (MYSQL), работающего на Heroku, в мой пример базы данных Postgres, работающей локально, я использовал NMIG, который представляет собой Node. Утилита преобразования базы данных на основе js.

После установки NMIG я настроил файл config.json с информацией о конечной точке базы данных и учетными данными, а затем запустил:

/path/to/nmig$ npm start

Затем я сделал резервную копию данных в файл с помощью следующей команды:

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

Вместо того, чтобы мучиться с созданием подписанного URL-адреса в AWS, я просто использовал клиент pgAdmin для импорта резервной копии во вновь созданный сервер Postgres. экземпляр на Heroku.

Запустив экземпляр Postgres и проверив данные, я создал новую базу данных Postgres в Render PaaS. Затем все, что мне нужно было сделать, это ввести следующую команду:

pg_restore --verbose  --no-acl --no-owner 
-d postgres://username:password@hostname.zone-postgres.render.com/example example.dump

Уроки, извлеченные на этом пути

Оглядываясь назад на свой переход с Heroku на Render, вот несколько уроков, которые я усвоил на этом пути:

* У меня была небольшая проблема с базой данных Postgres, которая обновляла значение даты/времени, чтобы включить смещение летнего времени. Возможно, это была проблема с моим первоначальным дизайном базы данных, но я хотел передать это. В моем случае затронутый столбец используется только для значений даты, которые для меня не изменились.

* Я включил столбец базы данных с именем END в одну из своих таблиц, что вызвало проблему, когда Postgres или Hibernate пытались вернуть собственный запрос. Служба увидела имя столбца END и внедрила его как ключевое слово SQL. Я просто переименовал столбец, чтобы решить эту проблему, чего я должен был знать с самого начала.

* С Render мне нужно было сделать службу RabbitMQ частной службой, потому что параметр веб-службы не предоставляет ожидаемый порт. Однако при таком подходе я потерял возможность доступа к административному интерфейсу RabbitMQ, так как Private Services не выставляются извне. Похоже, Render планирует удовлетворить этот запрос функции.

В общем, эти мелкие препятствия не были настолько значительными, чтобы повлиять на мое решение перейти на Render.

Заключение

Самым важным аспектом плато производительности Gartner является предоставление продуктов, платформ или услуг, которые позволяют потребителям процветать и достигать своих целей. Плато продуктивности не должно быть роскошным или модным  — в переносном смысле.

Когда я поделился этим выводом с Эдом, защитником разработчиков в Render, мне захотелось поделиться его ответом:

Ответ Эда произвел на меня глубокое впечатление и напомнил мне о времени, когда мой бывший коллега сказал мне, что мой код показался ему «скучным». Его комментарий оказался самым большим комплиментом, который я мог получить. Вы можете прочитать больше здесь.

В любом аспекте технологий решение о выборе поставщика всегда должно соответствовать вашей позиции в области технологий. Если вы не уверены, цикл ажиотажа Gartner — отличный ориентир, и вы можете начать с подписки на их сервис здесь.

Я сосредоточился на следующем заявлении о миссии, которое, как мне кажется, применимо к любому ИТ-специалисту:

"Сосредоточьте свое время на предоставлении функций/функций, повышающих ценность вашей интеллектуальной собственности. Используйте фреймворки, продукты и услуги для всего остального».

– Дж. Вестер

Когда я смотрю на экосистему Render PaaS, я вижу решение, которое соответствует моему заявлению о миссии, но в то же время соответствует моим предпочтениям в цикле ажиотажа.

Что делает ситуацию лучше, так это то, что я полностью рассчитываю на 44%-ную экономию моих личных наличных расходов   — даже больше, поскольку мои услуги должны масштабироваться по вертикали.

Для тех, кто рассматривает решения для хостинга, я рекомендую добавить Render в список поставщиков для обзора и анализа. Вы можете начать работу бесплатно, перейдя по этой ссылке.

Вторая часть этой серии будет захватывающей. Я покажу, как отказаться от оплаты моего статического клиента, написанного на Angular, и воспользоваться преимуществами бесплатного сервиса статических сайтов Render с использованием Vue или Svelte. Какой фреймворк я выберу… и почему?

Хорошего дня!