Что же делать на практике для масштабирования data-bounded (т.е. типичных) приложений?

Я опущу длительные рассуждения и представлю свою "поваренную книгу"

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

Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.

Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.

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

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

Copilot в Obsidian — полноценное решение для загрузки личной базы знаний в LLM-модель. С её помощью можно лучше понять себя, собрать мысли и найти новые связи в своих заметках.

Для подключения модели можно использовать множество различных поставщиков LLM-моделей.

В этой статье мы будем использовать локальную модель, запущенную с помощью Ollama. Поэтому нам понадобится командная строка, Docker и видеокарта (лучше от 24 Гб видеопамяти, или же для эксперимента можно арендовать GPU-сервер на пару часов).

Привет! Меня зовут Андрей Дорожкин, и я руковожу командой администрации баз данных в Hybrid. В этом материале я поделюсь опытом работы с ClickHouse — колоночной БД, разработанной специально для аналитических запросов, которая позволяет получать результаты в разы быстрее традиционных решений. Также я подсвечу, как устроен этот продукт, чем он отличается от реляционных баз данных, и в каких сценариях его использование может дать бизнесу реальное преимущество.

Пара слов о компании Hybrid. Мы — независимая AdTech-экосистема с собственным стеком технологий и решений для любых рекламных целей. Развиваем собственные технологии благодаря in-house отделу разработки, который каждый день работает над их улучшением. ClickHouse — инструмент, который мы выбираем для хранения данных за высокую скорость обработки запросов, эффективное сжатие данных и масштабируемость.

Распределенные системы лежат в основе большинства современных приложений - от облачных сервисов до финансовых платформ и социальных сетей. Проектирование сопряжено с рядом сложных компромиссов, особенно когда речь идет о согласованности данных, доступности системы и устойчивости к сетевым сбоям.

Теорема CAP (дословно: Consistency (согласованность), Availability (доступность), Partition Tolerance (устойчивость к разделению)), предложенная Эриком Брюером в 2000 году, объясняет, почему невозможно одновременно обеспечить все три этих свойства.

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

Да, многие могут сказать, что это больше стезя архитектора. Но грань между аналитиком и архитектором в текущих реалиях очень смазана. Хороший системный аналитик фактически является lite версией архитектора. Поэтому щас выскажусь!)))

Искусственный интеллект (ИИ) - ключевой компонент современных поисковых систем. Однако большинство популярных решений, таких как Google, Perplexity и ChatGPT остаются проприетарными, что затрудняет научные исследования и развитие таких технологий. В то же время, открытые решения для интеллектуального поиска часто оказываются менее качественными. Это создает разрыв между закрытыми коммерческими системами и доступными для разработчиков инструментами, которые не обладают такой же производительностью и качеством. Для устранения этого разрыва исследователи представили открытый фреймворк Open Deep Search (ODS), который позволяет интегрировать мощные инструменты для веб-поиска с любыми большими языковыми моделями (LLM), обеспечивая конкуренцию с коммерческими системами.

Я Диана, системный аналитик в Clevertec и экс-преподаватель. В этой нескучной лекции расскажу:

- Что такое Keycloak и для чего он нужен?

- Как Keycloak помогает с межсистемной аутентификацией?

- Какие плюсы и минусы у Keycloak при использовании в продакшене?

- Какие альтернативы есть у Keycloak?

Часто при разработке небходимо иметь на локальной машине сервер kafka с ssl аутентификацией.
Надеюсь эта статья поможет быстро поднять его и приступить к разработке.

Расскажем, как мы сделали отказоустойчивый WireGuard-сервер в Yandex Cloud, раскинув его на три зоны доступности. Получилось просто, надёжно и без сложных кластеров.

Мы не рассматриваем настройку самого WireGuard, конфигурацию групп безопасности, настройку VPC, NLB и прочее. Вся логика сосредоточена на том, чтобы обеспечить автоматическое переключение между зонами при сбоях. Сеть VPN-клиентов — 172.28.90.0/24 — должны быть доступна с любой из трёх зон.

Привет, Хабр!

Сегодня рассмотрим, как настроить CI/CD пайплайн для Docker-образов: от сборки (с docker buildx и buildah) до пуша с версионированием и автоматической очистки через GitLab API.

Мы продолжаем развивать нашу платформу для разработчиков и их команд. В этот раз мы снова наступили на грабли безопасности но уже в чаcти SSH доступа к серверам.

Представляю вашему вниманию перевод статьи SSL and SSL Certificates Explained For Beginners. Я долго разбирался с SSL, сертификатами, центрами сертификации - это единственная статья, после которой у меня что-то отложилось в голове :) Поэтому возникла идея перевести ее и донести до широких масс.

Часть 1 | mega.nz | Онлайн демо | GitHub

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

Добрый день. Прошло уже 2 года с момента написания последней статьи про парсинг Хабра, и некоторые моменты изменились.

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

Привет, Хабр! Меня зовут Натиг Нагиев, я Devops-инженер в МТС Диджитал.

Проект, над которым я сейчас работаю, занимается обеспечением авторизации внешних клиентов. Это Mission Critical система, поэтому нам нужно было ускорить и оптимизировать доставку секретов в контейнеры с микросервисом, избежать дополнительных рабочих нагрузок в kubernetes, гарантировать безопасность при доставке секретов и исключить внешние зависимости.

Сейчас де-факто стандартом для таких задач стало хранилище HashiCorp Vault, поэтому мы рассматривали и пробовали разные инструменты: Vault Agent Injector, Vault CSI Provider, External Secrets Operator и OpenBao — но в итоге остановились на связке Bank-Vault и Vault Secrets Operator.

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

Привет, Хабр! Меня зовут Натиг Нагиев, я Devops-инженер в МТС Диджитал.

На нашем проекте мы обеспечиваем авторизацию внешних клиентов в продуктах МТС. Это Mission Critical система, где мы оптимизировали и гарантировали доставку секретов в контейнеры с микросервисом, избавлялись от дополнительных рабочих нагрузок и исключали внешние зависимости. В прошлом материале я сравнил разные инструменты, которые мы перебрали, а в этом расскажу про наше итоговое решение — связку Bank-Vaults и Vault Secrets Operator.

Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.

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

Развитие методологий CI и CD не стоит на месте. Тем не менее, проверенные практики, вероятно, останутся актуальными и в 2025 году. В этой статье покажем некоторые из таких в действии.

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

В этой статье расскажу, как мы объединили несколько разных команд разработки Райффайзен Онлайн общим Observability и с помощью исключительно технических метрик отслеживаем здоровье бизнес-процессов. Как всё это помогает мгновенно находить первопричину сбоя. Как устроен OpenTelemetry и как с его помощью рассчитать доступность приложения в девятках, а также MTTR (Mean Time to Recovery).