Старое, но. Есть у меня монолит, который прошёл типичные "болезни роста", и мне есть тоже что сказать.
Это как если бы вы делали машину и у вас отдельно крутой эксперт по двигателям сделал мощный двигатель
Именно так и делают современные авто. И именно поэтому есть проблемы вида "чтобы поменять лампу в фаре, нужно снять колесо"
А вот ИИ хоть пока и не догоняет до уровня человека по умению создавать новое, но у него нет ограничений по скорости работы и умению обучаться
В корне неверные знания. Как тут уже говорили, все современные ии - уже НАТРЕНИРОВАНЫ и просто работают по своей базе. "Умение обучаться" - это понадобится целый датацентр видях и хотя бы месяц вычислений. И эти модели статичны и дообучение там невозможно. До настоящего самообучения ещё очень далеко.
Возьмем приложение для онлайн-магазина. У нас есть модуль заказов, модуль товаров, модуль пользователей. Каждый модуль инкапсулирует свою логику и данные. Но когда нужно оформить заказ - модуль заказов может напрямую получить все нужные данные о товаре и пользователе через методы этих модулей, без сетевых вызовов.
И далее - это работает, пока программистов условно 5 на проекте. Но ваш бизнес быстро растёт, прирост клиентов х2 каждый месяц, а то и больше (это прогрессивная шкала). Решено взять 100 разрабов. И начнётся:
Решили поменять товар (переименовать поле в БД), то есть теперь нужно править ВСЁ что ходит в эту таблицу, а часто ещё и менять логику в блоках товара, заказа, истории заказов, вероятно юзеров итд. А потом разрабы решили хранить JSON внутри - и снова привет. Далее, 100 разрабов создали 125 бранчей (что-то в работе, что-то в проверке итд), и теперь ВО ВСЕ нужно внести это изменение. А в это время другая команда, которая работала с заказами - и тоже решила переделать таблицу товаров, не важно зачем. И половина разработки тормозится на взаимной блокировке, им нужно согласовывать изменения, потом втаскивать изменения во все рабочие ветки, а там тоже были свои изменения - привет хаос.
Какой вывод напрашивается? С таблицей товаров работает класс товаров. Изменения уже частично скрываются, работа упрощается. Но - мы получили микросервис без обёртки (и бонус - мы можем вынести данную таблицу/набор в другую базу, а то и на другой сервер, в том числе для оптимизации производительности). Но разные версии кода ожидают стабильности от класса, то есть нужна какая-то версионность. И получаем плюс микросервиса - пока у нас снаружи ничего не меняется, не нужно думать что там внутри и о совместимости. Типичный подход к работе с версиями микросервисов, пока есть обратная совместимость (мы можем добавить новые методы, но не можем менять работу уже используемых) - мы минимизируем проблемы и простой.
Чтобы создать заказ нам надо:
Надо, и что? Это всё копеечные операции, "запросить, получить" - именно на сетевой части там микросекунды, особенно при использовании persistent connections. Если будут какие-то задержки - то только по вине кода, а в монолите они будут ровно такими же, если не больше.
И везде на этом пути могут быть проблемы - сеть лагает
проблема ни разу не сервисная, при нормальных сетевиках внутри отдельных ДЦ бывает чуть менее чем никогда
сервис не отвечает
при нормальной работе такого не бывает, опять же балансировка запросов, мониторинг итд, плюс монолит чем "хорош" - если он лёг то весь целиком, даже если проблемы в блоке истории заказов, куда юзеру сейчас было не нужно, то есть с микросервисами можно получить деградацию, но хотя бы частично сохранить работоспособность
версии API не совпадают.
опять проблема не сервиса и ровно так же можно в монолите поменять таблицу, изменить часть где работает заказ, но ломается история заказов. А апи ГАРАНТИРУЕТ неизменность структур, если нужно менять уже работающие методы - или делаются методы _v2, или весь апи становится новой версии, мажорно. Минимальный контроль - и на монолите шансы поймать проблему на порядки выше чем на микросервисах.
Плюс не забываем про асинхронную работу, в монолите это РЕЗКО поднимет сложность ("тут у нас кусок синхронный, но его могут дёрнуть асинхронно,значит 10% всего кода готовим к асинхронности"), у микросервиса нет такой сложности.
Но когда вам нужно собрать общую картину
Это нужно редко, очень редко, а для бизнеса сильно важнее именно стабильность и предсказуемость работы для клиента, а не "сложность общей картины".
"посмотреть что происходит в системе"
"Прямо сейчас" это нужно только для мониторинга, как работает система, всё ли доступно, хватает ли места, не перегружены ли диск-сеть-проц. Аналитикам максимум нужно "доходы за день на текущий момент", и то больше в стиле хотелки, нормальные аналитики работают именно на уровне "данные за вчера и старше". Опять же, если им сильно нужно - сделать отдельные микросервисы по нужным микросервисам. Звучит странно, но именно так и работает. А с монолитом кроме общей базы - нет там никакой "общей аналитики". Тупо общая база. Ну подключите в тот же airbyte сотню микробаз и настройте проливку типа CDC, будете иметь мгновенное состояние. Да, нужны понимающие люди, но на таком уровне проблема максимум в жадности на зп. Но тут "шашечки или ехать".
Я это делал 5 лет назад
у меня прямо сейчас проект, который к моему приходу был типичным монолитом, жил на 1 сервере, масштабировался "докинь ресурсов" при том что вм была почти на макс версии, все данные хранились локально на диске, база была общая гигов на 10 на том же сервере. Мониторинга не было. Время ответа главной страницы приближалось к 8 секундам. Я принимал активное участие в оптимизации и разделению этого монолита, банально добавить 2 сервер заняло где-то пол года с переработкой начинки монолита, сейчас чисто как легаси там 20 серверов + новый апи вовсю используется, который писали более года и постепенно переводили на него всё, но ряд вещей (мобилки, админка и все старые апи) по прежнему там. Балансировщик на входе, разделение по location итд. Но работать с тем кодом никто не любит, правили одно место, сломалось вообще другое, вообще никак логически не связанное с первым - это норма. Базу потом тоже через proxysql стали делить на запросы чисто на чтение (2 слейва под чтение), на запись - под это пришлось взять 3 железных сервера, только так перестали упираться в производительность. А это всего в 10 раз рост за год, х2 ежемесячно потребовал бы заметного изменения вообще всех процессов. Ну и девопсов - был 1, уже 9, и надо бы ещё.
ЗЫ Микросервисы дают больше сложность, но и больше управляемость, больше надёжность системы в целом, и больше разделение, в том числе на уровне команд. Можно спокойно писать модули, которые нужны "моментно", типа работы с модулями оплаты, а потом сотрудничество прервали - и просто удалили модуль. Вычистить такое из монолита полностью - часто невозможно, только отдельные части. Как итог - монолит хорош как MVP, или для вещей где новых фич и/или роста популярности не планируется, там сидит 2 девопса, 3 разраба, и тихо себе пилят монолит. Микросервисы это больше про активный рост клиентов и/или активные изменения кода
А я готовлюсь. Потому что знать всего невозможно, и часто есть "с этим не работал вообще, в это тыкал палочкой". Просто прочитать базу тут уже достаточно, а на собесе говорить - с этим не работал, но с технологией ознакомился и базу понял. Тут сразу несколько плюсов:
работодатель видит, что "не всё равно", а заинтересованность очень часто важнее реальных знаний + что конкретно под вакансию было изучение
на вопросах по этой технологии на уровне выше базы можно смело говорить "как я предупредил, я точного ответа не знаю, но могу предположить что ..." и рассуждения. Опять же, видны попытки вникнуть, размышления, желание учиться.
снимает каверзные вопросы - и так понятно что скорее всего не ответит, но нет этого чувства "тут плавает, минус". Обеим сторонам проще.
Конечно, азы знать нужно, но конкретный инструмент/либа изучается за ограниченное время. Я и сам при подготовке изучал потенциальные инструменты и говорил что работать не доводилось, и при найме совершенно спокойно принимал ответ "не доводилось, но что-то для изучения смотрел", нанимали таких. Важнее именно удовольствие от общения, что человек не боится сказать "не знаю", при этом есть интерес.
я бы больше ориентировался по нижней планке (точнее, ближе к медиане), это 300к и 250к соответственно (по медиане ближе к 350). Заметно ниже $5000. Суть, что когда много кандидатов и есть подходящий за 350к и за 450к, зачем брать за 450? Мы тоже, когда подбирали 2 мидлов из 10 кандидатов, смотрели в том числе и на ожидания по зп. Конечно, это не работает с очень узкими спецами, когда их условно всего 2 предложения, но девопсы и разрабы - выбор большой.
При этом банки почему-то предлагают заметно больше, даже учитывая что там аутстафф аутстаффа и по факту за сотрудника х2 легко переплачивается
Вроде никто не писал (или плохо пролистал комменты), но:
Наверное, думал, что я буду оплачивать со своего кошелька.
Именно так. Это мошенники, цель которых - именно заставить заплатить и испариться, особенно когда потрачено уже прилично времени - логика притупляется. Так что какой-то процент жертв платит, а они чисто на этом и живут...
Обязан ли водитель знать досконально устройство всех видов двигателей и коробок?
Так и тут, есть задачи "движок перебирать", а есть "каждый день перемещаться из точки А в точку Б". Это про разное, и механику для переборки двигателя ПДД не важно например. У всех своя сфера, не стоит обобщать по своему опыту всех.
в данном виде это "обкатка технологий", особых преференций оно не даёт.
Если же сдавать серьезные сертификаты - там явка лично, с паспортом, комп выдают - и сдаёшь. Дядю не посадишь, шпору не достанешь, с телефона не загуглишь (учитывая что времени и так впритык - даже если есть телефон/шпора, тупо по времени выпадешь)
Собеседование нужно в том числе для выяснения, насколько возникает контакт - с ним потом работать долгие годы, не вызывает ли он отторжения речью, поведением итд. Техническая основа тоже нужна, но я собеседовал недавно мидла - было и "тут я не знаю, в этой теме пока не шарю". Но уже через пол часа после собеса, обсудив с коллегой итоги - дали отмашку что берём. Не пожалели.
а с улицы зайти в какую-то фирму, без реальных знакомых - достаточно тяжело.
Без знакомств входил и в госуху, и в банки. Более того, искал тут мидл девопсов - тоже оказался тот ещё квест, или хотят больше чем я (техдир), или плавают в базовых вещах...
у меня на втором монике была то анима, то ютуб. Там явно написано "запрещено переключаться", включил - до окончания теста переключаться "на фильм" нельзя. Почти все тесты что запустил - сдал (где нет - было типа 9/13), свои дыры в знаниях увидел. Тоже польза.
Для государственных гражданских служащих (например, "специалист IT-отдела", "ведущий эксперт по информационной безопасности") диплом обязателен (ст. 12 ФЗ "О государственной гражданской службе РФ").
Но зависит от ряда условий, да. Причём для руководящих должностей тоже было где-то в законе
И да, я работал в паре гос компаний, диплом был именно обязателен и его проверяли на подлинность.
Любой сертификат это филькина грамота. Как и любая валюта, обеспеченная только верой в государство этой валюты (валют, обеспеченных золотом, вроде уже лет 80 как нет). Например, сертификат амазона или циски. Она показывает тоже примерно ничего, максимум что человек оплатил курс.
Так-то даже диплом универа показывает примерно ничего. Но при отборе многие смотрят просто на наличие. Так и тут, кому-то "чем больше, тем лучше"...
Индусы исчезали, а разработка отдавалась западным разработчикам, которые всё переписывали с нуля.
Если так, то всё хорошо. "сделать прототип и с нуля написать нормально" это суть мвп. Чаще же "ну мы вот уже сделали что-то максимально быстрое, а теперь это нужно отрефакторить до нормального кода". Не учитывая, что начинать там нужно вообще с архитектуры, по итогу того как выстрелил мвп. И выбора подходящего языка. И вот тут "тянуть код" - в корне неверно, если не сделан полный анализ и "язык сохраняем, архитектуру меняем тут и тут, эту половину кода переписать с нуля, тут мертвые фичи выкидываем", и всё это планом работ.
главное препятствие - для любого изменения нужно понимать архитектуру и код проекта, как это скормить ИИ?
Открываешь редактор с поддержкой ИИ (cursor, trae), делаешь проект, добавляешь туда код. Всё, ии его способен проанализировать и под "заюзать" он может предложить варианты. Рефакторинг можно сделать там же, порой получается неплохо. С багами сложнее, ряд багов он показывает сразу при правильном запросе, но многие баги - ручками или как тут рядом расписали.
Но не надо превращать ии в архитектора, и не надо пытаться им заменить программиста. Это инструмент, как круиз-контроль в авто - удобно, помогает, водителя не заменит.
"за день сделаю. А за 10? За 10 не сделаю, тут помощник нужен!"
х/ф «Формула любви»
Как раз команда медленнее работает, но более предсказуемо + масштабируется
Старое, но. Есть у меня монолит, который прошёл типичные "болезни роста", и мне есть тоже что сказать.
Именно так и делают современные авто. И именно поэтому есть проблемы вида "чтобы поменять лампу в фаре, нужно снять колесо"
В корне неверные знания. Как тут уже говорили, все современные ии - уже НАТРЕНИРОВАНЫ и просто работают по своей базе. "Умение обучаться" - это понадобится целый датацентр видях и хотя бы месяц вычислений. И эти модели статичны и дообучение там невозможно. До настоящего самообучения ещё очень далеко.
И далее - это работает, пока программистов условно 5 на проекте. Но ваш бизнес быстро растёт, прирост клиентов х2 каждый месяц, а то и больше (это прогрессивная шкала). Решено взять 100 разрабов. И начнётся:
Решили поменять товар (переименовать поле в БД), то есть теперь нужно править ВСЁ что ходит в эту таблицу, а часто ещё и менять логику в блоках товара, заказа, истории заказов, вероятно юзеров итд. А потом разрабы решили хранить JSON внутри - и снова привет. Далее, 100 разрабов создали 125 бранчей (что-то в работе, что-то в проверке итд), и теперь ВО ВСЕ нужно внести это изменение. А в это время другая команда, которая работала с заказами - и тоже решила переделать таблицу товаров, не важно зачем. И половина разработки тормозится на взаимной блокировке, им нужно согласовывать изменения, потом втаскивать изменения во все рабочие ветки, а там тоже были свои изменения - привет хаос.
Какой вывод напрашивается? С таблицей товаров работает класс товаров. Изменения уже частично скрываются, работа упрощается. Но - мы получили микросервис без обёртки (и бонус - мы можем вынести данную таблицу/набор в другую базу, а то и на другой сервер, в том числе для оптимизации производительности). Но разные версии кода ожидают стабильности от класса, то есть нужна какая-то версионность. И получаем плюс микросервиса - пока у нас снаружи ничего не меняется, не нужно думать что там внутри и о совместимости. Типичный подход к работе с версиями микросервисов, пока есть обратная совместимость (мы можем добавить новые методы, но не можем менять работу уже используемых) - мы минимизируем проблемы и простой.
Надо, и что? Это всё копеечные операции, "запросить, получить" - именно на сетевой части там микросекунды, особенно при использовании persistent connections. Если будут какие-то задержки - то только по вине кода, а в монолите они будут ровно такими же, если не больше.
проблема ни разу не сервисная, при нормальных сетевиках внутри отдельных ДЦ бывает чуть менее чем никогда
при нормальной работе такого не бывает, опять же балансировка запросов, мониторинг итд, плюс монолит чем "хорош" - если он лёг то весь целиком, даже если проблемы в блоке истории заказов, куда юзеру сейчас было не нужно, то есть с микросервисами можно получить деградацию, но хотя бы частично сохранить работоспособность
опять проблема не сервиса и ровно так же можно в монолите поменять таблицу, изменить часть где работает заказ, но ломается история заказов. А апи ГАРАНТИРУЕТ неизменность структур, если нужно менять уже работающие методы - или делаются методы _v2, или весь апи становится новой версии, мажорно. Минимальный контроль - и на монолите шансы поймать проблему на порядки выше чем на микросервисах.
Плюс не забываем про асинхронную работу, в монолите это РЕЗКО поднимет сложность ("тут у нас кусок синхронный, но его могут дёрнуть асинхронно,значит 10% всего кода готовим к асинхронности"), у микросервиса нет такой сложности.
Это нужно редко, очень редко, а для бизнеса сильно важнее именно стабильность и предсказуемость работы для клиента, а не "сложность общей картины".
"Прямо сейчас" это нужно только для мониторинга, как работает система, всё ли доступно, хватает ли места, не перегружены ли диск-сеть-проц. Аналитикам максимум нужно "доходы за день на текущий момент", и то больше в стиле хотелки, нормальные аналитики работают именно на уровне "данные за вчера и старше". Опять же, если им сильно нужно - сделать отдельные микросервисы по нужным микросервисам. Звучит странно, но именно так и работает. А с монолитом кроме общей базы - нет там никакой "общей аналитики". Тупо общая база. Ну подключите в тот же airbyte сотню микробаз и настройте проливку типа CDC, будете иметь мгновенное состояние. Да, нужны понимающие люди, но на таком уровне проблема максимум в жадности на зп. Но тут "шашечки или ехать".
у меня прямо сейчас проект, который к моему приходу был типичным монолитом, жил на 1 сервере, масштабировался "докинь ресурсов" при том что вм была почти на макс версии, все данные хранились локально на диске, база была общая гигов на 10 на том же сервере. Мониторинга не было. Время ответа главной страницы приближалось к 8 секундам. Я принимал активное участие в оптимизации и разделению этого монолита, банально добавить 2 сервер заняло где-то пол года с переработкой начинки монолита, сейчас чисто как легаси там 20 серверов + новый апи вовсю используется, который писали более года и постепенно переводили на него всё, но ряд вещей (мобилки, админка и все старые апи) по прежнему там. Балансировщик на входе, разделение по location итд. Но работать с тем кодом никто не любит, правили одно место, сломалось вообще другое, вообще никак логически не связанное с первым - это норма. Базу потом тоже через proxysql стали делить на запросы чисто на чтение (2 слейва под чтение), на запись - под это пришлось взять 3 железных сервера, только так перестали упираться в производительность. А это всего в 10 раз рост за год, х2 ежемесячно потребовал бы заметного изменения вообще всех процессов. Ну и девопсов - был 1, уже 9, и надо бы ещё.
ЗЫ Микросервисы дают больше сложность, но и больше управляемость, больше надёжность системы в целом, и больше разделение, в том числе на уровне команд. Можно спокойно писать модули, которые нужны "моментно", типа работы с модулями оплаты, а потом сотрудничество прервали - и просто удалили модуль. Вычистить такое из монолита полностью - часто невозможно, только отдельные части. Как итог - монолит хорош как MVP, или для вещей где новых фич и/или роста популярности не планируется, там сидит 2 девопса, 3 разраба, и тихо себе пилят монолит. Микросервисы это больше про активный рост клиентов и/или активные изменения кода
https://habr.com/ru/companies/selectel/articles/871012/
https://habr.com/ru/companies/slurm/articles/869724/
А я готовлюсь. Потому что знать всего невозможно, и часто есть "с этим не работал вообще, в это тыкал палочкой". Просто прочитать базу тут уже достаточно, а на собесе говорить - с этим не работал, но с технологией ознакомился и базу понял. Тут сразу несколько плюсов:
работодатель видит, что "не всё равно", а заинтересованность очень часто важнее реальных знаний + что конкретно под вакансию было изучение
на вопросах по этой технологии на уровне выше базы можно смело говорить "как я предупредил, я точного ответа не знаю, но могу предположить что ..." и рассуждения. Опять же, видны попытки вникнуть, размышления, желание учиться.
снимает каверзные вопросы - и так понятно что скорее всего не ответит, но нет этого чувства "тут плавает, минус". Обеим сторонам проще.
Конечно, азы знать нужно, но конкретный инструмент/либа изучается за ограниченное время. Я и сам при подготовке изучал потенциальные инструменты и говорил что работать не доводилось, и при найме совершенно спокойно принимал ответ "не доводилось, но что-то для изучения смотрел", нанимали таких. Важнее именно удовольствие от общения, что человек не боится сказать "не знаю", при этом есть интерес.
я бы больше ориентировался по нижней планке (точнее, ближе к медиане), это 300к и 250к соответственно (по медиане ближе к 350). Заметно ниже $5000. Суть, что когда много кандидатов и есть подходящий за 350к и за 450к, зачем брать за 450? Мы тоже, когда подбирали 2 мидлов из 10 кандидатов, смотрели в том числе и на ожидания по зп. Конечно, это не работает с очень узкими спецами, когда их условно всего 2 предложения, но девопсы и разрабы - выбор большой.
При этом банки почему-то предлагают заметно больше, даже учитывая что там аутстафф аутстаффа и по факту за сотрудника х2 легко переплачивается
Тут (на хабре) были статьи, что яндекс платит ниже рынка, может себе позволить. Но я там не работал, поэтому пока уровень "бабка сказала"
Вроде никто не писал (или плохо пролистал комменты), но:
Именно так. Это мошенники, цель которых - именно заставить заплатить и испариться, особенно когда потрачено уже прилично времени - логика притупляется. Так что какой-то процент жертв платит, а они чисто на этом и живут...
(уже обсудили, удаляю)
Солнце встало - значит полночь? Или теперь у каждого города снова своё время вплоть до своих минут?
Летнее/зимнее это бред, а вот сами часовые пояса - нужны
Обязан ли водитель знать досконально устройство всех видов двигателей и коробок?
Так и тут, есть задачи "движок перебирать", а есть "каждый день перемещаться из точки А в точку Б". Это про разное, и механику для переборки двигателя ПДД не важно например. У всех своя сфера, не стоит обобщать по своему опыту всех.
в данном виде это "обкатка технологий", особых преференций оно не даёт.
Если же сдавать серьезные сертификаты - там явка лично, с паспортом, комп выдают - и сдаёшь. Дядю не посадишь, шпору не достанешь, с телефона не загуглишь (учитывая что времени и так впритык - даже если есть телефон/шпора, тупо по времени выпадешь)
Где? я такое вижу только в статьях про америку и немного про европу.
Если брать рф - не так давно надо было сменить работу, через неделю уже были офферы.
Собеседование нужно в том числе для выяснения, насколько возникает контакт - с ним потом работать долгие годы, не вызывает ли он отторжения речью, поведением итд. Техническая основа тоже нужна, но я собеседовал недавно мидла - было и "тут я не знаю, в этой теме пока не шарю". Но уже через пол часа после собеса, обсудив с коллегой итоги - дали отмашку что берём. Не пожалели.
Без знакомств входил и в госуху, и в банки. Более того, искал тут мидл девопсов - тоже оказался тот ещё квест, или хотят больше чем я (техдир), или плавают в базовых вещах...
у меня на втором монике была то анима, то ютуб. Там явно написано "запрещено переключаться", включил - до окончания теста переключаться "на фильм" нельзя. Почти все тесты что запустил - сдал (где нет - было типа 9/13), свои дыры в знаниях увидел. Тоже польза.
в большинстве - требуют.
Но зависит от ряда условий, да. Причём для руководящих должностей тоже было где-то в законе
И да, я работал в паре гос компаний, диплом был именно обязателен и его проверяли на подлинность.
Любой сертификат это филькина грамота. Как и любая валюта, обеспеченная только верой в государство этой валюты (валют, обеспеченных золотом, вроде уже лет 80 как нет).
Например, сертификат амазона или циски. Она показывает тоже примерно ничего, максимум что человек оплатил курс.
Так-то даже диплом универа показывает примерно ничего. Но при отборе многие смотрят просто на наличие. Так и тут, кому-то "чем больше, тем лучше"...
какое счастье, что в большинстве языков это всё знать не нужно..
Если так, то всё хорошо. "сделать прототип и с нуля написать нормально" это суть мвп. Чаще же "ну мы вот уже сделали что-то максимально быстрое, а теперь это нужно отрефакторить до нормального кода". Не учитывая, что начинать там нужно вообще с архитектуры, по итогу того как выстрелил мвп. И выбора подходящего языка. И вот тут "тянуть код" - в корне неверно, если не сделан полный анализ и "язык сохраняем, архитектуру меняем тут и тут, эту половину кода переписать с нуля, тут мертвые фичи выкидываем", и всё это планом работ.
Открываешь редактор с поддержкой ИИ (cursor, trae), делаешь проект, добавляешь туда код. Всё, ии его способен проанализировать и под "заюзать" он может предложить варианты. Рефакторинг можно сделать там же, порой получается неплохо. С багами сложнее, ряд багов он показывает сразу при правильном запросе, но многие баги - ручками или как тут рядом расписали.
Но не надо превращать ии в архитектора, и не надо пытаться им заменить программиста. Это инструмент, как круиз-контроль в авто - удобно, помогает, водителя не заменит.
Идея для стартапа! )
А что за "нажал и оно развернулось"? Мне такое очень нужно