Послушал стрим "Что будет с IT в России" - https://youtu.be/RyIDxgFxfHY

Коротко:
- IT-компании, бизнес которых базируется на российском рынке, планируют и дальше развиваться
- Для успешной карьеры в IT по прежнему нужно качать скиллы, потому что спрос на толковых спецов всегда высокий
- Пока вычислительные мощности в дефиците, появился спрос на оптимизацию производительности
- В нестабильном мире бизнесу лучше перебазировать свои активы в место основного предоставления услуг (релокация серверов в отечественные облака, создание зеркал и т.п., если бизнес в РФ, либо релокация сотрудников, если бизнес за её пределами)
- Появляются перспективы создать отечественные конкурентные продукты, спрос на которые будет у бизнеса, лишившегося западного сервиса

Посмотрел на отечественную платформу хранения исходного кода GitFlic.

Вкратце, что понравилось
- Можно создавать приватные репозитории и группировать их
- Можно бесплатно использовать в команде до 5 человек
- Есть какие-то зеркала открытых проектов с GitHub

Что не понравилось
- Сырость проекта. Маркетинг не продаёт мне свой продукт. И это подтверждается интервью - авторы не располагают чёткой стратегией развития.
- Отсутствие мультиязычного интерфейса. Лично я предпочитаю везде включать английский. То есть в настоящее время авторы планируют ограничиться только отечественным рынком, предлагая продукт компаниям, которым некуда деваться из-за политических ограничений. Такое «импортозамещение» не взлетит.
- Очень мутная компания, занимающаяся разработкой сервиса. Можно ли доверить свой код стартапу из 5 человек?

Чего не хватает
- Инструментов. Сейчас довольно сложно представить GitHub без pages или GitLab без GitLab-CI. Тут пока ничего подобного нет.
- Уверенности. В текущем состоянии, не понимая на что способен сервис, какие нагрузки выдержит, как надёжно защищены данные и тому подобное, не хочется добровольно его использовать

Стоит ли попробовать?
Да, стоит. Но только под какой-нибудь pet project, чтобы не рисковать лишний раз. Потраченные усилия потом надо превратить в фидбек и отправить авторам проекта, чтобы они имели понимание как развивать свою платформу.

Посмотрел вебинар, на сколько это было возможным. Поскольку я ни разу не разработчик, а всего лишь колупатель инфры и пайплайнов, порадовался за лёгкость go и за наивные проблемы в мире разработки. Блажен тот, кто не ведает (это я про себя).

Начало Открытого практикума Golang by Rebrain: Разрабатываем CLI-приложение на Go уже через 5 минут.

Встречаемся в 19.00 МСК. Ссылка для входа: https://rebrainme.com/webinars/login/?webinar=e294b935-5c9b-4501-a870-e570acc19590

Идеальный пайплайн CI/CD

В принципе, ничего нового, чего бы не сумел Gitlab-CI, GitHub Actions или Jenkins в связке с aws, k8s и любое другое решение в облаке. Понеслась.

Исходники
1. Проводите код-ревью перед мерджем в основные ветки

Сборка
1. Скомпилируйте исходники и затяните зависимости
2. Запустите unit-тесты.
3. Измерьте покрытие кода тестами

Тестовая среда
1. Запустите интеграционные тесты (проверка API, бизнес-логики)

Препродакшн среда (на больших проектах)
1. QA
2. Проверка безопасности

Продакшн среда (1box)
1. Автоматическая отправка уведомлений об ошибках, проблемах с производительностью и ключевых бизнес-метриках
2. Bake time - срок повышенного внимания к сервису, за который может проявиться ошибка. Например, если сервис не под нагрузкой, можно не увидеть утечку памяти мгновенно. Здесь следует обратить внимание на аномалии, счётчики ошибок и задержки (latency)
3. Canary deployment - раскатка обновления на остальные хосты

Рекомендации
- Нужно иметь возможность включать или выключать каждый стейдж в зависимости от ветки или коммита.
- Для продакшена необходима возможность отката в случае появления ошибок после деплоя изменений. Концепция 1box - деплой на отдельный сервер нового изменения, чтобы, в случае обнаружения ошибок и сбоев можно было безболезненно откатиться в рабочее состояние.
- В каждой среде должна быть изолированная инфраструктура с копией БД, идентичной проду.
- При деплое в разные страны (регионы), хорошо иметь 1box в каждом из них, а ещё лучше - деплоить в разные регионы и тестовые среды.

По рекомендациям коллег, которых уже коснулась необходимость подстраховаться, вполне себе неплохой повод слезть с Bitwarden на self-hosted open source проект, написанный на Rust, Vaultwarden - https://github.com/dani-garcia/vaultwarden

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

И следом новость-подарок - Rocket.Chat и NextCloud объединяются, чтобы создать open source убийцу коллаборационных проприетарных платформ. То есть ребята интегрируют свои сервисы на уровне нативного API.

https://news.itsfoss.com/rocket-chat-nextcloud-collaboration/

На канале TechWorld with Nana вышел часовой ролик про k8s для новичков. И он прекрасен, потому что автор, в отличие от многих, смотрит на кубер с обратной стороны. Большинство курсов построено на стратегии "от меньшего к большему", где очень долго объясняют что такое Pod, RedplicaSet, Deployment и когда доходят до Service, студенты уже валяются при смерти с опухшей головой. Здесь - минимум бреда, максимум полезного для того, чтобы новичок осилил запуск своего первого приложения в облаке. Отличный спидран.

https://youtu.be/s_o8dwzRlu4

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

Использование Terraform на серверах с KVM. Часть 1

В статье я расскажу как использовать Terraform на сервере с KVM-виртуализацией.

https://blog.ionice.ru/terraform-kvm-part1