Кто я такой, чтобы делиться своими суждениями и утверждениями? Мне почти 47, в сфере IT профессионально работаю около 25 лет, начав самообучение со школы, с папиного i386 с сопроцессором и модемного dial-up на зюхелях (ну... все же помнят.. да? ну да же? :-) Естественно, среди моего опыта и высшее образование, и технические сертификаты, и работа во множестве компаний самого разного масштаба и разных стран. Сейчас я обладаю как негативным, так и позитивным опытом в различных аспектах IT технологий, попробовав себя как в софте, так и в железе.
Этот опыт заставляет меня поделиться информацией из той самой негативной составляющей с целью предотвратить его повторение читателями. И да, тут будет много злобы и яда к тому дерьму тем технологиям, с которыми приходится работать каждый день DevOps и даже системным администраторам. Однако статья наполнена реализмом, а вовсе не пессимизмом! :-D В ней будет раскрыта вся голая правда про лично Ваше будущее как DevOps инженера!
Моя карьера началась с работы у провайдера на горячей линии — помогать пользователям решать их проблемы с подключением к интернету. Потом были шатания от программирования на PHP и Perl до системного администрирования. Долгий путь продолжался от серверных Windows до FreeBSD с Linux как в bare metal так и в облаках и контейнерах.
Мне давно нравилось программирование, но во времена начала IT карьеры меня вводила в ступор всё набирающая популярность парадигма ООП. Переусложнённа, требующая долго разбираться в чужом, невероятно перенасыщенном громоздкими конструкциями коде. Сначала я подумал, что это во мне что-то не так, что программирование это не моё, коль меня воротит даже при взгляде на слово “public:”. Правду я осознал значительно позже, но сначала не мог понять, почему ООП вызывает такое внутреннее отторжение. Ведь и глубокое понимание, и использование ООП в коде требовалось буквально от каждого работодателя! Сделав неправильные выводы я начал искать свой собственный путь ронина в других околоайтишных сферах. Именно знания разнообразных операционных систем, маршрутизации и опыт в виртуализации привели меня на профессиональную стезю DevOps инженера. Эта стезя меня вбросила в AWS (Amazon Web Services) за неимением альтернатив в те времена.
Работая так более 10 лет и занимая при этом ведущие технические роли в сфере DevOps крупнейших компаний и банков я словил себя на мысли, что мне это никогда вовсе и не нравилось! И занимался я этим исключительно по причине хорошей зарплаты (при этом тихо завидуя разработчикам, например за несопоставимый уровень ответственности за продакшн).
Нда…. На самом деле меня просто тошнит от DevOps! Эта специализация — редкостное дерьмо и я готов обосновать своё нелицеприятное утверждение!
Первая причина — усложнения. Усложнения всего того, что могло бы быть простым. Усложнения усложнений! Надо больше абстракций! Просто так надо! Просто это модно! Просто так делают все! Потому что вот так! Потому что Кубернетис…
Всегда находится какой-то великий и могучий интеллект к которому прислушивается руководство и который укажет как надо делать «правильно». К сожалению, это ни разу не Оккам. И жизнь показывает — мнением DevOps инженера при этом даже не удосужатся поинтересоваться.
Мало развернуть приложение на EC2-инстансе и обновлять его по ssh. НЕТ! Его обязательно нужно запихать в Docker контейнер, а контейнер в свою очередь всунуть в кластер ECS и обмазать всё в CloudFormation! Был упомянут ECS??? О нет! ECS был уже вчера!!! Сегодня нужен только EKS! Он глючный и плохо интегрирован в остальной зоопарк AWS? Ну и что!? Зато все вакансии для DevOps только с опытом EKS не менее 10 лет. И плевать, что сама технология работает только 6. Любые аргументы против воспринимаются руководством только как саботаж со стороны подчинённого!
Об основной цели вынуть побольше денег из заказчиков AWS сто́ит умолчать, но упомянуть о побочных проблемах в виде сбоев на каждом слое абстракции и не забыть о том, что никто об этом недоразумении не позаботится кроме DevOps. И именно DevOps будет потом за всё отвечать и за всё отгребать всё разгребать!
Вторая причина. Нужно понимать 300500 технологий, иметь в них опыт и всё равно при смене работодателя на техническом собеседовании осознать, что из всего опросного листа можешь уверенно ответить только на половину. Остальное либо уже забыто, либо вообще никогда не встречалось даже по названию. Не менее 300 технологий на одном рабочем месте! Карл! И это не преувеличение хоть цифра и навскидку! А дальше — хуже!
Третья причина. Перспективы углубления знаний в том самом пресловутом количестве технологий. В жизни DevOps инженера мало знать 300 технологий. Через год такой инженер должен будет знать ещё 300, потому что за год выйдет именно столько изменений и старые технологии уйдут на второй план. Жил себе был Elastic Load Balancer, для решения глюков с которым уже понастроено 500 костылей, но НЕТ, он больше не нужен! Построим новые костыли и назовём их теперь Application Load Balancer и Network Load Balancer — любитесь! Как насчёт старых добрых опенсорсных HAproxy плюс BGP на Quagga? Нет, не слышали! Да и зачем такое знать клиентам, если на on premise нельзя их поиметь на деньги?!
Если работодатель пожелает резервировать свою инфраструктуру помимо AWS ещё и в GCP то инженеру придётся разбираться ещё с 3000 технологий, потому что там всё своё и абсолютно непохожее, начиная от терминологии и заканчивая GUI на пару с IaC. Или Azure кинет кость предложит на цент дешевле — эффективные менеджеры высунув язык мчатся в новом направлении. Что, опять смена работодателя?! Учите ещё 300 технологий! Например, разберитесь с terraform, но этого сразу будет мало, у нас же сложная инфраструктура! Поэтому нужен terragrunt, как же без этого, как же без усложнений с дополнительными слоями абстракции? Неужто мало? Но не надо беспокоиться — у следующего работодателя не будет ни первого, ни второго. У него CloudFormation на 30 000 строк IaC кода и всем предыдущим опытом останется только подтереться. Что, опять новый работодатель и опять terraform? Классно же, ведь проходили уже? Но за 3 года забивания головы другими 300 нанотехнологиями уже забываешь нюансы того самого terraform’a и банальные вопросы на собеседовании ставят в тупик…
Как оно в жизни: приходишь в компанию в помощь крутому 20 летнему девопсу, который там уже лет 100 работает и всё-всё знает (тут слышится закадровый смех ситкома). В результате оказывается, что от того девопса давно хотели избавиться и он через неделю уходит в закат на вторую работу о которой никто не подозревал, не оставив после себя ни паролей, ни ключей доступа к облаку. Пыхтишь по 12 часов в день без выходных чтобы превратить в конфетку всё то дерьмо проблемную инфраструктуру на которой крутится приложение в продакшене под большой нагрузкой. Терять трафик (значит терять клиентов) категорически нельзя ни при каких условиях, поэтому все изменения делаешь в 3-4 часа ночи по причине минимальной нагрузки на ресурсы. На твой сон и стресс всем плевать, мол, всё оплачено и «ты же понимаешь...». С нуля переделываешь инфраструктуру, переписываешь from scratch весь IaC, автоматизируешь деплоймент новых версий приложения через CI/CD, не спишь ночами когда DDoS и… Как только всё стабилизируется — компания начинает считать, что слишком много тебе платит, а с поддержкой на самом деле может справиться даже джун или те же фулстэки (подумаешь, пару кнопок нажать). И с этого момента всё в карьере DevOps начинается по-новому кругу… кругу ада. И увы, но это даже не самый печальный сценарий…
Подводя итог декады хочу признать, что я спустил в унитаз 10 лет своей профессиональной карьеры, в течение которых я пытался расти и развивать знания как технический инженер в сфере DevOps. 10 лет накопленных знаний, которые через 3-5 лет станут бесполезными! Всё настолько поменяется, что ничего из ныне востребованного НИКОМУ уже не будет нужно.
Пророчу. Придёт какая-нибудь контейнеризация на базе виртуализации написанная не на Go, но на Си и как следствие работающая в 10 раз быстрее... и Kubernetes перестанет существовать! Гугля скинется с майкрософтом, купит Amazon и всё что там есть переедет в GCP/Azure, будучи уничтоженным накорню. Не верится? А кто сейчас помнит про Skype? Ведь до покупки майкрософтом это был лучший мессенджер, который до сих пор никто не смог превзойти по целому ряду уникальных технологий, взять хотя бы распределённые вычисления о которых даже никто не подозревал... Эх...
Что ещё может произойти? Да что угодно! И с нами и с вами произойдут китайцы, например! Но что бы ни происходило, ни у одной из технологий, на которой сейчас базируются знания современных DevOps инженеров, не будет будущего уже в ближайшее десятилетие. Этих технологий просто уже не будет существовать или они перейдут в разряд невостребованных. Остались сомнения? А ну, кто сейчас вспомнит очень популярные в своё время операционные системы AIX, HP-UX (существующие, развивающиеся и продающиеся по сей день, кстати) и что произошло с теми инженерами, которые потратили десятилетия своей жизни работая с ними и совершенствуя в них свои знания?
Никогда! Никогда и ни за какие деньги не становитесь DevOps инженером! Это забивание бесперспективным мусором своего мозга и кратчайший путь к выгоранию.
Но что же делать? Разве вообще есть будущее в IT на фоне успехов AI? На этот вопрос персонально я могу ответить только экстраполируя свой индивидуальный опыт на своё же ближайшее будущее и приводя личные рассуждения, которые меня в конце концов привели к текущему окружению и новой профессии.
Я переквалифицировался и стал программистом Си. Всё верно, чистый Си. Ни C++, ни С# — всё это совершенно разные языки, безуспешно пытающиеся использовать имя самого успешного и востребованного, но не имеющие ничего общего с оригинальным Си в своём первозданном виде.
Как уже было упомянуто, повсеместное засилие ООП у меня вызывало недоумение и абсолютное отторжение. Тогда не получалось обосновать даже самому себе зачем так всё усложнять и почему несмотря на проблемы все упорно продолжают прыгать на грабли. Но время шло, я уходил всё дальше от программирования в DevOps и инжениринг операционных систем, но раз за разом в мыслях возвращаясь к теме разработки. И вот однажды меня прорвало — я сел и целеустремлённо погрузился в язык программирования, к которому ещё со времён PHP проявлял искренний интерес. Конечно же это Си! На PHP значительно повлиял синтаксис Си (и на самом деле PHP полностью написан на Си), только по этой причине PHP удостоился чести быть тут упомянутым. На этом его персональные достоинства заканчиваются.
Язык программирования Си увидел мир (Hello world) 52 года назад. О да, более полувека! И по сей день остаётся одним из лидирующих во всей отрасли (TIOBE Index). Именно на Си помимо PHP были написаны Perl и Java, Lua и Ruby, а так же ряд других языков. Только впоследствии были добавлены недостатки в виде гарбидж-коллектора, слабой типизации и другие «костыли», приводящие к значительному падению производительности и неконтролируемому расходу памяти под нагрузкой. Особенно в продакшене! Или что ещё хуже — под паразитным трафиком. И не надо мне рассказывать обратного! Уж кому-кому, но мне больше никто не сможет обосновать преимущества перед недостатками вышеупомянутых ЯП, а так же таких как NodeJS, Go, Python, C# и подобных наколеночных поделий «великих мастеров программирования» из другой вселенной, в которой не существует понятий QOS, Scalability, High load и Low Latency.
Си меня заинтересовал в первую очередь отсутствием каких либо ограничений. Ну кто будет писать драйверы на Java или PHP? Правильно, их пишут на Си! GUI? Пожалуйста! Супермейнфреймы? Не проблема! Создавая разнообразные программы я осознал, что это действительно язык вообще может всё! Он может предельно эффективно использовать ресурсы как mp3 плеера с простым чипом, трудиться в виде программ на Вашем лептопе, так и использовать все аппаратные возможности гигантских вычислительных кластеров. Работая с Си мне удалось ощутить радость от открывающихся возможностей и не найти ни одного недостатка. Да, Си не идеален абсолютно, у него есть свои сложности. Например, синтаксис механизма разыменований до сих пор иногда заставляет меня рыдать. Но это только сложность, это НЕ недостаток! Со временем я понял, что все аргументы против Си надуманы теми, кто его просто не знает или ищет оправдание своей безалаберности — один такой шутник ляпнул про ногу, прострелянную с помощью Си (Бьерн Страуструп) а толпа оголтелых подхватила это как знамя и неоспоримую аксиому. Тот же самый шутник пушил всему миру ООП и неплохо в этом преуспел, даже лучше чем любой наркодиллер. И что же оказалось в этой пресловутой парадигме не так? А то, что она просто НЕ НУЖНА!!! И это открытие меня поразило до глубины души. Оказывается, это не во мне проблема, просто мир вокруг сошёл с ума и каждый эффективный менеджер в сфере IT сидит с умным лицом и рассказывает, что без ООП обойтись невозможно. Но он это делает не со зла. Просто у него проблемы с критическим мышлением и отсутствие технического опыта, которые он компенсирует уверенным взглядом и хорошо поставленным голосом. При этом все прочтённые им умные книжки в один голос вещают, что только с ООП как раз и надо начинать строить любое ПО, особенно для решений бизнес-задач. И вот с этого момента управляемый подобным менеджером бизнес уходит во все тяжкие: винда, .NET, 50 Gb RAM и 10 CPU для программ уровня «Привет мир», и конечно на десерт — вся инфраструктура в облаках с расходами превышающими on premise на один порядок и выше, и вендор-лок в придачу. Может я малость приукрашиваю ради красивого словца, но таких примеров из жизни — легион! Потом проходит время и появляются конкуренты, которые умудрились построить инфраструктуру чуть удачнее и предложить цены уже ниже себестоимости вышеупомянутых монстров с ООП. И всё, бизнес коллапсирует, а эффективный менеджер ищет новую цель для улучшения личного благосостояния и очередного повышения ЧСВ.
На самом деле оказывается, что НЕ нужно буквально ничего, что проповедует ООП! Почему? Да потому, что и без этого всё превосходно работает! ООП «помогает» в работе с огромными проектами? Ерунда! Ядро Linux насчитывает миллионы строк кода и оно написано на Си в простой и понятной детям императивной парадигме, без каких-либо ненужных постулатов в виде инкапсуляций, наследования и полиморфизма; без всех тех костылей типа сеттеров и геттеров, которые являются последствием усложнённых усложнений.
За полвека для Си разработаны тысячи удобных инструментов, от IDE, до отладчиков, статических анализаторов и компиляторов на любой вкус и аппаратную платформу. Ориентируясь в Си даже на начальном уровне освоения уже невозможно просто так взять и выстрелить себе в ногу. Даже самый топорный современный компилятор сразу предупредит о проблеме в строке if (variable = NULL), а такие инструменты как sanitize или valgrind подскажут где проблема с контролем памяти, если это случайно упустит программист. Си универсален. Си 100% переносим и платформо-независим на уровне исходного кода. Он уже просуществовал полвека и будет существовать в своём мало-трансформирующемся виде ещё очень, очень долго!
Будущее Си — парное программирование с AI. Я достаточно интенсивно использую в своей работе современные AI технологии и прекрасно осведомлён как об их достоинствах, так и о недостатках. Пока AI далеки от самостоятельного написания полноценных программ и ограничиваются созданием кода уровнем чуть сложнее «Hello world». Пока нельзя просто так взять и описать для AI программу на 10 000 строк, которую он сгенерирует за секунды. Но учитывая тенденции развития эта ситуация рано или поздно изменится и изобретательские генеративные возможности превзойдут человеческий мозг. Это будет не сейчас и не завтра, но это неизбежно случится. А что же будет когда всё это произойдёт? Программисты уйдут на пенсию? Возможно да, но только потому что им надоест писать на старости лет :-D
На рынке останутся те, кто настолько хорошо разбирается в программировании, что сможет формулировать задания для AI с учётом глубокого понимания алгоритмов; сможет корректировать программы написанные AI, а так же контролировать результат что именно было написано и создавать юнит-тесты, по которым AI будет самостоятельно генерировать код.
На самом деле ничего нового! То же самое можно наблюдать сейчас в современных командах, в которых проповедуют любой из видов парного программирования. Только в будущем человек будет объединён с AI более тесно и такой пары будет достаточно для написания качественного кода.
К чему всё это было сказано? К тому, что в противовес постоянно изменяющемуся и даже, не побоюсь этого слова, ДЕФОРМИРУЮЩЕМУСЯ миру технологий DevOps, мир программирования на Си стабилен и будет таковым ещё очень долго — на век читателей точно хватит. Поэтому отказ от DevOps с переходом в программирование вообще и программирование на Си в частности, стало моим личным выбором. И я рад поделиться своим опытом с читателями.
