Что бы ответить на этот вопрос, нужно учесть очень много факторов. Размер группы которая останется без работы(относительный, абсолютный), уровень образования, когнитивные способности, культурные и религиозные особенности, эксперименты с безусловным доходом и тд. Боюсь, тут нужен робот матмодель, так так человеческому мозгу анализировать такие сложные структуры не под силу.
Новички и завышенные ожидания две разных причины, беда с пунктуацией просто. Первые переоценивают свои возможности пока не видят всей картины, а вторые уже понимают, но надеются на чудо.
Модное слово, мне кажется его используют слишком часто и не по назначению. Слишком часто что бы обращать на это внимание. Особенно странно бывает слышать про выгорание от людей работающих пару лет в профессии, это не выгорание - лень, завышенные ожидания, стандартные проблемы новичка, после малых успехов видеть себя архитектором через год и потом "выгореть" когда станет понятен масштаб.
Мне больше нравится слово "усталость". Устают в ИТ от разного, чаще, мне кажется от обычных человеческих взаимоотношений чем от необходимости постоянного обучения или решать сложные задачи.
Хороший пример про Юлю в отпуске. Очень важно отдыхать: вечером после работы, в выходные, не забывать про отпуска. Да, можно поработать и 16 часов в день, и без выходных, и подключиться с пляжа поднимать продакшн. Но это должно быть исключением, а не правилом. Иначе ни кому не хватит сил и он устанет. Устанет, даже если делает любимое дело для души. Когда все вокруг привыкнут и решат что это норма и они такие крутые менеджеры. Знаю это, как тот самый человек, который заражает коллег мотивацией работать и который уже уходил в отпуск на полгода.
Если речь о том, что при централизованном управлении конфигурацией, логгировании и мониторингом заходить на сервера нет необходимости, то это не так. * Всегда найдутся сервера, о которых узнаешь только когда они поломались и всего выше перечисленного там нет. * Почти всегда, кроме случая когда много однотипных серверов, зайти во время сбоя и исправить что-то на сервере руками быстрее чем писать плейбук. * Логов и метрик может быть недостаточно для траблшутинга. Для сложных проблем их всегда будет недостаточно. и тд.
Это можно для себя так делать. А если в команде несколько людей и они предпочитают разные утилиты. И у тебя тысячи серверов. На них, например, разные варианты linux развернутые разными людьми из разных шаблонов, на протяжении нескольких лет. Не очень реально.
Для админов(а кто еще живёт в консоли) использование утилит аналогов стандартным - злеейшее зло. Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия. В качестве бонуса, не нужно тратить полдня на настройку нового ноутбука под себя, можно работать с любого.
Про автоисправление уже написали, это крутая фича в IDE, где будет ревью, тесты и тд. Но не в консоли, где может не быть ни каких доп проверок, а ошибка может стоить очень дорого.
Не всё так страшно. Базовых знаний по linux и сети достаточно для старта стажёром или даже джуном. Скорее наоборот, из-за большого стека и его высокой изменчивости, польза от знания конкретных продуктов небольшая. Важнее обучаемость и софтскиллы. Глубокие знания линукса и сети нужны, но их и у мидлов то нет. Что бы студент не грустил один траблшутя продакшн, нужен просто ментор.
Без общения с коллегами теряется ещё пара важных моментов, кроме социализации. При работе в команде постоянно происходят дискуссии и споры по разным вопросам. Это позволяет шире смотреть на проблемы, видеть разные варианты решения, которые один человек, даже самый скиловый предусмотреть не сможет. На мой взгляд, "вариться в собственном соку" для не слишком опытного это тупик, для опытного, серьезная потеря в скорости развития. Другой момент, это "случайная мысль". Эффект, когда решение сложной проблемы находится во время обсуждения несвязанных с ней вопросов - просто болтовней за кофе, например, благодаря ассоциациям. Наверно, у этого есть какое-то умное название, но я не знаю.
Плохо ходить в эластик с фронта. Это всё-таки БД, хоть и с http интерфейсом: авторизация, изменение схемы, обновление версий, это всё будет приносить боль в такой схеме.
Впрочем он он всегда будет приносить боль, я бы отметил некоторое количество недостатков. 1) Невозможность изменить схему после создания. Мапинги можно добавлять только на новые поля, если изначально неправильно был выбран тип поля, а он 100% будет выбран неправильно при сколько-нибудь сложной схеме данных, что бы изменить мапинги придется полность пересоздать индекс и перелить в него данные. 2) Невозможность перешардирования на лету, как это например сделано в кассандре. Шард это физическая сущность, которая всегда привязана к ноде, если количество шардов не делится на количество нод, а так будет всегда при горизонтальном масштабировании, что бы изменить количество шардов нужно пересоздать индекс и перелить в него данные. 3) Неуправлемое кеширование полей, пресловутая fielddata. Размер fielddata зависит от параметров запроса, если он большой, инстанс упадет в OOM, если его ограничить инстанс перейдет в режим CB и производительность сильно упадет. 4) Это jvm, со всеми вытекающими плюсами и минусами. Из минусов, ограничение на вертикальное масштабирование из размера хипа(а его займет та самая fielddata), накладные на GC, не самая выдающаяся производительность. 5) Отсутсвие нормальной авторизации, её либо не будет совсем, либо это будет сквозное шифрование. 6) Пертурбации с лицензирванием.
Эти недостатки, мне кажется, общеизвестны и частично описаны в документации. Когда для схожей задачи был выбран эластик пару лет назад, очень надеялся что это все проблемы, но была обнаружена еще одна. Пункт 3 и 4 из списка выше, выливаются в ботлнек на поиск в виде нескольких тысяч rps на 1 ноду. При нагрузке выше начинается гонка при получении блокировки к fielddata cache и дальнейшее масштабирование возможно только увеличением колчества нод и шардов.
Это если в ИТ за деньгами. А если это было по любви, то ни чего не меняется. Так даже интереснее, делать то что нравится, да еще и нужно другим. 8 часов в день ходишь на митинги, дейлики и правишь чужой код потому что надо, потом еще пару часиков допиливаешь его же для души.
Изначально плохо поставлен вопрос. Любое изменение без цели несёт вред, повышает энтропию и приближает тепловую смерть вселенной. Заказчиком оптимизации выступает почти всегда эксплуатация, а не бизнес. Просто потому что мало где умеют считать стоимость инфраструктуры в разрезе сервиса/транцакции.
Нужна или нет оптимизация неплохо считается в деньгах. Например, если команда из 10 человек пишет сервис который занимает 1 сервер, разработка стоит дороже эксплуатации. А если сервис занимает уже 2-3 стойки, то зарплата разработки на порядок меньше расходов на инфраструктуру. Получается, что на начальном этапе развития сервиса на оптимизацию можно забить, что потом вылезет под нагрузкой. Это не отменяет, что разработка, в лице архитектора должна думать на шаг вперед, правильно строить архитектуру, выбирать стэк, ревьювить решения соизмеримо нагрузке планируемой.
Странная статья, зачем такое переводить. Единственное отличие service mesh от классического api-gateway, это распределённый data plane. За счет sidecar расположенного рядом с сервисом, мы уменьшаем сетевые задержки до балансера, можем вынести tls из сервиса(в api-gateway тоже можем, но выше возможность перехвата незащищённого трафика), для больших систем уменьшаем нагрузку на балансер, благодаря публикации на sidecar только необходимой части правил для исходящего роутинга.
А в статье какие-то выдуманные отличия. Service discovery, rate limiter, cb, мониторинг, трейсинг, авторизация и аутентификация, зеркалирование трафика - это всё можно использовать в обоих парадигмах.
"Это другое":-) Проблему дорогой последней мили Starlink и подобные пока не решает. Оборудование и абон. плата дорогие, если шарить, нужна всё та же последняя миля. Я скорее про небольшие населенные пункты, где канала во внешний мир либо нет совсем, либо это древняя телефонная медная линия.
Плохая еденица измерения. Так можно сравнивать с Красноярским краем и все страны кроме топ 10 будут меньше.
Япония совсем не маленькая, с учетом гор и сотен, если не тысяч мелких островов вполне актуально.
У нас так же, в маленьком и густонаселённом Краснодарском крае куча мест где ни кто не горит желанием тянуть 20 км оптики через горы для пары сотен абонентов.
Всё, что описано в списке проблем, это не от ускоренного обучения, а обычные проблемы техногика. Любого другого увлеченного человека. Я, например, лет до 25 не только игнорировал гуманитарные предметы, но даже кино не смотрел. Вполне комфортно общаясь со сверстниками. Про музыку, так же. Меладзе это же не на 5 лет разница, а на поколение, общение со сверстниками ни как бы на это не повлияло.
Всё дело в сложной человеческой природе. Зарплата как мотивация работает только для низкоквалифицированного труда, пока ее хватает на еду. С ростом квалификации и дохода, нужны дополнительные источники мотивации. Тут важен и общий настрой в компании, понимание целей и даже человеческие качества топ менеджмента и владельцев.
Что бы ответить на этот вопрос, нужно учесть очень много факторов. Размер группы которая останется без работы(относительный, абсолютный), уровень образования, когнитивные способности, культурные и религиозные особенности, эксперименты с безусловным доходом и тд. Боюсь, тут нужен
роботматмодель, так так человеческому мозгу анализировать такие сложные структуры не под силу.Новички и завышенные ожидания две разных причины, беда с пунктуацией просто. Первые переоценивают свои возможности пока не видят всей картины, а вторые уже понимают, но надеются на чудо.
Модное слово, мне кажется его используют слишком часто и не по назначению. Слишком часто что бы обращать на это внимание. Особенно странно бывает слышать про выгорание от людей работающих пару лет в профессии, это не выгорание - лень, завышенные ожидания, стандартные проблемы новичка, после малых успехов видеть себя архитектором через год и потом "выгореть" когда станет понятен масштаб.
Мне больше нравится слово "усталость". Устают в ИТ от разного, чаще, мне кажется от обычных человеческих взаимоотношений чем от необходимости постоянного обучения или решать сложные задачи.
Хороший пример про Юлю в отпуске. Очень важно отдыхать: вечером после работы, в выходные, не забывать про отпуска. Да, можно поработать и 16 часов в день, и без выходных, и подключиться с пляжа поднимать продакшн. Но это должно быть исключением, а не правилом. Иначе ни кому не хватит сил и он устанет. Устанет, даже если делает любимое дело для души. Когда все вокруг привыкнут и решат что это норма и они такие крутые менеджеры. Знаю это, как тот самый человек, который заражает коллег мотивацией работать и который уже уходил в отпуск на полгода.
Heap dump, для анализа проблем в джаве нужен хип дамп, ни каких тепловых карт.
PS. А еще yaml и все кодблоки поломаны в статье.
Это не зоопарк - это жизнь :) Когда источников правды много, лучшее что можно сделать не генерить лишней кастомизации.
Если речь о том, что при централизованном управлении конфигурацией, логгировании и мониторингом заходить на сервера нет необходимости, то это не так.
* Всегда найдутся сервера, о которых узнаешь только когда они поломались и всего выше перечисленного там нет.
* Почти всегда, кроме случая когда много однотипных серверов, зайти во время сбоя и исправить что-то на сервере руками быстрее чем писать плейбук.
* Логов и метрик может быть недостаточно для траблшутинга. Для сложных проблем их всегда будет недостаточно.
и тд.
Это можно для себя так делать. А если в команде несколько людей и они предпочитают разные утилиты. И у тебя тысячи серверов. На них, например, разные варианты linux развернутые разными людьми из разных шаблонов, на протяжении нескольких лет. Не очень реально.
Для админов(а кто еще живёт в консоли) использование утилит аналогов стандартным - злеейшее зло. Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия. В качестве бонуса, не нужно тратить полдня на настройку нового ноутбука под себя, можно работать с любого.
Про автоисправление уже написали, это крутая фича в IDE, где будет ревью, тесты и тд. Но не в консоли, где может не быть ни каких доп проверок, а ошибка может стоить очень дорого.
Не всё так страшно. Базовых знаний по linux и сети достаточно для старта стажёром или даже джуном. Скорее наоборот, из-за большого стека и его высокой изменчивости, польза от знания конкретных продуктов небольшая. Важнее обучаемость и софтскиллы. Глубокие знания линукса и сети нужны, но их и у мидлов то нет. Что бы студент не грустил один траблшутя продакшн, нужен просто ментор.
Без общения с коллегами теряется ещё пара важных моментов, кроме социализации. При работе в команде постоянно происходят дискуссии и споры по разным вопросам. Это позволяет шире смотреть на проблемы, видеть разные варианты решения, которые один человек, даже самый скиловый предусмотреть не сможет. На мой взгляд, "вариться в собственном соку" для не слишком опытного это тупик, для опытного, серьезная потеря в скорости развития. Другой момент, это "случайная мысль". Эффект, когда решение сложной проблемы находится во время обсуждения несвязанных с ней вопросов - просто болтовней за кофе, например, благодаря ассоциациям. Наверно, у этого есть какое-то умное название, но я не знаю.
Возможно постгря на десятках млн уже умрет, не пробовал, но очень хочется. То что выше писал, это проблемы для больших объемов.
Для небольших индексов, либо больших, но с низким рейтом поиска - эластик не плох.
Можно использовать индексы в postgres, поддерживающие полнотекстовый поиск. Но у меня нет такого опыта. В монге, кажется, тоже есть поддержка.
Плохо ходить в эластик с фронта. Это всё-таки БД, хоть и с http интерфейсом: авторизация, изменение схемы, обновление версий, это всё будет приносить боль в такой схеме.
Впрочем он он всегда будет приносить боль, я бы отметил некоторое количество недостатков.
1) Невозможность изменить схему после создания. Мапинги можно добавлять только на новые поля, если изначально неправильно был выбран тип поля, а он 100% будет выбран неправильно при сколько-нибудь сложной схеме данных, что бы изменить мапинги придется полность пересоздать индекс и перелить в него данные.
2) Невозможность перешардирования на лету, как это например сделано в кассандре. Шард это физическая сущность, которая всегда привязана к ноде, если количество шардов не делится на количество нод, а так будет всегда при горизонтальном масштабировании, что бы изменить количество шардов нужно пересоздать индекс и перелить в него данные.
3) Неуправлемое кеширование полей, пресловутая fielddata. Размер fielddata зависит от параметров запроса, если он большой, инстанс упадет в OOM, если его ограничить инстанс перейдет в режим CB и производительность сильно упадет.
4) Это jvm, со всеми вытекающими плюсами и минусами. Из минусов, ограничение на вертикальное масштабирование из размера хипа(а его займет та самая fielddata), накладные на GC, не самая выдающаяся производительность.
5) Отсутсвие нормальной авторизации, её либо не будет совсем, либо это будет сквозное шифрование.
6) Пертурбации с лицензирванием.
Эти недостатки, мне кажется, общеизвестны и частично описаны в документации. Когда для схожей задачи был выбран эластик пару лет назад, очень надеялся что это все проблемы, но была обнаружена еще одна. Пункт 3 и 4 из списка выше, выливаются в ботлнек на поиск в виде нескольких тысяч rps на 1 ноду. При нагрузке выше начинается гонка при получении блокировки к fielddata cache и дальнейшее масштабирование возможно только увеличением колчества нод и шардов.
Это если в ИТ за деньгами. А если это было по любви, то ни чего не меняется. Так даже интереснее, делать то что нравится, да еще и нужно другим. 8 часов в день ходишь на митинги, дейлики и правишь чужой код потому что надо, потом еще пару часиков допиливаешь его же для души.
Изначально плохо поставлен вопрос. Любое изменение без цели несёт вред,
повышает энтропию и приближает тепловую смерть вселенной. Заказчиком оптимизации выступает почти всегда эксплуатация, а не бизнес. Просто потому что мало где умеют считать стоимость инфраструктуры в разрезе сервиса/транцакции.Нужна или нет оптимизация неплохо считается в деньгах. Например, если команда из 10 человек пишет сервис который занимает 1 сервер, разработка стоит дороже эксплуатации. А если сервис занимает уже 2-3 стойки, то зарплата разработки на порядок меньше расходов на инфраструктуру. Получается, что на начальном этапе развития сервиса на оптимизацию можно забить, что потом вылезет под нагрузкой. Это не отменяет, что разработка, в лице архитектора должна думать на шаг вперед, правильно строить архитектуру, выбирать стэк, ревьювить решения соизмеримо нагрузке планируемой.
Странная статья, зачем такое переводить.
Единственное отличие service mesh от классического api-gateway, это распределённый data plane. За счет sidecar расположенного рядом с сервисом, мы уменьшаем сетевые задержки до балансера, можем вынести tls из сервиса(в api-gateway тоже можем, но выше возможность перехвата незащищённого трафика), для больших систем уменьшаем нагрузку на балансер, благодаря публикации на sidecar только необходимой части правил для исходящего роутинга.
А в статье какие-то выдуманные отличия. Service discovery, rate limiter, cb, мониторинг, трейсинг, авторизация и аутентификация, зеркалирование трафика - это всё можно использовать в обоих парадигмах.
"Это другое":-) Проблему дорогой последней мили Starlink и подобные пока не решает. Оборудование и абон. плата дорогие, если шарить, нужна всё та же последняя миля. Я скорее про небольшие населенные пункты, где канала во внешний мир либо нет совсем, либо это древняя телефонная медная линия.
Плохая еденица измерения. Так можно сравнивать с Красноярским краем и все страны кроме топ 10 будут меньше.
Япония совсем не маленькая, с учетом гор и сотен, если не тысяч мелких островов вполне актуально.
У нас так же, в маленьком и густонаселённом Краснодарском крае куча мест где ни кто не горит желанием тянуть 20 км оптики через горы для пары сотен абонентов.
Всё, что описано в списке проблем, это не от ускоренного обучения, а обычные проблемы техногика. Любого другого увлеченного человека. Я, например, лет до 25 не только игнорировал гуманитарные предметы, но даже кино не смотрел. Вполне комфортно общаясь со сверстниками. Про музыку, так же. Меладзе это же не на 5 лет разница, а на поколение, общение со сверстниками ни как бы на это не повлияло.
Всё дело в сложной человеческой природе. Зарплата как мотивация работает только для низкоквалифицированного труда, пока ее хватает на еду. С ростом квалификации и дохода, нужны дополнительные источники мотивации. Тут важен и общий настрой в компании, понимание целей и даже человеческие качества топ менеджмента и владельцев.