Брызгать слюной и пытаться унизить чужие статьи много ума не надо ) Да и самомнение у вас походу зашкаливает, раз вы решили что катализатором написания статьи были ваши статьи про микросервисы, я просто не читал ни ваши статьи, ни вас не знаю, ни вашу компанию. Так что корону советую снять )
я честно говоря не все ваши ответы понял, но сложилось впечатление, что и вы меня не поняли. Я не ругаю монолит, я больше скажу, я ЗА монолит, потому что в 99% случаях это лучше и проще и поддерживать и разрабатывать.
НО есть же моменты когда уже пора, и тут я думаю вы вполне меня поддержите.
Сорян, совершенно не очевидно, если это все монолит. Вас не затруднит расписать? Мне правда интересно
Из жизни. Мы пишем много на ноде использую NestJs. На нем же у нас все разбито на модули. Вот есть проект Онлайн-школы, на нем есть чаты и вот люди много пишут, мы отпочковали этот модуль и вытащили его на отдельную машину с отдельной БД, редисом, очередью и тд.
Еще из жизни. Есть ИМ(интернет магазин), там есть интеграции которые каждые несколько минут сканит базу цен, этот модуль будет дико нагружать основное приложение, соот-но его вынесли в отдельный сервис на отдельную машинку.
Распишите технически понятие "дружить". Сразу возникнет много всего интересного.
Сервисы же между собой как-то должны общаться. Очереди/Http/Tcp/GRpc и др.
Не плачу, но рассчитываю. Так все таки, рсскажите, в чем сложность горизонтального мсштабирования монолита в сравнении с микросервисами
Если примеры выше положить в горизонталь то машинки вам потребуются все довольно мощные чтобы держать такой монолит, в то время при разбивки на сервисы вы можете сами выбирать, какие лучше мощностя, выставлять лимиты на ресурсы. Плюс есть автоскейлинг который мы юзаем когда отдельный сервис нагружается.
Обратитесь к тех. спецу, чтобы он вам помог тогда написать статью :)
Так задачи не было техническую статью писать. Цель была донести до людей, НЕ технических, которые так же читают хабр, что не всегда им нужны микросервисы. У нас за последнее время было много заявок из разряда сделать лендос на мироксервисах, потому что клиент где-то прочитал что это круто, так и родилась идея статьи.
какие то сервисы все таки можно вытащить Есть разные парсинги, апишки, интеграции для ценовой политики Они сильно грузят ресурсы и поэтому мы стараемся такое выносить обычно
Как много токсичности )) Ну давайте по порядку. НО самое главное что статья не была расчитана на технически подкованных людей, а больше для людей кому пытаются "впарить" на этапе продажи то что ему не нужно.
Вы сначала поймите для себя, что такое "самый загруженный модуль" и что вообще в реальности загружается. А то выглядит так, что загрузка == это просто программный код. которому просто надоело работать. Вроде, один метод вызывается 1000 раз, а другой - 2. Вот первому и обидно стало :)
Я думал что оставляя такой комментарий, человек должен понимать что такое самый загруженный модуль. Описывать каждое предложение, что я имел ввиду будет не правильно, выйдет слишком много воды.
Куда дружить, с кем дружить, против кого дружить? Реально о чем все это?
Вот тут уровень токсичности возрастает. Вам все сложнее понимать о чем речь, ведь вы считаете себя сверхумным и готовы оспорить все что угодо.
В этот момент хочется спросить, а монолитное приложение, которое с точки зрения деплоя ничем не отличается от условного микросервиса не масштабируется горизонтально? Я открою секрет, схеме деплоя в многонодовом варианте с условным nginx/haproxy уже 100 лет в обед, и схожим решениям тоже.
Если же у вас есть баг, нет не так, БАГ - то он, если он к примеру в методе регистрации, то даже в монолите он никак не будет мешать работе других методов :)
Тут что-то на умном получилось сказать про nginx/haproxy. Можно конечно такой подход использовать. Остаться с голой жопой правда за оплату серверов, но вам то откуда это знать, я думаю вы за них не платите )) Не думаю что вы это поймете =) Ну и статья все таки про микросервисы
Лучше конечно 5 специалистов, но боюсь вы отсылку не поймете :)
Косяк, Каюсь перед вами. там должно было быть написано по 1 человеку на сервис. Но вы не могли пропустить такое, понимаю )
Ага, особенно если он другим тоже нужен. Да и то полезное, что он предоставляет пользователям тоже желательно не прерывать. Хотя - боюсь вы наверное думаете, що обновление монолита без прерывания сервиса является неподъемной задачей
Вы не поверите, но мы все раскатываем без прерываний, оказалась подъемной. А еще раскатывать можно не на всех, есть еще версии Api, и фронт можно и апки не на всех а на процент юзеров катать, но вот тут я думаю уже вы про такое не слышали, раз такую глупость написали.
P.S.
Засадить можно кого и что угодно, а вот помочь может не каждый. У нас есть отличный сервис с психологической поддержкой. Обращайтесь и я помогу оформить скидку.
да да, я понял. У нас похожая история, чтобы два рука было у одного человека, но именно руководит один, второй по факту как подстраховка или для решения спорных моментов
Выглядит как-будто вы пришли к матричной системе управления. В нашей компании что-то похожее с вашей на 60 разработчиков и это работает замечательно, а еще снимает кучу боли с людей которых в системе в этой быть не должно )
У нас есть описание в доп соглашении чтт заказчик получает на выходе
Для этого не обязательно писать ТЗ, и да у нас понимание ТЗ именно ближе к ГОСТУ так как есть проекты близкие к госам
Язвить кстати не обязательно про точки зрения, я лишь хотел сказать, что если у кого то не работает, как у нас, то это не значит что вообще ни у кого не заработает
Про намеки писал Вам не я ) Ваше право иметь другую точку зрения. То что работает у нас возможно не сработает в других командах. Все люди разные, поэтому каждая точка зрения в том числе ваша имеет место быть.
В одной из статей на других источниках я писал про модульный подход к разработке
В этом случае если меняется требование то и модуль полностью выкидывается, а Франкенштейна в этом случае не будет. Заказчик само собой за это платит и как правило это понимает. Не понимает только заказчик который за 3 копейки хочет ракету, но я думаю это точно у всех было )
Два таких проекта реализовано и сейчас в работе есть такие.
И я ничего не забывал добавлять, я описал нашу работу. Моей целью было поделиться что можно и так, а как вы будете работать это выбор вас или вашего руководства.
Брызгать слюной и пытаться унизить чужие статьи много ума не надо )
Да и самомнение у вас походу зашкаливает, раз вы решили что катализатором написания статьи были ваши статьи про микросервисы, я просто не читал ни ваши статьи, ни вас не знаю, ни вашу компанию. Так что корону советую снять )
Если вы технический специалист, а судя по вашим статьям это так то статья не для вас, а для людей кто не имеет никакого технического бэкграунда
Я выше в комментах это уже написал по какой причине вообще родилась идея написать такой пост
Да и я думаю что вы согласитесь со мной что в разработке много чего субъективного.
я честно говоря не все ваши ответы понял, но сложилось впечатление, что и вы меня не поняли.
Я не ругаю монолит, я больше скажу, я ЗА монолит, потому что в 99% случаях это лучше и проще и поддерживать и разрабатывать.
НО есть же моменты когда уже пора, и тут я думаю вы вполне меня поддержите.
Из жизни. Мы пишем много на ноде использую NestJs. На нем же у нас все разбито на модули. Вот есть проект Онлайн-школы, на нем есть чаты и вот люди много пишут, мы отпочковали этот модуль и вытащили его на отдельную машину с отдельной БД, редисом, очередью и тд.
Еще из жизни. Есть ИМ(интернет магазин), там есть интеграции которые каждые несколько минут сканит базу цен, этот модуль будет дико нагружать основное приложение, соот-но его вынесли в отдельный сервис на отдельную машинку.
Сервисы же между собой как-то должны общаться. Очереди/Http/Tcp/GRpc и др.
Если примеры выше положить в горизонталь то машинки вам потребуются все довольно мощные чтобы держать такой монолит, в то время при разбивки на сервисы вы можете сами выбирать, какие лучше мощностя, выставлять лимиты на ресурсы. Плюс есть автоскейлинг который мы юзаем когда отдельный сервис нагружается.
Так задачи не было техническую статью писать. Цель была донести до людей, НЕ технических, которые так же читают хабр, что не всегда им нужны микросервисы.
У нас за последнее время было много заявок из разряда сделать лендос на мироксервисах, потому что клиент где-то прочитал что это круто, так и родилась идея статьи.
такой подход мы обычно используем на старте новых проектов
какие то сервисы все таки можно вытащить
Есть разные парсинги, апишки, интеграции для ценовой политики
Они сильно грузят ресурсы и поэтому мы стараемся такое выносить обычно
Как много токсичности ))
Ну давайте по порядку.
НО самое главное что статья не была расчитана на технически подкованных людей, а больше для людей кому пытаются "впарить" на этапе продажи то что ему не нужно.
Я думал что оставляя такой комментарий, человек должен понимать что такое самый загруженный модуль. Описывать каждое предложение, что я имел ввиду будет не правильно, выйдет слишком много воды.
Вот тут уровень токсичности возрастает. Вам все сложнее понимать о чем речь, ведь вы считаете себя сверхумным и готовы оспорить все что угодо.
Тут что-то на умном получилось сказать про nginx/haproxy. Можно конечно такой подход использовать. Остаться с голой жопой правда за оплату серверов, но вам то откуда это знать, я думаю вы за них не платите )) Не думаю что вы это поймете =)
Ну и статья все таки про микросервисы
Косяк, Каюсь перед вами. там должно было быть написано по 1 человеку на сервис. Но вы не могли пропустить такое, понимаю )
Вы не поверите, но мы все раскатываем без прерываний, оказалась подъемной. А еще раскатывать можно не на всех, есть еще версии Api, и фронт можно и апки не на всех а на процент юзеров катать, но вот тут я думаю уже вы про такое не слышали, раз такую глупость написали.
P.S.
Засадить можно кого и что угодно, а вот помочь может не каждый.
У нас есть отличный сервис с психологической поддержкой. Обращайтесь и я помогу оформить скидку.
Почему так решили?
Аргументируйте )
да да, я понял. У нас похожая история, чтобы два рука было у одного человека, но именно руководит один, второй по факту как подстраховка или для решения спорных моментов
Выглядит как-будто вы пришли к матричной системе управления. В нашей компании что-то похожее с вашей на 60 разработчиков и это работает замечательно, а еще снимает кучу боли с людей которых в системе в этой быть не должно )
Те кто работает 3+ месяцев как правило попадают и делают даже раньше срока
Переработка является исключением и случается крайне редко
Так я про это и написал, модуль который пилили выкинули и на его место вставили новый, при этом другие участки кода не пострадали
И да новый модуль за новую оплату само собой
Это уже специфика проекта когда код и железки неотделимы
У нас все таки проекты про другое
В случае с описанным вами проектом ТЗ в полной мере прям от и до должно быть, тут даже не спорю
Мы для этого рисуем макеты, cjm, user story
У нас есть описание в доп соглашении чтт заказчик получает на выходе
Для этого не обязательно писать ТЗ, и да у нас понимание ТЗ именно ближе к ГОСТУ так как есть проекты близкие к госам
Язвить кстати не обязательно про точки зрения, я лишь хотел сказать, что если у кого то не работает, как у нас, то это не значит что вообще ни у кого не заработает
Про намеки писал Вам не я )
Ваше право иметь другую точку зрения. То что работает у нас возможно не сработает в других командах. Все люди разные, поэтому каждая точка зрения в том числе ваша имеет место быть.
В одной из статей на других источниках я писал про модульный подход к разработке
В этом случае если меняется требование то и модуль полностью выкидывается, а Франкенштейна в этом случае не будет. Заказчик само собой за это платит и как правило это понимает. Не понимает только заказчик который за 3 копейки хочет ракету, но я думаю это точно у всех было )
Мое мнение что железки и софт сравнивать не правильно
Мы тоже работаем с железками которые сами же заказывали для зарядных станций, и тут совсем другой подход.
Все верно, к каком то виде ТЗ все таки есть
Только не в том в котором его обычно ожидают увидеть
Вы первый внимательный читатель )
Да, рискнули и уже не один раз
Два таких проекта реализовано и сейчас в работе есть такие.
И я ничего не забывал добавлять, я описал нашу работу. Моей целью было поделиться что можно и так, а как вы будете работать это выбор вас или вашего руководства.