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

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

Вся жизнь IT-команды в одной статье.

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

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

Статья подойдёт:

— Новичкам в IT — тем, кто только начинает разбираться в Agile и хочет увидеть реальные процессы «изнутри».
— Коллегам из других сфер — если ваш опыт работы отличается, здесь вы найдёте конкретные примеры и, возможно, идеи для своих проектов.
— Критикам и экспертам — если вы замечаете спорные моменты или хотите поделиться альтернативным подходом, добро пожаловать в комментарии!
— Моей команде — как напоминание о наших договорённостях и повод для дальнейшего улучшения процессов.

Это моя первая статья поэтому я буду рад вашим комментариям и ценным советам.

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

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

Привет, Хабр. Продолжаем изучение Istio и сегодня рассмотрим некоторые интересные особенности, которые в дальнейшем могут облегчить сопровождение и развитие сервисной mesh-инфраструктуры в Kubernetes. С ростом распределённых систем и микросервисных архитектур в Kubernetes всё чаще встаёт вопрос о построении надёжной, масштабируемой и безопасной сетевой инфраструктуры. Когда одного кластера становится недостаточно, возникает потребность объединить несколько инсталляций в единую mesh-сеть. Здесь и появляется Istio, как кандидат на реализацию мультикластерной архитектуры.

Команда Spring АйО перевела и адаптировала доклад Даниэля Гарнье-Муару “Spring Security Architecture Principles”, в котором на наглядных примерах рассказывается, как пользоваться возможностями Spring Security, не запутываясь на каждом шагу и не зарабатывая себе головную боль. 

Доклад публикуется тремя частями. В первой части было рассказано об основных подходах к созданию цепочек фильтров, а также разработан простейший фильтр. Во второй части мы расскажем об Authentication объектах и продемонстрируем, как разработать специализированный фильтр для обеспечения доступа программы-робота к основному приложению.

Когда начинают говорить о транзакциях в redis некоторым представляется в голове что‑то типа «postgresql»: «...Суть транзакции в том, что она объединяет последовательность действий в одну операцию „всё или ничего“. Промежуточные состояния внутри последовательности не видны другим транзакциям, и если что‑то помешает успешно завершить транзакцию, ни один из результатов этих действий не сохранится в базе данных...». Если говорить в ЭТОМ контексте, то транзакций в redis НЕТ и мы имеем дело с морской свинкой («не морская и не свинка»). А что же есть и как это можно мониторить.

Всем привет! На связи Максим Набоких, архитектор и технический руководитель Deckhouse Kubernetes Platform. Deckhouse работает в компаниях из разных отраслей: нефтегазовые предприятия, финтех, государственные организации, банки, облачные провайдеры и так далее. И больше чем в половине этих организаций во внутренней инфраструктуре нет интернета — он просто запрещён. Поэтому нам надо было придумать процесс установки своей платформы в закрытый контур.

О том, как устанавливать Kubernetes (Deckhouse использует ванильный K8s), где «не ступал» ни один пакет из публичной сети, я рассказал на HighLoad++ 2023. Эта статья — текстовая версия моего доклада. Мы разберём целевую схему закрытого контура, нюансы работы инструментов для создания безопасной среды, посмотрим, как готовить дистрибутив Kubernetes-платформы к установке и осуществлять доставку приложений в закрытых окружениях.

Если ваш сервис рассчитан на миллиарды пользователей, то несомненно возникнет вопрос о масштабировании.

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

В командах, особенно быстро растущих, конфликты — не редкость. И часто они возникают вовсе не из-за личных антипатий, а из-за размытой структуры полномочий.

Кажется, вот появился новый человек, чтобы помочь… но почему-то вместо облегчения становится только сложнее. Один руководитель — это порядок. Два — это борьба. Особенно если старый — «свой», а новый — новичок с инициативой.

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

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

К сожалению, в последнее время всё больше и больше людей советуют использовать JWT для управления пользовательскими сессиями в веб-приложениях. Это ужасная идея, и в этом посте я объясню, почему.

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

Это статья описывает опыт миграции традиционного приложения java spring на Spring reactor стек. О специфике разрабатываемой информационной системы, уже подробно рассказывал. Кратко о системе - смешанная сервисно-микросервисная архитектура. Чтобы получить бизнес результат, требуется вызвать микросервис, который вызывает сервис, который вызывает набор микросервисов для формирования ценностного набора данных. Получается цепочка вызовов. Сервисы и микросервисы разрабатывались на традиционном технологическом стеке, без использования реактивного подхода.

Мое знакомство с реактивным подходом произошло в 2022 году. Плюсы и минусы я осознавал, как мог. В рамках разрабатываемой системы мне было сложно найти ему точку применения. Тогда сложилось понимание, что в существующих рамках реактивный подход не даст возможности эволюционных изменений. Если его применять, то применять ко всему и сразу, как постулирует реактивный манифест.  Даешь революцию! Это было заблуждение. Его я не смог разрушить, даже изучая документацию и статьи. Чего-то релевантного моей ситуации в открытых источниках я найти не мог. Этой статьей постараюсь предложить путь и убедить сомневающихся, что долго раздумывать не стоит. Делайте смелый шаг на пути к реактивному стеку.

Привет, Хабр! На связи Андрей Чернов, Java‑архитектор в СберТехе. В прошлой своей статье я рассказал про особенности работы с секретами в Java‑сервисах на Spring Boot — где их брать и как применять к вашему сервису, на примере того, как мы делаем это в Platform V Sessions Data.

Работа с секретами в современных реалиях, где ни с чем не интегрированных сервисов почти не осталось, очень важна. Она помогает снизить риски утечек и атак, а значит, сохранить деньги, время и репутацию компании. Секретами могу быть, например, сертификаты и учётные данные (имя пользователя, пароль и т. п.).

Как я уже говорил, файлы с секретами по разным причинам меняются, поэтому сервису нужно вовремя реагировать на это и применять новые секреты. В своём сервисе Platform V Sessions Data мы решили применять обновления секретов прямо «на горячую», не останавливая, не перезапуская сервисы, и даже не снимая с них нагрузку. Мы называем это hot reload.

Привет! Я Вероника, фронтенд‑разработчик, работала в корпорации и была человеком-оркестром в стартапе. В стартапе я как раз задумалась над темой развития карьеры по двум стратегиям: хайповой — поднимать зарплату раз в год через собеседования, и консервативной — то самое «думать с позиции бизнеса».

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

В статье разберём, какие бенефиты и подводные камни вас ожидают в каждой из стратегий.

OnlyFans сегодня — это бизнес на $5.5B с 50% маржинальностью, который почти не тратится на маркетинг. Я вкратце расскажу про эволюцию порнографии за последние 40 лет, историю появления и причины успеха OnlyFans среди конкурентов, и сколько денег получают обычные девушки за свои откровенные фоточки. Важно: я не буду разбирать моральную сторону темы — сегодня мы будем использовать только сухие цифры и решения руководства, которые и создали феномен OnlyFans.

Аудитории Хабра наверняка интересно, какие вопросы задают на техинтервью в мультинациональных корпорациях. Ведь ИТ-индустрия была и остается глобальной, несмотря на геополитику и разные другие сложности. Как минимум, такая информация об интервью «из первых рук» — это ориентир по уровню сложности собеседования на позицию Java Lead в любых других компаниях, включая крупные российские банковские и промышленные структуры. Именно поэтому эта статья в нашем блоге SSP SOFT.