Под слоганом «айтишникам — от айтишников» эксперты из Украины, Беларуси, России, Великобритании и Германии поделились опытом и рассказали о новинках индустрии. Полезно было всем — дизайнерам, девелоперам, тестировщикам и менеджерам. И теперь делимся инсайтами с вами.
По мотивам докладов экспертов NIX продолжаем серию материал на самые актуальные темы. В новой статье PHP developer Александр Павленко объясняет, на каком этапе разработки стоит перейти на микросервисы и как это сделать с минимальными рисками.
Хочешь знать больше — смотри конференцию на YouTube-канале.
Привет! Я Александр Павленко, разработкой на PHP занимаюсь около четырех лет. Среди крупных проектов — Car Sales Platform + Inventory, Archive of Scientific Documents, Job Search Platform, Natural Disasters Alarm System.
Стоит только заговорить о монолите и микросервисах, как многие начинают холивар вокруг их сравнения. Я считаю, вместо поиска плюсов и минусов, лучше выяснить, какой подход больше всего отвечает бизнес-задачам приложения. Наша команда занималась проектом в сфере FinTech, и он изначально строился на монолите. Почему так сложилось и какие возможности мы увидели в микросервисах — расскажу подробнее.
Монолит напоминает мне кубик Рубика: если вытащить из него одну деталь, собрать новую форму или добавить другие компоненты, кубик уже не будет полноценно работать. Каждый элемент формирует единый функционал. Если какой-то части не хватает, она сломана или стоит не на месте — цветное поле кубика не сложится.
В условиях стартапа с монолитом удается быстрее запустить проект. Когда, условно через месяц, надо презентовать клиенту MVP, но ни конкретных требований, ни спецификаций по продукту нет, спасает только гибкость монолита. Во-вторых, на старте его легко и быстро масштабировать. Для команды тоже были очевидны преимущества. К разработке на монолите может присоединиться больше специалистов, в том числе новички. В изучении PHP они непременно начинают с монолита. Он прост и понятен в использовании.
Наш стартап стремительно развивался. Росло количество пользователей, клиентов, регулярно добавлялся различный функционал. Спустя время проявились недостатки монолита. То, что было критично для нас:
К счастью, мы заранее предвидели риски, поэтому переход на новую архитектуру не шокировал. Все прошло плавно и спокойно. Микросервисный подход решил несколько задач:
Но тут же вспылили недостатки. Во-первых, повысился порог вхождения в проект. Во-вторых, усложнилось поддержание, конфигурация и тестирование настроек. По сути это не является минусом. Главное, что у нас микросервисами закрыли самые важные вопросы.
Со временем заказчик понял, что хочет продавать продукт не только целиком, но и отдельными частями, тем самым упрощая жизнь пользователям. На тот момент у нас уже был различный функционал, из которого планировали выделить небольшие независимые компоненты. А из них — построить идентичные конструкции или создать новые бизнес-решения. Каждый микросервис обладает своей логикой и функциями, но этот пазл можно интегрировать в любую другую систему и самостоятельно развивать ее. Если один из компонентов перестал работать, не значит, что вся система обязательно рухнет. Возможно, отвалится то, что тесно связано с данным микросервисом. Но в том или ином виде система продолжит работать.
Микросервисы хороши и тем, что их можно развертывать и тестировать независимо друг от друга. Это упрощает жизнь команде как в процессе разработки, так и в дальнейшем развитии проекта.
Что микросервисы дали нашему проекту:
Появились нюансы, усложняющие поддержку безопасности транзакций. В случае с микросервисами мы имеем дело с децентрализацией данных. Также, прежде чем писать код, разработчикам надо помнить о возможной несогласованности.
Не обошлось без сложностей для новых членов команды. Им нужно больше времени, чтобы понять, как микросервисы между собой взаимодействуют и делают ли это вообще. Насколько глубоко начинающий разработчик должен в этом разбираться? Чем разнообразнее база знаний, тем специалист ценнее на рынке и может оперативно реагировать на изменения в проекте. Когда есть, с чем сравнивать, намного легче среди нескольких вариантов выбрать наиболее подходящий в текущий момент. Поэтому, как минимум, ознакомиться с этим архитектурным подходом я советую всем. Новичок может начать с более простых вещей — с монолита — но помнить, что когда-нибудь придется углубиться в микросервисы. Все-таки тренды индустрии никто не отменял.
Монолит словно здоровенный котел, в котором варится сразу много всего. С появлением новых ингредиентов мы пытались все структурировать. Но помешивая этот «суп», затрагивали другие ингредиенты, даже когда это не требовалось. Микросервисы помогли создать современную технологическую кухню и разделить зоны функциональности. Мы уже не только «варили», но и «запекали», «кипятили», где-то «жарили», а где-то только «подогревали». Познав тонкости этой «высокой кухни», в результате получили качественные продукты.
На самом деле, окончательного ответа нет. В тех или иных ситуациях бывает логичнее стартовать с монолита. Но в будущем система может достичь таких масштабов, что переход к микросервисам неизбежен. Из личного опыта я отметил пару сценариев, в которых стоит задуматься о переходе на микросервисы:
Иногда мы сталкиваемся с настойчивыми клиентами, которые отказываются от здравой идеи разработчиков. Вот вздумалось ему только эту технологию или архитектуру применять. Почему? Да потому что. «Слышал в интернете» или «Все так делают». Заказчик редко задумывается о подводных камнях, на которые могут наткнуться программисты. Если вы видите, что есть более эффективный подход, идея заказчика вызовет новые проблемы или вообще остановит развитие проекта, ваша задача — не бояться сказать клиенту, что он не прав. Объясните, почему лучше использовать ту или иную технологию или подход. Как показывает практика, когда вы можете аргументировать преимущества своей идеи и недостатки предложенного заказчиком решения, он спокойно примет вашу сторону. Проект — это его детище, его деньги, и прежде всего клиент заинтересован в эффективности и прибыльности продукта.
В нашем случае мы разработали много спецификаций, которые жили обособленно и полноценно не взаимодействовали друг с другом. А как только разбили их на независимые микросервисы, получили высокие показатели в перформансе и счастливого заказчика, который приумножил прибыль. Подробности можно узнать из моего доклада на NIXMultiConf.
OpenAI готовится запустить собственную поисковую систему на базе ChatGPT. Информацию об этом публикуют западные издания. Ожидается, что новый поисковик может…
Центр управления связью общего пользования (ЦМУ ССОП) Роскомнадзора рекомендовал компаниям из реестра провайдеров ограничить доступ поисковых ботов к информации на российских сайтах.…
Apple возобновила переговоры с OpenAI о возможности внедрения ИИ-технологий в iOS 18, на основе данной операционной системы будут работать новые…
Конкурсный управляющий российской «дочки» Google подготовил 23 иска к участникам рекламного рынка. Общая сумма исков составляет 16 млрд рублей –…
Google завершил обновление основного алгоритма March 2024 Core Update. Раскатка обновлений была завершена 19 апреля, но сообщил об этом поисковик…
У частных продавцов на Авито появилась возможность составлять текст объявлений с помощью нейросети. Новый функционал доступен в категории «Обувь, одежда,…