Как собрать в прямом эфире 17 000 зрителей? Значит, рецепт такой. Берем 15 актуальных IT-направлений, зовем зарубежных спикеров, дарим подарки за активность в чате, и вуа-ля — крупнейший в Украине и восточной Европе онлайн-ивент готов. Именно так прошла ежегодная мультитул конференция NIXMultiConf.
Под слоганом «айтишникам — от айтишников» эксперты из Украины, Беларуси, России, Великобритании и Германии поделились опытом и рассказали о новинках индустрии. Полезно было всем — дизайнерам, девелоперам, тестировщикам и менеджерам. И теперь делимся инсайтами с вами.
По мотивам докладов экспертов NIX продолжаем серию материал на самые актуальные темы. В новой статье PHP developer Александр Павленко объясняет, на каком этапе разработки стоит перейти на микросервисы и как это сделать с минимальными рисками.
Хочешь знать больше — смотри конференцию на YouTube-канале.
Привет! Я Александр Павленко, разработкой на PHP занимаюсь около четырех лет. Среди крупных проектов — Car Sales Platform + Inventory, Archive of Scientific Documents, Job Search Platform, Natural Disasters Alarm System.
Стоит только заговорить о монолите и микросервисах, как многие начинают холивар вокруг их сравнения. Я считаю, вместо поиска плюсов и минусов, лучше выяснить, какой подход больше всего отвечает бизнес-задачам приложения. Наша команда занималась проектом в сфере FinTech, и он изначально строился на монолите. Почему так сложилось и какие возможности мы увидели в микросервисах — расскажу подробнее.
Монолит напоминает мне кубик Рубика: если вытащить из него одну деталь, собрать новую форму или добавить другие компоненты, кубик уже не будет полноценно работать. Каждый элемент формирует единый функционал. Если какой-то части не хватает, она сломана или стоит не на месте — цветное поле кубика не сложится.
В условиях стартапа с монолитом удается быстрее запустить проект. Когда, условно через месяц, надо презентовать клиенту MVP, но ни конкретных требований, ни спецификаций по продукту нет, спасает только гибкость монолита. Во-вторых, на старте его легко и быстро масштабировать. Для команды тоже были очевидны преимущества. К разработке на монолите может присоединиться больше специалистов, в том числе новички. В изучении PHP они непременно начинают с монолита. Он прост и понятен в использовании.
Наш стартап стремительно развивался. Росло количество пользователей, клиентов, регулярно добавлялся различный функционал. Спустя время проявились недостатки монолита. То, что было критично для нас:
К счастью, мы заранее предвидели риски, поэтому переход на новую архитектуру не шокировал. Все прошло плавно и спокойно. Микросервисный подход решил несколько задач:
Но тут же вспылили недостатки. Во-первых, повысился порог вхождения в проект. Во-вторых, усложнилось поддержание, конфигурация и тестирование настроек. По сути это не является минусом. Главное, что у нас микросервисами закрыли самые важные вопросы.
Со временем заказчик понял, что хочет продавать продукт не только целиком, но и отдельными частями, тем самым упрощая жизнь пользователям. На тот момент у нас уже был различный функционал, из которого планировали выделить небольшие независимые компоненты. А из них — построить идентичные конструкции или создать новые бизнес-решения. Каждый микросервис обладает своей логикой и функциями, но этот пазл можно интегрировать в любую другую систему и самостоятельно развивать ее. Если один из компонентов перестал работать, не значит, что вся система обязательно рухнет. Возможно, отвалится то, что тесно связано с данным микросервисом. Но в том или ином виде система продолжит работать.
Микросервисы хороши и тем, что их можно развертывать и тестировать независимо друг от друга. Это упрощает жизнь команде как в процессе разработки, так и в дальнейшем развитии проекта.
Что микросервисы дали нашему проекту:
Появились нюансы, усложняющие поддержку безопасности транзакций. В случае с микросервисами мы имеем дело с децентрализацией данных. Также, прежде чем писать код, разработчикам надо помнить о возможной несогласованности.
Не обошлось без сложностей для новых членов команды. Им нужно больше времени, чтобы понять, как микросервисы между собой взаимодействуют и делают ли это вообще. Насколько глубоко начинающий разработчик должен в этом разбираться? Чем разнообразнее база знаний, тем специалист ценнее на рынке и может оперативно реагировать на изменения в проекте. Когда есть, с чем сравнивать, намного легче среди нескольких вариантов выбрать наиболее подходящий в текущий момент. Поэтому, как минимум, ознакомиться с этим архитектурным подходом я советую всем. Новичок может начать с более простых вещей — с монолита — но помнить, что когда-нибудь придется углубиться в микросервисы. Все-таки тренды индустрии никто не отменял.
Монолит словно здоровенный котел, в котором варится сразу много всего. С появлением новых ингредиентов мы пытались все структурировать. Но помешивая этот «суп», затрагивали другие ингредиенты, даже когда это не требовалось. Микросервисы помогли создать современную технологическую кухню и разделить зоны функциональности. Мы уже не только «варили», но и «запекали», «кипятили», где-то «жарили», а где-то только «подогревали». Познав тонкости этой «высокой кухни», в результате получили качественные продукты.
На самом деле, окончательного ответа нет. В тех или иных ситуациях бывает логичнее стартовать с монолита. Но в будущем система может достичь таких масштабов, что переход к микросервисам неизбежен. Из личного опыта я отметил пару сценариев, в которых стоит задуматься о переходе на микросервисы:
Иногда мы сталкиваемся с настойчивыми клиентами, которые отказываются от здравой идеи разработчиков. Вот вздумалось ему только эту технологию или архитектуру применять. Почему? Да потому что. «Слышал в интернете» или «Все так делают». Заказчик редко задумывается о подводных камнях, на которые могут наткнуться программисты. Если вы видите, что есть более эффективный подход, идея заказчика вызовет новые проблемы или вообще остановит развитие проекта, ваша задача — не бояться сказать клиенту, что он не прав. Объясните, почему лучше использовать ту или иную технологию или подход. Как показывает практика, когда вы можете аргументировать преимущества своей идеи и недостатки предложенного заказчиком решения, он спокойно примет вашу сторону. Проект — это его детище, его деньги, и прежде всего клиент заинтересован в эффективности и прибыльности продукта.
В нашем случае мы разработали много спецификаций, которые жили обособленно и полноценно не взаимодействовали друг с другом. А как только разбили их на независимые микросервисы, получили высокие показатели в перформансе и счастливого заказчика, который приумножил прибыль. Подробности можно узнать из моего доклада на NIXMultiConf.
Под слоганом «айтишникам — от айтишников» эксперты из Украины, Беларуси, России, Великобритании и Германии поделились опытом и рассказали о новинках индустрии. Полезно было всем — дизайнерам, девелоперам, тестировщикам и менеджерам. И теперь делимся инсайтами с вами.
По мотивам докладов экспертов NIX продолжаем серию материал на самые актуальные темы. В новой статье PHP developer Александр Павленко объясняет, на каком этапе разработки стоит перейти на микросервисы и как это сделать с минимальными рисками.
Хочешь знать больше — смотри конференцию на YouTube-канале.
Привет! Я Александр Павленко, разработкой на PHP занимаюсь около четырех лет. Среди крупных проектов — Car Sales Platform + Inventory, Archive of Scientific Documents, Job Search Platform, Natural Disasters Alarm System.
Стоит только заговорить о монолите и микросервисах, как многие начинают холивар вокруг их сравнения. Я считаю, вместо поиска плюсов и минусов, лучше выяснить, какой подход больше всего отвечает бизнес-задачам приложения. Наша команда занималась проектом в сфере FinTech, и он изначально строился на монолите. Почему так сложилось и какие возможности мы увидели в микросервисах — расскажу подробнее.
Стартовать проще с монолитом
Монолит напоминает мне кубик Рубика: если вытащить из него одну деталь, собрать новую форму или добавить другие компоненты, кубик уже не будет полноценно работать. Каждый элемент формирует единый функционал. Если какой-то части не хватает, она сломана или стоит не на месте — цветное поле кубика не сложится.
В условиях стартапа с монолитом удается быстрее запустить проект. Когда, условно через месяц, надо презентовать клиенту MVP, но ни конкретных требований, ни спецификаций по продукту нет, спасает только гибкость монолита. Во-вторых, на старте его легко и быстро масштабировать. Для команды тоже были очевидны преимущества. К разработке на монолите может присоединиться больше специалистов, в том числе новички. В изучении PHP они непременно начинают с монолита. Он прост и понятен в использовании.
Наш стартап стремительно развивался. Росло количество пользователей, клиентов, регулярно добавлялся различный функционал. Спустя время проявились недостатки монолита. То, что было критично для нас:
- из-за стремительного роста системы становилось сложнее ее поддерживать и развивать без дополнительных ресурсов. Прежде всего это касалось стоимости внесения новых изменений. Чем дальше мы шли и внедряли новые фичи, тем больше они дорожали.
- рисковали в будущем застрять на старых технологиях. Думаю, многие коллеги сталкивались с legacy-монолитами — за окном 2020-й год, а на мониторе в коде 2003-й. Переписывать все это крайне сложно. Обычно не хватает ни времени, ни ресурсов.
К счастью, мы заранее предвидели риски, поэтому переход на новую архитектуру не шокировал. Все прошло плавно и спокойно. Микросервисный подход решил несколько задач:
- многократное использование микросервисов позволяло легче адаптироваться под новые требования стартапа и масштабировать его;
- внедрять новый функционал без дополнительных затрат;
- упрощать интеграцию последующих приложений;
- использовать разные языки программирования под микросервисы и разные виды протоколов для общения между ними.
Но тут же вспылили недостатки. Во-первых, повысился порог вхождения в проект. Во-вторых, усложнилось поддержание, конфигурация и тестирование настроек. По сути это не является минусом. Главное, что у нас микросервисами закрыли самые важные вопросы.
Со временем заказчик понял, что хочет продавать продукт не только целиком, но и отдельными частями, тем самым упрощая жизнь пользователям. На тот момент у нас уже был различный функционал, из которого планировали выделить небольшие независимые компоненты. А из них — построить идентичные конструкции или создать новые бизнес-решения. Каждый микросервис обладает своей логикой и функциями, но этот пазл можно интегрировать в любую другую систему и самостоятельно развивать ее. Если один из компонентов перестал работать, не значит, что вся система обязательно рухнет. Возможно, отвалится то, что тесно связано с данным микросервисом. Но в том или ином виде система продолжит работать.
Микросервисы хороши и тем, что их можно развертывать и тестировать независимо друг от друга. Это упрощает жизнь команде как в процессе разработки, так и в дальнейшем развитии проекта.
Что микросервисы дали нашему проекту:
- взаимодействие PHP и Golang. Отлично дополняют и в некоторых случаях перекрывают слабые стороны друг друга. По сравнению с PHP, с помощью Golang можно значительно улучшить перфоманс. За счет параллелизма — ускорить обработку и выполнение тех или иных процессов. В тоже время у PHP есть все для быстрой реализации удобного CRUD;
- от пяти крупных клиентов мы перешли к более чем 20-ти — все благодаря разграничению монолита на отдельные решения;
- оптимизировали нагрузку на сервера. По сравнению с PHP, Golang потребляет намного меньше памяти. С его внедрением и переписыванием и развитием нескольких частей приложения на Golang серверам стало легче. Больше мы с этой проблемой не сталкиваемся;
- разнообразили команду. Переход к микросервисам — это не только изменение архитектуры кода, но и самой команды. Мы поделились по зонам ответственности. Когда-то нас было пятеро, сейчас — около 40 человек. Добавились бэкенд-разработчики и бизнес-аналитики, заточенные под определенные спецификации.
Появились нюансы, усложняющие поддержку безопасности транзакций. В случае с микросервисами мы имеем дело с децентрализацией данных. Также, прежде чем писать код, разработчикам надо помнить о возможной несогласованности.
Не обошлось без сложностей для новых членов команды. Им нужно больше времени, чтобы понять, как микросервисы между собой взаимодействуют и делают ли это вообще. Насколько глубоко начинающий разработчик должен в этом разбираться? Чем разнообразнее база знаний, тем специалист ценнее на рынке и может оперативно реагировать на изменения в проекте. Когда есть, с чем сравнивать, намного легче среди нескольких вариантов выбрать наиболее подходящий в текущий момент. Поэтому, как минимум, ознакомиться с этим архитектурным подходом я советую всем. Новичок может начать с более простых вещей — с монолита — но помнить, что когда-нибудь придется углубиться в микросервисы. Все-таки тренды индустрии никто не отменял.
Монолит словно здоровенный котел, в котором варится сразу много всего. С появлением новых ингредиентов мы пытались все структурировать. Но помешивая этот «суп», затрагивали другие ингредиенты, даже когда это не требовалось. Микросервисы помогли создать современную технологическую кухню и разделить зоны функциональности. Мы уже не только «варили», но и «запекали», «кипятили», где-то «жарили», а где-то только «подогревали». Познав тонкости этой «высокой кухни», в результате получили качественные продукты.
Получается, микросервисы рулят?
На самом деле, окончательного ответа нет. В тех или иных ситуациях бывает логичнее стартовать с монолита. Но в будущем система может достичь таких масштабов, что переход к микросервисам неизбежен. Из личного опыта я отметил пару сценариев, в которых стоит задуматься о переходе на микросервисы:
- когда в монолитном проекте стоимость нового функционала не перекрывает ожидаемую пользу;
- когда проект разрастается до такой глыбы, что новые люди в команде теряются. В микросервисах можно взять отдельный компонент, определить, что в нем происходит и работать только с ним. В крупных проектах разделение обязанностей рано или поздно приведет к архитектурным разграничениям. Микросервисы позволяют легче пережить этот момент.
Иногда мы сталкиваемся с настойчивыми клиентами, которые отказываются от здравой идеи разработчиков. Вот вздумалось ему только эту технологию или архитектуру применять. Почему? Да потому что. «Слышал в интернете» или «Все так делают». Заказчик редко задумывается о подводных камнях, на которые могут наткнуться программисты. Если вы видите, что есть более эффективный подход, идея заказчика вызовет новые проблемы или вообще остановит развитие проекта, ваша задача — не бояться сказать клиенту, что он не прав. Объясните, почему лучше использовать ту или иную технологию или подход. Как показывает практика, когда вы можете аргументировать преимущества своей идеи и недостатки предложенного заказчиком решения, он спокойно примет вашу сторону. Проект — это его детище, его деньги, и прежде всего клиент заинтересован в эффективности и прибыльности продукта.
В нашем случае мы разработали много спецификаций, которые жили обособленно и полноценно не взаимодействовали друг с другом. А как только разбили их на независимые микросервисы, получили высокие показатели в перформансе и счастливого заказчика, который приумножил прибыль. Подробности можно узнать из моего доклада на NIXMultiConf.
