Deployment и DeploymentConfig — это, казалось бы, похожие объекты API для OpenShift Container Platform. Но на самом деле они предлагают разные гибкие методы управления интерфейсом пользователей. Расскажем о различиях и приведём примеры, когда какие объекты лучше использовать.

Логирование — это один из трех столпов мониторинга в распределенных системах. Мы можем видеть бурное развитие популярных продуктов с открытым исходным кодом типа ELK stack, и полноценных коммерческих продуктов, которые помогают с проблемами протоколирования в больших масштабах — Splunk, к примеру. Однако в таких сложных системах как Kubernetes протоколирование остается сложной проблемой. Она усугубляется постоянным ростом объема данных из–за всё большего внедрения контейнеризации.  

В этой статье мы рассмотрим различные виды логов Kubernetes, необходимых для улучшения системы мониторинга, уделим внимание подходам к сбору, агрегации и анализу логов. Также мы приведем решение с использованием open source-сервисов Fluentd и Fluent Bit — оно упростит сбор данных.

Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?

При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.

Хабр, привет!
Нас зовут Дмитрий Фролов и Владимир Мясников.Мы стандартизировали подход по документированию внутренних систем в команде интеграционного тестирования Мир Plat.Form с помощью «Модели С4».

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

Давайте разберемся, что такое «Модель С4» и какие задачи она помогает решать. С чего начать, если вам поступила задача задокументировать «большую» систему – читайте под катом.

Мониторинг очень важен для современных приложений, современные приложения по своей природе сильно распределены и имеют разные зависимости, такие как база данных, службы, кеширование и многое другое. Поэтому все более важны отслеживание и мониторинг этих служб, чтобы приложение придерживалось условий SLA ( Service Level Agreement). SLA — это соглашение между клиентом и поставщиком услуг, в нем учитываются надежность, скорость отклика и другие показатели уровня обслуживания.

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

Зачем это вообще может понадобиться?

1. Контроль доступа к файлам средствами nginx — актуально для концепции IaC (инфраструктура как код). Все изменения, связанные с доступом, будут вноситься только в конфигах, которые лежат в проекте.
2. Если отдавать файлы через свой nginx, появляется возможность их кэшировать и сэкономить тем самым на запросах к S3.
3. Подобный прокси поможет абстрагироваться от типа хранилища файлов для разных инсталляций приложения (ведь помимо S3 существуют и другие решения).

Продолжаем беседовать с разработчиками экосистемы сервисов Serverless. В прошлый раз Глеб Борисов рассказал о возможностях и перспективах функций в Yandex.Cloud, сегодня Данил Ошеров погрузит нас в мир бессерверных систем и сервис Object Storage.

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

Со временем такие системы перестали быть актуальными, они ушли на второй план, а на смену пришли новые, построенные по протоколу S3. Почему так случилось? Почему S3 стал «главным» протоколом для синхронизации данных? 

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

Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.

Мониторинг сегодня – фактически обязательная «часть программы» для компаний любых размеров. В данной статье мы попробуем разобраться в многообразии программного обеспечения для мониторинга и рассмотрим подробнее одно из популярных решений – систему на основе Prometheus и Grafana

Обратите внимание, что данная статья подходит только для версии Directum RX ниже 4.1. Не используйте эту статью для более новых версий Directum RX. Информация и рекомендации, приведенные в этой статье, предоставлена только для ознакомительных целей и не может служить заменой профессиональных консультации Службы поддержки DIRECTUM.

• высокой скорости работы, т.к. все данные хранятся в оперативной памяти;
• кроссплатформенности;
• распространению по BSD лицензии (относится к СПО).

Недавно я осознал нехватку вводных обучающих материалов о современной сетевой балансировке и проксировании. Я подумал: «Почему так? Балансировка нагрузки — одна из ключевых концепций для построения надёжных распределённых систем. Ведь должна быть доступна качественная информация об этом?» Я поискал и обнаружил, что информации мало. Статьи в Википедии о балансировке и прокси-серверах содержат обзоры некоторых концепций, но не могут похвастаться последовательным описанием предмета, особенно в том, что касается современных микросервисных архитектур. Поиск в Google информации о балансировке в основном возвращает сайты вендоров, заполненные модными терминами и скупые на подробности.

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

Базы данных (БД) существуют с первых дней программирования, а появились они ещё раньше. Это — неотъемлемые части любых приложений. Хорошо спроектированная БД — это один из важнейших компонентов, влияющих на производительность программных проектов. Из-за этого множество архитекторов программных решений исследовали массу подходов к управлению данными, пытаясь выяснить то, какие из этих подходов работоспособны в определённых сценариях, а какие — нет. Выбор подходящей архитектуры БД обычно сводится к выбору между SQL и NoSQL, между реляционными и нереляционными базами данных. А иногда в одном проекте используют и то, и другое.

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

Apache Cassandra - это распределенная NoSQL база данных. В этой статье будут описаны основные механизмы передачи, репликации и поддержания согласованности данных внутри сети.

Я не очень понимаю, почему об этом мало кто рассказывает.

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

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

Думаю, вы и сами представляете, как оно происходит в банках. Именно поэтому многие разработчики <sarcasm>так стремятся</sarcasm> в них работать.

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

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

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