Поговорим про ближайшее будущее Devops, каким его я его вижу в течении следующих 10 лет.

👽 Сразу скажу, что к астрологам я не обращался, а все нижеперечисленное является компиляцией информации, собранной из разных частей интернета и приправленной моим личным мнением.

Миграция из облаков
▪️Частичная миграция в виде создания гибридных окружений будет иметь место в ближайшие годы из-за экономических причин, а также в соответствии с обновленными политиками безопасности компаний, когда они хотят хранить и обрабатывать данные у себя.

Кубер на железе
▪️K8s on bare metal все больше будет набирать обороты исходя из пункта выше, поэтому придется разобраться в тонкостях развертывания кластера своими силами. Внезапно окажется, что облака нас сильно разбаловали, но куда деваться.

AI/MLOPS
▪️Еще одним следствием перехода от облачных решений будет усиление внедрения MLOPS, то есть операций для поддержания полного цикла работы с так называемым искусственным интеллектом. Уже сейчас многие компании готовят ML у себя, но из-за увеличения общего внедрения AI этот тренд только усилится.

Инструментарий
▪️Похоже что такие инструменты как Crossplane получат большее распространение. Также в пятки терраформу дышит похожий инструмент Pulumi, который позволяет описывать инфраструктуру используя языки общего назначения. Это снимает ограничение терраформа, где можно использовать только фирменный HCL, однако несет в себе необходимость знать какой-то еще язык. Это очередное подтверждение тому, что навык программирования девопсам очень желателен.

☝️Но а фундаментальные знания остаются востребованными в любом случае, поэтому не забывайте сначала инвестировать в них, а условный Crossplane вы легко потом вытянете.

Заметил, что обо мне, авторе канала, вы почти ничего и не знаете 👻.

Сейчас расскажу кто я и что вообще тут делаю:

👋 Меня зовут Александр, сейчас работаю DevOps инженером, по совместительству Go разработчик (для нужд devops). В прошлым бывал на позиции CTO.

В IT с 1999 года, именно тогда начал заниматься разработкой, а также настройкой и поддержанием серверов. В те давние времена еще не было такого понятия DevOps, но часть практик уже существовали. Шли годы, и мне все больше хотелось уйти от разработки и наладить CI/CD процессы в компании, что в итоге и было сделано.

👽 За свою жизнь сделал довольно внушительное количество проектов, своих и коммерческих (нужное подчеркнуть), обо всем можно почитать тут: https://lifeisfile.com/en/

🤠 Несколько лет назад у меня появилась идея создания практических курсов на собственной платформе, благо опыт в разработке позволял реализовать это с легкостью. Уже тогда мне было очевидно, что популярные образовательные платформы движутся не в том направлении, а их цена/качество очень далеки от идеала. Так появился проект DevopsTrain. Я уверен, что будущее не за массовым сегментом, а за персональным подходом.

Теперь я провожу консультации, менторю и создаю курсы, чтобы счастливых девопсов в этом мире стало чуточку больше 😎.

В этот раз я бы хотел затронуть тему так называемых софт-скиллов, то есть умения коммуницировать с людьми.

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

▪️Далеко не всегда задачи ставятся четко, и требуется пройти по нескольким контактам, чтобы понять в чем заключается задача, и начать ее выполнять. А далее вы понимаете, что не все данные для выполнения задачи у вас есть, и снова приходится обращаться к коллегам.

〰️ И поверьте, это не всегда стереотип, что айтишники интроверты, так действительно бывает. В этом нет ничего плохого, просто, чтобы делать свою работу нужно найти подход к каждому человеку. Кому-то достаточно написать, кому-то надо назначить онлайн встречу.

Да, работа в команде она такая, 50% времени - это коммуникации в разном виде.

👽 Сложнее всего бывает найти концы, когда вы точно не знаете кто вам нужен. Обращаетесь к одному, а он говорит, это не мое, спроси у Коли. А Коля переводит на Толю.

К этому надо быть готовым, ведь коммуникация - тоже часть работы, нравится или нет.

Решил я тут выделить преимущества своего наставничества и DevopsTrain перед популярными образовательными платформами 😎.

Давайте пробежимся по пунктам:

Индивидуальный подход
✖️ у других: обучение в группе, зачастую довольно большой
✅ у меня: обучение 1 на 1 с ментором (это я, если что)

График занятий
✖️ у других: определенный, с дедлайнами
✅ у меня: вы занимаетесь в своем темпе

Старт занятий
✖️ у других: в определенные сроки
✅ у меня: в любой день

Время занятий
✖️ у других: строго в определенное время
✅ у меня: вы сами бронируете удобное время в календаре

Стоимость
✅ у меня: Х
✖️ у других: 2Х-3Х

Репутация
✖️ у других: терять уже нечего
✅ у меня: крайне важна

Процесс обучения
✖️ у других: большое кол-во видео с минимальной практикой
✅ у меня: интерактивная платформа для выполнения задач, без видео

Возврат средств
✖️ у других: хрен вернешь чего
✅ у меня: согласно формуле расчета по оферте. Прецедентов не было пока.

Так что задумайтесь, у кого вы хотите учиться 😁.

☝️На апрель, кстати, осталось 1 место.

Подробнее о наставничестве можно почитать тут: https://devops.lifeisfile.com/post/mentorship/

Моя платформа: https://devops.lifeisfile.com

📎 Написать мне можно на почту devops@lifeisfile.com или в телегу.

Из каких профессий приходят в девопсы 👻

📎 Информация собрана из разных мест, включая общение с людьми, которые проходят обучение в devopstrain.

📈 Из тех. поддержки

Человек работал в ТП бок о бок с командой девопсов, нахватался у них разного, тема стала интересовать и плавно начал вкатываться.

📈 Из пехоты

Человеку 67 лет, служил в армии США на разных позициях. В 81-м начал интересоваться армейскими компьютерами, стал изучать язык BASIC. Затем прокладывал телефонию и LAN, и стал админить Windows NT. Потом переключился в Unix, и только потом уже в Devops. Вот такая интересная и долгая карьера. Те, кто думает, что уже опоздал - напрасно.

📈 Из QA (тестирование)

Автоматизировал тесты на Python и Docker, чуть касался инфраструктуры, которая выполняла эти тесты. Через 2.5 года перешел в devops.

📈 Из сисадминства

По наблюдениям, это самый очевидный путь для большинства.

📈 Из разработки (бекенд и даже фронт)

Собственно, автор этой заметки именно оттуда, хотя опыт сисадминства был и до этого еще.

📈 Из пекаря

Как вам такой путь: пекарь - официант - техподдержка - управление инцидентами - devops.

📈 Из DBA (администрирование баз данных)

Надоело готовить Oracle, перешел в Devops.

👾 Пишите в комментах, откуда вы к нам прибыли или собираетесь, интересно почитать.

🔒Основы безопасности в devops

Недавно прошло соревнование Pwn2Own 2024, результаты которого в очередной раз напоминают о главном правиле: абсолютно безопасных систем почти нет 👀, особенно если речь идет о приложении, в котором несколько сотен тысяч строк. Open source тут далеко не гарантия надежности.

Наша задача как devops инженеров - снизить вероятность взломов.

Для этого есть несколько правил:

1️⃣ Проблематично сломать то, к чему нет прямого доступа. Надежнее всего выключить сервер из сети, но это не всегда хороший вариант 😁.

Правило: наружу должно торчать только то, что необходимо. Например, если речь про сайт или мобильное приложение, то открыть нужно только доступ к 80 и 443 порту для браузера и аппки. Всякие служебные сервисы должны быть не просто закрыты файрволом, но желательно вообще сидеть во внутренней сети.

2️⃣ Бекенд и фронтенд должны быть спроектированы таким образом, чтобы известные методы взлома не работали, к примеру SQL инъекции, и прочие инъекции. Это не задача девопсов, но понимать этот вектор атаки важно.

3️⃣ Отказы в обслуживании или DDOS. Тут речь не про взлом, а про то что, приложение ляжет от паразитной нагрузки, что тоже так себе. Решением может стать фильтрация трафика своими средствами или внешними, вроде cloudflare.

4️⃣ Грамотное разделение доступов в компании: разработчикам не нужно (ну почти) иметь доступ к данным пользователей, поэтому не нужно и провоцировать их на это. Если нужно что-то поменять в базе, пусть пишут миграцию, которая будет применена в процессе CI/CD или через специальный хендлер

5️⃣ В git не должно храниться ничего, что представляет угрозу безопасности: пароли, ключи и тд. Приложение в момент запуска должно ходить в vault или аналог за всеми кредами, которые требуются для его работы.

А как у вас в компании с безопасностью? 👾

DevopsTrain

В продолжение поста про безопасность, сегодня поговорим про обновления, которые являются ключевым фактором обеспечения безопасности.

👽 Тут, кстати, все неоднозначно.

С одной стороны, нам все говорят: "обновляйтесь до последней версии", потому что в ней исправлены ошибки и уязвимости. Но забывают упомянуть, что вместе с этим могут быть добавлены новые ошибки и уязвимости 🫠.

Конечно, вы все уже наслышаны про недавний бекдор в архиваторе xz. Напомню, там была история, про то как один из разработчиков долгие годы втирался в доверие к мейнтейнеру проекта, в итоге, получил необходимые полномочия, чтобы добавить бекдор в исходный код. Но внимательный глаз Andres Freund обнаружил вредоносный код во время проведения бенчмарков и оповестил об этом сообщество. В итоге, версии 5.6.0 и 5.6.1 оказались уязвимыми.

Поэтому, к обновлениям нужно подходить прагматически, иногда обновления ради обновлений несут только новые проблемы. Другое дело, если вы точно знаете, что в новой версии исправлено то, что вам требуется. Тогда, конечно, обновляйтесь.

👾 Учитывайте также, что по народным приметам, обновление в пятницу - это плохо и ничего хорошего не сулит. Хотя... если планов на выходные нет...

Иногда, кстати, нас вынуждают просто обновиться, как правило, облачные провайдеры. Им поддерживать старье совсем не хочется, вот они и сдвигают окно доступных версий вправо и при случае сами обновляют сервисы, хотите вы этого или нет.

А ведь это тянет за собой изменения функционала, поэтому, мы, девопсы, без работы не останемся 🤌.

DevopsTrain

Раз уж в прошлом посте речь зашла про обновления, то имеет смысл поговорить про версии и схемы версионирования.

Самая популярная схема - Semver . Пример: 2.0.1

Тут выделяют части:
▪️ Major, в данном случае это 2
▪️ Minor, в данном случае это 0
▪️ Patch, в данном случае это 1

Когда же инкрементировать каждую из частей в данной схеме?

Major обновляем только в случае серьезных и зачастую обратно несовместимых изменений.
Minor обновим, если внесли значимое изменение, но оно не рушит обратную совместимость.
Patch - для очень мелких изменений и исправлений ошибок.

Еще вариант схемы - Calver. Пример: 2023.04.2

Вариаций может быть много, версия может включать день, квартал и Patch на конце. Он может быть полезен в системах, где часто происходят изменения и желательно знать время их выпуска, либо наоборот вы знаете график релизов заранее. Пожалуй самый яркий пример: Ubuntu. Скоро как раз ожидается версия 24.04 👽🤌

И конечно, вы наверняка знакомы со схемой Sequence base versioning, то есть простое увеличение целого числа. Примеры Firefox 125, Fedora 40, Android 15.

Наткнулся на интересное обсуждение зарплат и уровня жизни DevOps инженеров в разных странах.

Различия существенные: в Европе от 35К евро в год и до $350К+ (включая различные компенсации) в США. Конечно, в северной Америке совсем другие зарплаты, цены правда тоже другие.

Но факт остается фактом, американский рынок самый платежеспособный 💵.

Ну а в европейских странах в среднем платят 70К-90К евро в год. Однако, если сравнить с зарплатами на российском рынке, это все равно значительно больше.

В РФ можно расcчитывать на ЗП от 300К, бывает до 500К (ну это верхняя планка, чаще всего меньше). Что соответствует примерно 36К-60К евро в год.

👌 Но цены в России ниже европейских, поэтому уровень жизни девопсов плюс-минус такой же.

☝️На зарплату сильно влияет опыт, поэтому джун будет зарабатывать меньше в любой точке мира, но уже спустя несколько лет можно рассчитывать на существенную прибавку.

🤌  В Devopstrain созданы практические курсы и все условия для получения практического опыта. В данный момент прорабатывается новый проект "стажировка", который будет представлять собой возможность погрузится в реальную работу со всеми типовыми процессами и инструментами. Ориентировочный срок запуска - осень 2024.

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

Какие планы на праздники?

Шашлыки - это само собой, но пора бы заняться обучением (отговорки работой больше не принимаются) 😏

Дабы придать вам мотивации решил запустить "майские акции":

1️⃣ 1 курс + еще 1 курс = 3 курса
Выбирайте 2 любых курса на платформе и забирайте третий в подарок 😎

2️⃣ Скидка 5% на Индивидуальное наставничество.
Хотели прокачаться в Devops? - самое время начать! 👾

*Cкидка на наставничество действительна только на 3 места. Акции действуют до 5 мая.

В одном из первых постов, еще в ноябре прошлого года, я делился своими соображениями, почему имеет смысл выбрать DevOps/SRE направление для работы.

Сегодня представляю вам подборку ответов людей на вопрос: "Что вам больше всего нравится в вашей работе DevOps инженером?"

👉 Короткий ответ: "Зарплата" =)
Что ж, трудно не согласиться 😁

👉 "Если ты человек, которому интересно как все крутится, любишь решать пазлы, с возможностью иногда кодить, и за это ты еще и получаешь деньги, разве это не мечта? Ты можешь выстроить архитектуру по своему усмотрению, сесть и наблюдать как графики на мониторинге показывают как хорошо ты выполнил свою работу. А если ты разработчик, что ж, работай на следующий спринт."

👉 "Эта работа позволяет автоматизировать скучную рутину и превратить в нечто, что не будет выматывать. Возможность превратить целую экосистему из железа и софта в код - удивительно. Каждый день появляются новые варианты, и скучать некогда. Я чувствую себя ребенком с этим гигантским набором лего, который никогда не заканчивается."

👉 "Каждый день разный. Когда инфраструктура работает четко, я чувствую как усиливаю свою команду разработки. Мне не все нравится в этой работе, но ее невозможно бросить, когда ты делаешь такие интересные вещи."

👉 "Я просто занимаюсь своим хобби, а мне за это платят. Счастливчик."

👉 "Мне нравится, что мне доверяют решать самые сложные проблемы, а когда я их решаю люди в восторге.

👉 "Я родился деплоить kubernetes кластеры."

👉 "Круто, когда никто не знает, что ты делаешь, но ты «тот парень, который решил проблему». Также здорово иметь дело со срочными запросами и инцидентами, связанными с продуктом. Да, это стресс, но, черт возьми, ничто не сравнится с тем чувством, которое испытываешь, когда исправляешь чертову вещь, от которой пострадали почти полмиллиона пользователей."

👉 "Постоянное изучение новых инструментов очень затрудняет замену нас и требует также навыков межличностного общения и социальной инженерии."

И все они на самом деле правы 👽🤌

А каким бы был ваш ответ? 👇

Как безопасно хранить и использовать секреты

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

Так, например разработчики не должны видеть пароли от баз данных, в том числе и от стейдж и от продовых. Они, как правило, работают локально и этого им достаточно. Бывают, конечно, исключения.

📎 А еще есть секреты инфраструктурные, то есть те, которые не требуются приложению для работы, но используются для создания и работы самой инфры, связанной с приложением или не очень связанной.

☝️Разделять по этим типам секреты имеет смысл по той причине, что подходы для их внедрения могут отличаться. Например, часто секреты в приложение добавляются уже в процессе деплоя, а хранятся в специализированных хранилищах типа Vault.

Если мы говорим про инфраструктурные секреты, то там есть разные подходы:

▪️Можно использовать интеграцию с тем же vault для тех инструментов, которые используются для деплоя: helm, helmfile, terraform. Тут непосредственно секреты хранятся в виде пути: pass: ref+vault://databases/postgres/gitlab#DB_PASSWORD

▪️Еще одним решением может быть sops, то есть хранение в зашифрованном виде.

❗️Не столь важно какой подход вы выберите, важно запомнить, что ни при каких обстоятельствах секреты не должны попадать в код, и уж тем более на публичные git репозитории.

👽😬 У нас был кейс, когда данные SMTP (AWS SES) попали в открытый доступ на github. Среагировали мы быстро, не более получаса прошло, но было уже поздно, суточная квота писем (а это 500К) была успешно использована спамерами.

При устройстве на работу почти всем приходится проходить техническое интервью как первый этап.

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

Сегодня публикую некоторые из наиболее интересных вопросов:

1. Какой системный вызов завершается успешно, хотя код его завершения ненулевой?

Ответ: системный вызов fork() в Unix-подобных операционных системах, таких как Linux, создает новый (дочерний) процесс, дублируя текущий (родительский) процесс. У успешного выполнения этого системного вызова уникальное свойство отличается от большинства других системных вызовов: он возвращает разные коды в родительском и дочернем процессах. В родительском процессе fork() возвращает PID (идентификатор процесса) нового дочернего процесса, который является положительным числом. Это позволяет родителю идентифицировать и управлять его дочерними процессами.

2. Что происходит на системном уровне, когда вы выполняете в терминале ls -l?

Ответ: коротко так: Запуск shell-интерпретатора - Разбор команды - Поиск исполняемого файла - Запуск нового процесса - Замена образа процесса - Выполнение команды - Вывод результатов - Завершение процесса.

3. Сколько максимум процессов может быть в состоянии Running?

Ответ: максимальное количество процессов, находящихся в состоянии RUNNING (R) в системе Linux, определяется архитектурой системы и конфигурацией ядра. В непрерывном режиме в системе может работать только один процесс на каждое ядро процессора. Все остальные процессы имеют состояние S/D и ждут своей очереди на выполнение.

4. Какие технологии лежат в основе контейнеризации?

Ответ: две ключевые технологии лежат в основе контейнерного подхода в Linux: Namespaces и Control Groups. Пространства имен используются для изолирования рабочих процессов контейнера друг от друга и от хостовой системы. Технология control groups обеспечивает ограничение и изоляцию использования ресурсов (таких, как CPU, память, дисковое пространство, сеть и т. д.) каждым контейнером.

А теперь по кубу:

5. Что такое headless service?

Ответ: Headless Service - это особый тип service в Kubernetes, который не имеет собственного IP-адреса для обращения к нему. Вместо этого он делегирует управление прямо к подам. Наиболее полезен для приложений, где информация может быть сразу на всех узлах, и нагрузка будет распределяться между всеми узлами.

6. Сколько нод ETCD кластера оптимально запускать?

Ответ: часто используется конфигурация из трех нод, что позволяет кластеру терпеть одну ноду в состоянии отказа, и в то же время обеспечивает хороший уровень отказоустойчивости. Для очень высоких требований к доступности, вы можете рассмотреть пять нод, что позволяет двум нодам отказать, не препятствуя работе кластера. Для увеличения скорости обработки запросов нет смысла запускать больше нод etcd.

✅ Остальные популярные вопросы с подробными ответами можно посмотреть в моем Devops Roadmap.

А какие вопросы вам задавали на собеседованиях, на которые вы не смогли ответить? 👇

Пятничный видос про немцев и кубер 🍳🤓

Немного про Docker Hub.

Все наверное, уже слышали, что Docker отключил для российских IP свой Hub, где по дефолту хранятся образы.

👽 Это стало полной неожиданностью (с чего бы, да?) и коснулось многих.

📎 Ребята даже успели поднять свой proxy для всех.

А потом, спустя несколько дней, DockerHub снова заработал для российских IP.

👀 Что это было никто не понял, но не так важно.

👾 Я бы назвал это учениями, которые показали проблемы в компаниях.

В нашей компании мы тоже словили проблем, но к счастью, не с продом, там ничего упасть не успело.

И это несмотря на то, что мы уже давно используем Harbor для хранения образов, просто, оказалось что далеко не все приложения его используют.
😎 Оперативно пофиксили и возвращаться на DockerHub больше не планируем.

Мы поступили так: Harbor умеет работать в качестве кеширующего прокси, и ходить за образами во внешний Registry, если локально в кеше не нашел. Настроили его на зеркало докерхаба и это решило нашу проблему в моменте. Если зеркало отвалится, мы просто перенастроим его на другое.
Еще вариант: ходить на DockerHub с Harbor через VPN, но это просто чуть сложнее в настройке, поэтому не стали так делать.

Мораль такова: будьте готовы к любым резким движениям от любых компаний, особенно западных.

🤔 Автор канала задумался: а что будет, если CloudFlare перестанет работать с РФ?

🎉 6 июня Кубернетесу исполнилось 10 лет!

Да, как будто только вчера щупал первые версии, а это было аж в 2016. С тех пор много чего изменилось в самом кубе, в мире devops и облачных сервисах.

👨‍🍳 В пару кликов запустить кластер, как сейчас, было нельзя, но очень хотелось. Слабоумие и отвага позволяли уже тогда запускать продакшн нагрузку в k8s, и это выглядело фантастически на фоне обычных виртуалок с докером.

😬 Плясок и проблем было много, но если бы не они, devops сообщество бы не дошло в своем развитии до того уровня, который есть сейчас. Конечно, и сейчас k8s может выглядеть как пушкой по воробьям для некоторых приложений, но всеобщее распространение доказало эффективность этого инструмента.

Немного истории:

Гугл давно использовал контейнеры в своей инфре, еще до появления докера. У них даже была своя платформа под названием Borg, которая стала прототипом для k8s.

6 июня 2014 года был сделан первый коммит в репозиторий Kubernetes, а через год, когда вышла версия 1.0, Гугл передал управление проектом Cloud Native Computing Foundation (CNCF), что позволило еще больше укрепить его статус открытого проекта. С тех пор Kubernetes стал стандартом для оркестровки контейнеров. Он поддерживается крупнейшими облачными провайдерами, Google Cloud, Amazon Web Services и многими другими, включая отечественные облака.

Немного цифр 👀:

88,474 - людей приняло участие в разработке
15,121 - людей, кто коммитил код
4,228,347 - вместе они сделали столько изменений

👉 Все это делает k8s вторым по величине open-source проектом в мире. Первый, я думаю вы назовете сразу)

☝️ Умение работать с k8s является сегодня ключевым для Devops инженера, и совершенно точно имеет смысл проинвестировать свои усилия в обучение этому инструменту.

Напомню, что Devopstrain поможет вам в этом: у нас есть 2 авторских курса по Kubernetes, ставшие хитами продаж: 👇❤️‍🔥

https://devops.lifeisfile.com/courses/kubernetes/
https://devops.lifeisfile.com/courses/kubernetes_advanced/

А вот и еще один отзыв по программе наставничества 👾🤌

Я недавно завершил курс "Программа наставничества" и остался доволен. Курс был хорошо структурирован, а материалы - понятными и доступными. Практические задания помогли мне лучше понять теорию и применить её на практике.
Особенно хочу отметить работу наставника. Он всегда быстро отвечал и давал полезные советы.
После окончания курса я смог устроиться на работу в IT-компанию. Полученные знания и навыки сыграли в этом ключевую роль.
Если в конце вы сделаете "Проект", считайте получили опыт в коммерческом проекте. На собеседовании расскажите о проекте, что использовали, с чем работали. Ваш опыт будет намого выше чем на других курсах.
Рекомендую этот курс всем, кто хочет углубить свои знания в DevOps и найти работу в этой сфере.

Артем, 17.06.24

В DevopsTrain 👾

Ранее я делал пост о том, почему важно прокачивать скилл программирования для целей devops.

Теперь хотелось бы немного углубиться в тему, чтобы показать почему имеет смысл освоить Golang хотя бы на базовом уровне.

В различных материалах вы можете найти отсылки на Python в качестве языка для автоматизации задач администирования. В целом это так, но у Go есть ряд преимуществ, именно поэтому большинство современных devops инструментов написаны на нем.

✅ Удобство развертывания

Вам не нужно зависеть от наличия python интерпретатора и зависимых библиотек на целевой системе, чтобы ваша программа заработала. Все что вам нужно - это собрать под целевую архитектуру и ОС исполняемый файл через go build.

✅ Статическая типизация

Множество ошибок может быть поймано еще на этапе сборки, что сильно повышает надежность программы. В python тоже можно задавать типы, но можно и не задавать =)

✅ Эффективность

Go тупо быстрее чем интерпретируемые языки вроде Python или Ruby. Это факт. И памяти он ест меньше. Благодаря встроенной поддержки с первого релиза конкурентности, писать асинхронный код и запускать задачи в несколько потоков довольно просто и быстро.

✅ Стандартная библиотека

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

В целом экосистема и количество носителей языка Go хоть и уступает по размерам Python, но все же очень масштабная. Не даром эти известные проекты написаны на Go:
Kubernetes, terraform (и большинство продуктов HashiCorp), docker, minio, hugo, restic, grafana, prometheus и многие другие.

С чего начать изучение DevOps? 🤔

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

Фундаментальные вещи не меняются десятилетиями, и поэтому именно с них и нужно начинать. Нет смысла изучать новый "многообещающий" инструмент, если вы не знаете на чем он базируется, к тому же, хайповые вещи имеют свойство не оправдывать ожиданий и сдуваться.

К фундаментальным вещам я отношу:

1️⃣ Основы операционных систем, в частности Linux, как безальтернативный вариант для devops. Сюда же относятся и файловые системы, и наборы популярных утилит для управления системой и траблшутинга. Работа в терминале - обязательно.

2️⃣ Компьютерные сети. В своей реализации они платформонезависимые (фундаментально), но уметь приложить к нужной ОС или оборудованию может быть полезно.

3️⃣ Виртуализация и контейнеризация. Нужно уметь различать их и знать области применения.

4️⃣ Основы автоматизации и программирование. Умение написать программу или скрипт на одном языке сильно поможет вам в освоении другого. Ведь главное - это сам принцип.

👉 Это, пожалуй, база, с которой вы сможете двигаться дальше и изучать уже более узкие и более оплачиваемые инструменты вроде этих ваших кубернетесов, ci/cd и терраформов.

На платформе Devopstrain из базовых есть курсы Linux & Networks, а также Docker 🤌.