Эксперты Слёрма — Антон Черноусов, Павел Селиванов, Денис Наумов и Владислав Килин — собрались, чтобы обсудить, какой язык больше подходит для админов, инженеров и devops.

Дисклеймер. Этот материал не претендует на звание истины в последней инстанции. Статья создана на основе рабочего (и жизненного) опыта экспертов, которым они поделились на этом митапе.

Интро

Где кончается работа инженеров, и начинается работа программистов? С одной стороны, не инженерское это дело — программирование. Отдаем все в разработку, и гори оно синим пламенем. С другой стороны, на практике разницы все меньше и меньше. Возьмем SRE: эта сфера находится непосредственно в Ops-е (обслуживание и восстановление), но здесь нужно очень глубоко понимать разработку. Получаем, что SRE — это в том числе программист.

Google в своей SRE Book предлагает не разделять потоки найма и брать на работу SRE и разработчиков, которые пилят бизнес-фичи, из одних и тех же людей. Понятно, что нельзя нанимать программиста, который совсем не шарит в Linux, но знание ОС для него будет на ступень ниже: если условный разработчик собеседуется на сеньора, то ОС ему нужно знать на уровне мидла.

Для SRE все будет с точностью наоборот: сеньор должен знать ОС на уровне сеньора, а программирование — на уровне мидла. Поэтому инженеры, которые хотят перейти в SRE, должны качать разработческие навыки; нарабатывать опыт написания настоящих production-приложений, больших бизнес-приложений. Здесь важно понимание концепции микросервисов и их взаимодействия, разбития этого всего на OP.

Часто в компаниях практикуется полная передача проекта на сопровождение в SRE. Когда продукт находится не в стадии активной разработки, его поддерживает только SRE-команда. Соответственно, если в приложении возникают проблемы, инженеры открывают код, дописывают нужное, фиксят баги и выкатывают все в production. И это уже непосредственная, прямая разработка.

А теперь давайте говорить о программировании для инженеров.

Где-то в 99-м году главный выбор для инженера заключался между Bash и Perl. Естественно, хороший инженер должен был знать и то и другое, но в чем-то была нужна более сильная компетенция. Такие вот муки выбора вставали перед инженерами регулярно. Но со временем Perl стал применяться реже, и сейчас на горизонте практически не появляется.

Сегодня мы лицезреем другое противостояние необходимых навыков для инженера: Python против Golang. Первый — огромный как айсберг: за все годы на него многое наросло из разработки. Пайтон везде интегрирован, машинное обучение на нем поддерживать очень круто. С другой стороны врывается Go — быстрый, прямо крейсерский. А еще этот язык родился сразу «в облаках», поэтому вокруг него нарастает совершенно другая идеология разработки и инфраструктура.

Python

В Пайтон довольно просто погрузиться, когда не знаешь ничего о разработке: начать можно с простеньких скриптов или Hello world-ов. Это интерпретируемый язык, который позволяет писать скрипты. Отлично справляется, когда нужно автоматизировать 2 задачи друг за другом, но сделать чуть хитрее, чем может Bash.

Python точно пригодится инженеру, когда нужно скопировать операции прямо в production-е, чтобы они там сразу запустились. Конечно, лазать по prod-ам руками в 21-м веке со всеми нашими Cloud Native подходами — идея, мягко говоря, не слишком хорошая. Кто-то даже предлагает бить за такое по рукам. Но мы живем в неидеальном мире, и иногда приходится работать так. 

С помощью Пайтона можно походить по prod-овым сервакам и запустить важные операции. Уж точно лучше, чем руками. Если автоматизировать с головой, то вероятность ошибиться меньше, чем при ручном выполнении одной и той же операции по 500 раз. Скриптовый язык полезен для простеньких задач, когда нужно иметь в кармане скрипт, который делает что нужно, но не применяется регулярно. Будет даже удобнее, чем все время таскать за собой бинарник.

Python тяготеет ко многим практикам. Самое очевидное — грепать логи. Еще можно, например, автоматизировать простые задачи и класть их в Крон. Пользователи раскатываются из AD-шки простым Пайтоновским скриптом, который лежит в Кроне на каждом сервере. Раз в 5 минут он ходит в AD-шку, проверяет, не добавились ли в группу сервера новые пользователи, и создает всех пользователей на сервере. Это можно сделать и на Ansible, но он медленный и достаточно прожорливый — проще написать 20 строчек на Пайтоне.

С системами оркестрации этот язык тоже отлично справляется. Возьмем тот же Ansible: некоторые вещи сделать в нем сложнее, чем написать свой модуль, который будет делать задачу, как надо.

Еще одна важная область применения Python — ML-Ops. Здесь он решает 2 задачи: является языком поддержки ML-специалистов и одновременно системным языком, которым может пользоваться инженер. Важно учитывать, что никакие функции и библиотеки для Machine Learning-а чисто на Пайтоне не написаны (большинство на C++), здесь язык выступает как удобная API-шка. Большой плюс в экосистеме: у других языков на текущий момент столь распространенной экосистемы нет.

Даже с Kubernetes, написанном на Go, можно работать на Пайтоне. Например, проверять статусы pod-ов и в случае чего алертить в Telegram или Slack. Для этого можно взять родную Куберовскую библиотеку, сходить в API-шку K8s, достать все необходимое и отправить в условный Telegram.

Библиотек и фреймворков у Python тоже достаточно: DevOps Python Tools в GitHub-овских репозиториях, библиотека для работы с GitLab-ом, преобразователи (например, XML в Yaml) и прочее.

Пока все, о чем мы писали, говорит в пользу Python. Но у любого хорошего инструмента всегда есть обратная сторона.

Самое очевидное — табики, их многие не переваривают. Пайтон медленный, куда без этого. Язык подходит в основном для простых задач, когда нужно написать короткий скриптик, благополучно о нем забыть, а в нужный момент достать. Веб-приложение сделать на Python будет проблематично.

Выше говорили про запуск скриптов на prod-е, и это иногда может быть достаточно болезненно. Условный Memory Foot Prints от Пайтона на 2 или 3 порядка больше, чем от того же Go. С одной стороны, скрипт написать действительно проще. С другой — запускать его именно на prod-е, даже read only, не всегда рационально. Бывает, что production просто не позволяет занять 200 мегабайт оперативы скриптом, который грепает логи.

Простота для входа может быть как преимуществом Python, так и его существенным недостатком. Когда приходится погружаться глубже, то это вполне может привести к необходимости писать на C-подобном языке: С-Python, C, C++. Задачу нужно решить здесь и сейчас, но затык в том, что писать придется на C.

Пример. Возьмем большую систему сбора пользовательских событий с разных frontend-ов, с разных серверов, где все приложение написано на Пайтоне с использованием C-библиотек. Если по системе жахнет, скажем, 70 тысяч довольно-таки жирненьких запросов в секунду, ее придется переписывать.

Приближаясь к уровню сеньора, рано или поздно придется столкнуться с тем, что Python тормозит. Следовательно, всю экосистему надо адаптировать под нынешние реалии, когда десятки тысяч RPS — это обыденность, учитывая всякие Интернет вещей и прочее.

Golang

На Go легко начать писать большие сервисы, сложные консольные утилиты и при этом очень трудно что-то сломать. Поэтому если Ops никогда в жизни не писал код, то стоит поставить на Golang. Он также хорошо подойдет тем, для кого Python слишком медленный, а Java слишком объектно-ориентированная.

Это компилируемый язык, который хорошо справляется с регулярными процессами или высокими нагрузками. При необходимости написать что-либо сложнее скрипта — вебсервис или консольную утилиту, которую нужно разложить по серверам и периодически ей пользоваться, — Go станет эффективным решением. Гораздо удобнее сбилдить один бинарник без зависимостей и раскидать на все сервера по ESP.

С машинным обучением Golang тоже дружит. Он медленно, но верно движется в сторону того, чтобы занять нишу ML в Data Science наравне с Пайтоном и поделить с ним все пространство возможностей.

Лирическое отступление. Время и компетенции современного инженера стоят дороже, чем вычислительные ресурсы. Поэтому облака и Kubernetes-ы нацелены на то, чтобы однопоточные языки программирования могли работать быстро. Если система может держать, например, 10 RPS, то с помощью Kubernetes это количество можно серьезно увеличить.

Go смотрит в эту же сторону: лучше написать что-то простое и запустить в Kubernetes, чем сидеть на OS-ях и работать с памятью, отлаживая свою программу. А прямая работа с памятью еще и чревата ошибками.

Говоря о Кубере, можно назвать еще один плюс изучения Golang: он точно нужен инженеру, если компания нацелена на использование K8s в качестве основного средства оркестрации микросервисной архитектуры. Если инженеру нужно дописать оператор к Kubernetes, гораздо проще и удобнее реализовать это на Go: можно сделать все Kubernetes-подобным.

Но есть и подводные камни, без них никуда. Например, с GitLab-ом напрямую Go работать не умеет — приходится вручную прописывать запросы, Quary параметры.

Выводы

Какой язык выбрать инженеру в качестве первого? Как всегда, однозначного ответа нет. Раньше выбор ограничивался стандартами организации: хочешь в компанию — будь любезен, учи тот язык, на котором тут программируют. Поэтому выбирали языки, на которых потенциально могли начать работать. Теперь же ситуация поменялась: разработка стала гораздо более распределенной, давая возможность зарабатывать на жизнь при помощи любого языка.

Python станет адекватным выбором, если необходимо познакомиться со всеми распространенными концепциями в области разработки — с теми же классами. Этого языка будет достаточно, чтобы начать работу. 

Конечно, после изучения и работы на Python инженер может легко уйти в разработку, что не всегда выгодно компании. Но, как говорил философ, это уже совсем другая история.

Golang подойдет, если надо сразу с места в карьер: создание масштабных приложений, веб-сервисов. Плюс, на нем действительно трудно что-то сделать не так. Go могут выбирать инженеры, которые не планируют совсем с головой уходить в разработку.

А теперь — главный совет от экспертов Слёрма.

Бывает так, что человек всю жизнь учил Python, но при переходе в новую команду обнаружил, что здесь работают на Golang (или наоборот). Это нормально.

С точки зрения инженера все языки программирования выглядят примерно одинаково: те же самые функции и т. д. При этом синтаксис — это обычно документация на 3-4 странички, чтобы понять, как работает язык. Поэтому для современного инженера хорошей практикой станет качать не просто знание одного языка, а понимание программирования как такового вместе с умением читать чужой код.

Способность читать чужой код дает 50% знания языка. Можно сколько угодно знать Python, но не суметь понять код, написанный другим разработчиком.

Умение прочесть разные языки программирования сделает из инженера по-настоящему универсального специалиста, который сможет оперативно разобраться в любом коде с использованием Википедии и двух страничек о синтаксисе.

Конец.

P. S. У Слёрма есть курс «Python для инженеров», старт потока 29 августа, и «Golang для инженеров», старт потока 10 октября.