Когда я только начинал свою карьеру, я удивлялся большому количеству сленга. В те дни большинство новостей про технологии поступали в печатных еженедельных газетах, таких как InformationWeek и Network World. Помню, как частенько думал про себя: «Они используют одни и те же слова снова и снова».

Это же относилось и к людям, постоянно использующим сленг. В то время двумя моими любимыми модными словечками были отсылки к Интернету как к «всемирной паутине» и «информационной супермагистрали». Я про себя посмеивался, будет ли когда-нибудь супер-пупер-шоссе.

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

Представьте себе простой разговор:

Собеседник №1: Во сколько вылетает ваш рейс?
Собеседник №2: Позже в этом году.

В то время как Собеседник № 2 дает ответ, который фактически не является неверным, ответ на самом деле не дает никакой ценности для Собеседника № 1.

В своем стремлении перейти на микросервисы я столкнулся с аналогичными проблемами. Чаще всего я работал с клиентами и корпорациями, чей «микросервисный» дизайн приводил к единому моносервису. По сути, монолитное приложение было заменено действительно большим RESTful API.

Я решил, что в этой статье было бы интересно рассмотреть пример создания целенаправленного микросервисного дизайна… правильным способом.

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

Целеориентированный микросервис — это сервис, который может работать сам по себе и при необходимости включать в себя отдельное персистентное хранилище. Будучи ориентированным на цель, микросервис будет предоставлять определенный набор информации и станет системой записи для данных, управляемых в рамках связанных с ним API.

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

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

Давайте сосредоточимся на простом примере разработки микросервиса.

Создание микросервиса на основе Docker

Chinese Gender Predictor — табличная система, используемая для прогнозирования пола будущего ребенка. Это делается путем указания месяца зачатия и возраста матери на момент зачатия.

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

Ниже приведена иллюстрация таблицы Chinese Gender Predictor:

Например, 18-летняя мать, зачавшая ребенка в январе, родит ребенка женского пола.

Для данной публикации мы создадим микросервис, который возвращает прогноз пола на основе тех же критериев. Ответ с результатом для приведенного выше примера будет выглядеть так, как показано ниже:

{
    "month": 1,
    "age": 18,
    "gender": "female",
    "errorMessage": null
}

Микросервис будет использовать Java и Spring Boot, а также многоэтапный Dockerfile для сборки сервиса и создания образа Docker, в котором могут размещаться API-интерфейсы предикторов рождения.

Код сервиса располагается на GitLab по адресу: https://gitlab.com/johnjvester/birth-predictor

Создание воспроизводимого шаблона с использованием Render Blueprints

Я писал о платформе __Render__ в следующих публикациях:

• Как не тратить время на DevOps? Ответ: Render PaaS

• Идеальное облако: AWS, GCP и Azure «все в одном»

Для своих личных серверов, работающих на Render, я использовал язык программирования Go, статические сайты и Postgres. На этот раз я написал сервис на Java/Spring Boot. Хотя встроенной поддержки Java еще не существует, платформа Render включает поддержку всего, что работает в контейнере Docker.

Поскольку сервис прогнозирования рождения включает в себя многоэтапный Dockerfile, я хотел посмотреть, насколько просто развернуть сервис на основе Docker на платформе Render. Однако я заметил спецификацию Blueprint и захотел посмотреть, как она работает.

Что такое Blueprint?

Blueprint — это имплементация Infrastructure as Code от Render. IaC — это то, что я объединяю в более крупную концепцию под названием «* как код». Организации, которым необходимо управлять развертыванием нескольких сервисов или которые владеют сервисами, требующими множества параметров, могут определить свою Render инфраструктуру (сервисы, базы данных и группы среды) в виде кода в файле render.yaml.

Использование Render Blueprint

Опираясь на приведенный здесь пример Blueprint, я смог быстро создать Blueprint для своих сервисов Spring Boot, работающих через контейнеры Docker:

services:
  - type: web
    name: restful-api-spring-boot
    env: docker
    region: ohio # optional (defaults to oregon)
    plan: free # optional (defaults to starter)
    branch: master # optional (uses repo default)
    numInstances: 1 # optional (defaults to 1)
    healthCheckPath: /actuator/health
    envVars:
      - key: SERVER_PORT
        value: 443

Далее я кастомизировал данные YAML для сервиса прогнозирования рождения, чтобы обновить свойство имени и добавить свойство repo, как указано ниже:

services:
  - type: web
    name: birth-predictor
    env: docker
    repo: https://gitlab.com/johnjvester/birth-predictor
    region: ohio # optional (defaults to oregon)
    plan: free # optional (defaults to starter)
    branch: master # optional (uses repo default)
    numInstances: 1 # optional (defaults to 1)
    healthCheckPath: /actuator/health
    envVars:
      - key: SERVER_PORT
        value: 443

Эта информация была сохранена в корне репозитория birth-predictor в файле с именем render.yaml. После коммита данного изменения сервис был готов к развертыванию на платформе Render.

На панели Render Dashboard я выбрал theNew | Blueprint option:

Затем я выбрал репозиторий birth-predictor, который я подключил к своей учетной записи GitLab, используя вот эти инструкции.

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

После нажатия на кнопку «Применить» начинается процесс развертывания:

Сервис без проблем развернулся за несколько минут:

Предсказатель в действии

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

curl --location --request POST 'https://birth-predictor.onrender.com/predict' \
--header 'Content-Type: application/json' \
--data-raw '{
    "conceptionMonth" : 11,
    "conceptionAge" : 43
}'

Полученное тело ответа выглядит следующим образом:

{
    "month": 11,
    "age": 43,
    "gender": "male",
    "errorMessage": null
}

Эта информация совпадает с месяцем зачатия и возрастом моей жены на момент зачатия нашего сына (Финни). Он родился в августе 2017 года.

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

Заключение

С 2021 года я стараюсь жить в соответствии со следующей концепцией, которая, как мне кажется, вполне применима к любому ИТ-специалисту:

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

- Дж. Вестер

Спецификация Blueprints от Render соответствует этой концепции, позволяя группам разработки и администрирования сосредоточиться на достижении поставленных целей и задач, не беспокоясь ни о чем, связанном с DevOps.

Когда сервис, компонент или приложение готовы, командам нужно просто включить файл render.yaml в корень своего репозитория, а затем создать новый сервис на платформе Render с помощью опции Blueprint. В дальнейшем любые обновления в подключенном репозитории будут автоматически развертываться через несколько минут после внесения кода в нужную ветку.

Платформа Render основана на подходе Zero DevOps, что выражено в происхождении концепции Blueprint. Разработчики фич и сервисов хотят — и должны — сосредоточиться на поставке обновлений и фич, которые представляют наибольшую ценность для стейкхолдеров. Render действительно понимает эту реальность.

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

Если вас интересует исходный код этой статьи, вы можете найти его на GitLab по адресу: https://gitlab.com/johnjvester/предиктор рождения

Приглашаем всех желающих на открытое занятие, на котором поговорим про различные паттерны аутентификации и авторизации. Также рассмотрим сессионную аутентификацию на основе кук и на основе токенов (jwt), работу identity провайдеров. Регистрируйтесь по ссылке.