Перенёс загрузку архивов стримов в облачную инфраструктуру.

Для получения стрима нужна ссылка с ключом/подписью.

Ссылку выдаёт функция после проверки JWT токена.

Сейчас для этой задачи у меня работает отдельная виртуальная машина. Это потому что стримы занимают много места и приходится брать ВМ ради диска. В облаке место в ObjectStorage стоит очень дёшево (почти в 10 раз дешевле, чем виртуальная машина).

Для подобных задач схема «плати только за то, что используешь» намного выгоднее, чем аренда ВМ.

Структурировал темы по архитектуре, которые должны входить в архитектурный минимум каждого инженера.

P.S. сорян за качество, xmind не дает сделать лучше.

Типовые проблемы в архитектуре стартапов

За последний год провел 17 консультаций организаций малого бизнеса (размер организаций 15-100 человек). Обычно просят сделать анализ архитектуры на уровне кода, чтобы повысить скорость выхода на рынок и оптимизировать затраты на сопровождение.

Хочу рассказать о проблемах, которые есть почти у всех. Важно отметить, что улучшение архитектуры кода на таких размерах влияет в основном на вовлеченность разрабов, а чисто "технически" улучшения не так заметны. Обычно проблемы лежат в области процессов, мотивации и организации работы.

1. Проблема номер раз - технический долг. Обычно никто его не измеряет, в лучшем случае определяют "на глазок", а в худшем вообще не определяют. Предлагаю сделать простейший анализ, получаем цифры 60-70%. Для себя эмпирически установил, что при уровне техдолга 25-35% качество разработки становится заметно лучше.

2. Проблемы автоматизации и организации процессов. Например, в процессе разработки не используются фичи гита или не реализован CI/CD, нет автоматического тестирования, нет стат анализа, нет динамического анализа и т.д. Непонятно кто за что отвечает, кто что делает.
Обычно жалуются, что организовать процессы сложно и дорого. В качестве контраргумента я привожу в пример NarisApp, где процессы работают на голом энтузиазме и если бы не они, то проект давно закрылся.

3. Деньги не мотивируют. Я много раз убеждался, что в теории люди могут знать кучу всего хорошего, а на практике ничего не применять. Просто потому что "а зачем?". Я несколько раз проводил анкетирование, и оказывалось, что знания есть, а просишь показать примеры в коде, где эти знания применяются, показать не могут.
При этом если внедрить ревью кода, начать стимулировать разрабов писать код обдуманно, то увеличивается вовлечение в проект, и результат становится лучше.

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

У меня есть пример, когда решение кадровых вопросов, организация процессов и просто приведения "разработки" в порядок привело к увеличение производительности в 5 раз, при этом реорганизация заняла около года.

История успеха: NPM — как небольшой проект стал основой экосистемы JavaScript

Сегодня поговорим о NPM (Node Package Manager) — одном из самых важных инструментов в мире JavaScript. Это не просто менеджер пакетов, а целая экосистема, которая изменила способ разработки программного обеспечения. Давайте разберемся, как NPM стал таким успешным.

Начало: 2009 год

В 2009 году Райан Дал (Ryan Dahl) представил миру Node.js — среду выполнения JavaScript на стороне сервера. Node.js быстро набрал популярность благодаря своей асинхронной модели и высокой производительности. Однако разработчикам не хватало удобного способа делиться кодом и управлять зависимостями.

Именно тогда на сцену вышел NPM. Его создал Айзек Шлютер (Isaac Z. Schlueter) в 2010 году. Изначально NPM задумывался как простой инструмент для установки и управления пакетами в Node.js. Первая версия NPM была выпущена в январе 2010 года, и уже через несколько месяцев она стала стандартом для работы с пакетами в Node.js.

Рост экосистемы

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

Простота использования

NPM предоставил разработчикам простой интерфейс командной строки для установки пакетов. Например, чтобы установить пакет, достаточно было выполнить команду: npm install package-name

Централизованный реестр пакетов

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

Поддержка зависимостей

NPM автоматически управлял зависимостями между пакетами, что значительно упрощало разработку. Файл package.json стал стандартом для описания проекта и его зависимостей.

Расцвет: 2014–2016 годы

К 2014 году NPM стал неотъемлемой частью экосистемы JavaScript. Количество пакетов в реестре росло экспоненциально.

Рост числа пакетов

В 2014 году в реестре NPM было около 100 000 пакетов. К 2016 году их количество превысило 350 000.

NPM Inc.

В 2014 году Айзек Шлютер основал компанию NPM Inc., чтобы коммерциализировать проект. Компания начала предлагать платные услуги, такие как приватные репозитории и инструменты для корпоративных клиентов.

Интеграция с другими инструментами

NPM стал интегрироваться с популярными инструментами, такими как Webpack, Babel и React, что сделало его еще более востребованным.

Кризис и восстановление

В 2016 году NPM столкнулся с серьезным кризисом. Один из разработчиков удалил свой пакет left-pad, что привело к сбою в работе тысяч проектов. Этот инцидент показал уязвимость экосистемы, зависимой от небольших пакетов.

Однако NPM быстро отреагировал на ситуацию:
Была введена политика, запрещающая удаление пакетов, которые используются другими проектами.

Команда NPM начала активно работать над улучшением стабильности и безопасности реестра.

NPM сегодня

Сегодня NPM — это огромная экосистема, которая включает:
Более 2 миллионов пакетов в реестре.

Десятки миллионов разработчиков по всему миру.
Интеграцию с современными инструментами, такими как Yarn и pnpm.

В 2020 году компания GitHub (принадлежащая Microsoft) приобрела NPM Inc. Это событие укрепило позиции NPM как стандарта для управления пакетами в JavaScript.

Причины успеха NPM:

- Простота и удобство

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

- Сильное сообщество

Открытость и поддержка сообщества стали ключевыми факторами роста.

- Адаптивность

NPM смог пережить кризисы и адаптироваться к меняющимся требованиям разработчиков.


- Коммерциализация

Создание NPM Inc. позволило проекту развиваться и предлагать новые функции для корпоративных клиентов.

Заключение
NPM — это не просто инструмент, а целая экосистема, которая изменила мир разработки. Его история успеха показывает, как OpenSource-проект может стать стандартом индустрии и вдохновить миллионы разработчиков по всему миру.

🚨 Ваш Kubernetes небезопасен: 3 ошибки, которые делают все (и как их исправить за 5 минут)

Люблю Docker, K8s и кликбейтные заголовки. Но если серьёзно, то ошибок при конфигурировании кубера можно сделать очень много.

Сейчас многие играют с облаками (и я в том числе) в моей конфигурации опытный девопс сходу нашел 3 ошибки, из-за которых кластеры взламывают, майнят крипту или просто случайно роняют продакшен.

🔴 Ошибка 1: default namespace — мусорка, которая сожжёт вам всё

- Проблема: запустил поды в default, забыв про изоляцию.

- Чем опасно: Взлом одного сервиса = доступ ко всем.

- Как исправить:

kubectl create namespace my-app
kubectl config set-context --current --namespace=my-app



🔴 Ошибка 2: ServiceAccount с правами бога

- Проблема: сервисный аккаунт default:default имеет права cluster-admin (да, было лень разбираться с правами).

- Чем опасно: Злоумышленник → получил токен → полный контроль над кластером.

- Как исправить:

kubectl create rolebinding restricted-view \
--clusterrole=view \
--serviceaccount=default:default \
--namespace=default



🔴 Ошибка 3: Не включён PodSecurityPolicy (или его аналоги)

- Проблема: Поды могут запускаться от root, монтировать /etc и делать другие жуткие вещи.

- Чем опасно: Escalation privileges → хостовая система под ударом.

- Как исправить:

# Для новых версий K8s (PSP deprecated, но есть замены):
kubectl label ns my-app pod-security.kubernetes.io/enforce=restricted



💥 Бонус: Если ваш кластер уже живёт с этим годами — проверьте его :

kubectl get pods --all-namespaces -o json | grep "serviceAccount: default"


Есть и другие ошибки, которые я сделал, если тема интересна, то напишите в комментариях пользуетесь ли k8s для своих проектов, что предпочитаете manages cluster или колхоз а-ля minicube?