Коллеги то вам как мед "неправильные" девопсы попадались. Правильным - без разницы докер это или не докер. А некоторые даже strace иногда расчехляют. То что пришло поколение после курсов (в основном 2000+ года рождения) которые хотят миллионы и ничего не делать и учится тут я с вами согласен. Не раз собеседуя на таких нарывался.
"Ближайшие лет 5 будет в том, что разработчики сами станут строить инфраструктурные решения." - По опыту говорю что это будет тот еще цирк, костыли и велосипеды. Потому что большинство(не готов утверждать что все, видел разных) современных разработчиков в инфраструктуре , а тем более архитектуре не смыслят ничего. Встречаются либо - мое дело писать код - а вы ops парьтесь как хотите, либо я использую то что знаю, а то что этот инструмент для этого не предназначен - "так исторически сложилось". Так что я в корне с вами не согласен.
Из моего будничного - давеча написал api утилитку на go для автоматизации получения сетевых доступов. Но есть много и ops задач, согласен. Все больше сталкиваюсь с тем что разработка умеет писать код, но не понимает как работает определенная бд и архитектурные вопросы в целом. Мой любимый пример очереди в redis. Так что коллеги тут монета ребром как говорится.
Я так понимаю вы предварительно проверяли скрипты на тестовом окружении? И не думали об откатах? Согласен подход рабочий с некоторыми но. Но почему например не развить подход в сторону liquibase , flydb?
Прочел.Отвечу - вы забываете что инженер владеющий практиками DevOps тоже умеет писать код и даже порою не на одном ЯП, но почему то все упорно толкают их именно в сторону ops.
Этож какие такие ETL файлы? Apache Nifi и Airflow прекрасно справляются с ETL процессами. И они как раз гибче масштабируются в k8s. А про модно и молодежно, похоже на старую шутку «вы просто не умеете их готовить»
Самая проблематика мне кажется во всем это плане ,когда нужно будет заиспользовать https. Вот тут начнется веселье с самоподписными и указанием где то их валидности. И тут действительно использование внешнего кластера лучшее решение.
С таким же успехом можно провести аналогию с Майкрософт, Google, AWS etc. Кто платит того и тапки как известно. Начнет гайки крутить телеграмм, перейдут в Дискорд, Сигнал или еше куда. Селф-хостед Джаббер не панацея + этот протокол по сей день имеет куча недоделок (решаемых, тут не спорю).
И главное не очень освещены субъективные причины. Кто то устал от серого Питера и хочет погреться с семьей в Испании за ± теже деньги. Кого то не устраивает политика родной страны и он хочет «европейских свобод» и пускай там жилье и налоги выше, за то дороги нормальные. Вообщем во всем тут большой человеческий фактор, не всегда скачущий от ЗП и условий работы на родном рынке. Совсем же недавно была большая холиварная статья про ИТ в России… ну и по классике «Валим на Запад там радуга и единороги».
Коллеги то вам как мед "неправильные" девопсы попадались. Правильным - без разницы докер это или не докер. А некоторые даже strace иногда расчехляют. То что пришло поколение после курсов (в основном 2000+ года рождения) которые хотят миллионы и ничего не делать и учится тут я с вами согласен. Не раз собеседуя на таких нарывался.
"Ближайшие лет 5 будет в том, что разработчики сами станут строить инфраструктурные решения." - По опыту говорю что это будет тот еще цирк, костыли и велосипеды. Потому что большинство(не готов утверждать что все, видел разных) современных разработчиков в инфраструктуре , а тем более архитектуре не смыслят ничего. Встречаются либо - мое дело писать код - а вы ops парьтесь как хотите, либо я использую то что знаю, а то что этот инструмент для этого не предназначен - "так исторически сложилось". Так что я в корне с вами не согласен.
Соглашусь, однако используют его зачастую именно для оркестрации ETL. Ну насчет нет ничего, не соглашусь. Как же DAG’и которые добавляют ему гибкости.
Из моего будничного - давеча написал api утилитку на go для автоматизации получения сетевых доступов. Но есть много и ops задач, согласен. Все больше сталкиваюсь с тем что разработка умеет писать код, но не понимает как работает определенная бд и архитектурные вопросы в целом. Мой любимый пример очереди в redis. Так что коллеги тут монета ребром как говорится.
Эм это как бы нынче стандарты etl процессов)))
Я так понимаю вы предварительно проверяли скрипты на тестовом окружении? И не думали об откатах? Согласен подход рабочий с некоторыми но. Но почему например не развить подход в сторону liquibase , flydb?
Прочел.Отвечу - вы забываете что инженер владеющий практиками DevOps тоже умеет писать код и даже порою не на одном ЯП, но почему то все упорно толкают их именно в сторону ops.
Хм а вы «старое поколение» до сих пор считаете ftp безопасным протоколом?
И я открою страшную тайну есть виндовые контейнеры и ноды к8s на винде)
Этож какие такие ETL файлы? Apache Nifi и Airflow прекрасно справляются с ETL процессами. И они как раз гибче масштабируются в k8s. А про модно и молодежно, похоже на старую шутку «вы просто не умеете их готовить»
А позвольте поинтересоваться вы эти отлаженные процедуры до сих пор скриптами в базу пишите?
Посмотрите в сторону https://fastlane.tools, очень упростит ваш pipeline.
Напомню коллегам что пока поддерживаться в k8s сборка только через Dockerfile.
Самая проблематика мне кажется во всем это плане ,когда нужно будет заиспользовать https. Вот тут начнется веселье с самоподписными и указанием где то их валидности. И тут действительно использование внешнего кластера лучшее решение.
У metallb есть bgp режим.
https://metallb.universe.tf/concepts/bgp/