а как же другие решения на базе CNI, помимо flannel? например weave net или calico? и ещё пара других что упомянуты на просторах мануалов по настройке сети для kubernetes? их совсем не рассматривали или есть какая то объективная причина почему они были исключены?
многие из них утверждают что они «быстрее» чем flannel, вот и хотелось бы узнать насколько это правда…
список тут https://kubernetes.io/docs/concepts/cluster-administration/networking/
К сожалению слепое следование подобному подходу порождает до ужаса однобоких специалистов.
Я бы сказал что так должно быть в идеале в крупных проектах с большими командами (и обычно так и есть),
однако, если программист "только пишет код" и никогда даже не пытался "во все остальное", это чаще всего крайне посредственный программист.
Специалист должен знать смежные области, чтобы быть специалистом в своей.
Не выбирать фреймворк и не подбирать библиотеки: это роль архитектора
Программисту необходимо понимать почему был выбран именно этот фреймворк.
в зависимости от политики и размера команды и состояния проекта (например в начале) — принимать участие в обсуждении выбора оного вместе с архитектором.
Не закупать железо или облачные ресурсы: это сисадмин
Закупать железо не должен, но как минимум должен иметь представление на каких мощностях и платформах его код может/должен работать.
Не проектировать базу данных: это DBA
Очень спорно что программист не должен принимать в этом участия, выделенные DBA — это больше удел "у нас половина бизнес логики в БД", а обычно же бизнес-логика БД сильно переплетена с приложением (во всяком случае приложения рассчитывают на те гарантии что дают им БД), и знать реляционную теорию и принципы работы с массивами данных — прямая обязанность программиста, также как и принимать участие в проектировании процессов работы с данными.
Не заниматься выкладкой кода в бой и обновлением: это dev-ops
Да, хорошо когда этим занимаются отдельные люди, но понимание должно быть и приложения должны быть написаны таким образом, чтобы упрощать этот процесс, а это уже обязанность программиста а не dev-ops.
Не тестировать и не писать тестовые сценарии: это QA
Смотря что подразумевать под тестированием: автотесты (юнит, апи, интеграционные), само понимание того как сделать софт "тестируемым", проверка функциональности того что программист непосредственно пишет, да и вообще всяческий самоконтроль — это только в плюс, очень тяжело работать с людьми которые даже базово не пытаются проверять что пишут.
Я сталкивался с подобным, когда на ревью / к тестерам / в сборку отправляли вообще никак не работающий и не проверенный код, и это в больших компаниях, а в малых то и тестер не всегда есть.
и даже не настраивать себе софт на рабочем месте
Вот это, простите уже перебор, я бы даже не стал работать в месте где не могу настроить себе машину так как мне нужно, а человека который не может себе настроить рабочее окружение, никогда не возьму на работу.
Да, могут быть всякие штуки по безопасности которые настраиваются централизованно, и контролируется это отделом безопасности, но — рабочее окружение — это не их водчина.
В заключении скажу, что по моему опыту, огромная доля профессионального роста происходит как раз за счет понимания смежных областей. Огромное количество хороших практик разработки пришло как раз из понимания как облегчить жизнь себе и другим.
Программист должен знать те инструменты с которыми он работает.
Статья как раз о том — что нужно понимать почему мы выбираем тот или иной инструмент, нужно понимать как он работает изнутри, чем он нам поможет, а чем может навредить. А что бы хоть на каком то уровне это понимать нужно хоть немного (а чем больше тем лучше) "мочь в смежные области" — это и для себя хорошо и для работодателя. Без понимания этих вещей, которыми программист вроде бы не должен заниматься, невозможно грамотно этот самый инструмент выбрать и избежать тем самом казусов описанных автором.
Заодно такое понимание может привести вас к возможности исполнять те самые роли, которые "должны" этим заниматься, а иначе откуда же возьмутся все те "разбирающиеся в технологии" консультанты и крутые архитекторы которые подскажут что же надо выбрать и почему.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Устройство JS — интерактивная презентация: Loupe
в дополнение к статье хорошо зайдет.
многие из них утверждают что они «быстрее» чем flannel, вот и хотелось бы узнать насколько это правда…
список тут https://kubernetes.io/docs/concepts/cluster-administration/networking/
К сожалению слепое следование подобному подходу порождает до ужаса однобоких специалистов.
Я бы сказал что так должно быть в идеале в крупных проектах с большими командами (и обычно так и есть),
однако, если программист "только пишет код" и никогда даже не пытался "во все остальное", это чаще всего крайне посредственный программист.
Специалист должен знать смежные области, чтобы быть специалистом в своей.
Программисту необходимо понимать почему был выбран именно этот фреймворк.
в зависимости от политики и размера команды и состояния проекта (например в начале) — принимать участие в обсуждении выбора оного вместе с архитектором.
Закупать железо не должен, но как минимум должен иметь представление на каких мощностях и платформах его код может/должен работать.
Очень спорно что программист не должен принимать в этом участия, выделенные DBA — это больше удел "у нас половина бизнес логики в БД", а обычно же бизнес-логика БД сильно переплетена с приложением (во всяком случае приложения рассчитывают на те гарантии что дают им БД), и знать реляционную теорию и принципы работы с массивами данных — прямая обязанность программиста, также как и принимать участие в проектировании процессов работы с данными.
Да, хорошо когда этим занимаются отдельные люди, но понимание должно быть и приложения должны быть написаны таким образом, чтобы упрощать этот процесс, а это уже обязанность программиста а не dev-ops.
Смотря что подразумевать под тестированием: автотесты (юнит, апи, интеграционные), само понимание того как сделать софт "тестируемым", проверка функциональности того что программист непосредственно пишет, да и вообще всяческий самоконтроль — это только в плюс, очень тяжело работать с людьми которые даже базово не пытаются проверять что пишут.
Я сталкивался с подобным, когда на ревью / к тестерам / в сборку отправляли вообще никак не работающий и не проверенный код, и это в больших компаниях, а в малых то и тестер не всегда есть.
Вот это, простите уже перебор, я бы даже не стал работать в месте где не могу настроить себе машину так как мне нужно, а человека который не может себе настроить рабочее окружение, никогда не возьму на работу.
Да, могут быть всякие штуки по безопасности которые настраиваются централизованно, и контролируется это отделом безопасности, но — рабочее окружение — это не их водчина.
В заключении скажу, что по моему опыту, огромная доля профессионального роста происходит как раз за счет понимания смежных областей. Огромное количество хороших практик разработки пришло как раз из понимания как облегчить жизнь себе и другим.
Программист должен знать те инструменты с которыми он работает.
Статья как раз о том — что нужно понимать почему мы выбираем тот или иной инструмент, нужно понимать как он работает изнутри, чем он нам поможет, а чем может навредить. А что бы хоть на каком то уровне это понимать нужно хоть немного (а чем больше тем лучше) "мочь в смежные области" — это и для себя хорошо и для работодателя. Без понимания этих вещей, которыми программист вроде бы не должен заниматься, невозможно грамотно этот самый инструмент выбрать и избежать тем самом казусов описанных автором.
Заодно такое понимание может привести вас к возможности исполнять те самые роли, которые "должны" этим заниматься, а иначе откуда же возьмутся все те "разбирающиеся в технологии" консультанты и крутые архитекторы которые подскажут что же надо выбрать и почему.