15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Большинство разработчиков считают, что графы не имеют значения для их повседневной работы.
Но причина в том, что они не знают алгоритмы работы с графами и области их применения.
Вы измените своё мнение, как только узнаете эти 5 алгоритмов:
1. Поиск в ширину (Breadth-first search, BFS)
Это алгоритм обхода графа, реализуемый с использованием структуры данных «очередь».
Он начинается с одной вершины и сначала исследует все её соседние вершины.
Затем переходит к вершинам, находящимся на расстоянии двух шагов от начальной, и так далее.
Примеры применения BFS:
● построение индекса веб-страниц в веб-краулерах
● обнаружение соседних узлов в p2p-сетях
● поиск ближайших объектов в GPS-навигации
2. Поиск в глубину (Depth-First Search, DFS)
Это алгоритм обхода графа, реализуемый с использованием структуры данных «стек».
Он начинается с одной вершины и исследует путь максимально глубоко, прежде чем возвращаться назад.
Когда на текущем пути больше нет непосещённых вершин, происходит откат к предыдущей вершине.
Примеры применения DFS:
● поиск пути между двумя вершинами
● обнаружение циклов в графе
● топологическая сортировка
● решение лабиринтов и головоломок, таких как судоку
3. Кратчайший путь (Shortest Path)
Это алгоритм обхода графа, который вычисляет кратчайший путь между двумя вершинами.
Кратчайший путь минимизирует сумму весов на пройденных рёбрах.
Существует два основных алгоритма: Дейкстры и Беллмана–Форда.
Примеры применения алгоритма кратчайшего пути:
● поиск маршрутов в навигационных системах
● решение задачи минимальной задержки в сетевых протоколах
● определение оптимального маршрута от одной точки к другой в видеоиграх
4. Топологическая сортировка (Topological Sorting)
Это алгоритм теории графов, который определяет порядок обхода вершин.
Он упорядочивает вершины ориентированного графа по прямой линии так, что для каждого ребра x → y вершина x предшествует y.
Примеры применения топологической сортировки:
● планирование взаимозависимых задач
● сериализация данных и упорядочивание предложений
● упорядочивание задач компиляции и разрешение зависимостей между символами
5. Минимальное остовное дерево (Minimum Spanning Tree, MST)
Это алгоритм теории графов, который находит подмножество рёбер, соединяющее все вершины графа.
Такое множество рёбер не содержит циклов и имеет минимальную суммарную стоимость (вес).
Каждый связный неориентированный граф имеет хотя бы одно остовное дерево.
Примеры применения MST:
● проектирование сетевой инфраструктуры
● регистрация изображений и отслеживание объектов
● анализ кластеров в графовых данных
👉 @BackendPortal
7 вещей, которые хотел бы знать до начала проектирования систем
7. Масштабируемость — это не про микросервисы
Начинай с простого. Преждевременное дробление — путь не к ясности, а к путанице.
6. Работа архитектора — не только про код
Придётся согласовывать команды, принимать компромиссы и переводить бизнес-пожелания в реальные решения.
5. Доступность — это компромисс
Маркетинговому сайту не нужен аптайм в 99.999%. Проектируй под реальные SLA.
4. Технический долг неизбежен
Его не избежать. Главное — управлять им осознанно и с расчётом на отдачу.
3. Диаграммы — это результат
Проектирование — это общение. Если схему не поняли — её нужно переделать.
2. Читать кода придётся больше, чем писать
Архитектор должен понимать существующие системы не хуже, чем проектировать новые.
1. Ни один дизайн не выдерживает столкновения с реальностью
Ошибки будут. Нужно быстро адаптироваться, упрощать и двигаться вперёд.
Проектирование систем учит держать себя в руках 😈
👉 @BackendPortal
Бесплатные песочницы по Linux, сетям, контейнерам и Kubernetes
50+ удалённых playground'ов (и число растёт). Всегда актуальные — идеально подходят для:
> Тренировка Linux-навыков
> Работа с сетями, TCP/UDP
> Контейнеры (Docker, Podman)
> Kubernetes — деплой, отладка, масштабирование
> Безопасные тесты конфигураций и CI/CD пайплайнов
> Подходит для запуска dev-сервисов и моков
Вся подборка тут: link
👉 @BackendPortal
Новинка: AI Substitutor
Забудь про ручную подстановку параметров в HTTP-запросах.
AI Substitutor — это инструмент, который автоматически подставляет умные, контекстно-зависимые значения в параметры и заголовки запросов.
Работает идеально с:
> Swagger/OpenAPI
> JS-генерированными запросами
> Автогенерированным трафиком
👉 @BackendPortal
Хватит слать "пустые" события, из-за которых потребителям нужно обращаться обратно к вам.
В 90% случаев можно использовать Event-Carried State Transfer — и сделать события самодостаточными. 🤗
Вместо простого OrderPlaced — отправляйте полные данные заказа.
Почему это важно:
> Потребителям не нужно делать обратный вызов за недостающей информацией
> Исключаются каскадные сбои, если исходный сервис недоступен
> Уменьшается связность между командами во время исполнения
Есть компромиссы:
> Увеличивается размер события
> Нужно версионировать payload
> Данные могут устареть, если событие задержалось
Но это того стоит.
Если потребителю нужно делать callback, чтобы понять событие — это не событие, а уведомление.
В хорошо спроектированной системе данные должны свободно течь
👉 @BackendPortal
Как спроектировать эффективные и безопасные API?
API всё чаще становятся основой современного софта.
Чтобы понять ключевые принципы и лучшие практики проектирования API, давай разберём пример социальной платформы
🔸Именование ресурсов
↳ Ясность — ключ к хорошему API. Использование простых имён ресурсов, например /users для получения профилей пользователей и /posts для получения их публикаций, упрощает разработку и снижает когнитивную нагрузку.
🔸Использование множественного числа
↳ Важно соблюдать единообразие в дизайне API. Для лучшей читаемости и предсказуемости используйте имена ресурсов во множественном числе, например GET /users/{userId}/friends вместо /friend, чтобы избежать неоднозначности в запросах
🔸Связывание ресурсов
↳ Взаимосвязь между ресурсами, например получение комментариев к посту через GET /posts/{postId}/comments, упрощает доступ к связанным данным. Это делает API более логичным и улучшает пользовательский опыт
🔸Безопасность
↳ Очевидно, что безопасность — обязательна. Для защиты конечных точек API используйте методы аутентификации, такие как X-AUTH-TOKEN и X-SIGNATURE, а также заголовки авторизации для проверки прав доступа пользователя
🔸Версионирование
↳ Использование версионирования и прозрачная коммуникация об обновлениях — ещё одна важная практика. Например, GET /v2/users/{userId}/posts позволяет поддерживать разные версии API без ломки текущей функциональности. Такой подход обеспечивает обратную совместимость и плавный переход как для пользователей, так и для разработчиков.
🔸Пагинация
↳ Этот приём важен для производительности. Разбивайте большие наборы данных — например, ленты или списки комментариев — на страницы с помощью запроса вроде GET /posts?page=5&pageSize=20, чтобы ускорить доставку данных и улучшить пользовательский опыт
🔸Идемпотентность
↳ Надёжность API — обязательное условие. Идемпотентность гарантирует, что операции, например обновление профиля (PUT /users/{userId}/profile), приведут к одному и тому же результату независимо от количества повторных вызовов.
Тщательная документация, надёжный мониторинг и логирование, а также единообразная обработка ошибок — лишь часть необходимых привычек для создания эффективных и безопасных API.
Следуя этим принципам и практикам, мы можем разрабатывать безопасные и производительные API, обеспечивающие качественный пользовательский опыт 😎
👉 @BackendPortal
👨💻 Эти каналы реально помогают в изучении программирования и IT
Не веришь? Проверь сам:
👩💻 Easy GitHub — лучшие репозитории с гитхаба для практики и освоения IT.
🌐 Easy WebDev — всё про Frontend, Backend и сопутствующие технологии.
🖥 Easy Python — лёгкое изучение самого универсального языка в мире.
🔠 Easy InfoSec — ИБ, хакинг, OSINT, анонимность, пентест и многое другое.
🖥 Easy Coder — а здесь вообще про всё, что нужно знать для работы в IT.
🖱 Просто выбери нужное и получай топовые материалы каждый день!Читать полностью…
Этот инструмент — позволяет узнать всю информацию о домене:
DNS, WHOIS, IP-адреса, поддомены, SSL-сертификаты и многое другое!
→ http://digger.tools
👉 @BackendPortal
Каждый бэкенд-инженер должен уметь ответить на вопрос:
Что произойдёт, если база данных упадёт посреди транзакции?
Причины могут быть разные: отключение питания, сбой оборудования и т.д.
Чтобы не потерять данные, система должна сохранять их на энергозависимом хранилище, например, на диске.
Когда пользователь выполняет транзакцию, база данных делает две вещи:
> записывает данные в отдельный лог
> применяет обновление
Лог нужен для повторной обработки транзакции при перезапуске, чтобы восстановить консистентное состояние после сбоя.
Запись в лог быстрая, так как это бинарный файл с добавлением только в конец (append-only).
Это исключает затратные операции поиска по файлу.
А если база распределённая?
Тут сложнее — серверам базы нужно координироваться с помощью протокола двухфазной фиксации (2PC).
В этом процессе один из серверов выступает координатором:
> он отправляет всем участникам запрос на коммит
> ждёт подтверждения от всех
> затем сообщает коммитить или откатить транзакцию
👉 @BackendPortal
Периодическая таблица Kubernetes
Подробный визуальный гид, который проясняет ключевые строительные блоки этой мощной платформы оркестрации контейнеров.
Эта периодическая таблица Kubernetes охватывает 120 важнейших компонентов, составляющих экосистему Kubernetes.
Будь вы разработчик, системный администратор или облачный энтузиаст — этот наглядный ресурс поможет сориентироваться в мире Kubernetes 💪
👉 @BackendPortal
DynamoDB и Aurora завели ребёнка — встречайте Aurora DSQL
Вот что нужно знать.
Десятилетиями масштабирование реляционных баз данных требовало компромиссов:
> Реплики — для чтения
> Шардинг — для записи
> И куча «костылей», чтобы имитировать глобальную согласованность
Такова была реальность.
Но Aurora DSQL обещает настоящую масштабируемость — без хаков и компромиссов.
Это новая безсерверная SQL-база, оптимизированная под транзакционную нагрузку и созданная для облака.
Она только что стала общедоступной и меняет наше представление о масштабировании транзакционных систем.
Построена на PostgreSQL, использует распределённую архитектуру, работает на Rust для минимальных задержек.
Поддерживает active-active режим и мультирегиональный SQL по умолчанию.
Всё, что ты ожидаешь от SQL — транзакции, схемы, индексы, join'ы и т.д. — тут есть.
С гарантированной согласованностью и изоляцией.
Один endpoint на регион. Пиши где угодно. Читай где угодно. Всё строго согласованно.
Почему это важно:
> Масштабируемая запись без шардинга
> Настоящий мультирегиональный failover без даунтайма
> Совместимость с PostgreSQL — ничего переписывать не нужно
> Автоматическое масштабирование без сложной настройки
И да — это действительно похоже на ребёнка DynamoDB и Aurora, который говорит на SQL.
Мы становимся свидетелями перехода, где распределённый SQL — это уже не исследовательская тема и не нишевая технология,
а готовое к продакшену, облачное и экономичное решение.
Похоже, открывается новое пространство для проектирования систем с транзакционными гарантиями и глобальным масштабом —
без необходимости выбирать только одно из двух.
Может быть, это конец эпохи хакающих баз на больших масштабах? 😃
👉 @BackendPortal
Схема основных компонентов и инструментов бэкенд-системы
😃😃😃
👉 @BackendPortal
Шпаргалка по Linux для бэкендера и DevOps
Вот компактная шпаргалка, к которой я постоянно возвращаюсь: системная информация, сети, операции с файлами и не только
💪💪💪
👉 @BackendPortal
Понимание системных логов в Linux
Системные логи, как правило, находятся в каталоге /var/log в Linux-системах и являются важным инструментом для мониторинга и устранения проблем. Ниже — краткие описания некоторых распространённых логов:
> syslog: универсальный системный лог, содержащий сообщения от различных системных служб и приложений. Является основным логом, куда стекаются многие другие сообщения.
> auth.log: записывает события, связанные с аутентификацией, включая успешные и неудачные попытки входа, смену пароля и другие действия, связанные с доступом пользователей.
> kern.log: содержит сообщения от ядра, включая ошибки оборудования, загрузку модулей ядра и другие действия, связанные с ядром.
> messages: универсальный лог-файл, в который пишутся различные системные сообщения, такие как загрузка и выключение системы, а также другие события.
> dmesg: отображает сообщения кольцевого буфера ядра, давая обзор событий ядра и обнаружения оборудования во время загрузки.
> cron: логирует сообщения, связанные с заданиями cron и планировщиком, включая время их выполнения и ошибки при запуске.
> secure: записывает события, связанные с безопасностью, включая попытки аутентификации, повышение привилегий и другие важные события.
> apache/access.log и apache/error.log: логи Apache. Первый содержит HTTP-запросы, второй — ошибки и предупреждения сервера.
> nginx/access.log и nginx/error.log: аналогичные логи для Nginx: доступ и ошибки сервера.
> mysql/error.log: фиксирует ошибки и предупреждения от сервера MySQL, включая ошибки запуска, сбои запросов и падения базы.
Эти логи дают важную информацию о производительности системы, событиях безопасности и помогают в отладке. Регулярный анализ логов помогает поддерживать систему в хорошем состоянии и заранее выявлять проблемы 😊
👉 @BackendPortal
Как работает HTTPS:
1. TCP-рукопожатие (TCP Handshake)
Клиент и сервер устанавливают соединение:
> SYN →, SYN-ACK ←, ACK →
2. Проверка сертификата (Certificate Check)
> Клиент отправляет Client Hello
> Сервер отвечает: Server Hello, свой сертификат (содержит публичный ключ), и Server Hello Done
3. Обмен ключами (Key Exchange)
> Клиент генерирует сеансовый ключ (session key)
> Шифрует его публичным ключом сервера и отправляет
> Сервер расшифровывает сеансовый ключ своим приватным ключом
Это называется асимметричное шифрование
4. Передача данных (Data Transmission)
Теперь обе стороны используют один и тот же сеансовый ключ для шифрования/дешифрования данных
> Это уже симметричное шифрование — быстрее и эффективнее
Ключевые понятия:
> Публичный ключ используется для шифрования
> Приватный ключ — для расшифровки
> Сеансовый ключ — общий, используется для шифрования трафика
👉 @BackendPortal
Что должен знать каждый программист о памяти
Обратите внимание на интересную статью Ульриха Дреппера, в которой рассматриваются системы компьютерной памяти и их значение для разработчиков программного обеспечения.
Понимание этих концепций критически важно, если вы стремитесь создавать высокоэффективное ПО.
В статье рассматриваются:
> Кэш-память CPU — зачем она нужна и как оптимизировать её использование для ускоренного доступа к данным.
> Виртуальная память — как происходит управление памятью на низком уровне и что это означает для ваших приложений.
> Шаблоны доступа к памяти — ключ к написанию эффективного кода заключается в понимании иерархии памяти.
> Инструменты для анализа производительности — практические советы по использованию инструментов для выявления и устранения узких мест, связанных с памятью.
> Блокировки (locks) — понимание влияния многопоточности на работу с памятью.
> Многопоточность и память — как неравномерный доступ к памяти (NUMA) влияет на производительность программ на современных многопроцессорных системах.
По мере роста требований к ПО и увеличения разрыва в скорости между CPU и памятью, грамотное управление доступом к памяти становится ключевым фактором производительности.
Это обязательный материал для разработчиков, стремящихся к низкоуровневым оптимизациям 🐸
👉 @BackendPortal
Развертывание без простоя с GitHub Actions + PM2 (Node.js)
Настройка CI/CD для небольших приложений на VPS может быть неудобной. Вот чистый способ развертывания без потери трафика:
> Используйте GitHub Actions для CI/CD
> На сервере выполняйте git pull из репозитория
> Перезапускайте приложение через PM2 (сохраняет аптайм, управляет логами)
👉 @BackendPortal
Разыгрываем лучшие гаджеты года: iPhone 16 Pro Max на 256 ГБ, 15-дюймовый MacBook Air 16/256 ГБ и PlayStation 5 Pro!
Чтобы их получить, достаточно подписаться на:
• наш канал «Техночат»
• И на канал «Больше, чем экономика»
Нажимаете после этого на кнопку «Участвовать» и ждёте 2 июля — в этот день в 20:00 по московскому времени рандомайзер выберет трёх победителей. Первый получит айфон, второй — макбук, а третий — PlayStation.
Призы бесплатно вышлем в ближайший к вам пункт выдачи СДЭК, поэтому уточните, есть ли он в вашей стране.
Как выбрать шаблон проектирования?
Выбор подходящего шаблона проектирования в программной инженерии — ключ к эффективному решению задач. Этот гайд упрощает процесс выбора, помогая принимать обоснованные решения в зависимости от конкретных потребностей.
В нём даны краткие описания и практические случаи использования каждого шаблона, что облегчает их понимание и применение в реальных проектах.
Чтобы выбрать шаблон, сначала необходимо определить тип проблемы:
> Создание объектов? → Порождающие шаблоны
> Компоновка объектов? → Структурные шаблоны
> Взаимодействие объектов? → Поведенческие шаблоны
Приступим.
1. Порождающие шаблоны
> Singleton — используется, когда нужен единственный экземпляр класса. Примеры: логгирование, подключения к базе данных.
> Factory Method — отделяет создание объекта от его использования. Пример: создание разных типов подключений к БД на основе конфигурации.
> Abstract Factory — создаёт семейства связанных объектов. Пример: парсеры для разных форматов файлов.
> Builder — пошаговое создание сложных объектов. Пример: построение сложного объекта доменной модели.
> Prototype — создание копий объектов и повторное использование закэшированных экземпляров для снижения количества запросов к БД.
2. Структурные шаблоны
> Adapter — делает несовместимые интерфейсы совместимыми. Пример: подключение новой библиотеки логгирования к системе с другим интерфейсом.
> Composite — представление иерархий "часть-целое". Пример: графические объекты в редакторе, объединяемые в группы.
> Proxy — управление доступом к объекту. Пример: ленивое подключение изображения высокого разрешения.
> Decorator — динамическое добавление/удаление поведения. Пример: добавление сжатия или шифрования для потоков файлов.
> Bridge — разделение абстракции и реализации. Пример: изоляция платформозависимого кода от основной логики.
3. Поведенческие шаблоны
> Strategy — определяет семейство алгоритмов. Пример: выбор между различными алгоритмами сортировки или сжатия.
> Observer — оповещение об изменениях состояния. Пример: уведомление подписчиков о событиях в системе сообщений.
> Command — инкапсулирует запрос как объект. Пример: реализация undo/redo в текстовом или графическом редакторе.
> State — инкапсулирует поведение в зависимости от состояния. Пример: разные состояния UI-элемента (вкл., выкл., выделен).
> Template Method — задаёт скелет алгоритма, позволяя подклассам реализовать отдельные шаги. Пример: базовый класс для юнит-тестов с переопределяемыми шагами подготовки и очистки.
В итоге мы подбираем тот шаблон, который наилучшим образом решает конкретную задачу
👉 @BackendPortal
Что такое Event Sourcing? Чем он отличается от обычного CRUD-дизайна?
Диаграмма показывает сравнение между обычным CRUD-дизайном системы и дизайном с использованием Event Sourcing. В качестве примера используется сервис заказов.
Парадигма Event Sourcing применяется для проектирования систем с детерминизмом. Это меняет саму философию традиционного дизайна систем.
Как это работает? Вместо того чтобы сохранять состояния заказа в базе данных, при использовании Event Sourcing фиксируются сами события, которые приводят к изменениям состояния, в хранилище событий (event store). Хранилище событий — это лог только для добавления. События должны иметь последовательную нумерацию для гарантии порядка. Состояние заказа может быть восстановлено из событий и поддерживаться во OrderView. Если OrderView недоступен, мы всегда можем полагаться на event store как на источник истины для восстановления состояния заказа.
Рассмотрим подробные шаги:
> Обычный (не Event Sourcing) подход
Шаги 1 и 2: Боб хочет купить товар. Заказ создаётся и сохраняется в базу данных.
Шаги 3 и 4: Боб хочет изменить количество с 5 до 6. Заказ обновляется с новым состоянием.
> Event Sourcing
Шаги 1 и 2: Боб хочет купить товар. Создаётся NewOrderEvent, которому присваивается последовательный идентификатор eventID=321, и он сохраняется в хранилище событий.
Шаги 3 и 4: Боб хочет изменить количество с 5 до 6. Создаётся ModifyOrderEvent, которому присваивается eventID=322, и он также сохраняется в event store.
Шаг 5: Представление заказа (OrderView) пересобирается на основе событий, отражая актуальное состояние заказа.
А теперь к вам: какой тип системы лучше всего подходит для архитектуры с Event Sourcing? Использовали ли вы эту парадигму в своей работе? 😎
👉 @BackendPortal
Если ты бэкендер на старте пути и чувствуешь, что структуры данных это что-то из теории, которую никто не применяет — вот тебе годный разбор
Автор показывает, как использовать массивы, очереди, списки и другие DSA прямо в реальных задачах: от TODO-листов до обработки заявок в техподдержке. Всё на JavaScript, понятно и по делу
👉 @BackendPortal
Пропускная способность Kafka у OpenAI выросла в 20 раз за последний год, при этом используется более 30 кластеров.
Их инфраструктура обеспечивает доступность в пять девяток (99.999%).
Вот как им это удалось 👇
🔸Группы кластеров
Кластеры разделены на группы, каждая из которых живёт в отдельном регионе.
Пользователь через конфигурационный сервис создаёт логические топики, которые размещаются внутри группы.
Каждый логический топик соответствует физическому топику в каждом кластере группы.
Это хорошо абстрагировано — разработчики работают только с "топиками", не задумываясь о кластерах или брокерах.
🔸Prism — прокси для продюсеров
Это простой прокси, предоставляющий единственный gRPC-эндпоинт — ProduceBatch.
Prism радикально сократил число подключений к брокерам — раньше доходило до 50 тысяч на брокер, и память просто заканчивалась. 😥
Также реализованы кросс-региональные ретраи: если кластер в одном регионе недоступен — запрос уходит в другой.
🔸uForwarder — прокси для консьюмеров
Используется open-source прокси от Uber — uForwarder.
Он переводит работу с Kafka в push-модель: сам тянет данные из Kafka и пушит их подписанным консьюмерам по gRPC.
В итоге приложения вообще не взаимодействуют с Kafka — не нужен клиент, конфигурация, авторизация или управление смещениями. Всё упрощено.
Дополнительно, прокси даёт:
> автоматические ретраи
> очередь "мертвых" сообщений
> потребление из нескольких кластеров
> отсутствие блокировок в начале очереди
> параллелизм выше количества партиций
🔸Компромиссы
Этот подход требует отказаться от:
➖ транзакций и идемпотентности
➖ гарантированной очередности
➖ управления партициями
Но OpenAI предложили альтернативы:
> идемпотентная обработка downstream
> упорядочивание по логическим таймстампам downstream
> перепартиционирование через Flink
Они следовали принципу:
"Простое должно быть простым, сложное — возможным."
Большинство систем не проходят проверку на согласованность.
Вы пишете бэкенд. Всё работает — пока две операции не попытаются записать одновременно.
Тогда появляются:
> двойные списания,
> потерянные изменения,
> повреждённое состояние.
Это не просто баг — это ошибка в дизайне.
Базы данных решают эту проблему уже много лет, и существует всего 3 способа обеспечить согласованность:
> Write-Ahead Logging (журналирование перед записью)
> Блокировки
> Версионирование
Автор разобрал каждый из них с диаграммами, компромиссами и примером из реального мира — как DynamoDB обеспечивает согласованность.
Если вы когда-либо выпускали фичу, которая иногда затирает пользовательский ввод — это для вас 😎
👉 @BackendPortal
Доступ к Docker Daemon с другой машины
Иногда возникает необходимость запускать команды Docker с отдельной машины, где установлен только Docker CLI, но не сам движок Docker.
Например: Docker работает на домашнем сервере, а управлять им вы хотите с ноутбука или рабочей машины
👉 @BackendPortal
Что такое Multi-Stage сборки в Docker?
Multi-stage сборки позволяют разбить процесс сборки на этапы — это упрощает workflow и делает финальный образ чище.
Зачем использовать:
> Разделение задач: сборка, тесты, упаковка
> Меньше размер: без лишних зависимостей
> Безопаснее: меньше поверхность атаки
> Удобнее отладка: можно запускать конкретные стадии
Как работает:
1. Build stage — собираем код, артефакты
2. Production stage — берём лёгкий образ, добавляем только нужное
На выходе — минимальный, безопасный и быстрый production-образ.
Пример для Node.js: ☹️
👉 @BackendPortal
Этот carlosalbertoalvesscorreia/would-the-kubernetes-cpu-limit-be-an-anti-pattern-2b07d92d7bd8">пост ставит под сомнение привычную практику DevOps — задавать лимиты на CPU в Kubernetes.
Автор показывает, что это мешает эффективно распределять нагрузку, вызывает торможение при пиковых запросах и в итоге приводит к лишним тратам на инфраструктуру. 😱
👉 @BackendPortal
Как Terraform создает инфраструктуру в масштабе?
Инфографика от ByteByteGo наглядно объясняет, как работает Terraform:
1. Write
> Разработчик создает .tf-файлы
> Использует переменные, модули, функции
> Подключает модули из Public Module Registry
2. Plan
> terraform plan — показывает, какие изменения будут внесены
> Сравнивает текущее и желаемое состояние
3. Apply
> terraform apply — применяет план
> Делает API-запросы к облачным провайдерам
> Создает, обновляет или удаляет ресурсы
4. Infra Ready
> Более 1000 провайдеров (AWS, Azure, GCP и др.)
> Инфраструктура развернута и готова к работе
👉 @BackendPortal
kubectl-mcp-server — мост между Kubernetes и AI-интерфейсами (Claude, Cursor и др.)
Этот проект превращает kubectl в управляемый ассистентом инструмент. Теперь можно взаимодействовать с кластером на естественном языке — запускать поды, читать логи, проверять состояния, и всё это через AI 💪
pip install kubectl-mcp-tool
kubectl-mcp serve
Почему мы решили писать собственный Object Storage для новой платформы MWS?
🔗Рассказываем в статье в хабе DevCloud от MWS на Хабр
Вы узнаете:
⏺️Почему нам не подошли даже зрелые решения вроде Ceph RGW
⏺️С какими техническими ограничениями и компромиссами мы столкнулись при оценке альтернатив
⏺️Как устроено наше собственное S3-совместимое хранилище — и зачем мы вообще его делаем
⏺️Как архитектура с Golang, PostgreSQL и Kafka даёт гибкость и масштабируемость
⏩️Подписаться на хаб
Когда-нибудь задумывался, как топовые компании выкатывают обновления в несколько окружений и не ломают прод?
Секрет — в правильной стратегии ветвления и CI/CD.
Вот как это выглядит в живом процессе:
> Создаёшь фичу → деплоишь на dev
> Создаёшь тег → деплоишь на test
> Мёржишь в release → идёт на staging
> Делаешь pre-release → preprod
> Всё ок? Выпускаешь релиз → летит в prod
Каждое окружение проверяет код на разных этапах, а автоматизация через CI/CD экономит кучу времени и нервов.
Плюсы:
✅ Повышается надёжность релизов
✅ Удобно тестировать на каждом этапе
✅ Быстро ловятся баги до прода
Минусы:
✅ Нужно больше ресурсов (серверов/окружений)
✅ Требует хорошей настройки пайплайнов
✅ Сложнее поддерживать маленькой команде
Освоишь такую схему — легко ответишь на любой вопрос по DevOps или CI/CD на собесе.
👉 @BackendPortal