Я думаю, что он там не только в докере, а ещё и в виртуалке поверх этого самого докера.
Уже прошли те времена, когда виртуализация\контейнеризация оказывала какое-то существенное влияние на производительность. У докера оверхеда практически нет, у виртуализации - в пределах погрешности (а применительно к БД иногда и напротив выигрыш бывает - потому что кеширование дисковых операций работает чуть интереснее, чем на bare metal). В любом случае, жертвовать 1% производительности ради потери управляемости - нонсенс, железо стоит значительно дешевле времени людей, которые его обслуживают.
Просто гляньте, как на крупных платформах (GCP, Azure, AWS) работает Managed SQL.
Всё с DevOps в порядке. Не нужно путать макро- и микроуровень, и всё станет на свои места.
Если у Вас управление релизным циклом существует только в виде "нескольких команд cp", а в качестве среды выполнения крутится десяток (ну пускай даже сотня) виртуалок, то оно вам и в самом деле не надо.
Большая часть аргументов в статье сводится к тому, что Ваш продукт не очень большой, и оверхеды, вносимые собственными девопсами - существенны. Но это ведь касается не только девопсов - даже обычный найм программистов не масштабирует их производительность линейно при совместной работе над одной задачей.
Но вот есть, например, такой комплайнс - в определенном продукте нужно создавать изолированные среды для каждого заказчика, мультитенант не катит. Говоря проще - провайжнить продукт тысячами отдельных инстансов, и менеджить всё это. Скриптами будем делать, или возьмем всё же готовое?
Опять же, деливери - это всегда контейнеры. Нравится, не нравится - ну вот такое оно, сегодняшнее настоящее. Если привыкли править на проде - будет мешаться, а если выстроены процессы быстрой доставки в этот самый прод - будет помогать обеспечивать SLA.
TL;DR: как и любой другой инструмент, DevOps методологию нужно оценивать не для абстрактного, а конкретно для вашего проекта. Экстраполировать же свои проекты на других - плохое хобби.
Так вот увеличение размера пакета пропорционально снижает оверхед от операций декапсуляции TCP и в общем-то позволяет возвращать нормальную логику работы приложений (с прыжками в ядро за свежей информацией от сетевой карты). Насчет увеличения пропускной способности на 50% - мне сложно сказать, что они там меряли, но явно не в bandwidth упирались.
Как правило, нарезка на сегменты "окончательного" размера происходит в самом конце, уже после SSL offload. До этого внутри приватных сетей может быть что хочешь и с каким угодно размером мту, лишь бы L1 позволял. А оно виртуальное процентов на 90 нынче, так что позволит хоть гигабайт, хоть три.
Когда я работал с 25\40G аплинками - мы решали достаточно очевидную, и в то же время сложную задачу. Банально - процессору не хватает гигагерц, чтобы индивидуально обрабатывать каждый приходящий пакет, насыщенный 25г линк может бодро кинуть вам на дата плейн 40 миллионов пакетов в секунду, и на их софтовый разбор останется около 100 процессорных тактов на пакет (и это - оптимистичный вариант). Приходится по-всякому кроить время - сначала ПЛИСина на сетевой карте занимается коннтрекингом и отправляет каждое соединение на конкретный TX\RX чейн (который привязан к определенному физическому ядру), потом через DMA все эти штуки попадают в кольцевые буфера - таким образом не нужно генерировать прерывание на каждый пакет и отрабатывать какое-то определенное количество пакетов за один чих.
А дальше начинается тёмная материя - например, чтобы сократить количество context switch из режима ядра в режим пользователя, стек TCP\IP выносится в юзерспейс целиком в контекст обслуживающего процесса, для него через mmap() из ядра вытаскивается тот самый кольцевой буфер сетевой карты, и всё это бодро крутится в юзерспейсе без дорогостоящих прыжков в ядро за новыми пакетами от сетевухи. Люто и весело, в общем.
И это 40г, а что там на 100г - я даже подумать боюсь. Но подозреваю, что там без балансировщика на входе делать нечего.
Да можно и /dev/urandom по кругу гонять, и даже /dev/zero
Трунасы\медиаволты\тдтп это конечно хорошо, но ничего из этого не требует даже jumbo frames. Чтобы почувствовать какой-то буст, Вам как минимум понадобится какой-то кластер, low-latency свитч, FCoE\RoCE\RDMA\bla-bla-bla-capable сетевухи ну и некий ингресс, чтобы всё это в массы отдавать. Суммарная стоимость такого барахлишка выскочит по цене примерно как полторы-две квартиры, в которых снимались фоточки и видосики, так что целесообразность под вопросом.
Про нагрузку забыл. Гигабитный зырнет сейчас даже трехкопеечный арм в полку уводит, так что придётся либо делать кат6 вайринг, либо оптику кидать. Но самое забавное то, что обычный nvme ssd, зацепленный к usb4\thunderbolt положит всё это дело на лопатки в сценариях использования одним пользователем.
Рискну предположить, что существует ряд принципиальных ограничений. И самое главное - запрет фрагментации TCP-сегментов, означающий, что нижестоящие уровни модели OSI позволят надежно обмениваться сегментами такой длины.
В домашних условиях редкий свич умеет MTU выше 1600, так что будет по-старинке MSS 1460 без всякого вот этого. Да и скажем честно - ну вот даже 9к фреймы взять дома особо не откуда, разве что если у Вас только нет выделенного SAN сегмента для какой-нибудь лабы.
Powershell смотрит с недоумением на "нормальный" кли. Видали мы башовские портянки, там соотношение костылей к полезной нагрузке превышает все разумные пределы. Это так, к слову об ущербности тулинга.
Использовать текстовый интерфейс в графической среде - совершенно нормально, если пользователя это устраивает. Персонально я использую тотал, но знаю десятки людей, которые счастливы с FAR. И если фар делает их жизнь проще - то это отличная программа.
Ценность любой программы заключается в первую очередь в количестве пользы, которую она приносит людям. Гуй\не гуй\кли\не кли\виндовс\не виндовс - совершенно не имеет значения.
обычный i7-1185G7 легко работает полный рабочий день (9+ часов) в 13-дюймовом ультрабуке.
Я думаю, что в каких-нибудь маркетинговых задачах его легко можно заставить прожить часов 12, а ноутбук у самсунга наверняка будет побольше и потяжелее хотя бы из-за бОльшей диагонали.
Ну вот у меня совершенно чудесный Dell XPS 13, к которому придраться можно только по качеству встроенных динамиков. Если сунг выкатит что-то подобное - будет пользоваться спросом.
И чем плох ирис? В сегменте бизнес-ноутбуков его за глаза вообще хватает, а игрушки играть на ноутбуке нужно далеко не всем.
Там в любом случае два варианта - или быстрообучаемый с хорошей базой, или какие-то курсы + пару раз делал чекаут какого-нибудь фреймворка. Нужны и те и другие, но сегменты рынка разные. На какой-нибудь битрикс тоже сейчас требуются-требуются, но от души посоветовать такой карьерный путь я никак не могу.
В статье ни слова про английский язык. Имея уверенный B1 (активный, т.е. говорить надо) - без работы не останетесь.
Публичный гит - всегда плюсик, главное чтобы код был свой, а не чей-нибудь.
Курсы, как мне кажется, больше работают на DevOps направлении. В программировании на начальных уровнях важны алгоритмы\структуры данных, литкод (пусть даже изи, но много). Умение писать код в блокноте демонстрирует уровень реального владения языком. От джуна тут странно ждать каких-то откровений, но как минимум синтаксис должен быть правильным =)
Главное - здраво оценивать свои скиллы и понимать, что путь из джунов наверх займет несколько лет. И всё это время придётся учиться каждый день.
TL;DR: открываешь литкод и начинаешь решать. за полгода накопится 200 задач, с ними идешь на собес и получаешь оффер, всё.
А что с долговечностью и с устойчивостью ко внешнему воздействию у таких устройств?
Коробку с кассетами я могу уронить со второго этажа или залить водой\пеной, с огромной вероятностью после этого данные получится вытащить. Ну и лежать они могут почти вечно, у меня LTO5 архив уже лет 10 вполне себе доступен, периодически вытаскиваем из него информацию.
Смысл кассет как раз в их простоте, дешевизне и надежности - во всем остальном HDD или флеш значительно удобнее.
Как минимум в голове освежаются структуры данных, да и в целом в работе меньше начинаешь бояться алгоритмических каких-то штук.
Но лень. Премиум помогает два месяца в году - за месяца до экспайра и месяц после продления премиума :) Приходится себя заставлять, но это уже не к литкоду вопросы.
Лишний раз напомню, что в верхней линейке Zenbook у ASUS есть проблемы с петлями. Точно такие же, как у дешевого китая, и точно тот же поксипол в качестве решения. А официальный сервис в процессе ремонта петли умудрился сжечь материнку, а затем долго и нудно судиться. Асус в данной ситуации хранил гордое молчание, а я в свою очередь выкинул асус из всех закупок и ушел в Dell.
Поддержка - а нет её больше. Свежекупленный за ~180к Dell XPS вместо двухлетней гарантии показывает болт, т.к. компания ушла с рынка и до свидания.
Реальные же проблемы - кривой биос, отваливающиеся устройства на thunderbolt, отсутствие запчастей и нежелание любого СЦ браться за решение минимальных проблем.
Но проблемы с китайскими нонейм ноутбуками - это мелочи. Вы ещё автомобилей не видели :)
Особенно - rpi, производительность которого в десяток раз ниже самой дохлой виртуалки (в первую очередь из-за медленного io).
Из всех описанных задач только HomeAssistant более-менее релевантен, и то по уму его нужно дублировать в дц, т.к. задачи включения света в доме - критичны, а рпи не является сколько-нибудь надежной железякой в принципе.
Автор упускает, что всему устанавливаемому на домашний сервер софту требуется обслуживание. Тот же nextcloud нужно обновлять, для Plex нужна большая хранилка, трансмишн на rpi - боль, т.к. нет сата интерфейсов. Между apt install trasmission и нормальным сидбоксом - пропасть, равно как пропасть между любым прототипом и коммерческим продуктом.
Более того - знания, полученные в процессе ковыряния со всеми этими продуктами, на рынке труда не будут стоить ни копейки. Вам не дадут денег за умение ковырять дебиан, а навык администрирования nextcloud сам по себе тоже не является востребованным скиллом. Но вы потратите МНОГО времени на запуск и поддержку "бесплатного и дешевого" домашнего сервера.
Не будем ходить далеко - даже если вместо ковыряния некстклауда заняться ковырянием какого-нибудь Docker - то те же некстклауды вы будете поднимать пачками по щелчку пальцев, у Вас будет универсальный реюзабельный конфиг и десятки бесплатных виртуалок по реферральным программам всех ваших заказчиков. А на сэкономленные деньги вы легко сможете оплатить пару подписок на какие-нибудь киношно-музыкальные сервисы и смотреть кинцо on demand без трансмишнов и плексов.
4 собеседования за последнюю неделю. И на каждом - алго секция есть. Небольшая, задачи простые (связные списки, бинарный поиск, обход дерева) - но если их заранее не прорешать, то будет немного бледный вид.
Но справедливости ради - это 0.5% от того, что спросят на алгособесе на middle+ SWE.
Я думаю, что он там не только в докере, а ещё и в виртуалке поверх этого самого докера.
Уже прошли те времена, когда виртуализация\контейнеризация оказывала какое-то существенное влияние на производительность. У докера оверхеда практически нет, у виртуализации - в пределах погрешности (а применительно к БД иногда и напротив выигрыш бывает - потому что кеширование дисковых операций работает чуть интереснее, чем на bare metal). В любом случае, жертвовать 1% производительности ради потери управляемости - нонсенс, железо стоит значительно дешевле времени людей, которые его обслуживают.
Просто гляньте, как на крупных платформах (GCP, Azure, AWS) работает Managed SQL.
Всё с DevOps в порядке. Не нужно путать макро- и микроуровень, и всё станет на свои места.
Если у Вас управление релизным циклом существует только в виде "нескольких команд cp", а в качестве среды выполнения крутится десяток (ну пускай даже сотня) виртуалок, то оно вам и в самом деле не надо.
Большая часть аргументов в статье сводится к тому, что Ваш продукт не очень большой, и оверхеды, вносимые собственными девопсами - существенны. Но это ведь касается не только девопсов - даже обычный найм программистов не масштабирует их производительность линейно при совместной работе над одной задачей.
Но вот есть, например, такой комплайнс - в определенном продукте нужно создавать изолированные среды для каждого заказчика, мультитенант не катит. Говоря проще - провайжнить продукт тысячами отдельных инстансов, и менеджить всё это. Скриптами будем делать, или возьмем всё же готовое?
Опять же, деливери - это всегда контейнеры. Нравится, не нравится - ну вот такое оно, сегодняшнее настоящее. Если привыкли править на проде - будет мешаться, а если выстроены процессы быстрой доставки в этот самый прод - будет помогать обеспечивать SLA.
TL;DR: как и любой другой инструмент, DevOps методологию нужно оценивать не для абстрактного, а конкретно для вашего проекта. Экстраполировать же свои проекты на других - плохое хобби.
Так вот увеличение размера пакета пропорционально снижает оверхед от операций декапсуляции TCP и в общем-то позволяет возвращать нормальную логику работы приложений (с прыжками в ядро за свежей информацией от сетевой карты). Насчет увеличения пропускной способности на 50% - мне сложно сказать, что они там меряли, но явно не в bandwidth упирались.
Ну это маленько устаревшее видение.
Как правило, нарезка на сегменты "окончательного" размера происходит в самом конце, уже после SSL offload. До этого внутри приватных сетей может быть что хочешь и с каким угодно размером мту, лишь бы L1 позволял. А оно виртуальное процентов на 90 нынче, так что позволит хоть гигабайт, хоть три.
Когда я работал с 25\40G аплинками - мы решали достаточно очевидную, и в то же время сложную задачу. Банально - процессору не хватает гигагерц, чтобы индивидуально обрабатывать каждый приходящий пакет, насыщенный 25г линк может бодро кинуть вам на дата плейн 40 миллионов пакетов в секунду, и на их софтовый разбор останется около 100 процессорных тактов на пакет (и это - оптимистичный вариант). Приходится по-всякому кроить время - сначала ПЛИСина на сетевой карте занимается коннтрекингом и отправляет каждое соединение на конкретный TX\RX чейн (который привязан к определенному физическому ядру), потом через DMA все эти штуки попадают в кольцевые буфера - таким образом не нужно генерировать прерывание на каждый пакет и отрабатывать какое-то определенное количество пакетов за один чих.
А дальше начинается тёмная материя - например, чтобы сократить количество context switch из режима ядра в режим пользователя, стек TCP\IP выносится в юзерспейс целиком в контекст обслуживающего процесса, для него через mmap() из ядра вытаскивается тот самый кольцевой буфер сетевой карты, и всё это бодро крутится в юзерспейсе без дорогостоящих прыжков в ядро за новыми пакетами от сетевухи. Люто и весело, в общем.
И это 40г, а что там на 100г - я даже подумать боюсь. Но подозреваю, что там без балансировщика на входе делать нечего.
Да можно и /dev/urandom по кругу гонять, и даже /dev/zero
Трунасы\медиаволты\тдтп это конечно хорошо, но ничего из этого не требует даже jumbo frames. Чтобы почувствовать какой-то буст, Вам как минимум понадобится какой-то кластер, low-latency свитч, FCoE\RoCE\RDMA\bla-bla-bla-capable сетевухи ну и некий ингресс, чтобы всё это в массы отдавать. Суммарная стоимость такого барахлишка выскочит по цене примерно как полторы-две квартиры, в которых снимались фоточки и видосики, так что целесообразность под вопросом.
Про нагрузку забыл. Гигабитный зырнет сейчас даже трехкопеечный арм в полку уводит, так что придётся либо делать кат6 вайринг, либо оптику кидать. Но самое забавное то, что обычный nvme ssd, зацепленный к usb4\thunderbolt положит всё это дело на лопатки в сценариях использования одним пользователем.
Рискну предположить, что существует ряд принципиальных ограничений. И самое главное - запрет фрагментации TCP-сегментов, означающий, что нижестоящие уровни модели OSI позволят надежно обмениваться сегментами такой длины.
В домашних условиях редкий свич умеет MTU выше 1600, так что будет по-старинке MSS 1460 без всякого вот этого. Да и скажем честно - ну вот даже 9к фреймы взять дома особо не откуда, разве что если у Вас только нет выделенного SAN сегмента для какой-нибудь лабы.
Это может быть банальный датчик движения, примерно такой же, как и для освещения.
Powershell смотрит с недоумением на "нормальный" кли. Видали мы башовские портянки, там соотношение костылей к полезной нагрузке превышает все разумные пределы. Это так, к слову об ущербности тулинга.
Использовать текстовый интерфейс в графической среде - совершенно нормально, если пользователя это устраивает. Персонально я использую тотал, но знаю десятки людей, которые счастливы с FAR. И если фар делает их жизнь проще - то это отличная программа.
Ценность любой программы заключается в первую очередь в количестве пользы, которую она приносит людям. Гуй\не гуй\кли\не кли\виндовс\не виндовс - совершенно не имеет значения.
обычный i7-1185G7 легко работает полный рабочий день (9+ часов) в 13-дюймовом ультрабуке.
Я думаю, что в каких-нибудь маркетинговых задачах его легко можно заставить прожить часов 12, а ноутбук у самсунга наверняка будет побольше и потяжелее хотя бы из-за бОльшей диагонали.
Ну вот у меня совершенно чудесный Dell XPS 13, к которому придраться можно только по качеству встроенных динамиков. Если сунг выкатит что-то подобное - будет пользоваться спросом.
И чем плох ирис? В сегменте бизнес-ноутбуков его за глаза вообще хватает, а игрушки играть на ноутбуке нужно далеко не всем.
Мы же про джуна говорим.
Там в любом случае два варианта - или быстрообучаемый с хорошей базой, или какие-то курсы + пару раз делал чекаут какого-нибудь фреймворка. Нужны и те и другие, но сегменты рынка разные. На какой-нибудь битрикс тоже сейчас требуются-требуются, но от души посоветовать такой карьерный путь я никак не могу.
В статье ни слова про английский язык. Имея уверенный B1 (активный, т.е. говорить надо) - без работы не останетесь.
Публичный гит - всегда плюсик, главное чтобы код был свой, а не чей-нибудь.
Курсы, как мне кажется, больше работают на DevOps направлении. В программировании на начальных уровнях важны алгоритмы\структуры данных, литкод (пусть даже изи, но много). Умение писать код в блокноте демонстрирует уровень реального владения языком. От джуна тут странно ждать каких-то откровений, но как минимум синтаксис должен быть правильным =)
Главное - здраво оценивать свои скиллы и понимать, что путь из джунов наверх займет несколько лет. И всё это время придётся учиться каждый день.
TL;DR: открываешь литкод и начинаешь решать. за полгода накопится 200 задач, с ними идешь на собес и получаешь оффер, всё.
А что с долговечностью и с устойчивостью ко внешнему воздействию у таких устройств?
Коробку с кассетами я могу уронить со второго этажа или залить водой\пеной, с огромной вероятностью после этого данные получится вытащить. Ну и лежать они могут почти вечно, у меня LTO5 архив уже лет 10 вполне себе доступен, периодически вытаскиваем из него информацию.
Смысл кассет как раз в их простоте, дешевизне и надежности - во всем остальном HDD или флеш значительно удобнее.
Однозначно полезно решать литкод.
Как минимум в голове освежаются структуры данных, да и в целом в работе меньше начинаешь бояться алгоритмических каких-то штук.
Но лень. Премиум помогает два месяца в году - за месяца до экспайра и месяц после продления премиума :) Приходится себя заставлять, но это уже не к литкоду вопросы.
Лишний раз напомню, что в верхней линейке Zenbook у ASUS есть проблемы с петлями. Точно такие же, как у дешевого китая, и точно тот же поксипол в качестве решения. А официальный сервис в процессе ремонта петли умудрился сжечь материнку, а затем долго и нудно судиться. Асус в данной ситуации хранил гордое молчание, а я в свою очередь выкинул асус из всех закупок и ушел в Dell.
Поддержка - а нет её больше. Свежекупленный за ~180к Dell XPS вместо двухлетней гарантии показывает болт, т.к. компания ушла с рынка и до свидания.
Реальные же проблемы - кривой биос, отваливающиеся устройства на thunderbolt, отсутствие запчастей и нежелание любого СЦ браться за решение минимальных проблем.
Но проблемы с китайскими нонейм ноутбуками - это мелочи. Вы ещё автомобилей не видели :)
Задач не бывает, а требования вполне могут быть. Всё же инфраструктурный объект, секретность повышенная и вот это всё.
Так-то $100к за сервак - дохрена, конечно. но если учесть, что это практически штучное изделие - вполне допускаю, что так может произойти.
Отсутствие массовости в таких штуках будет делать их цену неподъемной в любом случае, будут там распилы или нет.
В данном случае было закуплено два сервера 2U-2Э16-SC, по 7 с лишним миллионов за штучку.
Вполне допускаю задачи, для которых нужны именно такие процы и именно в таком количестве.
Новость по сути высосана из вполне себе рядовой госзакупки.
Нинасколько не круто иметь свой сервер в комнате.
Особенно - rpi, производительность которого в десяток раз ниже самой дохлой виртуалки (в первую очередь из-за медленного io).
Из всех описанных задач только HomeAssistant более-менее релевантен, и то по уму его нужно дублировать в дц, т.к. задачи включения света в доме - критичны, а рпи не является сколько-нибудь надежной железякой в принципе.
Автор упускает, что всему устанавливаемому на домашний сервер софту требуется обслуживание. Тот же nextcloud нужно обновлять, для Plex нужна большая хранилка, трансмишн на rpi - боль, т.к. нет сата интерфейсов. Между apt install trasmission и нормальным сидбоксом - пропасть, равно как пропасть между любым прототипом и коммерческим продуктом.
Более того - знания, полученные в процессе ковыряния со всеми этими продуктами, на рынке труда не будут стоить ни копейки. Вам не дадут денег за умение ковырять дебиан, а навык администрирования nextcloud сам по себе тоже не является востребованным скиллом. Но вы потратите МНОГО времени на запуск и поддержку "бесплатного и дешевого" домашнего сервера.
Не будем ходить далеко - даже если вместо ковыряния некстклауда заняться ковырянием какого-нибудь Docker - то те же некстклауды вы будете поднимать пачками по щелчку пальцев, у Вас будет универсальный реюзабельный конфиг и десятки бесплатных виртуалок по реферральным программам всех ваших заказчиков. А на сэкономленные деньги вы легко сможете оплатить пару подписок на какие-нибудь киношно-музыкальные сервисы и смотреть кинцо on demand без трансмишнов и плексов.
Плюсану.
4 собеседования за последнюю неделю. И на каждом - алго секция есть. Небольшая, задачи простые (связные списки, бинарный поиск, обход дерева) - но если их заранее не прорешать, то будет немного бледный вид.
Но справедливости ради - это 0.5% от того, что спросят на алгособесе на middle+ SWE.