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

Алексей Барабанов, IT-директор «Хлебница» и спикер курса «RabbitMQ для админов и разработчиков», подготовил конспект, который поможет понять терминологию и базовые сущности RabbitMQ.

В этой статье я расскажу об инструкциях Docker, о том как написать Dockerfile и о существующих best practice для этого!

В этой статье я расскажу о том что такое docker compose, как его написать и разобраться во всех возможных конфигурациях этого файла!

Чтобы понимать, какие запросы можно отправлять в GraphQL API и что можно получить в ответе, нужно уметь читать его схему. Это как WSDL в SOAP API — описание всех доступных методов.

Да, программы типа Postman или Apollo сами считывают схему и показывают вам всё в красивом виде — просто ходи да «натыкивай» запросы. Но если само API ещё в разработке, чтение схемы поможет понять, что вас ожидает.

Поэтому в этой статье я расскажу, что такое Schema GraphQL API и как её читать.

В работе мы с коллегами часто видим как компании сталкиваются с проблемой управления данными – когда таблиц и запросов становится сильно много и управлять всем этим очень сложно. В таких ситуациях мы рекомендуем моделировать данные. Чтобы разобраться, что это такое – я перевела статью-обзор про моделирование данных от Towards Data Science, в которой кроме основных терминов и понятий можно найти наглядный пример использования моделирования данных в ритейле. Вперед под кат!

Введение

Часто, в обзорах видов баз данных упоминают реляционные и “другие”, “NoSQL” и т.д., либо приводят самые основные типы СУБД (базы данных), забывая о редких. В данной статье я постараюсь описать максимально полно виды баз данных и привести примеры конкретных реализаций. Разумеется, статья не претендует на всеохватность и классифицировать базы данных можно по разному, в том числе по типам оптимальной нагрузки и т.д., но надеюсь, она даст базовое представление о видах СУБД и принципах их работы.

В статье мы рассмотрим следующие типы баз данных:

«Скажите, какие основные преимущества микросервисов и почему?». Вероятно, это самых популярный вопрос последних 6–10 лет на любом собеседовании для бэкенд разработчика. Каким-то чудом он даже обогнал: «Назовите три принципа ООП» и «Чем отличается класс от объекта».

Первые упоминания о практическом использовании микросервисной архитектуры появились в 2010-х годах. Но сейчас она стала стандартом для отрасли. Ведущий архитектор Группы «Иннотех» Александр Соляр рассказал о некоторых нюансах микросервисов, а также принципах их использования.

Продолжаем обзор паттернов интеграции микросервисов. В первой части мы рассказали, зачем IT-специалистам нужны шаблоны интеграции, и для каких задач они подходят. Подробно остановилисьна Circuit Breaker, Sidecar, Ambassador, Anti-Corruption Layer и Async Request-Reply. Сегодня по плануразобрать Backends for Frontends, Cache-Aside, Gateway, Gateway Aggregation и Gateway Routing. 

В серии из трех статей рассказываем о переходе с монолитной на микросервисную архитектуру. Разбираемся, когда и кому это действительно нужно, рассматриваем 7 миграционных шаблонов и самый больной вопрос: «Как быть с данными?».

Программные брокеры сообщения уже стали стандартом при построении больших и сложных систем. Однако до сих пор не все ИТ-специалисты понимают, как работают эти инструменты. Главный системный аналитик «Иннотех» Павел Малыгин помогает разобраться в брокерах сообщениях и их работе.

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

Микросервисы стали выбором многих благодаря их гибкости, масштабируемости и способности поддерживать сложные приложения в динамично меняющемся мире.

Но не всё так просто. Одной из ключевых проблем, с которыми сталкиваются при переходе от монолитных архитектур к микросервисным, является обеспечение согласованности данных.

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

Впереди зимние каникулы, и, наверное, многие выбирают себе чтение на эти дни. Самая известная книга среди системных аналитиков — «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти. Это как Кнут для программистов — все про неё слышали, но мало кто читал от начала до конца. Труд монументальный — в русском издании больше 700 страниц! Мало кто осилит. В сети ходит краткий конспект страниц на 70, но и это много. Я написал для вас супер‑краткий конспект или инструкцию по чтению. Так что, если вы давно хотели прочесть Вигерса, но вас пугал объем — воспользуйтесь этой инструкцией, тут ровно то, что вам следует знать про разработку требований, без воды.

Страницы приведены по изданию БХВ, 3-е издание, на русском языке. Для уточнения смысла я иногда заглядывал в англоязычный оригинал.

Конспект супер‑циничный, имейте в виду!:) Итак, поехали, что вам нужно знать «из Вигерса»:

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

Меня зовут Сергей Громов, я работаю в IT уже 30 лет. Прошел путь от программиста на Assembler и преподавателя до ведущего системного аналитика.

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

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

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

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

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