Насчет GitOps боюсь вы ошибаетесь. Как раз таки потенциала там в разы больше и когда у вас пару десятков микросервисов каждый со своим хелм чартом, и по паре кластеров для каждой команды разработки, не считая стейджингов и прода - деплоить это все тем же ArgoCD куда как проще, чем обслуживать зоопарк из десятков разных пайплайнов.
Попробуйте как нибудь тулы от Argo, мне кажется они медленно и верно двигаются в сторону стандарта де-факто для CD в кубер.
gitlab ci и argocd - абсолютно разные вещи. argocd - полноценная gitops платформа, заточенная конкретно на деплой в кубер. gitlab - классическая ci/cd платформа для любых задач.
Деплоить в кубер конечно удобнее через argo, сборку и тестирование - классической CI системой.
Странные представления о рынке - у авторов этой статьи. Я со своими полутора десятками лет в индустрии вроде как представление о зарплатных вилках имею.) Правда да, насчет рынка в РФ слабо ориентируюсь. Но в международном аутсорсе, продуктах из стран СНГ/восточной Европы, западных продуктах хайрящих у нас на удаленку зарплаты как-то не менялись. Уже года 4 как $1000 - это зп ждуна. Хотя коненчо кое где могут демпить и до 500. $2-3к - зп мидла. $3.5-5к - синьора. У лидов от $4-5 до $8-10. Конечно рынок часто проседает из за внешних факторов, и вакансий может быть меньше (как например почти весь прошлый год), как следствие кто-то начинает пытаться сэкономить и найти хорошего специалиста задешево. Но в целом зп последние годы имхо в таких пределах и остались.
Орнул с того, что тысяча долларов - это сейчас зарплата мидла, а 1.5-2 тысячи - это уже "высокооплачиваемый специалист". Все таки внутренний СНГ рынок сильно просел по зарплатам за последних года два, после того как отвалилась конкуренция с международным аутсорсом и иностранными продуктами.
Пробовал, но не на два фултайма, а на полтора. Первый раз работая в крупном аутсорсе, взял на парт тайм работу девопсом в крипто-компании. Изначально договаривался с зказчиком что работаю минимум 4 часа в день, но при возможности могу большо вплоть до 8и. Удавалось совмещать без проблем, строгих дедлайнов не было, на основной работе какое-то время даже был бенч, поэтому на доп работе получалось комитать по 5-7 часов в день. Выходило по деньгам почти как два фултайма. В целом круто, работал бы и дальше, если бы компания не отказалась от идеи работать с контракторами.
Сейчас работаю тоже в крупном аутсорсе, в котором весьма спокойно относятся к практике, когда ты берешь на себя больше проектов. При этом не за мифические бонусы в конце года, а за живые деньги здесь и сейчас. Взял второй проект на 4 часа в день - получай сразу 150% зарплаты. И это очень круто. Во-первых тебе не надо скрываться. Твой менеджмент который видит твой ассайнмент по проектам относится снисходительно, если в какие-то дни есть просадка по производительности, или если ты сказал прямым текстом "сори на этот митинг не попадаю, важный митинг на втором проекте". Пропадает весь головняк с налогами и переводами второй зарплаты, все приходит тебе официально сразу на карту с уже уплаченными налогами.
Да, работать конечно сложнее, каждый день пусть и по 8-9 часов, но приходится работать нонстоп, голова постоянно занята задачами. Пока-что проработал в таком режиме где-то четыре месяце, успешно закрыл второй проект. Сейчас уже второй месяц отдыхаю на одном проекте, но планирую уже подыскивать себе второй.
Я так понимаю эта ситуация коррелирует и с размером инстанса. Если у вас большие ноды на которых крутятся сотни подов, то могут быть проблемы, но если на ноде крутится с десяток тяжеловесных подов, то проблем не будет?
По моему опыту для большинства нагрузок оптимальный размер нод, если в классификации Амазона, это xlarge и 2xlarge. И те же крупные дев кластера лучше скейлить горизонтально.
Соглашусь, при этом абсолютно не обязательно полное моделирование всех физических процессов возникающих во вселенной. Вобщем-то эти физические процессы важны только для ученых или людей которые непосредственно строят умственные или «реальные» эксперименты на эту тему. И для них может включаться более ресурсно-затратная модель вселенной на конкретный отрезок времени эксперимента. Тогда как для большинства людей это может быть абсолютно упрощенная модель на уровне компьютерной игры, с каким-то мимнимальным допустимым SLO по погрешностям в физических законах :)
Да даже существование всех людей в каждый момент времени исторического процесса не обязательно, в какой-то момент для людей (важных для работы симуляции) реальное сознание на вычислительных мощностях может просто подключаться, а воспоминания о прошлой жизни просто создаваться, как что-то существовавшее ранее.
А почему энергия должна существовать на самом деле, в реальном мире (реальной симуляции), а не только лишь в сознании людей, которые узнавали об этой энергии в процессе экспериментов и например из вычислительных приборов за всю история существования эти научных изысканий? я к тому что вся вселенная допустим может существовать только в сознании наблюдателей, то есть иметь только лишь информационную сущность, а вся материя, энергия, физические законы — существовать только в сознании людей/«симуляций» как саморазивающийся абстрактный тип данных)
Сколько работал с микросервисами в энтерпрайзах и в стартапах, готовый продукт обычно был от двух десятков до сотни компонентов. И обычно это несколько девелопмент окружений, qa, perf, стейджинг. Да имхо даже десяток подов, но когда есть разграничение по командам разработки и окружениям удобнее запускать в кубернетс. И с точки зрения централизованного управления правами, политиками, внешним доступом, и с точки зрения оптимального использования ресурсов виртуалок.
Зато когда кубик уже есть (а пол тысячи подов это по сути набор окружений для небольшого микросервисного решения в пару десятков компонентов, что вполне себе покрывает потребности проекта даже на десяток человек), то запускать далее небольшие и редкие нагрузки в серверлесс — это хайп и каргокульт. Настроенный и отлаженный k8s в данном случае для нас вообще бесплатен, несколько кронджоб запускаемых раз в сутки не потребуют даже какого либо скейлинга нод
Immutable образы в этом контексте выглядят самой подходящее практикой имхо. И решается не сложно, как уже упоминали, версионировать образы по sha коммита, плюс запрет на перезапись артифактов в хранилке. По крайней мере для дев окружений, в продакшн с семвер версинированием как-то удобнее )
Все эти проблемы решаются одним простым сопособом, нужно знать сколько ты стоишь и сколько хочешь получать. Сразу называешь рекрутеру цифру (чуть повыше от той что хочешь) и дальше вы уже смотрите, смогут ли они тебе это дать.
А рыночек изучить на специализированных ресурсах да знакомых поопрашивать кто-где-сколько приблизительно получает для человека который не первый год в отрасли думаю проблем не доложно составлять.
Как-то осталось за кадром, что сокращения в единорогах — это совсем другое, что сокращения в обычных компаниях. В Airbnb всем сокращенным выплачивают компенсацию 3 месяца зарплаты плюс по одной неделе сверху за каждый год отработанный в компании, разрешают забрать себе оборудование, дают годовую страховку и помогают найти новую работу.
Это выглядит как минимум странно. Как они отлаживаться будут? Ну, и раз есть доступ к конфигмапам — значит, они смогут сломать этот деплоймент.
Например, у меня есть неймспейс с системными утилитами, ну там кронджобы которые делают чистку артифкатори, которые суспендят окружения по вечерам и в конце недели и так далее. Я тоже не любитель конфиг файлов, считаю что параметризировать свои приложениия удобнее энв переменными. Но зачем мне давать доступ разработчикам к правке своих огромных манифестов, где сотни строк кода? Я им говорю, если вам нужно свою группу енвайронментов добавить в suspend-list — вот в этом секрете/конфигмапе одна строчка, добавьте туда через пробел регэксп на свои неймспейсы и все. Это гораздо проще как для разработчика так и для меня, повышается и читаемость кода и уменьшается шанс на ошибку.
А какие нибудь часто применяемые действия, например если разработчик хочет чтобы его энв сегодня саспендился в 23-00, а не в обычные 19-00, так вообще лучше на уровень аннотаций к неймспейсу выносить, чем править конфиг самого приложения.
Если же у нас софт свой со 100500 ручек — какая разница куда инжектировать параметры? Вы говорите всерьез, будто люди в деплойменте в кубере что-то глазами смотрят. Постоянно.
Люди не смотрят, а автоматизация смотрит. Допустим если у нас в коммите поменялся манифест деплоймента, то гитлаб-сиай установит новое окружение в отдельный неймспейс и прогонит инфраструктурные тесты. А если только файлик с конфигмапом, то деплоймент останется тот же и запустятся только тесты по хелсчекам самого приложения.
Не аргумент, если используется хельм. Там все параметры в values.yaml сплошной портянкой.
В Helm тоже можно использовать обвзяки, чтобы был не один сплошной values.yaml, а много values файлов где параметры сгруппированы по своим задачам/по смыслу.
По мне так наоборот, писать конфиги напрямую в деплойменте это по меньшей мере неудобно.
Если у нас конфиги — это километровые yaml или, чем черт не шутит, легаси xml с вкраплением go темплейтинга — то манифест деплоймента превращается в нечитаемую кашу. А когда конфиги в конфигмапах в отдельных файлах в гите — это нагляднее, понятнее кто куда делал изменения, удобнее писать пайплайны (на определенные тесты при изменении конфигов и другие тесты при изменении деплойментов или других компонентов).
Плюс разграничения в правах. Допустим мы хотим девелоперам на этом окружении дать права на изменения конфигмапов, но не на изменения самих деплойментов.
Как из одной строчки совета "добавляйте sleep в prestop hook, чин под успел корректно удалиться из сервиса" написать целую статью :D
Но вообще спасибо, полезная информация :)
Насчет GitOps боюсь вы ошибаетесь. Как раз таки потенциала там в разы больше и когда у вас пару десятков микросервисов каждый со своим хелм чартом, и по паре кластеров для каждой команды разработки, не считая стейджингов и прода - деплоить это все тем же ArgoCD куда как проще, чем обслуживать зоопарк из десятков разных пайплайнов.
Попробуйте как нибудь тулы от Argo, мне кажется они медленно и верно двигаются в сторону стандарта де-факто для CD в кубер.
gitlab ci и argocd - абсолютно разные вещи. argocd - полноценная gitops платформа, заточенная конкретно на деплой в кубер. gitlab - классическая ci/cd платформа для любых задач.
Деплоить в кубер конечно удобнее через argo, сборку и тестирование - классической CI системой.
ну конечно ребята из Флант будут использовать свои in-house тулы) почему избыточно?
Почитал список инструментов и с удивлением стал пересматривать заголовок - это точно статья из 2024 а не из 2016? 😅
Странные представления о рынке - у авторов этой статьи. Я со своими полутора десятками лет в индустрии вроде как представление о зарплатных вилках имею.) Правда да, насчет рынка в РФ слабо ориентируюсь. Но в международном аутсорсе, продуктах из стран СНГ/восточной Европы, западных продуктах хайрящих у нас на удаленку зарплаты как-то не менялись. Уже года 4 как $1000 - это зп ждуна. Хотя коненчо кое где могут демпить и до 500. $2-3к - зп мидла. $3.5-5к - синьора. У лидов от $4-5 до $8-10. Конечно рынок часто проседает из за внешних факторов, и вакансий может быть меньше (как например почти весь прошлый год), как следствие кто-то начинает пытаться сэкономить и найти хорошего специалиста задешево. Но в целом зп последние годы имхо в таких пределах и остались.
Орнул с того, что тысяча долларов - это сейчас зарплата мидла, а 1.5-2 тысячи - это уже "высокооплачиваемый специалист". Все таки внутренний СНГ рынок сильно просел по зарплатам за последних года два, после того как отвалилась конкуренция с международным аутсорсом и иностранными продуктами.
Пробовал, но не на два фултайма, а на полтора. Первый раз работая в крупном аутсорсе, взял на парт тайм работу девопсом в крипто-компании. Изначально договаривался с зказчиком что работаю минимум 4 часа в день, но при возможности могу большо вплоть до 8и. Удавалось совмещать без проблем, строгих дедлайнов не было, на основной работе какое-то время даже был бенч, поэтому на доп работе получалось комитать по 5-7 часов в день. Выходило по деньгам почти как два фултайма. В целом круто, работал бы и дальше, если бы компания не отказалась от идеи работать с контракторами.
Сейчас работаю тоже в крупном аутсорсе, в котором весьма спокойно относятся к практике, когда ты берешь на себя больше проектов. При этом не за мифические бонусы в конце года, а за живые деньги здесь и сейчас. Взял второй проект на 4 часа в день - получай сразу 150% зарплаты. И это очень круто. Во-первых тебе не надо скрываться. Твой менеджмент который видит твой ассайнмент по проектам относится снисходительно, если в какие-то дни есть просадка по производительности, или если ты сказал прямым текстом "сори на этот митинг не попадаю, важный митинг на втором проекте". Пропадает весь головняк с налогами и переводами второй зарплаты, все приходит тебе официально сразу на карту с уже уплаченными налогами.
Да, работать конечно сложнее, каждый день пусть и по 8-9 часов, но приходится работать нонстоп, голова постоянно занята задачами. Пока-что проработал в таком режиме где-то четыре месяце, успешно закрыл второй проект. Сейчас уже второй месяц отдыхаю на одном проекте, но планирую уже подыскивать себе второй.
Я так понимаю эта ситуация коррелирует и с размером инстанса. Если у вас большие ноды на которых крутятся сотни подов, то могут быть проблемы, но если на ноде крутится с десяток тяжеловесных подов, то проблем не будет?
По моему опыту для большинства нагрузок оптимальный размер нод, если в классификации Амазона, это xlarge и 2xlarge. И те же крупные дев кластера лучше скейлить горизонтально.
Да даже существование всех людей в каждый момент времени исторического процесса не обязательно, в какой-то момент для людей (важных для работы симуляции) реальное сознание на вычислительных мощностях может просто подключаться, а воспоминания о прошлой жизни просто создаваться, как что-то существовавшее ранее.
Биржа бирже рознь. Почитайте про decentrilized exchange и свопы.
Единый стандарт и открытый софт — это k8s :)
Зато когда кубик уже есть (а пол тысячи подов это по сути набор окружений для небольшого микросервисного решения в пару десятков компонентов, что вполне себе покрывает потребности проекта даже на десяток человек), то запускать далее небольшие и редкие нагрузки в серверлесс — это хайп и каргокульт. Настроенный и отлаженный k8s в данном случае для нас вообще бесплатен, несколько кронджоб запускаемых раз в сутки не потребуют даже какого либо скейлинга нод
Immutable образы в этом контексте выглядят самой подходящее практикой имхо. И решается не сложно, как уже упоминали, версионировать образы по sha коммита, плюс запрет на перезапись артифактов в хранилке. По крайней мере для дев окружений, в продакшн с семвер версинированием как-то удобнее )
А рыночек изучить на специализированных ресурсах да знакомых поопрашивать кто-где-сколько приблизительно получает для человека который не первый год в отрасли думаю проблем не доложно составлять.
Например, у меня есть неймспейс с системными утилитами, ну там кронджобы которые делают чистку артифкатори, которые суспендят окружения по вечерам и в конце недели и так далее. Я тоже не любитель конфиг файлов, считаю что параметризировать свои приложениия удобнее энв переменными. Но зачем мне давать доступ разработчикам к правке своих огромных манифестов, где сотни строк кода? Я им говорю, если вам нужно свою группу енвайронментов добавить в suspend-list — вот в этом секрете/конфигмапе одна строчка, добавьте туда через пробел регэксп на свои неймспейсы и все. Это гораздо проще как для разработчика так и для меня, повышается и читаемость кода и уменьшается шанс на ошибку.
А какие нибудь часто применяемые действия, например если разработчик хочет чтобы его энв сегодня саспендился в 23-00, а не в обычные 19-00, так вообще лучше на уровень аннотаций к неймспейсу выносить, чем править конфиг самого приложения.
Люди не смотрят, а автоматизация смотрит. Допустим если у нас в коммите поменялся манифест деплоймента, то гитлаб-сиай установит новое окружение в отдельный неймспейс и прогонит инфраструктурные тесты. А если только файлик с конфигмапом, то деплоймент останется тот же и запустятся только тесты по хелсчекам самого приложения.
В Helm тоже можно использовать обвзяки, чтобы был не один сплошной values.yaml, а много values файлов где параметры сгруппированы по своим задачам/по смыслу.
По мне так наоборот, писать конфиги напрямую в деплойменте это по меньшей мере неудобно.
Если у нас конфиги — это километровые yaml или, чем черт не шутит, легаси xml с вкраплением go темплейтинга — то манифест деплоймента превращается в нечитаемую кашу. А когда конфиги в конфигмапах в отдельных файлах в гите — это нагляднее, понятнее кто куда делал изменения, удобнее писать пайплайны (на определенные тесты при изменении конфигов и другие тесты при изменении деплойментов или других компонентов).
Плюс разграничения в правах. Допустим мы хотим девелоперам на этом окружении дать права на изменения конфигмапов, но не на изменения самих деплойментов.
Как из одной строчки совета "добавляйте sleep в prestop hook, чин под успел корректно удалиться из сервиса" написать целую статью :D
Но вообще спасибо, полезная информация :)