Самое интересное 👇

👾 Вот вам ссылочки на мой бестселлер - индивидуальное наставничество и курсы, с которыми у вас просто нет шансов не получить знания и навыки.

🤖 @devopstrain_mentoring_bot - ответит на все ваши вопросы 24x7

✔️ Проходите пробные уроки, практикуйтесь, там выбран интересный формат обучения - без видео, через практику. Однозначно не скучно.

💪 Так что, если хотели прокачать Kubernetes, Terraform, Docker, CI/CD, Linux получить опыт и навыки, которые можно добавить в резюме - welcome.

А в этом канале вас ждут:

〰️ свежие IT-новости (чтобы быть топ of the топ)
〰️ полезные советы от меня и что действительно важно в этом devops
〰️ эксклюзивные материалы
〰️ релизы (обновления) топовых инструментов, их фичи и баги
〰️ обзоры вакансий
〰️ личный взгляд на девопс-сферу

Ну и не стесняйтесь комментировать/спрашивать и познавать devops.

Итак, что у нас по вакансиям в сфере DevOps/SRE. Мониторю обстановку, и у меня сложился ряд наблюдений:

▪️ Рынок все же сейчас не наш, рынок сейчас работодателя, из этого вытекает, что требования достаточно высокие.

▪️ Но есть варианты и не только для сеньоров, мидлов вполне тоже могут взять. И даже джунов берут, иногда. Просто требования стали выше.

▪️ Фанатизм вроде "работать можно только из РФ" в случае российских компаний, субъективно пошел на спад, но зависит конечно.

▪️ Некоторые, не многие, но по-прежнему спрашивают алгоритмы на собесах, хотя мы вроде как не разработчики 👽.

▪️ Стек стал более похожим чем несколько лет назад, опять же субъективно. По сути roadmap, закрывает 90% требований 90% вакансий.

▪️ Сеньорская вилка довольно широкая, от 280 до 450 т.р. Но за 400+ хотят прям много всего. Скажем так, больше чем за $5К в западных компаниях, но с ними тоже есть нюансы.

▪️Наиболее часто встречающиеся сферы: финтех, банки, геймдев, е-коммерс и ритейл, а также интеграторы для таких компаний.

Вот такой обзор текущей ситуации, продолжаю мониторить и отбиваться от HR 👀, а как у вас дела с работой?


DevopsTrain

Senior YAML developer

В прошлом посте я написал, что мы, то есть девопсы - не разработчики.

👽 На самом деле это не совсем так, во-первых потому, что devops = development + operations, что как бы намекает на разработку. Я имел ввиду, что разработка - это не главное занятие девопс инженера, хотя читать и писать элементарный код надо уметь.

〰️ Во-вторых, нас в шутку называют Senior YAML developer, что только отчасти шутка, принимая во внимание, сколько yaml кода приходится писать: от манифестов для Kubernetes до плейбуков на Ansible. Да, выбирая современный девопс, вы невольно становитесь yaml "разработчиком", хотите или нет.

Поэтому, важно понимать все структуры языка и как они соотносятся с Json:
* скалярные типы (строки, int, float, boolean, null, datetime)
* списки (sequences)
* словари (mappings)
* блоки | и >
* разделение документов —-

Конечно, существуем масса других форматов конфигов: toml, ini, json, jsonnet, hcl, но yaml - самый популярный

DevopsTrain

Метрики Prometheus

В современном мире Devops, метрики формата Prometheus уже стали стандартом, который применяется для мониторинга приложений, а также для их масштабирования.

◽️Напомню, что архитектурно Прометей использует pull модель для получения данных, то есть сервер сам запрашивает с указанных точек метрики с заданным интервалом. Эти самые точки принято называть exporters. Существует великое множество готовых экспортеров на все случаи жизни.

👾 К примеру, мы хотим, мониторить redis на предмет длины очереди, которая не должна превышать заданного прога. Для этого можно запусть redis exporter, который будет связующим звеном между prometheus и сервером redis. А в его настройках укажем запрос, который нам необходим.

◽️Приложения, конечно, могут иметь и встроенные метрики, в этом случае промежуточное звено не требуется.

Prometheus определяет четыре основных типа метрик:

1. Counter: Счетчик представляет собой простую числовую метрику, которая только увеличивается или сбрасывается до нуля на перезапуске. Примеры счетчиков: количество запросов к HTTP-серверу, количество выполненных задач и т.д.

2. Gauge: Это метрика, которая представляет собой одиночное числовое значение, которое может произвольно увеличиваться или уменьшаться. Примеры: текущее использование памяти, количество одновременно работающих потоков и т.д.

3. Histogram: Гистограмма представляет собой метрику, которая собирает наблюдаемые значения в виде бакетов (группы значений в определенном диапазоне) и также обеспечивает счетчик накопленных наблюдений и сумму всех наблюдаемых значений. Примеры: измерение времени ответа, размер запроса и т.д.

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

DevopsTrain

Недавно пришлось настраивать Grafana Agent Flow для отправки логов в Loki, и вот что интересно:

Читаю доку и вижу подобное:

logging {
level = "warn"
}

loki.relabel "gelf" {
forward_to = []
rule {
source_labels = ["__gelf_message_host"]
target_label = "host"
}
}

loki.source.gelf "listen" {
forward_to = [loki.process.extract.receiver]
relabel_rules = loki.relabel.gelf.rules
}
...

Был уверен, что это HCL - язык конфигурации Terraform, с которым многие из вас уже знакомы. Но нет, каждая уважающая себя компания должна создать свой язык конфигурации, который вдохновлен [чем-то] и лучше [тем-то].

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

env("HOME")

Прямо как в меме про 14 конкурирующих стандартов =)

👽 Если вы еще не знакомы с Terraform, то у меня есть свежий практический курс

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

Я к этому пришел уже давно, но далеко не сразу.

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

К примеру, вы наткнулись на проблему: не получается удалить некоторые PVC в Kubernetes. Либо хотите иметь в быстром доступе команду или список фактов о чем-либо. Как пример: особенности протокола TCP. Часто такие вещи требуются неоднократно, и это означает что каждый раз вам нужно найти решение в гугле → потратить на это время.

👾 При наличии локальной БД, вы быстро откроете нужную заметку. Конечно, с появлением GPT стало чуть проще, но это НЕ замена личной базы знаний.

◽️В качестве реализации можно использовать разные инструменты: Obsidian, Logseq, Notion, Roamresearch и т.д.

Но я, как любитель консоли, в итоге остановился на Emacs + Org-roam + MD-roam.

😎 В итоге, одним из продуктов, основанных на моей базе знаний, стала образовательная платформа DevopsTrain, которая позволила упорядочить информацию наилучшим образом.
Вместо классического подхода с видео, я сосредоточился на практике с оптимальной дозой теории, взятой из моих записей, собранных в процессе многолетней работы.

До сих пор очень часто попадаются devops вакансии, где среди требований есть стек ELK(EFK) - Elasticsearch + Logstash + Kibana

👽 Осмелюсь выразить свое мнение на этот счет. Я конечно понимаю, что легаси нельзя просто так взять и заменить на что-то современное, но все же 23 год уже подходит к концу.

Нет, безусловно, у Elasticsearch есть свои преимущества, но если уже использовать его, то по моему мнению лучше взять для этого Graylog, это комплексный продукт, который умеет делать за вас многие ручные операции, включая ротацию индексов, запуск input'ов, и т.д.

👾А современный подход - это хранение данных в S3-хранилище, который обойдется вам в разы дешевле, чем огромный индекс логов в elasticsearch на диске.

◽️Речь идет про стек Grafana + Loki + (что-то, что пишет в локи, например Promtail/Grafana Agent), бонусом идет единый интерфейс Grafana для метрик, трейсов и логов.

Суть в том, что можно хранить дешево, а значит за долгий период. А скорость выборки зависит от количества реплик querier в составе Loki. Они просто разделяют работу по обработке данных между собой, то есть вы можете регулировать что для вас важнее, скорость или экономия.

💪 Все это я подробно разбираю на курсе Kubernetes Advanced, в разделе "Средства для логгирования".

DevopsTrain

Из backend-разработчика в DevOps: как так получилось

Когда-то давно, мне повезло работать в стартапе, и там я был одним из немногих разработчиков. Кодил бекенд на питоне (django). К слову, тогда еще не было такого богатого фронтенда, поэтому тебе давали просто html верстку страницы, и ты натягивал ее на бекенд, то есть страницы полностью генерились на сервере.

👽 На тот момент мне это было интересно, я прокачивал навыки, получал опыт. Но любое приложение должно быть где-то задеплоено, чтобы его увидел мир. Угадайте, кто этим занимался? Правильно, я. Приходилось настраивать сервера (физические!), а не вот эти ваши кубернетесы смузишные. Ладно еще, что арендованные, а не свои.

К чему я это? К тому, что начиная с начала 2000-х часто приходилось заниматься тем, что можно было отдаленно назвать DevOps.

👾 Поэтому когда стартап вырос до 10 разработчиков, а мне уже эта разработка порядком надоела, от меня было выдвинуто предложение:

"А давайте замутим нормальные девопс процессы и ускорим наши релизы, сделаем их более надежными и предсказуемыми! Я со своей стороны готов покинуть разработку" уж так и быть, кто-то же должен принять это непростое решение =)

~ Примерно в это же время на моем горизонте уже появился язык Golang, после которого я уже не возращался к разработке на Python, и надеюсь - не придется. А в devops процессах он очень даже помогает.

Вот так, тихо и не заметно я переключился в devops и, по правде говоря, обратно в разработку уже не тянет 👀.

DevopsTrain

Почему Makefile до сих пор актуален?

Немного истории: инструмент make и соответствующий ему Makefile были созданы в 1976 году в рамках проекта Bell Labs для Unix. В то время разработка софта становилась все более сложной, и возникла необходимость в автоматизации билдов из большого количества исходных файлов ➟ Makefile был создан как решение этой проблемы.

~ Основная идея состояла в том, чтобы определить "правила", которые описывают, как из исходных файлов получить конечный продукт (например исполняемый файл)

В Devops также часто используется Makefile не только для сборки софта, но и для удобного формата написания "скрипта".

К примеру, такой простой Makefile:

.PHONY: build push deploy
build:
  go build main.go
  docker build -t someimage:tag .
  rm main
push:
  docker push someimage
deploy:
  kubectl set image deployment.v1.apps/someapp container=someimage:tag

позволит вам обойтись без написания bash скрипта, при этом выглядит понятно и используется удобно:

make build && make push && make deploy

Сюда же можно добавить аргументы и их валидацию. Конечно, нельзя сказать, что это идеальное решение, но оно хорошо тем, что стандартное, ведь make есть везде, как vim. Говорят, есть более современное решение, но руки не доходят его опробовать - https://taskfile.dev/

Если вы уже пробовали - напишите в комментариях

Не все йогурты одинаково полезны

Сейчас чего-то много развелось разных курсов, обещающих хорошую ЗП после их завершения.

Как многие уже знают, обещать - не значит жениться.

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

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

Что бы я отмел сразу: курсы типа "профессия DevOps". Это не профессия, это набор материала, который может пригодиться в этой профессии. Поэтому имеет смысл сформировать свой план изучения и искать курсы, которые "не профессия", а "навык".

Для этого даже ходить далеко не надо: есть Devops Roadmap, который является готовым планом развития и освоения девопс.
А также курсы по куберу (аж два, для разных уровней), терраформу и докеру.

Еще важный момент, на который стоит обратить внимание - формат курса.

Если много видео и теории и мало практики - толку тоже мало. В приведенных выше курсах 93.5% практики и необходимая теория.

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

На днях вышел Kubernetes 1.29 "Mandala", который будет поддерживаться до 28.02.25.

Среди новшеств можно выделить следующие:

◽️ sidecar container достиг состояния беты и включен по умолчанию. Напомню, что это новый тип контейнеров, который не блочит остановку пода, помогает собирать логи и много другое.

◽️ Precision Image Pulling - возможность задать runtimeClassName для того чтобы влиять на то из какого registry доставать образ.

◽️ ReadWriteOncePod - новый режим, если доступ нужно ограничить единственным подом на одном узле. Существующий режим ReadWriteOnce (RWO) ограничивает доступ к узлу, однако можно читать из нескольких подов на данном узле.

◽️ Новый бекенд для kube-proxy на базе nftables вместо устаревающего iptables.

◽️ Kubectl drain helper callbacks - возможность создать свой скрипт, который будет исполняться в разные моменты операции drain на ноде, таким образом можно контроллировать процесс очистки ноды, включая различные уведомления.

◽️Добавлены новые метрики (CPU utilization, Use of ephemeral storage, bandwidth of each node).

→ Это основные изменения, остальное можно изучить в release notes.

👾 Напомню, что существуют два курса по kubernetes от Devopstrain.

Сегодня я хотел бы поговорить об операционных системах, на которых лучше всего готовить Девопс.

Я давно уже вынашивал эти мысли, но раньше у меня не было канала, где я бы мог их изложить, а теперь - есть 😎.

Собственно, о чем речь: речь о главном инструменте devops инженера - его компе. Да, в любом деле главное - подходящий инструмент и умение им пользоваться. Комп сам по себе - железка, важно на чем он работает.

🐧 Как известно, в мире devops самой востребованной системой является Linux (различные его варианты). В моем roadmap он даже идет первым пунктом. Впрочем, и в остальном мире Linux - это самая популярная ОС (Андроид работает на базе Linux ядра).

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

Конечно, MacOS тоже unix-подобная ОС, но все же это совсем другая песня, и несмотря на то, что это сильно лучше, чем Windows, все равно я крайне рекомендую использовать Linux в качестве основной. Встречались правда люди, которые неплохо девопсят и с windows, но это скорее исключение и явно антнипаттерн, несмотря на наличие WSL, который был жалкой попыткой остановить отток разработчиков и прочих технарей с винды.

Сам я с года 2001 уже винду не использовал, вместо этого открыл дивный мир Linux, который не перестает меня радовать до сих пор. Что уж говорить, сейчас и 20 лет назад это совершенно разный экспириенс, стало сильно меньше страданий, хотя по юности это скорее воспринималось как очередной челендж. Вообщем - рекомендую!

Давайте подведем итоги 2023 года, как обычно принято делать в конце декабря.

👽 В devops сфере не произошло каких то серьезных изменений, однако, по моим ощущениям, тренд по его внедрению продолжает усиливаться. Как следствие, больше компаний внедряют Kubernetes (какой без него девопс?) и прочую автоматизацию.

➜ В зависимости от специфики и локации компаний, требования разные, и способ развертывания k8s кластера свой: кому-то нужно обязательно свой кластер на своем железе, а кому то и облачного за глаза. В связи с развитием искусственного интеллекта все больше внедряется MLOPS.

💪 Что по итогам года платформы Devopstrain (небольшая копипаста из недавней рассылки):

👾 В марте платформа devopstrain была по сути перезапущена после 2 лет паузы
👾 В то же время был доработан курс "Kubernetes на практике"
👾 Был обновлен основной сайт, запущен блог
👾 Был создан Kurator - open-source инструмент для автоматической проверки заданий на localhost (для terraform и docker курсов) - об этом можно написать отдельный пост, очень крутая штука.
👾 В сентябре был сделан курс "Terraform на практике"
👾 В октябре стал доступен курс "Docker на практике"
👾 В ноябре вышел в продажу курс "Kubernetes advanced"
👾 Примерно тогда же появился ставший хитом мета-курс "Devops roadmap"

🌲 С наступающими праздниками, пожеланием успехов в работе и удачных деплоев в будущем году!

Когда все выпито, и оливье доеден, захотелось порассуждать на злободневную тему - ИИ (AI), то есть про искусственный интеллект и как он может коснуться нашей с вами работы в DevOps.

▪️Прошлый год, очевидно стал наиболее значимым для AI сферы: множество обычных людей и компаний не только попробовали его использовать, но и плотно подсели на такие вещи как ChatGPT и Midjourney.
Безусловно, мир уже не будет прежним, потому что ИИ реально помогает делать работу. Рутину вообще прекрасно можно поручить AI.

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

👾 Позитивная сторона: devops - это то глубокая интеграция в разработку и эксплуатацию, что затрудняет внедрение AI, по крайней мере в ближайшие годы, а возможно и не очень ближайшие. Потому что доверить доступы и проведение ответственных операций неподконтрольной нейросети - это безумие.
Даже если нейросеть под вашим контролем, все равно цена ошибки слишком высока, и явно выше зарплаты devops, с которого можно спросить, если что.

◽️Другое дело разработка, там не требуются доступы, рутинный код уже может быть сгенерирован через chatGPT, и получается, что джуны уже остались не у дел. Отсюда я прогнозирую скорую переквалификацию разработчиков в другие сферы, в частности в DevOps, что приведет к большей конкуренции в данной области.

➟ Поэтому, рекомендую не откладывать обучение в долгий ящик, AI наступает на пятки, хоть и через разрабов. Если что, курсы Devopstrain как раз заточены на быстрое освоение наиболее важных тем в devops 🫡.

Ну что, как прошла ваша первая рабочая неделя?

У меня довольно продуктивно, пополнил список курсов еще одним 😎

👾 Сегодня, слегка с опозданием, стал доступен курс "CI/CD на практике", в котором изучается тема Continuous Integration & Continuous Delivery на примере Gitlab CI и инструментов из мира GitOps.

🤝 Этот курс предназначен для обучения основам CI/CD, с использованием инструментов GitLab и GitLab CI. Вы научитесь создавать пайплайны и выкатывать код в продакшн и тестовые окружения.

✔️Мы рассмотрим, как использовать GitLab CI в среде Kubernetes, и как создать универсальный пайплайн, который может быть использован во многих проектах. Для этого будет запущен выделенный лично вам k8s кластер.

Список разделов: https://devops.lifeisfile.com/courses/ci_cd/

Сам курс тут: https://ci-cd.lifeisfile.com/

👻 В настоящий момент курс доступен по специальной pre-sale цене.

Так что, давайте, начинаем год с новых скиллов 💪

Сегодня поговорим о тестовых стендах, для чего они нужны?

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

Можно выделить такие популярные окружения как
- dev - сюда сливают все изменения из feature-branch и тестируют на тестовом наборе данных
- stage (он же staging) - а тут тестируют уже в максимально приближенном к проду окружении, в идеале даже на копии базы данных из прода
- production - ну а тут тестируют на пользователях то, что не выловилось на более ранних стадиях =)

Кроме этого часто тестируют отдельные ветки (feature branch) где добавлена только одна какая-то фича.

По URL можно придерживаться такой схемы:
dev: dev.mycompany.com
stage: stage.mycompany.com
prod: mycompany.com
Одна фича: feat-123.mycompany.com

✔️ Таким образом тестировщики знают что именно они тестируют и в каком окружении

Конечно создание и обновление окружений должно быть автоматизировано, особенно это касается динамических фиче-окружений, ведь не будешь же под каждую задачу вручную все создавать. Существуют разные подходы для автоматизации в зависимости от платформы которую вы используете для деплоя. Проще всего это реализовать в контейнерной среде (docker/kubernetes).

А вы тестируете на стенде или сразу в продакшн? 👽

Как известно, люди делятся на два типа: кто делает бекапы и кто уже делает бекапы.

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

Вместо этого поговорим о базовых принципах:

Принцип №1: не храните яйца в одной корзине (они нынче дорогие).

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

Принцип №2: проверяйте

▪️Регулярно проверяйте бекапы на возможность восстановления и в целом мониторьте процесс создания. Если проверку бекапов можно делать раз в месяц, то мониторить создание надо постоянно, то есть требуется настроенный мониторинг.

Принцип №3: шифруйте

▪️Чтобы ваши данные никуда не утекли, важно шифровать бекапы перед их отправкой на хранение, но вы должны четко понимать как будете расшифровывать при необходимости.

Принцип №4: интервалы создания бекапов должны быть приемлемы с точки зрения потенциальных потерь.

▪️То есть если для вас ОК потерять не более часа истории, то значит бекап должен быть ежечасный.

Принцип №5: Определитесь со стратегией (полный или инкрементальный бекап)

▪️В зависимости от частоты создания бекапа и его объема, правильно выбранный вариант избавит вас от проблем типа race condition, то есть ситуации, когда вы создаете бекап, пока прошлая процедура создания еще не завершилась.

👾 Если ваш десктоп на linux, то удобно использовать DejaDup + Gnome backups для создания ежедневных инкрементальных бекапов. Для серверных решений подходят такие вещи как minio client, s3cmd, rclone. А если нужно инкрементальный - то restic.

Как у вас с бекапами?

Поскольку я решил меньше времени тратить на работу, а вместо этого больше посвящать времени своим проектам, в частности DevopsTrain, у меня для вас предложение.

Мне было бы интересно взять несколько человек на индивидуальное обучение профессии DevOps.

Что это такое?
Это индивидуальное наставничество для максимально эффективного обучения профессии DevOps инженера и достижения ваших конечных целей: повышения зарплаты, грейда, устройства на желаемую работу.

📌 Детально предложение можно изучить ТУТ.

Что входит в программу?

✔️ 4 консультации (час-полтора каждая), где мы оценим ваш опыт, умения, приоритеты, стремления и выстроим индивидуальный план с регулярными встречами для координации и коррекции обучения

✔️полный доступ на ВСЕ курсы платформы, а именно:

◽️CI/CD
◽️Terraform
◽️Docker
◽️Kubernetes
◽️Kubernetes advance
◽️Devops Roadmap

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

✔️ Доступ к базе DevOps кейсов, доступный только в рамках этого предложения, его нельзя купить отдельно. Это подборка из моей Devops практики.

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

✔️ Для решения текущих вопросов - оперативная и приоритетная поддержка по email на весь срок обучения

Цель - сделать практическое обучение на платформе максимально эффективным и помочь вам достигнуть желаемого.

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

🤝 Жду ваших вопросов и отзывов, приложите ваше резюме по возможности, если у вас оно уже есть. В ответ я пришлю индивидуальный расчет стоимости.

Обращайтесь по адресу devops@lifeisfile.com или в телегу

Стандартизация vs монополия

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

Конечно, они действуют хитро, давая взамен удобство, но иногда оно обходится слишком большой ценой. Вернемся к облакам (и все что можно к ним отнести, например SaaS), тут канал про devops вроде как. Такие штуки как собственные сервисы визуализации и сборки метрик/логов, API gateways, Lamda/Cloud functions (serverless) не позволят вам быстро отказаться от них, т.к. стандартных аналогов нет.

А зачем, спросите вы, отказываться? Причин может быть много, от политических до экономических, думаю, что сейчас уже нет ни у кого иллюзий на этот счет. Каждый раз, когда вы планируете использовать какой-либо продукт, особенно облачный, задайте себе вопрос: "А если что, у меня есть альтернатива, на которую я смогу перейти в разумные сроки?"

Всегда выбирайте решения, которые стали стандартом. Хороший пример Kubernetes, его теперь можно запустить в любом облаке, и несмотря на мелкие отличия, переехать из одного облака в другое вы тоже сможете с легкостью. То же самое с Docker. Потому что это - стандарт.

☝️Стандарт - это хорошо, а монополия - плохо.

Почему я считаю, что email до сих пор один из лучших способов обмена информацией, несмотря на проблемы вроде спама?

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

Конечно, многие используют gmail, в том числе и для коммерческой почты, чтобы самим не заморачиваться со множеством проблем, которые решает гугл. Он, кстати, и создает их при этом. Я тут недавно заметил, что теперь на gmail можно поставить реакцию, прям как в телеге. Серьезно? Особенно прикольно это работает когда ты ставишь реакцию на письмо, которое уйдет не на гугловский ящик. Попробуйте) 👾

DevopsTrain