Большинство современных дево-псов фактически являются yaml-кодерами, способными с большей или меньшей вероятностью написать докерфайл и конфиг для кубернетеса. Как это работает внутри и и что делать, если оно работать перестаёт - они не знают.
А нормальный сисадмин - из тех, кто 30 лет назад мог спокойно пропатчить ядро или какой-нибудь сендмайл, а то и собственную файловую систему написать - сейчас превращается в крайне редкую птицу под названием SRE. Хотя по факту это просто нормальный специалист, умеющий и в инфраструктурную часть на всех уровнях, и в коде поковыряться и поправить кривой SQL-запрос.
Вопрос в стоимости сопровождения. Кубер требует достаточной квалификации и хотя бы одного выделенного девопса. А это сразу +400-500к к ФОТ. Тогда как compose или swarm вполне может освоить приличный разраб.
Вообще, вот Ваше мнение опытного человека - начиная с какого масштаба инсталляции Вы считаете оправданным применение k8s?
Одно другому не противоречит. Кубернетес штука хорошая, но применять его нужно там, где в нём действительно есть потребность. Если у вас кровавый энтерпрайз типа одноклассников или вконтактика и целая команда сеньор-девопсов по сопровождению этого добра - да, применение кубера оправданно. Но его ж пихают куда только можно, я встречал проекты на десяток контейнеров на одной ноде - и для оркестрации подняли k8s, потому что "это модно" и "все так делают".
Только всё то же самое было изобретено десятилетия назад в виде пакетов. deb, rpm, pkg и так далее.
Беда докера не в нём самом, а в том, что контейнерная виртуализация - это мощная, но всё ещё сырая технология, идущая путём проб и ошибок. Те, кто начинал работать с докером давно, помнят его нестабильность на первых порах, помнят глюки unionfs и aufs. Ну ладно, за 10 лет стабилизировали в виде overlayfs. Потом выяснили, что собирать в докере небезопасно и придумали отдельно buildah и buildkit, заодно придумали podman и runc и задумались - а зачем тогда, собственно, докер?..
Я уж про оркестрацию не говорю. Docker compose, docker swarm, rancher, nomad, кубер-мать-его-нетес и openshift. Ну куда столько, а главное - зачем? И всё это отомрёт ещё лет через 5, а придёт что-то новое.
Я согласен с автором в том плане, что возраст даёт представление о ретроспективе. Между 20 и 25 - пропасть, между 40 и 45 - не так уж и много. Банально эти все технологии воспринимаются как бабочки-однодневки, когда ты в профессии 30 лет.
Архитектура - набор ключевых решений при проектировании системы, удовлетворяющих следующим критериям:
Проблема уже в самом начале статьи: Вы путаете понятие "архитектура" и характеристику "хорошая архитектура". О критериях "хорошей" можно рассуждать долго, но и плохая архитектура приложения - тоже архитектура.
Тут вопрос, понимает ли человек, какую именно пользу он приносил предыдущему работодателю и способен ли он сформулировать, какую пользу он принёсет новому.
Если Вам нужно сделать дома электрику и Вы нанимаете исполнителя - вряд ли Вас устроит формулировка "я клал провода и приделывал выключатели". Скорее уж Вы хотите услышать "я сделал под ключ 40 объектов от однушек-хрущёвок до коттеджей на 3000 квадратов, Вашу квартиру тоже могу сделать".
Если работник, даже самый рядовой, не может сформулировать, ЗАЧЕМ была нужна его работа - в компетенции этого работника появляются сомнения.
Кто-то выбирал метрики, кто-то писал документацию и ТЗ, кто-то собирал данные, кто-то решал, где и как они будут храниться, кто-то прописывал алгоритмы их подсчета, кто-то дизайнил, кто-то кодил фронт, кто-то кодил бэк
В итоге на вопрос "кто шил костюм" ответа не дождаться.
И это, увы, массовая тенденция среди современных программистов: "моя задача - тикеты в джире закрывать, а зачем это надо - пусть ПМ думает". Разработчики вообще не представляют и не хотят представлять сути бизнес-процессов, которые они автоматизируют, в итоге деградируют до обычных кодеров.
Я полагаю, что Вы утрировали, перечисляя количество необходимых для разработки дашборда специалистов, но это пугает. Разве что Вы описывали Газпром какой-нибудь. Потому что в моей практике такие дашборды для банка из Top100, с сотней филиалов по стране и штатом в несколько тысяч человек писались силами команды из 3-х разработчиков. И да, эти дашборды включали в себя сбор всего - от бизнес-метрик из АБС и до среднего времени ответа на тикет в сервисдеске и средним временем опоздания из СКУД.
3 человека, понимаете? Не десяток, не сотня. Опытный тимлид, который сам в состоянии принять решения "где хранить, как обрабатывать" и может общаться с бизнесом, разбираться, что ему надо и как; разраб-мидл на текущие задачи и разработчик корпоративного портала, куда этот дашборд был интегрирован.
Сертификат гарантирует хотя соответствие продукции и производителя определённым нормам на момент сертификации.
В частности - что этот сыр вообще можно есть и что это именно сыр с проверенной рецептурой и ингредиентами, а также что на производстве соблюдаются санитарные нормы и мигранты с ближнего Востока не омывают ноги в чане с закваской.
Отсюда резко снижается область потенциальных мест для расследования. Хранение - да, транспортировка - да, ну и локальные нарушения норм на производстве никаким сертификатом не гарантируешь.
Но именно для этого магазин, торгующий сыром, тоже должен иметь сертификаты и регламенты хранения, в которых будет прописано - как обязан этот сыр храниться и что храниться он будет именно в правильных холодильниках, а не в доставшемся от дедушки. И перевозчик тоже обязан иметь как минимум сантехпаспорт транспортного средства (что в этом драндулете вообще можно возить еду), а в случае перевозки скоропортящихся продуктов - там отдельные дополнения к транспортной накладной оформляются.
Разумная доля свободы, безусловно, должна быть - но именно разумная. И она должна быть ОЧЕНЬ разумная там, где речь идёт о жизнях людей.
Кто в Голландии будет отвечать, если этим сыром всё-таки отравится сто человек , из них двадцать - насмерть, из них пятеро - дети?
С учётом реалий нашей страны, где приблизительно у 100% населения - криминальное мышление - сертификация и жёсткий контроль просто необходимость. Хорошо будет, если когда-то это поменяется, но пока вот так.
Никуда не дели. SPL теперь является частью ядра PHP, а типизация является переключаемой. По умолчанию, для совместимости, работает слабая, но можно объявить директиву strict_types и будет строгая.
В общем, обратная совместимость очень высокая, до сих пор можно писать в старом стиле, но в современном коде есть возможность использовать все современные подходы.
PHP сейчас всё ближе к джаве и у хороших пхп-шников всё в порядке и с шаблонами проектирования, и с пониманием SOLID, GRASP и DDD и со сложными структурами языка.
И получить пачку исков от клиентов, включая требование возмещения косвенных убытков и недополученной прибыли. С учётом того, насколько быстро сейчас сайты вылетают из топа поисковиков в случае падения сервиса, после нескольких десятков исков хостеру придется закрыться, продать оборудование и левую почку.
Ещё на вузовской скамье самостоятельно учат реально востребованные на рынке технологии, языки и фреймворки, участвуют в опенсорс-проектах, благо там всегда руки нужны, или пилят собственные пет-проекты для удовольствия.
И к окончанию ВУЗа имеют уже портфолио, пачку статей на хабре, а не то и широкую известность в узких кругах.
Большинство современных дево-псов фактически являются yaml-кодерами, способными с большей или меньшей вероятностью написать докерфайл и конфиг для кубернетеса. Как это работает внутри и и что делать, если оно работать перестаёт - они не знают.
А нормальный сисадмин - из тех, кто 30 лет назад мог спокойно пропатчить ядро или какой-нибудь сендмайл, а то и собственную файловую систему написать - сейчас превращается в крайне редкую птицу под названием SRE. Хотя по факту это просто нормальный специалист, умеющий и в инфраструктурную часть на всех уровнях, и в коде поковыряться и поправить кривой SQL-запрос.
Вопрос в стоимости сопровождения. Кубер требует достаточной квалификации и хотя бы одного выделенного девопса. А это сразу +400-500к к ФОТ. Тогда как compose или swarm вполне может освоить приличный разраб.
Вообще, вот Ваше мнение опытного человека - начиная с какого масштаба инсталляции Вы считаете оправданным применение k8s?
Проксмокс сам умеет мигрировать виртуалки в обоих случаях. Не так красиво, как в vSphere, но для маленьких инсталляций вполне сойдёт.
Одно другому не противоречит. Кубернетес штука хорошая, но применять его нужно там, где в нём действительно есть потребность. Если у вас кровавый энтерпрайз типа одноклассников или вконтактика и целая команда сеньор-девопсов по сопровождению этого добра - да, применение кубера оправданно. Но его ж пихают куда только можно, я встречал проекты на десяток контейнеров на одной ноде - и для оркестрации подняли k8s, потому что "это модно" и "все так делают".
Только всё то же самое было изобретено десятилетия назад в виде пакетов. deb, rpm, pkg и так далее.
Беда докера не в нём самом, а в том, что контейнерная виртуализация - это мощная, но всё ещё сырая технология, идущая путём проб и ошибок. Те, кто начинал работать с докером давно, помнят его нестабильность на первых порах, помнят глюки unionfs и aufs. Ну ладно, за 10 лет стабилизировали в виде overlayfs. Потом выяснили, что собирать в докере небезопасно и придумали отдельно buildah и buildkit, заодно придумали podman и runc и задумались - а зачем тогда, собственно, докер?..
Я уж про оркестрацию не говорю. Docker compose, docker swarm, rancher, nomad, кубер-мать-его-нетес и openshift. Ну куда столько, а главное - зачем? И всё это отомрёт ещё лет через 5, а придёт что-то новое.
Я согласен с автором в том плане, что возраст даёт представление о ретроспективе. Между 20 и 25 - пропасть, между 40 и 45 - не так уж и много. Банально эти все технологии воспринимаются как бабочки-однодневки, когда ты в профессии 30 лет.
Проблема уже в самом начале статьи: Вы путаете понятие "архитектура" и характеристику "хорошая архитектура". О критериях "хорошей" можно рассуждать долго, но и плохая архитектура приложения - тоже архитектура.
А если предположить, что болтающие с Алисой люди как раз и находятся на упомянутом Вами уровне интеллекта?..
Сколько разработчиков при этом было в команде проекта, если не секрет?
Тут вопрос, понимает ли человек, какую именно пользу он приносил предыдущему работодателю и способен ли он сформулировать, какую пользу он принёсет новому.
Если Вам нужно сделать дома электрику и Вы нанимаете исполнителя - вряд ли Вас устроит формулировка "я клал провода и приделывал выключатели". Скорее уж Вы хотите услышать "я сделал под ключ 40 объектов от однушек-хрущёвок до коттеджей на 3000 квадратов, Вашу квартиру тоже могу сделать".
Если работник, даже самый рядовой, не может сформулировать, ЗАЧЕМ была нужна его работа - в компетенции этого работника появляются сомнения.
В итоге на вопрос "кто шил костюм" ответа не дождаться.
И это, увы, массовая тенденция среди современных программистов: "моя задача - тикеты в джире закрывать, а зачем это надо - пусть ПМ думает". Разработчики вообще не представляют и не хотят представлять сути бизнес-процессов, которые они автоматизируют, в итоге деградируют до обычных кодеров.
Я полагаю, что Вы утрировали, перечисляя количество необходимых для разработки дашборда специалистов, но это пугает. Разве что Вы описывали Газпром какой-нибудь. Потому что в моей практике такие дашборды для банка из Top100, с сотней филиалов по стране и штатом в несколько тысяч человек писались силами команды из 3-х разработчиков. И да, эти дашборды включали в себя сбор всего - от бизнес-метрик из АБС и до среднего времени ответа на тикет в сервисдеске и средним временем опоздания из СКУД.
3 человека, понимаете? Не десяток, не сотня. Опытный тимлид, который сам в состоянии принять решения "где хранить, как обрабатывать" и может общаться с бизнесом, разбираться, что ему надо и как; разраб-мидл на текущие задачи и разработчик корпоративного портала, куда этот дашборд был интегрирован.
А чего с фрилансом не так, не подскажете?
Фрилансил до сентября прошлого года, куча знакомых фрилансит до сих пор. В самых разных сферах. У всех всё хорошо. Что мы делаем не так?)
Можно идти во фрилансеры с почасовой оплатой и работать столько, сколько захочется.
Сертификат гарантирует хотя соответствие продукции и производителя определённым нормам на момент сертификации.
В частности - что этот сыр вообще можно есть и что это именно сыр с проверенной рецептурой и ингредиентами, а также что на производстве соблюдаются санитарные нормы и мигранты с ближнего Востока не омывают ноги в чане с закваской.
Отсюда резко снижается область потенциальных мест для расследования. Хранение - да, транспортировка - да, ну и локальные нарушения норм на производстве никаким сертификатом не гарантируешь.
Но именно для этого магазин, торгующий сыром, тоже должен иметь сертификаты и регламенты хранения, в которых будет прописано - как обязан этот сыр храниться и что храниться он будет именно в правильных холодильниках, а не в доставшемся от дедушки. И перевозчик тоже обязан иметь как минимум сантехпаспорт транспортного средства (что в этом драндулете вообще можно возить еду), а в случае перевозки скоропортящихся продуктов - там отдельные дополнения к транспортной накладной оформляются.
Разумная доля свободы, безусловно, должна быть - но именно разумная. И она должна быть ОЧЕНЬ разумная там, где речь идёт о жизнях людей.
Кто в Голландии будет отвечать, если этим сыром всё-таки отравится сто человек , из них двадцать - насмерть, из них пятеро - дети?
С учётом реалий нашей страны, где приблизительно у 100% населения - криминальное мышление - сертификация и жёсткий контроль просто необходимость. Хорошо будет, если когда-то это поменяется, но пока вот так.
Никуда не дели. SPL теперь является частью ядра PHP, а типизация является переключаемой. По умолчанию, для совместимости, работает слабая, но можно объявить директиву strict_types и будет строгая.
В общем, обратная совместимость очень высокая, до сих пор можно писать в старом стиле, но в современном коде есть возможность использовать все современные подходы.
Ну вот критерий "нет нормальных классов" - он как раз здравый и абсолютно понятный.
Востребованность на рынке, функциональность, область применения - да. А скобочки - ну такое...
Каков подход, таковы и комментарии. Выбор языка из-за моды и скобочек - чисто женский подход, отсюда и комментарии такие.
PHP сейчас всё ближе к джаве и у хороших пхп-шников всё в порядке и с шаблонами проектирования, и с пониманием SOLID, GRASP и DDD и со сложными структурами языка.
И получить пачку исков от клиентов, включая требование возмещения косвенных убытков и недополученной прибыли. С учётом того, насколько быстро сейчас сайты вылетают из топа поисковиков в случае падения сервиса, после нескольких десятков исков хостеру придется закрыться, продать оборудование и левую почку.
Ещё на вузовской скамье самостоятельно учат реально востребованные на рынке технологии, языки и фреймворки, участвуют в опенсорс-проектах, благо там всегда руки нужны, или пилят собственные пет-проекты для удовольствия.
И к окончанию ВУЗа имеют уже портфолио, пачку статей на хабре, а не то и широкую известность в узких кругах.