Когда я только начинал свою карьеру, я удивлялся большому количеству сленга. В те дни большинство новостей про технологии поступали в печатных еженедельных газетах, таких как 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__ в следующих публикациях:
Для своих личных серверов, работающих на 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 провайдеров. Регистрируйтесь по ссылке.
ссылка на оригинал статьи https://habr.com/ru/company/otus/blog/687166/
Добавить комментарий