Comments 187
Проблемы не в Devops или ООП, это инструменты всего лишь.
Проблемы в том, что как не умели так и не умеют толково и дельно превращать реальность в байты и обратно.
А пожалуй соглашусь, все это похоже на усложение ради усложнения. Классическое нет цели, только путь. Микрософт погряз в перестановке иконок в офисе и смене положения меню пуск в ос. Надо же чем то людей занять, пусть -(плац ломом подметают)- пусть запускают десятую итерацию виртуализации. Это признак стагнации и отсутствия новых идей, но может эра ИИ как то сподвигет мир на более конструктивные действия.
Это похоже на усложнение для неспециалистов. А для специалистов очевидно, что это не усложнение, а нормальный процесс работы и есть вполне себе нормальное понимание, зачем так и что будет, если так не делать.
Но, как обычно, находятся умники, которые на ровном месте знают всё лучше всех и вот сейчас-то они расскажут, как делать сложные вещи правильно.
Ох! если бы оно было так.
Заказчик взял сервера в аренду и заказал на них Proxmox кластер.
При профилактических работах, через месяц, видим на кластере Proxmox развернутый k8s. И отдельные VM с LXD контейнерами вперемешку.
Еще через полгода заказчик просит проработать переезд всей инфраструктуры Proxmox в Yandex Cloud. Без изменений в самой инфраструктуре.
А при проработке ТЗ на переезд, со "специалистами" заказчика, пришлось долго объяснять, что FC SAN это не оптоволокно, которое в iscsi может само превратится. И за это надо платить отдельно.
А что плохого в развёрнутом на виртуалках Кубе? Наоборот, очень удобно мигрировать ноды при техработах или в случае выхода железа из строя. А контейнеры - для каких-то standalone-сервисов, которым важнее низкий оверхед по ресурсам, а не изоляция и live migration, например.
Почему-то вспомнился Ф.Кривин "если бы я был горностаем"
Про Си прям набор сопливых легенд. "Си 100% переносим и платформо-независим на уровне исходного кода." Ну что, удачи. Осталось только найти работодателя-фаната pure C.
Сам удивился что это возможно, но вспомним рейтинг TIOBE. И как результат анализ рынка на linkedin по моему региону:
* 30 вакансий в день Senior DevOps Engineer. На каждую вакансию около 5000 резюме
* 1 вакансия в 3 дня Pure C Developer, на каждую максимум 10 резюме
Посчитаем вероятность:
30/5000 = 0,006
0,3/10 = 0,03
Можно сделать смелое предположение, что найти работу Pure С разработчика почти на порядок проще.
Насчёт ООП вы не правы от слова совсем. Вы его не поняли, не поняли то, где его очень удобно применять. Например, при написании библиотеки GUI.
Насчёт Си - вы слишком сильно радуетесь, и слишком верите всем этим инструментам в плане безопасности - 75% уязвимостей связано с ошибками управления памятью, и аргумент опыта и внимательности просто не работает. Если компилятор не ловит такие ошибки, то жопа обязательно будет.
Так что лучше уж изучить Rust, хотя бы будете писать безопасные программы. Кстати, в Расте нет ООП ;)
Ой, ну всё! Уже и сюда его вставили, этот Rust! Mozilla Firefox был прекрасным браузером, но ровно до тех пор, пока его не переписали на этот самый невероятный Rust, после чего Firefox превратился в тормознутое дерьмо: что CPU жрёт как не в себя, что RAM. Достаточно открыть 5 окон с десятком вкладок и всё, от 32Gb RAM ничего не осталось и Load Average 15!
Раньше долго мигрировал на MF, теперь не знаю как от него избавиться...
хотя бы будете писать безопасные программы
Я пишу безопасные программы и на Си тоже. Достаточно понимания каких ошибок нельзя допускать. Для этого есть книжки и даже не сильно толстые.
И ни какой Rust не спасёт от логических ошибок, сделанных самим программистом. В результате код на любом языке станет небезопасным.
Mozilla Firefox был прекрасным браузером, но ровно до тех пор, пока его не переписали на этот самый невероятный Rust, после чего Firefox превратился в тормознутое дерьмо
Сразу видно человека, который совершенно не в курсе как пишется ПО.
Во-первых, там переписано на Раст очень мало, например только движок CSS (Stylo) и какие-то кодеки. Во-вторых, как будто одновременно со вставкой этого движка НИЧЕГО другого в браузере не менялось, да? :) Никакие другие стандарты не реализовывались, UI не переделывался, и т.п.
Достаточно открыть 5 окон с десятком вкладок и всё, от 32Gb RAM ничего не осталось и Load Average 15!
У меня месяцами ФФ открыт с десятками вкладок, обвешан кучей расширений, и жрёт не больше 3-4Гб. Что-то вы готовить не умеете.
Я пишу безопасные программы и на Си тоже. Достаточно понимания каких ошибок нельзя допускать.
Да-да, инженеры Гугла и Микрософта тоже крутые, но даже у них тысячи ошибок и CVE в основных продуктах. Этот аргумент НЕ РАБОТАЕТ.
И ни какой Rust не спасёт от логических ошибок, сделанных самим программистом.
С этим никто не спорит.
У меня месяцами ФФ открыт с десятками вкладок, обвешан кучей расширений, и жрёт не больше 3-4Гб
Они все сейчас выгружают неактивные вкладки из памяти, то есть совсем. Хорошо, если на диске в кэше останется, а то иногда откроешь старую вкладку - а там уже 404. Оптимизация, которую мы заслужили.
Не.. ФФ реально ногами писанный. Я его все еще использую, вместе с остальными, но буквально недавно исправленный баг, с которым я более года промучался - открытый на паузе сезонвар (видео) отьедал за пару часов 10+ гигов. И хто не кеш фидьма, хз что это. Оставлять надолго ФФ было категорически нельзя, если афк. Сейчас глянул - уже норм, но было же.
Когда будет группировка вкладок? Запуск несколько инстансов с разными профилями? Это все нужно.
Несколько окон Firefox с разными профилями давно использую одновременно. Или речь о том чтобы в одном окне вкладки с разными профилями были?
Когда будет группировка вкладок?
https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/
Это просто был завершён Firefox. И вчера я повторял с ним то же самое, и по той же самой причине. Рад, что эта проблема беспокоит только меня одного и больше ни у кого ничего подобного не наблюдается — спасибо безопасному Rust и настоящим программистам, которые хорошо разбираются как пишется ПО.
GUI спокойно пишется и без ООП (tk тому пример). Тоже не понимал, да и не понимаю до сих пор особо, точнее не вижу применения (хотя Qt и применял), конечно это не значит ,что его (применения) нет.
Человек занимался не любимой работой, соответственно делал все от балды тяп ляп и не разбирался зачем оно все нужно.
А тем кому нравится тоже уходить да )?
соответственно делал все от балды тяп ляп и не разбирался зачем оно все нужно
Напротив, делал всё тщательно и старательно, как и должно быть у перфекциониста. Проактивность, личная ответственность и все остальные атрибуты современного результативного подхода к работе. И моментами даже нравилось, особенно когда попадался по-настоящему интересный проект, в котором работодатели давали волю для самовыражения и творческого подхода.
Но контекст статьи не в том, что нравится, а что нет. Тут поднимался вопрос перспектив "А что будет дальше в мире DevOps?". Если я для себя чётко могу ответить на этот вопрос в контексте Си, то по теме DevOps у меня логического ответа вообще нет, одни негативные эмоции.
Я ведь не зря указал свой возраст. Когда мне было 20 — было интересно буквально всё! А теперь ценности сильно изменились и прошлые интересы оцениваются в первую очередь критически, и только потом с любых других ракурсов. Сейчас я смотрю на технологию только с точки зрения личного интереса: сколько я могу на этом заработать денег? Могу ли я расти как специалист, углубляясь в технологию? Пригодятся ли мои знания другим работодателям? В Си можно расти и развиваться всю жизнь, язык сильно переплетён с аппаратной составляющей, мир которой преображается не за годы, но за минуты. Взять тот же ИИ, в бэкграунде которого важна предельная производительность и экономия ресурсов.
А тем кому нравится тоже уходить да )?
Решение принимать только Вам. Лично я давно перестал видеть перспективы в DevOps. Там просто некуда расти. Если под "расти" не подразумевать добычу опыта в борьбе с глюками очередной технологии от Amazon. Разобраться в каком-нибудь AWS Glue? И зачем всё это лично мне? Чтобы через год появилось очередное индусское говноподелие типа AWS Athena или AWS Glue DataBrew и по прихоти очередного умника ("Только это спасёт наш бизнес") перейти уже к борьбе с их багами? Так себе "интересная работа"...
Поэтому я параллельно учил программирование и пока ту самую упомянутую интересность вижу только в этом направлении.
Вы просто устали от одной сферы работы и хотите пойти в другую сферу.
Статья - это эмоциональное обоснование выбора, но с набросом, чтобы немножко пожечь напоследок.
Потом можно будет написать еще одну, когда выяснится, что мир чистого C существует только издалека, а реальность несколько более блекла.
И что перфекционизм не всегда нужен и не всегда оплачивается в обоих помянутых сферах. Но очень сильно вытягивает силы.
Нет и не будет, полагаю, проблемы быть консервативным инженером, работающим по методологии Devops, которая внезапно, не только и вообще не про тысячи новых технологий и переизобретений.
У нас стек технологий на уровне теории не менялся с конца 70х, если внимательно посмотреть.
И верхнеуровневые паттерны тоже.
Были неймспейсы в позднем юникс 80х, а сейчас это одна из технологий под капотом контейнеризации.
Виртуализацию теоретически изобрели/обосновали тоже где-то в 60х, но кому-то она перевернула мир сильно позже.
И так далее. А новое под этим солнцем случается, но не столь уж часто. Проекты для резюме случаются гораздо чаще и нужно просто отличать первое от второго.
Ну и отсылки, что ECS стало вдруг не модно - его заменил EKS, как пример - прекрасны. Если что, между их релизами толи 6, толи 8 лет. И ECS до сих пор живой, и не помню, чтобы задепрекейченный. Нет необходимости бежать с горящими пятками, если вас устраивает ECS. И так почти во всем.
В приведенном примере про более быстрый в 10 раз Кубер - ну вообще не очень. Кому он нужен, в 10 раз более быстрый? Это оркестратор. 99% времени кластеру он не нужен, после запуска и вообще не участвует, пока все хорошо. Поэтому его x10 никому не нужно, кроме чистой теории. Если речь про контейнеризацию под капотом - она как бе опирается на ядро линукса. И на его механизмы. Быстрее в целом некуда и не за чем(потому что накладные расходы в рантайме на контейнеризацию исчезающе малы). Еще раз - там под капотом технологии, запиленные в начале 90х-00х в ядро линукса. В основе. И до сих пор работает, незаметно модернизируясь и сохраняя совместимость.
Нормальная инженерия, она про то, что вам надо минимальными ресурсами/технологиями закрыть требования, чтобы работало. Переписывание всего на последную супер-технологию, выпущенную Васей(да простят меня все Васи) - вчера - это какая-то не инженерия. Там про требования ничего нет.
Статья - это эмоциональное обоснование выбора
Я искренне жалею о том десятилетии, которое я слил на DevOps. Поэтому статья — скорее предостережение другим. Чтобы помимо восхваления этого пути в других публикациях (особенно от крупных компаний, заинтересованным в специалистах) у интересующихся был выбор мнений.
меня так забавляет, когда люди обесценивают опыт другого человека словами "вы просто....".
А может это вы просто не поняли автора на самом деле? будь то по вашей или его вине.
Не стоит так делать. Лучше говорить "Я не согласен. Мой опыт сильно отличается от вашего.". Так вы выскажете ту же точку зрения, но не покажете будто ваша более "правильная/правдивая", чем автора.
У нас стек технологий на уровне теории не менялся с конца 70х
теория это далеко не все
Да, вам будет легче учить новые технологии, так как база одна с 70х годов. Но это никак не исключает факта, что в каждом из этих велосипедов есть нюансы/bad practice/best practice, которые нужно знать.
Нет необходимости бежать с горящими пятками, если вас устраивает ECS
Вы приходите в компанию и она уже не использует X, а использует Y.
Ваши действия
убедить всех, что нужно X, а не Y; потратить много много часов на то, чтобы сделать X.
научиться работать с Y
Для меня тут очевиден факт того, что второй пункт наименее трудозатратен
Я только клаырять начал докуры-херокеры, но в голове та же мысль -и нафига так сложно?
Не, ну понятно - изоляция... Развертывание... Но проще можно было.
А то что в каждом втором резюме аисты пишут что они девопс, а сами тянут образ альфрески и ВЕСЬ контент файловый оставляют в контейнере, как и бд. Я же правильно понимаю что так нельзя?
Не понимаю, а что сложного в докере?
Вы берёте консоль, берёте код, выполняете команды, получаете нечто.
В докере вы делаете тоже самое - берёте файлик и описываете теже команды, манипулирующие кодом, но в него.
Далее вам больше не нужно ставить на сервер ничего, кроме докера, так как у вас приложение взяло, оба-оба, сбилждалось на раннере и вы получили готовый контейнер. В автоматическом режиме. И это будет каждый раз, раз за разом.
Прикиньте, не надо настраивать окружение, не надо билдить на сервере. Просто получаем готовое приложение, которое уже сбилдилось.
Ну, да, наверное можно было проще. Только мы сэкономили на спичках, чтобы заплатить за это стоймостью крыла самолёта.
И да, вы правильно понимаете, что так нельзя. Ну, много чего нельзя и много кто чего пишет. Главное, кто и чем является. И хреновые специалисты это не проблема методологии, это проблема того, что у нас готовят хреновых специалистов, которые делают тяп-ляп
Только всё то же самое было изобретено десятилетия назад в виде пакетов. deb, rpm, pkg и так далее.
Беда докера не в нём самом, а в том, что контейнерная виртуализация - это мощная, но всё ещё сырая технология, идущая путём проб и ошибок. Те, кто начинал работать с докером давно, помнят его нестабильность на первых порах, помнят глюки unionfs и aufs. Ну ладно, за 10 лет стабилизировали в виде overlayfs. Потом выяснили, что собирать в докере небезопасно и придумали отдельно buildah и buildkit, заодно придумали podman и runc и задумались - а зачем тогда, собственно, докер?..
Я уж про оркестрацию не говорю. Docker compose, docker swarm, rancher, nomad, кубер-мать-его-нетес и openshift. Ну куда столько, а главное - зачем? И всё это отомрёт ещё лет через 5, а придёт что-то новое.
Я согласен с автором в том плане, что возраст даёт представление о ретроспективе. Между 20 и 25 - пропасть, между 40 и 45 - не так уж и много. Банально эти все технологии воспринимаются как бабочки-однодневки, когда ты в профессии 30 лет.
Благодарю, что разделяете моё мнение.
И всё это отомрёт ещё лет через 5, а придёт что-то новое.
А вы думаете, почему оно отомрёт? Да потому, что выживает более удобный и лучше работающий инструмент. Однако, как он становится лучшим? А в конкуренции с другими... Это всё естественные процессы, как эволюция обезьяны. Без криворуких обезьян как промежуточных предков, человека не возникло бы. Жаловаться, что приходится эволюционировать - примерно как жаловаться, что дождь идёт.
Теория Дарвина не всегда работает в IT. Иногда появляются такие уродливые монстры, которые, казалось бы, не имеют права на существование. Но за неимением альтернатив они не только живут и умудряются развиваться, но на их базе строят других монстров. Пример — Java, которая написана на Си, и Scala, которая написана на Java... Почему просто не писать на Си? ;)
P.S. Чувствую, за джаву мне сразу снесут карму, несмотря на смайлики. Надо было привести другой пример... Может котика приаттачить? :-D Не не поможет?
Докер удобен при обновлении сложного сервиса, как пример gitlab - представляю обновление всего, что туда входит, в виде пакетов. А так одной командой обновляется все сразу.
Также запуск кучи мелких сервисов (с разными зависимостями) на одном узле, без взаимного влияния.
А вот кубер -да, зачем его пихают во все дыры не понятно.
Кубер это следующая ступень эволюции. Вот у нас приложуха в кластере. Когда прогер пушит новый комит, гитлаб агент в кластере запускает компиляцию кода, сборку образа и выкатывает в кластер простой командой kubectl set image. Все остальное кубер делает сам: запускает контейнер с новой версией, ждёт когда она заработает, переключает входящие запросы на новую версию, гасит контейнеры старой версии. Если новая версия по какой-то причине не завелась за отведенное время, выкатка неуспешна, но сервис продолжает работать на старой версии. Нулевой даунтайм сервиса. Юзеры ничего не замечают, прогерам /девопсам нужно вмешиваться только при сбое. Без кубера нужно делать свой велосипед для такого уровня сервиса.
А тем кому нравится тоже уходить да )?
Вспомнилось
Хаус: Форман увольняется
Вилсон: Почему ? Что случилось ?!
Хаус: Сказал не хочет закончить как я
Хаус: Я остроумно возразил, только не помню как
Вилсон: Что сам не хочешь закончить как ты
Хаус: Именно! Мне тоже уволиться ?
Статья какой-то сумбурный высер. Я уже разбирал с пяток подобных и извините, но сегодня у меня выходной, мне лень.
Скажу ровно 2 вещи:
Становится DevOps-инженером действительно не надо. DevOps это методология. DevOps-инженер звучит так же нелепо, как Kanban-менеджер. Нужно становится просто инженером по инфраструктуре.
Чел, извини, но тебе 47. Я всегда говорю, что сейчас у ИТ есть 2 проблемы - динозавры 40+, которым всё сложно и которые цепляются за то, к чему привыкли, отрицая что-то сложнее деплоя по ftp и малолетние смузихлёбы, которым всё сложно и они ненавидят всё старое, при этом готовы внедрять любую вышедшую неделю назад 0.0.1 pre-aalpha в проект, просто потому, что вышла статья на хабре на 10 плюсов.
В итоге у первых есть фундамент, но нет развитие, у вторых нет фундамента, есть просто тяга к блестяшкам.
Хотите стать инженером? Становитесь. Хотите заниматься инфраструктурой - окей, круто, давайте к практикующим специалистам, объясним концепции, научим думать, считать и реализовывать. Расскажем, что, как, почему и в каком случае делается, какие есть критерии, зачем нужны все эти абстракции и "усложнения" и к чему вы придёте, поленившись или "упростив" на ранних этапах (спойлер - к пересборке самолёта в процессе полёта и просиранию кучи денег и времени).
И это не реклама курсов, мне ваши деньги нафиг не упали. Это приглашение в сферу от практикующего специалиста, который в своём деле немного так понимает. Не бойтесь, заходите. На своём пути вы встретите много слабых специалистов, но встретите и много хороших и годных
Статья какой-то сумбурный высер
Зачем же так грубо? Статья — частное мнение, не претендующее на объективность, но оппозитное тем восхищённым хомячкам, которые в основном пишут тут на хабре про технологии не успевшие им набить оскомину.
Чел, извини, но тебе 47
Ну что-же, буду рад услышать обновлённое мнение уже к Вашим 47 :-) Тем более, будет время проверить озвученные тут утверждения.
Зумеры такие умные пошли... Все что у вас есть - сделано динозаврами.
Все что у вас есть - сделано динозаврами.
Получается, тот же kubernetes тоже сделан «динозаврами»? А как тогда назвать «динозавров» считающих «он нам и на…й не нужон, кукаретис ваш!»?
Одно другому не противоречит. Кубернетес штука хорошая, но применять его нужно там, где в нём действительно есть потребность. Если у вас кровавый энтерпрайз типа одноклассников или вконтактика и целая команда сеньор-девопсов по сопровождению этого добра - да, применение кубера оправданно. Но его ж пихают куда только можно, я встречал проекты на десяток контейнеров на одной ноде - и для оркестрации подняли k8s, потому что "это модно" и "все так делают".
Иронично, ведь я работал во вконтактике как раз в devops команде сопровождения кубера) Да, это было оправдано, но и на проектах кратно меньше, тоже предпочел бы кубер альтернативам типа swarm
Вопрос в стоимости сопровождения. Кубер требует достаточной квалификации и хотя бы одного выделенного девопса. А это сразу +400-500к к ФОТ. Тогда как compose или swarm вполне может освоить приличный разраб.
Вообще, вот Ваше мнение опытного человека - начиная с какого масштаба инсталляции Вы считаете оправданным применение k8s?
ИМХО, если разраб сумел освоить compose и/или swarm, то сможет и k8s на уровне, достаточно для локальной разработки/базового понимания как работает его приложение.
Кубер требует достаточной квалификации и хотя бы одного выделенного девопса
Это довольно спорно и сильно зависит от процессов.
начиная с какого масштаба инсталляции Вы считаете оправданным применение k8s
Тоже очень скользкая тема и все зависит от множества факторов - есть ли экспертиза, какая стратегия развития, какой план роста, какой продукт и тд и тп.
Далее, сугубо мое ИМХО и только в рамках web разработки: Так, например, считаю что k8s оправдан практически всегда, когда речь идет о развертывании собственного продукта. От ботика в телеграмме, до соцсети. ("Сайтик на тильде" в моем представлении продуктом не является, продукт там это сама тильда и я почти уверен, что под капотом там тоже кубер).
Ведь за абстрактным k8s может быть много реализаций - это может быть single node инсталяция (вон k3s позволяет в пару команд организовать решение), свой полноценный кластер или облачный кубер.
В этом и вся его прелесть, что сегодня, например, mvp вашего сервиса, внутри k3s на одной виртуалке, а завтра в полноценном кластере в облаках. При этом со стороны сборки/развертывания приложения скорее всего практически ничего не меняется - правильно написанный манифест (helm-чарт/helmfile/helmwave.yml/werf.yaml - тысячи их) почти наверняка будет работать.
Kubernetes - просто еще один инструмент, привносящий слой абстракции, а как говорится:
Любую проблему можно решить введением новой абстракции. За исключением проблемы чрезмерного количества абстракций.
Для кого-то - серебряная пуля (9000 stateless микросервисов с rest api по 3.5 эндпоинта), для кого-то - сущий кошмар (базы данных в кубах это ОЧЕНЬ больно)
Кубернетес штука хорошая, но применять его нужно там, где в нём действительно есть потребность.
не поверите, но это относится к любой технологии/языку ;)
Ирония а другом - вы вместо адекватного и простого init везде суëте монстроидальный systemd, но оправдываете это тем, что "это не я, это разработчик ОС принял такое решение, а я лишь жертва обстоятельств" (не виноватая я, он сам пришёл).
Но при этом отказываете другим развернуть куб (который концептуально не особо сложнее systemd) там, где они хотят.
Куб может быть оправдан в виде minikube на raspberry Pi (если на то есть причины, возможно даже просто "мне по фану"), а может быть совершенно лишним в кластере на сотню серверов. У каждого инструмента есть свои задачи и области применения.
динозавры 40+, которым всё сложно и которые цепляются за то, к чему привыкли, отрицая что-то сложнее деплоя по ftp
Динозавр-программист 45лвл итт. На последней работе сознательно внедрил докер, и слал в пешее эротическое сисадмина-смузихлёба, который ныл "зачем так сложно". Просто потому что я ЗАДОЛБАЛСЯ "деплоить по ftp". Я задолбался от монотонной ручной работы. Я задолбался от бесконечных ошибок, когда правую панель перепутали с левой, когда сделали git reset --hard не в той репе, когда всё правильно перенесли, но забыли что надо снести одну старую системную библиотеку и добавить две новых. И я даже до docker swarm дошёл, ради бесшовного обновления. До кубера не дошёл, там сразу скачок кривой сложности, и ничего близко похожего на кластер у нас не было, и ресурсов не вагоны, вся инфраструктура хорошо если десятилетней давности, то есть десятилетней на момент моего прихода.
Да, и к картинке ниже - я мечтал об ансибле или чём-то похожем, чтобы управлять хранением настроек инфраструктуры и автоматизированно её разворачивать. Но наш админ на мои намёки ныл "зачем так сложно".
Всё это, блин, нужно, как только начинаешь заниматься реальными задачами, а не форумами на phpbb, которые упадут - туда им и дорога. Когда у тебя в казалось бы не очень большом проекте две сотни открытых тикетов не предел, и три одновременно решаемых задачи у разработчика - не предел, начинаешь задумываться об управлении этим всем. Автоматизированном управлении. Когда ты понимаешь, что абстракции даны тебе в ощущениях, они есть в бизнес-процессе, который ты автоматизируешь, ты начинаешь скулить "а вот были бы в моём языке хотя бы интерфейсы, и чтобы типизация была построже и чуточку более явной".
Так и не понял как вам докер помог с git reset не в той репе и ручной работой.
кубер, кстати, не то чтобы сильно сложнее, там просто подход другой.
он меня сначала бесил своей многословностью, потому что ну вот есть docker-compose, там всё описывается десятком строчек, зачем тут столько всего городить?
а потом дошло.
у нас есть host-ориентированный подход docker-compose и манифест-ориентированный подход кубера (даже сингл-ноде).
swarm -- это попытка уйти от host-ограничений compose, тут можно подискутировать насколько удачная, но по факту swarm не взлетел.
написал, перечитал и понял, что не то.
ещё проще. Вот есть докер-композ и есть куб.
пока запускаешь рукакми, второй кажется сложнее. А потом пишешь .gitlab-ci и такой -- ааа! Так вот оно для чего!
Динозавр 50. По мне так проблема в обилии молодых "специалистов", пришедших в профессию за легкими деньгами. Вот они и начинают ныть в стиле автора исходной статьи.
А динозаврами становятся вот прям ровно в 40? ;))
Мне 43 и я себя как-то не считаю динозавром. Да, есть некоторое занудство - к примеру, если по правилам компании запрещено деплоить в прод в пятницу вечером и вообще есть процесс деплоя (включая согласования руководства), то бью по рукам коллегам, которые хотят выкатить что-то в прод забив на процедуры по принципу "да ладно, я так 100 раз делал, ничего не падало". Но процедуры на то и процедуры - либо иди и согласовывай их изменение внутри компании, либо выполняй.
В остальном вроде всё норм, отлично разбираюсь с новыми технологиями и новыми направлениями, а имеющийся за плечами опыт позволяет сразу же смотреть на потенциально проблемные места.
Присоединюсь к комментаторам выше.
Я с вами согласен, что в DevOps не нужно идти, если ты не любишь копаться в дерьме. И знаете почему?
Да по тому, что DevOps и есть та половая тряпка, которая подтирает за всеми, у кого пролилось. А проливается - у всех.
Я начинал как Sparc инженер, сертифицирован по Solaris9 и на Sun железе. Но тогда был другой мир. Приложения были локальными, сервисы - монолитными. Был жёсткий вендор-лок и шаг влево, шаг в право был подобен смерти: нет поддержки (она, конечно, не покрывает убытки, но даёт иллюзию что твою, даже самую-самую зубодробильную, проблему решат), нет резервирования, ты должен был всю команду держать у себя, вместе со всем железом, кабельными журналами и этим вот всем.
Порог входа был огромен, smb отличался от enterprise как рисунок 3хлетки от Ван Гога.
И вы знаете что? Всем надоело. Надоело держать команды, платить вендорам, строить свои ЦОД и содержать кабельные журналы в более-менее актуальном состоянии. А это магическое слово Veritas и Oracle RAC...
То, что сегодня есть 100500 мультонов решений, которые вообще как-то друг с другом интегрируются и на них можно запускать почти любые поделки любой макаки - удивительно уже само по себе. Я не жалею что все это появилось.
Докер был ошибкой с самого начала, но небыло и нет ничего, что бы его заменило. Не в плане техническом, а в плане использования, ценности, которую он "создаёт". А далее эффект снежка - чем больше индустрия адаптировала, тем больше на это завязывались.
Дошло до страшного - найти людей, которые бы могли "руками" держать сервисы через докер и гит - почти невозможно. Всем подавай Амазон, Кубернетис и это вот все.
Когда я показываю решение, которое работает почти на баш портянках, на меня смотрят как на инопланетянина. Но, я так же понимаю, что это все на "моих масштабах". Если бы мне нужно было это все масштабировать - я бы ушел в тот же Амазон. Потому, что AWS создаёт ценность только на масштабе. Если у вас его нет, не нужно туда соваться.
Мы все - жертвы маркетинга и DevOps их самое кровавое воплощение. Пока мальчики в кедах и худи слушают сказки про космические корабли, девопсятина, как Титаны - держат это все от неминуемого коллапса.
Нет, современное ИТ это не про инженеров, это про макак. Я не утверждаю, что разработчики или те же DevOps не могут быть супер профессионалами, но тренд - на прикладывание красного кубика к синему тетраидеру. Профессионализм в том, знает ли данный индивид каким клеем это склонять и при каких условиях оно будет держаться.
Мы больше не можем позволить себе роскошь затачивать катану, нас нужно быстро бежать.
AI, в конечном итоге, слизнет эту всю пену и снова будет время крутых спецов, которые могут решать сложные задачи зная узкий стек. Это не так далеко как кажется. Мы, конечно, ещё посопротивляемся, но DevOps будут вторыми или третьем, кого слижет. Так что да - не стоит туда идти.
Если меня бы спросили дети "Папа, мы хотим в ИТ, чё делать?", я бы порекомендовал им идти в разработку аппаратного обеспечения, в "железячники". Если конечно, они не могут на, условный, мехмат. Тогда не вопрос - будут заниматься AI, или ещё какой-то корневой технологией, на которой все крутится в их "будущем" мире.
А системный администратор как был дерьмовой работой, так и остаётся дерьмовым DevOps
Дошло до страшного - найти людей, которые бы могли "руками" держать сервисы через докер и гит - почти невозможно. Всем подавай Амазон, Кубернетис и это вот все.
По моему опыты на такие проекты не найти людей, потому что никто не хочет идти , а не потому что нет тех кто разбирается в докере, гите и башеписании. Просто мало желающих идти в проект с костылями и велосипедами на баше. Так как чаще всего автор этих костылей и велосипедов уже отсутствует в проекте , как и какая либо документация с мониторингом. Но деплой то нужен сегодня, и все это превращается в операцию с даунтаймом, страшным сном суппорта, и требующую решительности, отваги и поиска кого нибудь кто хоть примерно представляет как это работает. А бизнес считает, что мы нашли аж целого DevOps инженера (модное слово же) и сейчас он нам все сделает как в той книжке которую гугл в свободный доступ выложил.
Ой, смотрите, как мы в два присеста докатились до понимания, что всякие HAproxy "в чистом виде" это проблема!
Оказывается, обёртка нужна для того, чтоб экономить ресурсы по средством стандартизации реализации и разделении труда. Разработчики ELB за нас уже написали все башпортянки, задокументировали это все и куча народу уже это поковыряла, заполнив Stack overflow своими знаниями.
Я даже больше скажу - попробуйте попросить архитектора "брат, а давай твои орлы сами напишут объектное хранилище, ну че там, пару картинок сохранить!".
Вам удалось гораздо лучше и без эмоций выразить все те мысли, которые я хотел донести. Благодарю.
Вот за обзывание работы системного администратора было обидно.
Позвольте предположить из контекста, что в оригинале фраза должна была иметь несколько иной смысл: "Работа системного администратора как была невероятно сложной, скучной и недооценённой, так и остаётся таковой, но уже в ключе DevOps и облачных инфраструктур". Всё точно @HellKaim? ;-)
Ну почти.
Я никогда не понимал чистый случай сисадминства.
Вот у вас в системечто? Она самоценна? Стоит шкаф, на нем система, в ней... Что, постоянно происходит тюнинг каких-то параметров? Подкручиваем susctl и vm.options?
Во времена системных инженеров, это было управление оборудованием, параметрами драйверов и сетевого стека. Где это нужно - баллансировщики, системы сетевой фильтрации, сервера БД, редко - сторадж серверы.
Все остальное это мышкование с софтом или настройка Group policy. А если это мышкование с софтом, то это уже не системное администрирование, а деплой или саппорт конкретного софта
Но, и я писал об этом, у нас теперь не страшный вендормонолит или WebSohere - у нас теперь чудо дивное вон тех ребят из соседнего опенспейса. Они и сами не очень знают что они делали в прошлую пятницу, так как уже новый спринт, Продакт зубами скрипит и саппорт подпирает свежими тасками.
Это - не системное администрирование уже ни разу. И, как выясняется, если нужен на фултайм человек, который будет "чисто системами заниматься" - юзаерей заводить, или бдшки разворачивать, он сам себе башпортянки напишет. А если их несколько и один - со знанием С, он ещё и свою собственную систему мониторинга запилит (я не шучу, а рассказываю о 2000х годах и тяжёлых юникс сетапах).
А потом что-то пошло не так, эти самопальный баш/С поделки всех достали и им на смену пришли Телеграфы, Кубернетись, Ансамбли и Докер.
А потом и это всех достало и пришли облака, в виде Амазона и присне.
И наш сисадмин, который и так-то копался ток с виндой, так как только там и был нужен, по сути, совсем погрустнел. Системные инженеры вымерли как класс и на их место пришли люди-оркесиры, которые умеют это все вместе собирать. Правда, вместо своей башпортянки они мучаются с десятком-другим чужих.
Сколько я уже встречал разрабов, которые без DevOps сами не могут развернуть докер или подобное. Я уж молчу про k8s. DevOps нужны, и необходимы. Но это не должна быть затычка в каждую дырку. Всё должно быть по делу.
Это-то и пугает.
Разработчик, который не щупал среду в которой его софт будет крутиться... Да что я вам рассказываю.
Именно по этому я и писал - DevOps за всеми подтирает.
Есть ли места где все ок - безусловно! Много ли их - достаточно. Но, в среднем по больнице - мрак и ужОс.
Ну я больше к тому, что каждый должен выполнять свою задачу. А щупать должны уже QA. Представим что разраб будет выполнять весь стек и обязанности DevOps. Можно будет забыть что какой-нибудь софт когда-нибудь выйдет.
Большинство современных дево-псов фактически являются yaml-кодерами, способными с большей или меньшей вероятностью написать докерфайл и конфиг для кубернетеса. Как это работает внутри и и что делать, если оно работать перестаёт - они не знают.
А нормальный сисадмин - из тех, кто 30 лет назад мог спокойно пропатчить ядро или какой-нибудь сендмайл, а то и собственную файловую систему написать - сейчас превращается в крайне редкую птицу под названием SRE. Хотя по факту это просто нормальный специалист, умеющий и в инфраструктурную часть на всех уровнях, и в коде поковыряться и поправить кривой SQL-запрос.
Все так, SRE позиций кот наплакал.
Вы, наверное, шутите. Сколько человек в стране 30 лет назад могли спокойно ядро пропатчить?
Да практически каждый хороший линукс-админ мог. Потому что владение Си и дебаггером в то время было даже не то, чтоб обязательным - повсеместным для среды. И нынешние системные администраторы выросли из позиции "системный программист". Софта было мало, гитхаб ещё не придумали, нужное было проще написать, чем найти, ну или дописать необходимое самостоятельно.
Докер был ошибкой с самого начала
Искренне не понимаю почему, но буду рад понять
но небыло и нет ничего, что бы его заменило
Был LXC (или вы про другое), сейчас есть CRI и его реализации
Искренне не понимаю почему, но буду рад понять
Потому, что реализация кривая. В данном случае я про сетевой стек. Настроить фильтрацию трафика для конкретного контейнера ещё те костыли. И там ещё можно накопать при желании, которого нет. Мы все знаем что это достаточно стремянок поделье, но таков путь. Докер появился как срочный ответ на назревший вопрос. И кривость этого ответа была меньше чем запрос.
Был LXC (или вы про другое)
Я про то, что когда вы идете в любой проект, там в условном README написано docker compose up, а не lxc launch.
Почему так получилось, вопрос к историкам индустрии. Сегодня есть flatpack, appimage и даже snap, которые лучше со всех точек зрения, но мы продолжаем плодить докеры, так как они прощают нам гораздо больше, чем описанные выше вещи. Они почти такие же добрые как и виртуалки.
Сегодня есть flatpack, appimage и даже snap, которые лучше со всех точек зрения
Но ведь это же вообще другое - это альтернатива распространению пакетов, apt/dpkg/pacman/итд, с докером никак не связанная
А докер, простите, тогда что?
Средство виртуализации. И нужен он в первую очередь для изоляции окружения, а не распространения пакетов. Внутри контейнера вы можете использовать flatpack/appimage для создания окружения, а наоборот - сомнительно. (UPD - да, есть whalebrew например, но это скорее исключение)
Все верно, средство изоляции, точно так же как и апаимадж.
И сегодня докер - среда распространения приложения в изолированной среде.
Вы один раз собрали апаимкдж и распространяете его на свои кластеры.
Не, не подумайте, прелесть докера это его обвязка и эти докфайоы, которые инструктируют докер и его окружение как-то верно себя вести. Именно они делают самый фарш в докере, а не его изоляция.
У аппимаджей и флатпаклв этого всего нет, есть только изоляция.
Если интересно, как это "могло бы быть" - смотрите Lutris.
У аппимаджей и флатпаклв этого всего нет, есть только изоляция
Только для случая, например "пакет A использует openssl@1, а пакет B - openssl@3".
Изоляцию уровня "веб-серверу A я доверяю 0.5 cpu и запрещаю ходить в файловую систему хоста, а веб-серверу B я разрешаю ходить за данными на диск, но только сюда и только для чтения" средствами appimage/flatpack/итд не обеспечить - потому что это разные абстракции и разные изоляции.
Изоляция, про которую docker, можно сделать и нативными средствами linux (на хабре есть хороший цикл статей про это https://habr.com/ru/articles/458462/)
С каких пор докер стал виртуализацией ?
Контейнерной виртуализацией. Контейнеризация это тоже виртуализация, просто на другом уровне абстракции - не вне ОС, а внутри нее.
linux cgroups вместе со связанными механизмами это вообще не виртуализация. И Любой контейнер технологически ничем не отличается от system-unit, почему собственно при запуске контейнеров нет никакой привязки к собственно продуктам docker, podman и подобным. Более того, большинство фич, приписываемых контейнерам докер полностью доступны для настройки для любого systemd-unit. Накладных расходов от виртуализации у контейнеров нет, у них производительность нативного приложения со всеми плюсами "всё своё ношу с собой", когда нет разницы чем и какими версиями наполнена выполняющая контейнер система.
интересная фраза получилась)) в предпоследних абзацах - "нас нужно быстро бежать "
Просто вы не любите абстракции ради абстракций, без обоснования их необходимости. У меня такое есть. Возможно, особенность мышления.
С ООП тоже знакомо - после Си поначалу буквально не лезло в мозг, поскольку не понимал, зачем оно. Но приходилось через нехочу. И в какой-то момент понял, что дальше жить без него не смогу.
Сейчас, когда я в коде создаю очередную абстракцию, я точно знаю, зачем она, и когда может мне понадобиться. При этом все так же считаю, что в чужом коде абстракциями часто злоупотребляют.
Си хороший язык, но с очень узкой сферой применения, в нынешних реалиях. И у него низкая производительность разработчика.
Соглашусь буквально со всем. Помню мнение одного Erlang разработчика. Он сказал: "Я лет пять писал в функциональной парадигме, и только потом начал понимать её изящность". Наверно да, особенность моего личного мышления, потому что близки принципы Оккама и KISS. Упрощать где это можно и не плодить сущностей где без этого можно обойтись. И с другой стороны — отвергать всё, что противоречит концепции.
Я полностью разделяю эти принципы, и могу написать подобную статью, почему не нужно становиться Software developer ) В основном, потому что это далеко не всегда созидательный труд, а гораздо чаще, изматывающее ковыряние в legacy, чужом непонятном коде. И тебе редко когда позволят это исправить, потому что нужно выкатывать новые фичи, а за рефакторинг бизнес не хочет платить.
Говнокод побеждает, потому что он выгоднее в ближней перспективе, а в дальней никто не считает. Я одно время интересовался DevOps. Вот, Докер - вау, все просто. Вот Кубернетис - чего-то уже наворотили, но вроде понятно. Настроил CI/CD в гитлабе - красота! Но это все на личном проектике, где ты сам себе хозяин. А когда увидел портянку helm от реального enterprise проекта, успевшего за десяток лет обрасти костылями - желание продолжать как-то пропало =)
И что же оказалось в этой пресловутой парадигме не так? А то, что она просто НЕ НУЖНА!!! И это открытие меня поразило до глубины души.
Тоже считаю «почти также». Но только не эта парадигма не нужна, а она нужна, но в другом виде. Лично мне претит ООП с одним уровнем вложенности членов класса. Хочешь два/три уровня как в JSON - добавляй структуру или класс. Вот зачем? Неужели одного класса мало? Не, пусть будет возможность разложения разных уровней абстракции на классы, но пусть бы была возможность многоуровневой абстракции тоже.
Но ведь почти везде есть вложенные анонимные структуры/классы, разве нет?
Честно говоря просто для внутренней структуризации данных городить такой огород из всяких анонимных конструкторов и структур очень напрягает. Сравните, когда этого делать не хочется, то скрепя внутренней гордостью очередной раз чертыхаешься про себя и вводишь какой-то суффикс или префикс. И то и то выглядит криво. Вот пусть бы компилятор сам делал эти «анонимные» классы и структуры. Это ему надо, не мне. (Простите, это вопрос скорее риторический, я не в упрёк вам это говорю)
Может быть я не понимаю проблему, поэтому уточню. Что не так с этим кодом на Go? На C и C++ можно очень похожие вещи делать.
type Game struct {
Video struct {
framedata []byte
colormap []byte
canvas *window.Window
}
Random struct {
prndindex byte
rndindex byte
}
StatusBar struct {
InventoryActive bool
ArtifactFlash byte
}
}
func (g *Game) Reset() error {
g.Random.rndindex = 0
g.Random.prndindex = 0
g.Video.canvas.Reset()
}ООП с одним уровнем вложенности членов класса
Или я не понял, что Вы имеете ввиду или предлагаете "нафиг этот ваш закон Деметры"?
Правду я осознал значительно позже, но сначала не мог понять, почему ООП вызывает такое внутренне отторжение. Ведь и глубокое понимание, и использование ООП в коде требовалось буквально от каждого работодателя!
Просто задачи изменелись. В мире двух-уровневых архитектур это смотрелось избыточно, так как логику можно было сделать хранимками в базе, а морду наклепать - да неважно на чем. Либо "консольное" приложение - тоже ничего такого. Вход/выход == stdin/stdout/stderr, логику пишешь как есть. Хотя лично я начал писать еще на третьем курсе на С++, так как было прикольно. Хотя по работе писал на чистом С и было норм. Но да, наверное для моих задач (а писали в основном под *nix можно было и просто на С.
Но это было давно, а сейчас такие задачи довольно таки нишевые. Но я допускаю, что тогда это было важно в тех местах, куда вы совались
Первая причина — усложнения. Усложнения всего того, что могло бы быть простым. Усложнения усложнений! Надо больше абстракций! Просто так надо! Просто это модно! Просто так делают все! Потому что вот так! Потому что Кубернетис…
Ну, такое. Я в до контейнерную (для меня) эпоху я вот отлично помню опыт автодеплоя на IBM WebSphere. Фееричное упражение. Не, гибкая архитектура, масштабируемая. Скрипті пишутся на чем-то жутко пропиетарном. Одна отрада. Слеав что-то в консоли, можно посмотреть, а чего ж там произошло и скопировав команду можно попробовать засунуть приложение в кластер и сделать этот скрипт частью CD. Но простой там и не палхо. А уж пререносимостью
Хотите просто. Та не вопрос. Есть чудесная утилита make. Пишите Makefile и все будет по старому, как вы любите. Давно писали файл на большой проект с кучей либ и прочего? Так чтобы сам файлик на несколько сот строк и еще с кучей дочерних
Как все это ставить на реальную среду - bash в помощь. Я кстати отлично и сейчас его знаю, может на прям супер-супер, но ... решите современную задачу на связке bash + make, а я посмотрю. Или вспомните как это делали Х лет назад.
И эти чудные IF... THEN ... ELSE где только можно, чтобы обеспечить кросс-платформенность. Кстати, вот где отлично залетал С-ный препроцессор :) Прям аж ностальгия пробила.
Вторая причина. Нужно понимать 300500 технологий, иметь в них опыт и всё равно при смене работодателя на техническом собеседовании осознать, что из всего опросного листа можешь уверенно ответить только на половину
Ну это смотря что спрашивают. Как по мне, смысла спрашивать "а как там выглядит третья слева галочка в пятом ряду" не очень имеет смысл. Человек должна знать базовые сервисы и базу для них. Остальное можно быстро прочитать и осознать за полчаса. Тут скорее вирус "индуса" прилетел и заразил всех в конкретного работодателя
Третья причина. Перспективы углубления знаний в том самом пресловутом количестве технологий. В жизни DevOps инженера мало знать 300 технологий. Через год такой инженер должен будет знать ещё 300, потому что за год выйдет именно столько изменений и старые технологии уйдут на второй план.
Как архитектор могу сказать еще более ужасную вещь. Надо еще изучать концепции, новинки. Также въезжать в бизнес домен, так чтобы через три месяца уверенно обсуждать с заказчиком нюансы его процессов. Как иногда хочется быть простым DevOps и просто стучать по клаве, когда тебя никто не трогает
--------------
Про С ... не знаю. В мире корпоративных решений ему нет места, как по мне. Ни на веб-морде, ни на беке по хорошему. А значит большая часть заказчиков машет ручкой и никогда к вам не придет. Но если вы счастливы там где вы есть - рад за вас.
Возможно ближе к пенсии я тоже захочу все послать подальше и спокойно кодить на чем-то просто и понятном
Даже самый топорный современный компилятор сразу предупредит о проблеме в строке if (variable = NULL)
Эх, хорошо жить в детерминированном мире, наверное.
Вот вам русская рулетка в виде абсолютно безопасного (с точки зрения как минимум PVS-Studio) кода:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int *generate()
{
static int generate1 = 42;
static int generate2 = 43;
srand(time(NULL));
// Simulate a typo: "&generate" instead of &generate1.
return (rand() % 6 == 1) ? &generate : &generate2;
}
int main ()
{
int *pi = generate();
(*pi)++;
return(0);
}
Нет и не может быть безопасности в языке с сырыми указателями и никакие санитайзеры тут не помогут.
Пример интересный и показательный. Долго думал каким именно образом можно проигнорировать проблему такого масштаба и гонял пример разными техническими средствами. Сделал два интересных вывода и хочу ими поделиться:
1. Есть 10 постулатов NASA про безопасный кодинг на Си. Они описаны в статье "10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками" Один из этих постулатов заставляет не игнорировать ни каких warning от компиляторов и выводить их на максимальный уровень.
Пусть статические анализаторы не видят ничего подозрительного в коде, но компилятор явно намекает, что не всё так гладко. Да, это не фатальная ошибка по мнению компилятора, но и gcc, и шланг выдают предупреждение, которое заставляет задуматься:
warning: incompatible pointer types returning 'int *(*)()' from a function with result type 'int *' [-Wincompatible-pointer-types]2. В нашем распоряжении теперь есть такие замечательные инструменты как ИИ. Обе версии GPT-3 и GPT-4 точно определили где именно проблема и даже предложили исправленный вариант.
Ваш код содержит ошибку. Давайте разберемся, что именно не так.
В функции generate(), вы возвращаете указатель на generate вместо generate1. Это ошибка, так как generate - это имя функции, а не переменной. Вам следует возвращать указатель на generate1.
За полвека для Си разработаны тысячи удобных инструментов, от IDE, до отладчиков, статических анализаторов и компиляторов на любой вкус и аппаратную платформу. Ориентируясь в Си даже на начальном уровне освоения уже невозможно просто так взять и выстрелить себе в ногу. Даже самый топорный современный компилятор сразу предупредит о проблеме в строке if (variable = NULL), а такие инструменты как sanitize или valgrind подскажут где проблема с контролем памяти, если это случайно упустит программист. Си универсален. Си 100% переносим и платформо-независим на уровне исходного кода. Он уже просуществовал полвека и будет существовать в своём мало-трансформирующемся виде ещё очень, очень долго!
Кто-то слишком много слушал Торвальдса :)
Не угадали. Все эти айтишники — жуткие зазнайки, хорошо разбирающиеся только в одном. Им как синоптикам — верить нельзя ни одному, Торвальдсу тем более. Надо делать свои ошибки и на них учиться. Потом делать самостоятельные выводы и описывать эти выводы в статьях, чтобы в результате тебе никто не верил — ведь ты же айтишник :-)
Слили карму, не могу голосовать, во многом соглашусь, из сисадминов ушел в девопс и голова разрывается от количества технологий и количества абстракций. И вроде как понимаешь что каждая отдельная технология решает отдельную проблему, и каждая отдельная абстракция тоже нужна и вроде на своем месте, но вместе с тем держать в голове всё многообразие технологий так или иначе имеющих отношение к девопсу и все нюансы довольно тяжело мягко говоря и чуть не каждый месяц появляется новый продукт который вроде как решает какую-то проблему и всё это нужно изучать чтрбы не слишком сильно отставать в девопс технологиях. Бежим чтобы стоять на месте (с)..
Можно быть хорошим админом без какого-либо девопса, можно остаться фиговым админом в компании, где сплошной девопс. Можно прирасти корнями к определённым технологиям и не желать слышать ни о чём новом. Что не осилил автор статьи, понятно - надеюсь лет через десять не обнаружить себя на его месте.
Здесь наверно даже вопрос не в неосилении отдельных технологий. Один пример, вы привыкли использовать ansible, а приходите в компанию где все на puppet и хочешь не хочешь, придется себя ломать и писать на puppet. И так во многом. Переходя на новое место работы ты обязательно сталкиваешься с тем что какой-то инструмент ты не знаешь или не достаточно хорошо знаешь в девопс стеке технологий. А Си он и в Африке Си.. в этом проще с одной стороны. Ну или любой другой язык программирования в целом.
Если знание определённой технологии критично - обычно вы просто технические собеседования не пройдёте без неё. Если же технология - не громадный пласт (а в эксплуатации в основном такие), обычно влиться реально за вменяемые сроки (если ещё не наступили возрастные когнитивные изменения, хе-хе).
З.Ы. конкретно относительно Паппета - я бы на вашем месте не стал "себя ломать" и трижды подумал, надо ли оно мне, когда есть масса мест, где используют прекрасный Ансибл :)
когда есть масса мест, где используют прекрасный Ансибл
К сожалению инженеров, за последнее время рынок сильно изменился. Где раньше компании боролись за специалистов сейчас идёт борьба за тёплое место в хорошей компании — толковых и высокопрофессиональных инженеров больше чем бизнес может обеспечить. Вот представляю ситуацию, когда изо дня в день ищет DevOps работу 5 месяцев и приходит job offer от компании с puppet. Он такой: "Та ну нахер, не пойду".
но вместе с тем держать в голове всё многообразие технологий так или иначе имеющих отношение к девопсу и все нюансы довольно тяжело мягко говоря
Так не надо пытаться объять необъятное. Это невозможно, не зависимо от возраста. Та даже в пределах одного провайдера, например, AWS, никогда не сможешь знать все 300+ сервисов
А вы точно не используете в Си инкапсуляцию (сокрытие) и наследование (переиспользование)?
Тоже думал про C недавно, совпадение?) Советы для начинающих? Что почитать? Куда посмотреть? Что использовать? И вот это вот все.
Сегодня это очень нишевый язык с тенденцией к уменьшению доли. Надо реально понимать зачем это тебе надо или беззаветно его любить. Для кругозора можно потыкать палочкой, но перспективы сильно так себе.
Согласен с автором про девопс и администрирование в целом. Надо иметь особый склад ума и психику, чтобы эти авгиевы конюшни разгребать. Но в С с мотивацией что ООП не осилил, это тоже "феномен".
Начните с какой-нибудь хорошей книги по Си и алгоритмам. Вот накидал архив, но там всё вперемешку:
magnet:?xt=urn:btih:1fcb1af4885a33e4020775b612193be516d167a0&dn=%D0%9F%D0%BE%D1%87%D0%B8%D1%82%D0%B0%D1%82%D1%8C%20%D1%87%D0%B0%D1%81%D0%B8%D0%BA%20%D0%BF%D0%B5%D1%80%D0%B5%D0%B4%20%D1%81%D0%BD%D0%BE%D0%BC%20%D0%B4%D0%BB%D1%8F%20%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA%D0%B0%20%D0%A1%D0%B8Выбирайте литературу под Ваш текущий уровень вовлечённости в программирование. Если можете читать на языке оригинала, то могу подкинуть ещё тонну книг на английском.
НЕ начинайте с Кернигана и Ричи, как рекомендуют многие источники. Си в той книге сильно отличается от современных компиляторов и 64-битных реалий. Даже более того, там описаны приёмы типа goto, которые давно признаны как потенциально небезопасные.
Когда я начинал, мне очень помогли на форуме https://www.cyberforum.ru/ и я рад что он поныне процветает. Там можно задавать вопросы по непонятным темам и есть много тех, кто искренне готов помочь. Конечно, есть https://ru.stackoverflow.com на русском, но там достаточно токсичное сообщество (хотя... если сравнивать с хабром...). Они тоже могут здорово подсобить — главное не напороться на уже открытую ранее тему и формулировать вопрос чётко и однозначно, чтобы не снесли карму.
Если планируете не для души, но для заработка, то помимо Си придётся доводить знание английского хотя бы до Upper Intermediate уровня. В русско-говорящих странах просто таких заказчиков найти очень сложно — у нас всё делается «хуяк-хуяк и в продакшн» чтобы побыстрее срубить бабла пока конкуренты не отжали, тонкости ни кого не интересуют.
Помимо этого интенсивно общайтесь с GPT. Бесплатный вариант последней четвёртой версии можно получить через браузер Edge, зарегистрировав через него левый аккаунт на майкрософте. На начальном этапе этот инструмент может стать просто спасательным кругом и быстро ввести в технологию. Жаль такого решения не было раньше и каждый ответ на банальные вопросы нужно было вытаскивать из сети клещами — лично у меня не было ментора, которого можно было бы пингануть в любой момент и получить поддержку.
Алгоритмы это тема, которая идёт отдельно от конкретного языка программирования, но со всеми популярными алгоритмами и их принципами из computer science нужно хотя бы ознакомиться в общих чертах, чтобы понимать для чего они и какие задачи позволяют решать.
Помимо теории ещё есть практический аспект — выберете опенсорсный проект, который лично Вам хотелось бы улучшить. Разберитесь в каждой строчке кода этого проекта. Чужие примеры многому учат. Потом реализуйте в этом проекте то самое улучшение. Далее, по мере роста знаний и умений, сами создайте свой опенсорсный проект. Добавьте документацию, автоматизацию сборки, юнит-тесты и продолжайте его развивать. Помимо личного совершенствования это даст возможность продемонстрировать потенциальным работодателям Ваши возможности как программиста.
Насчет линуксового ядра, которое "написано в императивной парадигме" вы очень сильно ошибаетесь.
Возьмите например struct file и struct file_operations. Это как раз классический пример ООП, когда собственно struct file это объект, file.file_operations - VMT (virtual methods table), а file->file_operations->write(file, ... ) это по сути развернутый вариант file->write( ... )
Поэтому, ядро линукса это как раз хороший пример ООП, без излишних абстракций.
Использование структур для определения классов и их атрибутов достаточно распространённый приём в Сишке. И я согласен что очень удобный. Кроме ядра Linux такое используются в том числе для построения GUI (где-то было упоминание тут в комментариях).
Разница в уровне сложности между нативным OOP в том же C++ и трюками в Сишке. Чтобы не многословить просто укажу ссылку на одну из статей: "Десять вещей, которые я терпеть не могу в ООП" И одной такой заметкой список не ограничивается. Есть много хейта вокруг конкретно C++ и Java именно в ключе их усложнённости ради усложнения, когда программисты с 20 летним опытом просто не могут понять чужой код.
Ах дач про С, про С я забыл.
С сегодня действительно, очень... ОЧЕНЬ нишевый. И он не чистый там.
Так как вокруг С существует дивный мир, ищут не просто С, а С+х, и засада в этом самом Х.
Он может быть всяким, внезапным и вообще ни разу не широко доступным. И да, придется менять локацию, так как позиций прям скажем, мизер.
Что действительно раздражает в этом всем новомодном, это обилие слабо совместимых, подчас фигово документированных yaml-xml соплей.
Основная проблема не в "технологии", а в реализации. Есть огромный пласт софта, который внезапно ломает совместимость или просто документирован по принципу "мы следуем тут RFC1234". Ты не читал - лох!
Вот это да, это поджигает почище много чего.
Но, индустрия ест, за это платят деньги - значит это нужно. Если бы это было так ужасно, что было бы что-то дешевле (читай быстрее, меньше цена специалистов, меньше требования к оборудованию, среде) - индустрия бы пошла туда. Я же и писал это выше - ушли мы от спарков не потому, что x86 был хорош, а потому, что на цену 1 спарка можно было купить 20-50 x86. И внезапно, горизонтально масштабировать стало выгоднее... Докер, да
придется менять локацию
Вынужден согласиться. Не раз пытался в прошлых локациях перейти в разработку, но повезло только сейчас и только тут. Раньше просто не мог найти работодателей, даже в удалёнке. Сейчас удалось зайти в интересный High Load проект. В нём такие ресурсы задействованы, что ничего кроме ассемблера и сишки не справится. Так же есть спрос на разработчиков модулей ядра операционок типа AIX, Linux, FreeBSD, разработчиков в сфере безопасности SELINUX/BPF, и, конечно, Embedded — это вообще большинство вакансий.
индустрия ест, за это платят деньги - значит это нужно
К сожалению у индустрии всегда есть своё мнение, и оно часто бывает деструктивным по отношению к людям ею нанятым. То швеи спиваются, то девопсы выгорают...
Я пришёл в DevOps после многих лет работы разработчиком и сисадмином. И лично для меня постоянная изменяемость и новизна технологий - это плюс, потому что не надоедает. Работать разработчиком мне надоедает, админом - тоже. А DevOps - нет. Здесь и админство (инфраструктура в железе и облаках), и есть место автоматизации (пайплайны, всякие инфраструктурные скрипты), и даже суппорт в виде живого общения с людьми, т.к. нужно организовывать конвеер.
Платят тоже, кстати, неплохо.
Кстати, тонко подмечено:
у последнего — правая рука в наручнике...
Я ещё несколько лет назад понял, насколько профессия DevOps способствует выгоранию. Поэтому никогда даже не думал становится им.
Плюс у меня был опыт поднятия и надстройки всех этих серверов и выбора технологий, когда приходиться читать тонны документации, чтобы просто начать писать код. Так как тот, кто этим должен был заниматься, игнорировал свою работу.
Так же сам оказывался в ситуации, когда начальник отдела внезапно ушёл, не оставив ни паролей, ни доступов, ни даже списка проектов и клиентов, которыми он занимался. Несколько месяцев убил, чтобы просто собрать информацию чем он занимался, получить доступы и разгрести проблемы с клиентами.
Поэтому когда уже я в середине апреля подал заявление на увольнение, я решил все задачи по проектам, прочитал лекцию тому, кто остаётся после меня, подготовил пачку документации и напихал комменты в код. А так же составил список из 25 проектов, которыми в последнее время занимался, сбросив все доступы и оставив описание проблемных мест и о чём вообще эти проекты.
Ну и напоследок раздал сетевые ресурсы, которые принадлежали компании вроде ботов, чатов, каналов, контактов и всё такое главам различных отделов.
Пару дней назад ушёл, зная, что выполнил свой долг как разработчика.
Привет от человека, который ушел из программирования "потому что скучно" в девопс. Прошло 5 лет, до сих пор тащусь от того, чем занимаюсь
Мало развернуть приложение на EC2-инстансе и обновлять его по ssh. НЕТ
еще скажи делать git pull на сервере )))
Как насчёт старых добрых опенсорсных HAproxy плюс BGP на Quagga? Нет, не слышали! Да и зачем такое знать клиентам, если на on premise нельзя их поиметь на деньги?!
так настраивай что хочешь, тебя заставляют использовать elb ? Аргументируй клиенту что haproxy/bgp будет дешевле/надежнее/эффективнее. Не можешь ? Так зачем разводить полемику
Как оно в жизни: приходишь в компанию в помощь крутому 20 летнему девопсу, который там уже лет 100 работает и всё-всё знает. В результате оказывается, что от того девопса давно хотели избавиться и он через неделю уходит в закат на вторую работу о которой никто не подозревал, не оставив после себя ни паролей, ни ключей доступа к облаку.
и при чем тут devops ?
Опус больше похож на кризис среднего возраста у ТС )))
и при чем тут devops?
Суть цитируемого раздела заключается в том, чтобы передать мысль: DevOps — это одноразовый инструмент. Им пользуются и выбрасывают сразу же, как только запахло жареным. DevOps — это недешёвый ресурс, и от таких специалистов избавляются в первую очередь, особенно когда инфраструктура уже налажена, проект достиг пиковой стадии и дальнейшего развития не предвидится. Проект функционирует самостоятельно, принося прибыль, и для его поддержки требуется минимум усилий. Или, наоборот, если владелец бизнеса не увидел ожидаемой отдачи от своих инвестиций и начинает сокращать штат, то DevOps-инженеры улетают одними из первых, сразу после дизайнеров. Если в вашей компании начали сокращать дизайнеров — это уже первый звоночек, и пора обновить резюме. :-D Текст написан с долей юмора, но, как известно, в каждой шутке…
Никакой проблемы для DevOps'а в этом нет, т.к. как правило из-за специфики работы DevOps'ы вполне восприимчивы к перемене организаций, технологий и редко сидят на одном месте больше нескольких лет. Думаете всё настроили и девопс не нужен? Ок, найду другую работу а вашу организацию буду поддерживать в качестве подработки (или не буду). Поддержка неразвивающейся инфраструктуры - это уже не совсем DevOps, поэтому скорее всего он сам уйдёт раньше чем его попросят.
DevOps — это одноразовый инструмент. Им пользуются и выбрасывают сразу
же, как только запахло жареным. DevOps — это недешёвый ресурс, и от
таких специалистов избавляются в первую очередь
а причем тут описанный организационный бардак, когда ни паролей ничего нет, к теме devops ? У программистов такого не бывает априори и такие случае специфичны только для devops ?
особенно когда инфраструктура уже налажена, проект достиг пиковой стадии и дальнейшего развития не предвидится
слабо себе такое представляю, разве что какие то рога и копыта
а больше похоже на классику
Вот кстати автор прав, ТОЛЬКО В ИТ технология которая еще актуальна сегодня может быть уже заброшена завтра, потому что вышла очередная модная параша, которую сразу лепят в вакансии и опыт с ней от 5 лет нужно. Ненавижу бл*№ь за это ИТ люто, но ничего не поделаешь.
Вот и я к пришёл к тому же через такие же негативные эмоции и выгорание. Но при этом мне нравится сфера IT и поэтому хочу в ней оставаться дальше. Тем более платят ощутимо лучше, чем за всё остальное! ;-) Долго думал чем бы заниматься таким, что уже завтра не уйдёт в забвение и в результате нашёл для себя выход в Си.
Сегодня нужен только EKS! Он глючный и плохо интегрирован в остальной зоопарк AWS? Ну и что!?
Хотелось бы увидеть примеры/пруфы/первоисточники...
Пруфы того, что всем нужен EKS? Легко:
https://www.linkedin.com/jobs/search/?keywords=devops eks&origin=JOBS_HOME_SEARCH_BUTTON&refresh=true
Или пруфы что он плохо интегрирован с остальными элементами AWS по сравнению с ECS и гораздо более глючный? Проще простого:
https://stackoverflow.com/questions/tagged/amazon-eks?tab=Unanswered
Или пруфы что он плохо интегрирован с остальными элементами AWS по сравнению с ECS и гораздо более глючный? Проще простого:
https://stackoverflow.com/questions/tagged/amazon-eks?tab=Unanswered
и это доказательство ? показать сколько вопросов по с/с++/python ?
можно совет тогда с высоты вашего опыта. Вот я админ 5 лет с саппорта в тех поде провайдера, до админства офиса в 600 человек в одного, сеть-серваки-виртуализация-секурити немного. думаю в девопс перейти, бо зп выше при тех же объемах работы (ну я так думаю) но вот чего дальше делать непонятно, в девопс хочу, но сейчас всем надо опыт работы в этой сфере, а опыта то нет. да я могу дженкинс поднять и с интегрировать, в ансибле плейбуки написать, но всем надо фиг пойми чего. кодить? но кодить мне не очень нравится, да и не занимался этим никогда. и в итоге непонятно чего дальше делать
Как вариант попробуйте найти такого нового работодателя, у которого есть две инфраструктуры: on-premise и в облаке. Или у него есть планы построить Disaster Recovery в облаке, продублировав инфраструктуру или её основные элементы. Там точно будет много практики и нового опыта с облаками. А чтобы расширить выбор работодателей улучшайте английский хотя бы до уровня Upper Intermediate. С таким английским вариантов выбора работодателей для работы в удалённом режиме возрастает на два порядка. В любом случае откажитесь от обслуживания конечных пользователей. Они сжирают всё время и не дают расти. Попросите у руководства для обслуживания пользователей отдельного эникейщика, который будет им помогать, чтобы Вы могли сосредоточиться на саморазвитии и поддержке серверных решений. В конце-концов предложите развернуть Disaster Recovery текущему работодателю. Хотя бы бэкапы хранить в облаке.
ну вот ищу уже пару месяцев и нифига, на линкидине голяк: на удаленку сбегается толпа чуваков и всегда находится другой что милее работодателю. А англ b2 с залетом в с1 ток немного практики
Если Вы ищете удалённую работу в Google из Тагила, то по очевидным причинам Ваше оформленное не по стандартам принимающей стороны резюме даже не будет рассмотрено. Тогда остаётся вариант предложить изменить локацию. Там автоматически изменится уровень доверия, схемы налогообложения и прочие мелочи жизни, которые работодателю могут быть принципиально важны. А так же откроется возможность рассмотреть варианты hybrid и on-site.
С Вашим английским можно претендовать на очень крутые компании в случае переезда в зону их интересов. А ещё есть масса нюансов типа ATS и правил оформления резюме под конкретного работодателя или правил, относящихся к конкретной стране. Они есть и иногда очень жёсткие, и даже регулируются законом. Поищите комьюнити в социалках, задавайте вопросы именно по той локации, на которую рассчитываете и Вам подскажут как избежать ошибок при подаче резюме и прохождении интервью.
В моей локации у компаний богатый выбор аутсорсеров, но они предпочитают местных только потому, что их можно будет взять за жабры и трепать до конца жизни как того Буратину, в случае если сотрудник превращается в источник проблем.
Ещё вариант присоединиться к международным галерам, специализирующимся на аутсорсе. Но там, как правило, маленькие проекты с коротким сроком жизни... ну хоть руку набить и строчку в резюме добавить и то уже неплохо! Однако... как повезёт... У меня есть друг, который в галерах не первый год и на одном и том же проекте. При этом галеры помогли ему вместе с семьёй и тремя детьми релоцироваться в страну его мечты и он работает по 4 часа в день. При этом все довольны.
да, из тагила.. переезжать не на что, чтоб заработать на апереезд надо работать, а пока не переедшь на работу не берут. ну и чтоб девопосом стать теперь нужно сразу мидлом мининум быть, а я вообще админ, ниже описывал чего делал. ну и с моим опытом я конечно без вопросов за пару недель или месяцок мидлом стану, но кто ж даст. А можете галер названия дать, а то epam тоже чет не принимает, я ж не армении какой нибудь
К сожалению, в текущей печальной ситуации, по галерам очень сложно что-либо подсказать. Все достаточно известные (на которых вообще можно было бы хоть куда-то выехать) просто перестали набирать персонал в странах xUSSR.
Ситуация действительно непростая, но если Вы хотите сделать качественный скачок в Вашей жизни, то придётся прыгнуть выше головы. Однако ничего неосуществимого в этом нет. Я бы порекомендовал работать над собой сразу в нескольких направлениях:
Если Вы админите только Windows платформы (например), то расширять свои знания и умения в других OS и не только в теории, но и внедрять их в работу, даже на текущем рабочем месте. Разберитесь с ядрами операционок на низком уровне. Например, нужно знать что за чем загружается и как этим зоопарком управлять. Это часто задают на собеседованиях.
Опыт с железом. Попробуйте администрировать аппаратные составляющие инфраструктуры: серверы, Storage Area Network, загрузка по сети и разобраться в протоколах их окружающими, как например: iSCSI, FC, iLO.
Фриланс. Берите проекты, развивайтесь сами и развивайте свой рейтинг. Может здорово помочь при трудоустройстве и дать ресурсы на переезд. Да и на случай безработицы хороший рейтинг может очень здорово подсобить и поддержать штаны — ремень безопасности.
Программирование. Выберете язык программирования по вкусу и учите параллельно со всем остальным. Учите, пишите программы и вполне возможно, что в Вашем случае будет проще найти работу именно в этой сфере.
Английский. Это очевидно.
Пункты я привёл как пример из своего опыта. Вам, конечно, будет лучше изучить рынок, выбрать направление по-душе и подтянуть каждый пункт требований из вакансий на такой уровень, чтобы гонялись за Вашим резюме, а не наоборот.
Может план выглядит странно, но я уже такое проделывал неоднократно. Был период, когда просто брал одну сумку с самым необходимым и ехал за новым опытом, накопив перед этим знаний по вышеприведенному списку.
да занимался этим всем, год в одно лицо офис на 600 человек держал. ну без FC и программирование.. не вкатился, ну ansible могу конечно, bash, PoSH. но не языки (никогда задач не было, чтоб в этом синтаксисе разбираться). Моя проблема что я на траблшутинге поднялся, и учителя или старшего админа почти никогда не было. Поэтому сконфигурить все могу, а вот на собесе по терминам разложить.. из головы все вылетает. Ну или какие то глубокие вещи я не знаю, потому в экслпуатации они не требовались
На 600 человек надо 6 человек минимум. Как ты это вывозишь один непонятно. Может быть, конечно, ты не саппортишь самих юзеров.
да вобщем и целом не сложно. обычные виндовые пользователи. MDT Для деплоя, дает возможность выбирать софт при деплое а значит не надо сто пиццот образов на каждый отдел. групповые политики, чтоб на каждый комп не настраивать конфиги для крипто ключей, ну в целом gpo psexec скрипты. а так всё ж сейчас клиент-серверное, так что клиенты деплоятся конфиг один раз делается, потом недельку подгоняется и готово, можно не трогать. с цисками та же фигня tftp снимаем конфиг, если массово чего то хочется то ansible часок пишем плейбук и хоть на сколько свичей одним нажатие раскатывается. те же эксченжи, антиспамы и прочие фаерволы по большому счету один раз настраиваются и работают.. ну спам поблочишь, или впн кому подключишь, или письмо затерявшееся найдешь.. пацанам поможешь если они тупят, И в целом получается что полдня свободен.
Всем надо автоматизировать инфраструктуру. Автоматически создать виртуалку терраформом, настроить её ansible и подключить в инфраструктуру с автодобавлением в мониторинг. В инфраструктуре нужен оркестратор kubernetes, чтобы сервисам абстрагироваться от железа, операционных систем и понимания в онпреме оно или в облаке у провайдера. В кубер всё нужно деплоить автоматически: инфраструктурное через GitOps-подход Application-of-Applications от ArgoCD, и прикладное через CI/CD на Gitlab. Всё в кубере надо уметь сделать прозрачным: поднять мониторинг на Promeheus и сбор логов на Loki + promtail. Этой базы достаточно для замены любой перечисленной составляющей на кучу аналогичных: принципы одни и те же, однако сразу надо учиться на хорошем.
Самому надо освоить кубер (для экономии времени и денег лучше по этому курсу за 10$ https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/ с выполнением всех лаб), helm, CI/CD на базе Gitlab и основы мониторинга на связке Grafana+Prometheus. Этого достаточно для уверенной работы джуном в компании из нескольких девопсов, от которых уже нахватаешься более широкого спектра систем.
Крайне рекомендую использовать канал Артура Крюкова https://www.youtube.com/channel/UCU55LZT7oRxhX4GTvb5H4HA на котором он честно делится всеми основами и всем кодом.
ну если в компании есть отдел разработки то да, а если весь айти отдел 5 человек из которых один - менеджер а три саппорта, то как бы нет. ну есть железо в кластере, схд, коммутаторы Л2. серверы типа скудов каспера файловой хранилки и прочие днс. все в виндах и ексченжах. что из этого переводить в кибернетс? MDT с образами, вот то что надо, скрипты для деплоя всего чего можно эт да. ну ансибл если очень хочется конфиги на коммутаторы кидать. (но это чисто для личного удобства так как ситуации когда тебе привозят сто свичей и надо их за день стартануть не встречаются, да и циски скопом не ломаются, поэтому tftp с конфигами достаточно). ну я автоматизировал что можно чтоб отдел полдня отдыхал, но куда в этой ситуации линуксы пихать блин не придумал
Статья прекрасна, как минимум, как альтернатива. Надоело читать сопли по то, как все прекрасно в девопс. Хотя, как мне кажется, автор не остановится на С, и через N лет будет заниматься чем-то другим =)
Я бы отделил мух от котлет. ООП и контейнеризация (как пример) реально "помогают", они частично автоматизируют процессы. Это котлеты. А мухи в том, что не всегда это реально оправдано для внедрения)
Полностью согласна. Иногда кажется, что компании тратят слишком много времени и ресурсов на мелкие изменения, вместо того чтобы фокусироваться на разработке новых идей и технологий. Вместо перестановки иконок и изменения интерфейсов, лучше бы вложить усилия в развитие новых продуктов или улучшение существующих.
Плюсую за хороший выбор. Си дает очень хорошую и стабильную основу.
Но я бы выбрал немного иной путь - изучить computer science. И уже как необходимость для практики - изучения языка. Не суть важно какого, но си вполне достойный вариант.
На самом деле изучение computer science подозревается по-умолчанию. Если ставится цель профессионально работать программистом, то без знания алгоритмов, работы памяти, параллелизма и других аспектов делать нечего не только в Сишке, но и в любом другом языке программирования. Однако computer science это такой пласт знаний, в который можно углубляться бесконечно не для практических задач, но ради академических знаний.
https://www.youtube.com/watch?v=cdX8r3ZSzN4
Оставлю тут нетленочку =)
Я с точно таким же бэкграундом: возраст, жизнь в ИТ, широкий набор навыков, сейчас зарабатываю как DevOps-инженер. Я тоже из поколения, чей карьерный путь начался в буме внедрения массового ИТ в России и с которым по мере взросления в обществе сдвигается приемлемый возраст для ИТ-инженера. Более того: я отлично вижу фундаментальные вещи, на основе которых строятся каркасы современных инфраструктур и могу переточить решения своими навыками между онпремом, Yandex Cloud, AWS и GCP. Мне без разницы на чём строить CI/CD: Gitlab, Jenkins, Bamboo: я смогу сделать CI/CD даже на shell :) Я регулярно хихикаю, когда вижу как очередной стек инфра-технологий замечательно автоматизируется через старый добрый shell scripting несмотря на все верхнеуровневые кнопки "сделать всё зашибись". Я умею в python/golang/c/cpp, но как инфраструктурщику мне обычно хватает unix way с его гениальным shell scripting, отточенным нуждой в переносимости и требованиями приемлемой производителности, когда окружение даёт кучу специализированных инструментов, которые ты как кубики Лего склеиваешь между собой. Опыт позволяет мне успешно строить прозрачность и наблюдаемость решений. Опыт позволяет мне успешно заниматься выявлением и устранением узких мест в производительности инфраструктуры и я успешно помогая командам притащить эти инструменты в продукты и облегчить им процесс поддержки стабильности в продуктиве. Более того, накопленный опыт позволяет мне строить процессы и я знаю как построить команду и процессы в ней, чтобы бизнес имел на руках максимально адекватный импульс от инфраструктуры для его продуктов, работающих и развивающихся в режиме 24/7. Опять же, доступен левелап: процессами и уровнем обслуживания можно успешно заниматься сколько угодно времени, платя за это существенной частью жизни на совещаниях.
И я не жалею о выборе карьерного пути.
Мне не очень понятен выбор C вместо Golang: гошечка даёт продуктовые вакансии, где инженеры это часть контура зарабатывания денег и поэтому обласканы множеством компаний. И у go есть всё, чтобы массово и успешно писать востребованный быстрые высоконагруженные сервисы: её делали те самые дядьки, которые делали C и они применили весь свой опыт, отточенный многими десятилетиями mainstream IT: gperf, прозрачность, каналы, мощная простота и нативная жизнь в сети. Тогда как по ощущению C это практически только железо или древнючее легаси, что в российских условиях жизни электроники только в Китае смутно ощущается как тотальное кроилово на людях внутри чего-то, похожего на советские НИИ с их специфичной атмосферой.
не очень понятен выбор C вместо Golang
Хотелось бы обосновать свой выбор. Он исключительно субъективный, но у меня есть причины.
Зачем мне Golang если я знаю Си на котором могу написать буквально всё. Те же самые "буквально всё" на Golang, к сожалению, не напишешь. Люблю свободу без ограничений.
Если смотреть с точки зрения асимптотической сложности накладных расходов в больших проектах, то производительность программ на Си почти равна возможностям железа и, например, каждое новое клиентское подключение будет потреблять линейное количество ресурсов O(n) или близкое к тому. Накладные расходы любого другого языка программирования с теми же принципами, которые заложены в Golang (например гарбидж-коллектор) никогда не будет линейной, а с значительным коэффициентом.
Упрощу объяснение на выдуманном примере:
а) Программа на Си для одного клиентского подключения потребляет 1Mb и 1/1024 CPU. Для 1024 клиентов она потребит 1Gb и 1CPU. Это, конечно, очень грубое представление — в реальной жизни может быть как меньше ресурсов, так и больше — тут целое поле для оптимизаций.
b) Программа на Golang для одного клиентского подключения потребит 1Mb и 1/1024 CPU, но для 1024 клиентов она потребит 100Gb и 10CPU. Цифры взяты от потолка, прошу не придираться, цель их присутствия только для того, чтобы передать идею накладных расходов, а не принизить достоинства ЯП.
Я в своей инженерной практике не припоминаю софта на C за пределами частей операционной системы или чего-нибудь вроде СУБД, соответственно не вижу массового рынка заработка на разработке на С, сопоставимого с заработками в прикладной разработке сетевых сервисов, хоть могу и ошибаться.
Мне кажется, что Вам стоит дать шанс языку Golang, который проектировался в том числе для тех, кто умеет в C. Он очень хорош для многопоточной обработки и не страдает вашими вымышленными "для 1024 клиентов она потребит 100Gb и 10CPU": его делали те, кто делали С и Unix и они досконально знают про всё, связанное с производительностью и переносимостью.
В любом случае удачи!
Все эти абстракции это попытка людей нащупать такие, чтобы было проще решать различные проблемы, от понимания чужого кода, до проблем с распределёнными транзакциями. Это долгий путь, он спиральный, и это ещё надолго =)
У Си есть огромное преимущество - его легко встраивать в других языки. А языков наплодили много. С C++, вирт методами и его исключениями возникают сложности.
Если говорить про простоту кросс-платформенности - то это не Си. Начиная от различных выравниваний, разных размеров типов, posix функций которых нет например в win и нужны эти чертовые порты, заканчивая тем что поток не всегда легко выбить из блокирующих функций (а в системах очень много латентных IO операций, туда же относится файловая даже не супер быстром SSD).
Учитывая эффективность самого языка (не библиотек), многопоточности, простоты асинхронности, простоты кросс-платформенной компиляции - я лично за C#. У него как и у каждого языка свои плюсы и минусы. С чистым native бывает не просто с ним. Не надо там на Hello world 10 ГБ оперативы, сейчас конечно сборка уже по-проектная, а в классике было чисто scs, и он умел намного больше, чем обычно использовали через IDE. А вот все IDE жрут много.
Я вот в последнем проекте собираю C++, он во время сборки 10 ГБ за секунды сжирает.
Но это всё это только инструменты. А есть то, зачем этот инструмент, сама задача которую надо решить.
По возрасту почти как автор (скоро 45 лет). Карьерный путь был тернистым и иногда напоминал метания и ощущения что нахожусь не на своём месте. И весьма забавно, что именно сегодня, когда я вечером размышлял о своих 22+ годах карьеры, мне попалась эта статья. Волею судеб все мои попытки уйти в разработку давали мне понимание, что не совсем это моё. Да близкое и интересное, но не моё. Пока что в роли Devops я ощущаю себя на своём месте, но как знать, что я буду говорить в 47)) Я вот даже не знаю, динозавр я уже или ещё нет. Стремительно пробежали последние лет 15. А всё почему, а потому как когда появляются дети, время летит быстрее. Технологии летят также стремительно, но с возрастом приходит какое-то спокойствие в оценках нового и попытки обосновать технологию для самого себя приводят в целом к верным выводам. Так в спокойном темпе, подключая старые знания, изучаю что-то новое.
Восхвалять именно Си сейчас - это смешно. В первую очередь это язык ответственный за большую часть уязвимостей. Во вторую, там нет даже автоматической очистки только что выделенной руками памяти. Нечего там защищать: господь, жги... А мысль первой половины текста, про превращение мира девопса в мир джава скрипта по части гонки технологий - она понятна; я не девопс, но наблюдал немного со стороны что-то похожее, и вероятно автор тут прав.
автоматической очистки только что выделенной руками памяти
Вот даже страшно было это читать, куда уж себе такое представить...
Ладно, добавлю смайлик. Дружелюбный. :o)
В Си что-то поменялось и вызов memset() больше не требуется?
Павел, без обид, но у складывается стойкое впечатление, что про Си Вы просто когда-то услышали и услышанное не совсем хорошо запомнилось.
язык ответственный за большую часть уязвимостей
Для полноты набора популярных стереотипов осталось только упомянуть про простреленную ногу.
Вы бы по существу хоть что-то ответили. Про вызов мемсета после инициализации локальной struct-переменной, если добавить конкретики.
В любом случае рад Вашему интересу к Си. Только Павел, я не справочник по основам языка и не надо меня ставить в позицию допрашиваемого. Лучше потратьте немного времени, написав несложные программы на Си. Судя по Вашим разносторонним публикациям разобраться в основах и сделать это не составит труда. Я со своей стороны готов помочь со сложностями в коде. Если Вы с таковыми столкнётесь — присылайте примеры, разберём.
Я прямо увидел своё отражение. Мой путь в IT был 1 к 1 с твоим особенно в начале и ближе к концу )
И я испытывал похожие сложности с пониманием ООП. Я перечитывал OOP С++ по 10+ раз пока не понимал и двигался дальше. Но не смотря на то, что я разобрался и проникся в итоге красотой ООП я пошел по пути админства и девопства. Сейчас пока наслаждаюсь терраформом с ансибл и иногда пишу питон скрипты с классами для разных нужд )
Иногда скучаю по чистому программированию ... возможно это наш путь вернуться к истокам )
Полностью согласен с автором. Кстати добавлю вот что: подход ООП ограничился декларациями вектора состояния объекта и фунциями, которые просто переводят этот объект из одного состояния в другое. И тела этих функций описывает сам автор объекта. По сути описание жизненного цикла объекта лежит на самом программисте, а тут как говорится, все в меру способностей этого самого программиста. Никаких стандартных способов существования объекта во времени, языки, подобные С++ не предусматривают (такие например как, численные методы решения задачи Коши). Поэтому ООП остается недоделанным.
Единственно, что может пригодиться, так это простота описания интерфейсов, но это легко сделать на чистом С, тем более что ООП и так является недоделанным обрубком.
Работаю Девопсом уже 8 лет, в чем то согласен с автором, в чем то нет.
Например, комментарий по поводу "усложнений". Никто в бизнесе не делает эти "усложнения" и "абстракции" по фану. Люди которые ранают все эти тех отделы не аутисты, они принимают решения по созданию каких то "усложнений" основываясь на каких то причинах. Чаще всего появляются какие то проблемы, которые требуют решения. Например - терраформ и "усложнение" поверх - террагрант. 2 года назад моя команда тоже перешла на террагрант. Не потому что нам было скучно, а потому что на нашей огромной инфре все начали ехать кукухой, а классический терраформ не позволяет красиво с реюзобилити распределить по папкам всю инфру, да так чтоб модули было удобно вызывать и переменные по 20 раз не надо было дублировать. А террагрант позволил всю нашу здоровую инфру разместить в удобный вид и сейчас даже джун разраб разберется что где для чего лежит. По этому же принципу работают все современные новые решения - Классический лоад балансер амазона не вывозил application лейер, пожалуйста АЛБ работает как здоровый ингресс. Классический РДС не вывозит мгновенное High Load скалирование - пожалуйста вам Aurora. Каждое новое решение создано на основе какой то существующей проблемы. Обычно эти проблемы решаются костылями - например кастомными питон скриптами и магией вуду. Со временем эти костыли становятся новым решением, чтоб 100 новых девопсов Вась не писали свои кривые костыли с нуля. Так к теме "зачем эти усложнения нужны" я отношусь скептически. Они нужны, их делают, ими пользуются.
Другая тема этой статьи это про количество технологий и как это заябывает. Мне 32 года, я спокойно вывожу перепрыгивания с EKS на Kops на Deckhouse на Openshift на бэирметал магию питона. Вывожу и Athena и Glue. Вывожу и миллион модулей для кубера которые как грибы спамятся каждый день, мне не впадлу разобраться с новыми сервисами Амазона (которые тоже каждый день релизятся). Но я прекрасно понимаю, что лет через 10 мне уже будет впадлу прыгать с тулы на тулу. Так что находясь в состоянии "пока что норм", я понимаю что автор статьи нашел прекрасное решение "на пенсию". И если честно, очень логично и поучительно. Может лет через 5 тоже начну переходить во что то стабильно-базовое, чтоб в 50 лет не сидеть и не пытаться разобраться что там за АИ-бейзд орекстрация контейнеров снова появилась. Так что спасибо, автор, опыт всегда приятно почитать
Спасибо, что поделились личным опытом. Было очень интересно прочесть.
Вопрос чисто из академического интереса. За что минусуют сообщение, в котором автор статьи благодарит комментирующего за описание его личного опыта?
Вам, батенька, следовало бы чаще бывать у психолога, такое крайнее неприятие порождает нужду постоянно ссать против ветра, так далеко не уедешь.
Прочитал как бальзам на душу, почти во всем совершенно согласен, но мне 41, начинал с первого пентиума и модемов u s robotics и acorp, зухель видел уже позже, когда модемы были не нужны ) так же десятки раз через силу заталкивал в себя ооп в несколько подходов и всегда не понимал и не мог себя заставить. А уж про девопс технологии насколько вы правы...
Можно согласиться, что в dev ops часто пихают много лишнего. С другой стороны, не разделяю наивняк автора по поводу лёгкости и перспективности си для вкатуна, и некоторые другие идеи. Для каждой задачи свой инструмент, но и он не поможет, если этот инструмент не изучать и не использовать. При этом порог входа весьма высок, что иллюстрируется тотальным непониманием автора (несмотря на 25 лет опыта в айти) удобства ООП в определенных проектах, PHP в вебе и тп.
Прочитав внимательно вашу статью. Полагаю что высокая ЗП и привела к выгоранию, поскольку приходилось её оправдывать сверхурочными часами, ну и к тому же перфекционизм, который тоже не дает покоя на работе. Еще вижу, что вам приходилось внедряться во много разных компаний и проектов где все было по разному, и вам сильно захотелось прийти к общему знаменателю и выбрать хоть какой-то плот стабильности в этом хаотичном мире ИТ.
Отчасти с вами соглашусь, каждый год выходят новые технологии, и уследить за ними уже не хватает времени и сил, но, вместе с тем, огромное количество технологий становятся не нужными, и только единицы становятся популярными и полезными.
Вот жил себе спокойной Terraform, и тут появился Pulumi. Мне начальство говорит, мол вон смотри, тут новый пацан на районе, как он тебе? А я говорю, что это тоже самое что и Terraform, только вам нужно учить какой-нибудь язык программирования, людей с опытом в ней нет, нужно организовывать модули и тд и тп, и начальство немного остывает. Но я его как-нибудь попробую, чтобы понять что это за зверь.
В деплоях на виртуалки ничего лучше Ansible еще не придумали, хотя активно пытаются.
БД потихоньку обрастают операторами для кубернетеса. Я был всегда против, но теперь я уже думаю, что это неизбежно и операторы уже дошли до стадии, когда ими можно реально пользоваться без хайпа.
CI/CD тут уже много шишек набито, и думаю что лучше GitLab ничего нет.
А чем вам не угодили контейнеры? По-моему это крутая технология, которая много чего упрощает.
В начале карьеры DevOps я был ближе к разработчикам и помогал им конфигурировать и деплоить приложения. Потом стал поддерживать и администрировать БД, и стал ближе к инфраструктуре. Потом случился Kubernetes и понадобилась помощь и там и там. Было интересно, да и до сих пор интересно, потому что простые пробеламы сменяются сложными и все глубже погружаешься в недры куба.
Потом настал AWS и GCP, стал учить Terraform и облака. Тоже интересно, там валом всего, чтобы мысленно поупражняться.
Я думаю, что у вас выгорание чистой воды от переработок и смен работы, и скорее всего коротких сроков, что у вас не осталось удовольствия от работы и технологий. Логичным был уход в тихую гавань вечного и могучего С. Я вот тоже подумаю, только про Rust ;)
Но пока к меня поле не пахано с PostgreSQL в Kubernetes, и Data Science стеком на Амазоне при помощи Pulumi ну и своим Kubernetes кластером в on prem.
На последок хочу поблагодарить вас за то, что поедлились своей опытом и болью. Надеюсь вы найдете себя в С, а DevOps останется страшным сном ;)
З.Ы. Считаю что дело не в DevOps, а в условиях труда, коротких сроках и стрессе.
Поддерживаю Ваше мнение абсолютно во всём! И хочу добавить, что выгорание случается не из-за перемен, а и-за их количества! Будь-то частая смена работы из-за обстоятельств, от сотрудника не зависящих; или смена технологий по причине бурного роста компании; или требуют сделать быстрее, но при этом качественно не получается и в тебе умирает частичка перфекциониста. Тут дело даже не в той частичке, а в осознании, что любые недоработки сейчас выльются в серьёзные проблемы в будущем с недосыпанием и сбоям в 3 ночи. Все эти факторы вводят в депрессию с последующим выгоранием.
С одной стороны, стабильность и уверенность в завтрашнем дне невероятно важны для эмоционального здоровья. А с другой (хочу обратить отдельное внимание) что даже когда жизнь предоставляет возможность стабильно годами работать на одном месте в секторе DevOps, улучшая окружение и углубляя личные знания в основной сфере у таких как мы всё равно подгорает и хочется двигаться вперёд, прекрасно осознавая что не бывает стояния на месте — либо деградация, либо совершенствование. Вот в такие моменты осознаёшь, что надо начинать диверсифицировать свои знания, совершенствуясь в чём-то помимо DevOps. Я для себя выбрал Си в силу исторически сложившихся причин — моего подсознательного стремления к стабильности, интересу к программированию и отторжению противоестественных парадигм типа функциональной и ООП.
Согласен, когда перебор с переменами, не успеваешь продумать одно, как наваливается другое, а потом через неделю недоделанное первое дело даёт о себе знать и так попадаешь в порочный круг. Ещё достает, когда начинаешь рабочий день с четкого плана, а потом сразу всё идёт куда попало. Раньше меня это сильно беспокоило, но потом я понял, что рабочий день у меня нормированный, и я могу все это время либо решать чужие проблемы, либо свои задачи, но не все вместе. И как-то отпустило. Сроки можно и подвинуть, а вопрос о том, на что мое время будет лучше потрачено оставлю менеджерам.
Вот вы говорите что ООП и ФП противоестественны. А что в них такого? Не из пробирки же они вылезли. Как и все, они были рождены для решения проблем. И если эти проблемы Вам не знакомы, то и решение будет казаться чем-то странным.
Приведу пример. Работал в компании. Там было всего две среды - тест и прод. Чтобы развернуть два кластера БД, можно было написать скрипт для тест среды, потом его скопировать и поменять части под прод и будет два скрипта. Потом приходит требование сделать ещё один БД кластер в каждой среде. И тут начинаешь думать. По накатанной копировать скрипты и менять в них перенные или подумать, а чем же они отличаются и что в них одно и то же и вынести все разное отдельно, а все одинаковое вместе. Вот и получается абстракция. А скрипт становиться функцией от переменных, который в идеале должен приводить к кластеру БД.
Или а том же GitLab есть могучая функция extends, с помощью которой можно много чего упростить и сделать скрипт более компактным и понятным, а по сути это банальное наследование и композиция.
Вообще OOП зародился в Smalltalk в плоскости GUI и подразумевал обмен сообщениями между объектами, что ничего общего не имеет с тем же ООП в Java.
Думаю что True OOP - это сейчас Erlang. Гениальный язык и среда выполнения.
ФП - это уже из математики. Пока только помог чтобы осознать map/reduce ;) Монады вообще от лукавого.
Мне C нравиться тем, что на нём можно написать самую быструю прогорамму, но вот недавно я понят что можно ещё быстрее! ПЛИС - программируешь себе процессор, которые будет выполнять задачи быстрее любого кода, даже на ассемблере.
Вот думаю когда DevOps наскучит, разобраться в ПЛИС. Жаль там денег мало платят, но как хобби сойдёт.
Опыт в ПЛИС на пару с Сишкой это уже направление embedded. Очень, кстати, востребованное направление! И как хобби интересно, и для диверсификации знаний прекрасная альтернатива DevOps.
А что в них такого?
Я их отношу к противоестественным хотя бы потому, что мозгу Homo Sapiens естественной является императивная парадигма. Поэтому писать в ней код легко обучаются даже маленькие дети — простая последовательность действий как рассказ в книжке с ссылками на другие книги (функции). Чтобы научить мозг мыслить ФП, например, его сначала нужно вывернуть наизнанку и только потом на получившееся натянуть парадигму. И главный вопрос — ради чего всё это "натягивание"? Ради реальной пользы, или от скуки и повыпендриваться перед собой (Because! I! Сan!) Ну не существует реальной потребности перехода от императивной парадигмы к ФП! Любые задачи могут быть решены БЕЗ ФП и даже наоборот, если оставаться в рамках парадигмы то тот же Erlang не справится с парсингом 50 мегабайтового JSON — потребление ресурсов растёт геометрически (пишу с чужих слов, личного опыта в Erlang нет и не будет, да простят меня душнилы :)
Я вот тоже подумаю, только про Rust ;)
Меня как-то заинтересовала модель работы с памятью пресловутого Rust — что же там за клиллер-фича такая, от которой все в восторге? Почитал, разобрался ровно до того уровня, чтобы осознать что да, это конечно не то дерьмо в виде гарбидж-коллектора, это — другое. Просто иная модель автоматизации работы с памятью. Простите за нелестный отзыв, но почистить локальные переменные в конце функции добавив одну строчку free() мне и в C не составит труда. Подобный вывод у меня сложился по отношению ко всему тому, что считается лидирующими преимуществами Rust. Может быть для тех, кто Си ещё не знает или испытывает затруднение при прямой работе с указателями Rust может показаться интересным языком программирования, но лично мне он просто не нужен. Ну не конкурент он Си! Хотя бы потому, что программы на Rust априори потребляют больше ресурсов. А пресловутая «безопасность»… О ней можно будет судить только по мере накопления статистики серьёзных сбоев. У Си богатая история и обширная база статистики дорогостоящих ошибок — и думаю это основная проблема при сравнении «небезопасного» Си и вчерашнего младенца с именем Rust.
А ещё... Завтра появится какой-нибудь супер-новый, мегамодный... ну, например «Хруст». В котором выдумают новую фичу с переподвывподвертом и всё! Упомянутый Rust уйдёт в забвение вместе с тем ворохом созданного кода только потому, что все хомячки будут вещать исключительно о «Хрусте» и о том, что Rust уже стал вчерашним днём. И каково будет разочарование разработчиков Rust, когда вакансий будет становиться всё меньше и меньше? Все снова дружно побегут за пищащими хомячками учить «Хруст»?
Хочу привести жизненную аналогию. Стекло. Банальное стекло! У меня вся нога в швах и шрамах после детской травмы от разбитого стекла. Там шили на нескольких уровнях — кожа, мышцы, сухожилия и сосуды. Как результат разрезанных нервных волокон в определённой зоне полностью потеряна чувствительность — там хоть гвоздём ковыряй я ничего не почувствую. Заставил ли меня этот опыт отказаться от стекла? О нет! Конечно же нет! Оно смертельно опасно, но им пользуются буквально все! Всё потому, что удобство превышает недостатки. Да, детей ради их же безопасности приходится учить бережно и с предельным вниманием относится к стеклу и обращению с ним — у меня маленькая дочка и я знаю о чём говорю. Так же и программистам приходится предельно аккуратно относиться к созданию своих программ и специально учиться приёмам безопасного кодинга, но это не повод выбрасывать «опасный» язык программирования на свалку истории, тем более что широта возможностей без навязанных ограничений позволят не только себе выстрелить в ногу, но и соседу :-D
Я ничего не писал на С или Rust, поэтому даже особо сказать нечего. Тут каждый выбирает то, что ему больше нравится.
Мне Rust приглянулся тем, что у него самый высокий рейтинг "радости" разработчиков и что компилятор помогает находить и решать ошибки до исполнения. А как с этим дело в С?
Читал что уже в ядре Linux есть маленькая часть кода на Rust, так что думаю у него есть будущее. Не думаю, что матёрые разработчики ядра Linux абы кого к себе пустили.
С еще долго будет с нами, потому очень стабильный выбор.
Есть ещё путь поддержки редкого легаси кода и всяких Fortran. Ниша, но слышал там хорошо платят, а специалистов мало.
А как с этим дело в С?
Там полный порядок, не о чем беспокоиться. Во множестве имеются продвинутые компиляторы, высококлассные средства отладки и профилирования. На определённом уровне погружённости в язык приходит осознание, что все "проблемы" и "недостатки" языка полностью надуманы теми, у кого просто не хватило усердия его освоить.
легаси кода и всяких Fortran
Да, это удивительно, но это правда. И это очень интересный сектор рынка, в котором нет ни одного индуса-говнокодера, готового работать за 5 долларов в месяц. В зависимости от станы можно поднять до $300,000 в год на такой работе, каждый спец на перечёт. Главное, чтобы к этому душа лежала.
CI/CD тут уже много шишек набито, и думаю что лучше GitLab ничего нет
свой голос отдаю teamcity
Интересно. А для чего вы его используете? Как на нем DevOps пайпланы писать?
У меня есть пайплайн в GitLab, в котором два уровня триггеров, потому что набралось 108 кластеров, а и есть лимит триггеров, потому их пришлось организовать так. Сначала идут триггеры среды, они создают триррегы кластеров, а они в свою очередь создают пайплан для отдельного кластера. И все это чистый YAML, и знаний программирования не надо.
Такое в Jenkins даже думать страшно. Насколько я помню TeamCity не далеко от Jenkins, там тоже DSL, и что-то сложное на нем подчас просто не напишешь. Могу ошибаться.
TeamCity не далеко от Jenkins, там тоже DSL, и что-то сложное на нем подчас просто не напишешь
Да, Kotlin DSLи именно поэтому там как раз и можно написать очень сложные вещи. Да, в конечном счете это статичный конфиг на xml, но формирование этого xml на полноценном языке программирования - это очень удобно.
На одной из работ использовали довольно удобную (имхо) иерархию классов (и тут ООП, ога), что позволило добавлять проекты в CI/CD пайплайны буквально одной строкой.
Пока нельзя просто так взять и описать для AI программу на 10 000 строк, которую он сгенерирует за секунды. Но учитывая тенденции развития эта ситуация рано или поздно изменится и изобретательские генеративные возможности превзойдут человеческий мозг. Это будет не сейчас и не завтра, но это неизбежно случится.
Программа на С - это точное описание того, что должен делать железный друг. Точное описание на точном, однозначно понимаемом, языке.
Возможно ли описание сложной задачи для компа на естественном, человеческом, неоднозначном, языке?
Думаю, что да. Но будет ли оно более коротким, чем на С? Не потребует ли формулировка на нем ещё больше усилий, в том числе усилий по отлавливают багов (нежелательного поведения программы), возникающих из-за скрытых противоречий, неполных утверждений, множественности смыслов и т.п.?
Всё верно подмечено. Но мы же можем ИИ дать задание писать не сразу бинарный код для железа, а генерировать программу на Си, открывая возможности ревизии кода человеком. Это как написать ТЗ для джуна, которое будет исполнено почти мгновенно, а программист уже потом внесёт свои корректировки. Что для программиста будет проще, читать чужой код и вносить коррективы (которые, кстати, для ИИ тоже можно описать человеко-понятном языком) или писать код с нуля? Лично я с удовольствием даже сейчас рутину переношу на плечи ИИ и он прекрасно справляется с созданием целых блоков. Тем более код взрослых проектов иногда подвергается глобальному рефакторингу, когда программа полностью переписывается с нуля с целью устранения фундаментальных недостатков, от которых по-иному не избавиться. В таких случаях помощь будущих ИИ будет невообразимо полезной — скормили ему код и указали что именно нужно переделать. Лично меня такие возможности только воодушевляют и растёт понимание, что от опытного программиста как от лишней прослойки между project owner и ИИ индустрия не сможет избавиться ещё очень и очень долго. По крайней мере именно для высоконагруженных проектов, где действительно важна предельная производительность аппаратной составляющей.
Я когда на перле програмил, тоже думал "нам ваш ООП нафик не нужОн". И делал довольно внушительные проекты - шли доказательством, что можно что угодно написать без ООП. А потом поменял основной язык, а также начал "слегка" рефакторить старые проекты и офигел насколько мир изменился и насколько много в мире айти появилось сущностей, которые похожи друг на друга - и само наследование, абстракции просто напрашивались. А так да, лет 25 назад, та каких 25, лет 10 назад я бы говорил: да зачем там все усложнять?? зачем тут объект, просто функцию вызываешь и все. Так к чему я... я пришел к ООП эволюционно, своим собственным опытом и потраченным временем. На мой, естественно, субъективный взгляд, даже то ООП, что у нас есть - один из лучших инструментов на данный момент
Плюсую в карму за обоснованное контр-мнение.
На мой личный вкус есть большая разница между понятием удобства использования и тем высером головного мозга, который сейчас постулируется как ООП в C++, например. Там явно перемудрили. За Perl давно не слежу, но помню что их реализация OOP была вполне себе удобной для понимания в чужом коде. Как и PHP, кстати. Современное состояние дел меня подавно не интересует, т.к. даже во времена начала освоения пыхи и перлухи я посматривал в сторону Сишки с завистью, вздыхая над очередными ограничениями осваиваемых языков. Я даже тогда не мог понять почему в пыхе память дублируется при копировании массива в функцию и не вычищается даже после того, как я произвёл все изменения и изначальный массив уже вообще не нужен. Особенно расстраивало, когда обрабатываешь какой-нибудь мегабайтный массив погоняв его по коду, а пыха в результате отъедает полгига. И до сих пор не понимаю почему нельзя использовать указатели хотя бы в таких случаях (пусть бы неявно), особенно учитывая что пыха сама писана на Си и люди её пишущие очевидно должны разбираться в вопросе.
-
Почему ни в коем случае НЕ надо становиться DevOps инженером! Предостережения начинающим и совет что же делать если «НЕ»