Привет, Хабр! Меня зовут Иван Вербов, я UI/UX дизайнер команды разработки платформы контейнеризации dBrain.cloud. Эта статья адресована моим коллегам-юиксерам, а также всем, кого затрагивают задачи анализа, обсуждения и согласования предложений и результатов работы над дизайном.
Привет, Хабр ?! Меня зовут Александр, я занимаюсь разработкой ПО. В этом посте я расскажу про свой опыт, как желание улучшить свой рабочий процесс CI, помогло ускорить все golang пайплайны в PaaS в СберМаркета.
В данной статье обсудим создание REST-сервиса в “реактивном” исполнении. Приведу примеры кода на Kotlin в двух вариантах: Reactor и coroutines
Всем привет! Сегодня мы будем говорить о новых рисках в OWASP API Security Top 10, что плохого они нам обещают и что со всем этим можно сделать.
В 2023 году некоммерческая организация OWSAP обновила свой отчёт и выпустила новую версию 2023. По сравнению с 2023 годом, перечень рисков претерпел довольно сильные изменения, которые мы постарались представить в виде таблицы. Дополнительно, в таблице отмечено, какие из пунктов уже сейчас покрываются продуктами от «Выбмониторэкс», а какие будут закрыты в ближайшем будущем.
В мире современных технологий и инноваций роль аналитика становится все более важной и востребованной. Однако, каким образом можно развивать свои аналитические навыки и экспертизу, чтобы выделиться среди конкурентов и создать что-то уникальное?
Один из способов – ведение пет-проектов. В этой статье я затронул тему, как пет-проект может стать не только практичным инструментом для развития аналитических навыков, но и возможностью создания полезного продукта, способного удовлетворить потребности рынка.
А также расскажу о своем пет-проекте, который может стать таковым.
В этой статье, посвященной Python streaming с использованием Spark и Kafka мы рассмотрим основные шаги по настройке окружения и запуску первых простых программ
При разработке больших web-проектов нам часто приходится взаимодействовать с API сторонних или внутренних микросервисов. Когда количество таких взаимодействий растёт, настройки вызовов к другому API и подробности самих вызовов кратно множатся и могут растекаться по проекту.
В Домклике у нас микросервисная архитектура, и каждому сервису приходится взаимодействовать с десятком других. Чтобы межсервисное взаимодействие было предсказуемым, надёжным, удобным и отслеживаемым, мы следуем ряду практик при разработке, и в этой статье я расскажу вам о них.
Работаете с распределенными системами или только пытаетесь к ним подобраться? Проектировать такие системы с нуля бывает сложно и страшно: чтобы учесть все нюансы, нужен определенный багаж знаний.
На помощь приходит Reactive Manifesto — документ, который обобщил опыт целого ряда компаний по созданию распределенных систем. Манифест формулирует главные принципы, на которые стоит опираться на этапе проектирования и эксплуатации таких систем.
Меня зовут Андрей Василевский, я системный архитектор в Lamoda Tech. В этой статье я на примерах из своей работы покажу, как применять Reactive Manifesto на практике. Статья будет полезна тем, кто только начал изучать распределенные системы, хочет закрепить теорию или тем, кто хочет структурировать проектирование микросервисов в своей компании.
При росте нагрузки одна из частей системы может подтормаживать. Часто уязвимым местом оказывается база данных. Так произошло и в нашем случае.
Я работаю в Mindbox в команде, которая отвечает за выдачу товарных рекомендаций. Наша база периодически деградировала, заливать ее деньгами (скейлить) не хотелось, а кешировать запросы не позволяла специфика данных.
В этой статье расскажу про комплексное решение, к которому мы пришли — динамически ограничивать конкурентные запросы и менять лимит в зависимости от времени ответа базы.
Рассмотрим требования к безопасности информации в средствах контейнеризации, указанные в Выписке из Приказа ФСТЭК России № 118 «Требования по безопасности информации к средствам контейнеризации», приведем разъяснения к каждому требованию. Также в статье проанализируем техническую реализацию требований Приказа ФСТЭК России № 118 на примере ОС Astra Linux Special Edition и программные механизмы реализации в среде ОС.
По мотивам Adidas Running (ex. Runtastic)
Как я бы проектировал это интересное, но малоизвестное у нас приложение в роли архитектора.
Предыстория
Рынка систем электронных соревнований (в 2012 г) нет, но есть огромный интерес к спортивному образу жизни и к соревнованиям. В США не менее 50 миллионов (!) человек (это примерно 15% всего населения) хотя бы раз в неделю выходят на пробежку.
Адидас имеет объем продаж 20–30 млрд долл. в год.
Основной рынок – США, остальные страны – второстепенные рынки.
На последней кибербитве Standoff 12, которая проходила в ноябре 2023 года, впервые был представлен вымышленный финтех — Global Digital Bank, максимально автоматизированный, с облачными приложениями на основе микросервисов «под капотом». Задачей команд атаки (red team) было реализовать недопустимые события, в случае с финтехом — остановить работу банка, выкрасть базу данных клиентов, взломать новостной портал. Назначение PT Container Security — защитить контейнерные среды и помочь синим командам отследить действия атакующих. Что из этого получилось? Рассказываем!
Приветствую всех новичков и гуру фронтенда, а также всех, кто работает с интерфейсами. Я Никита Борцов, создаю красоту на фронте первой в России FinOps-платформы для управления облачными затратами “Инферит Клаудмастер”.
В этой статье вы узнаете о:
• факторах, сформировавших тренд на уход фронтенд-разработки от монолита к микрофронтенду,
• процессах со стороны команды разработки при переходе на микрофронтенд,
• кейсе платформы “Инферит Кладумастер”: почему для нашей команды микрофронтенд с плагином Module Federation стал полезным решением,
• признаках того, что пора переходить на микрофронтенд.
Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.
В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.
В первую очередь материал рассчитан на разработчиков, которым ещё не приходилось погружаться в тонкости работы с RabbitMQ или использовать его вообще. Более опытным читателям статья может пригодиться в качестве компактной и упорядоченной выжимки из уже знакомых статей, вебинаров и многочисленных страниц документации.
Привет, Хабр!
Nameko, как фреймворк для Python, предлагает удобные абстракции и инструменты для создания микросервисов, ориентированных на сообщения и события.
С Nameko можно получить не только инструмент для создания микросервисов, но и платформу для реализации распределенных систем с поддержкой Dependency Injection, позволяющей легко интегрировать различные компоненты приложения.
Как-то в конторе появилась мысль, что надо бы продумать как нам распараллелить работу над одни микриком, так чтобы команды не пересекались друг с другом. Есть некоторые API над которыми работают несколько команд. Каждая работает над своей фичей локально и пишет тесты, а вот при деплое на стэнд получается столпотворение потому, что нужно изменения слить в одну ветку аля develop и её закинуть на тест. При этом могут быть конфликты при мерже кода или измениться проперти, которые не совместимы между разными ветка.
Мобильный банк сейчас обслуживает 450+ микриков. Над которыми работают более 90 команд. Так как у нас в проекте нет code ownership, то каждая команда вносит изменения в нужные им микрики. Чтобы избежать различного рода сложностей, которые приводят к увеличению времени time to market, нужно было развести разработку отдельных команд так, чтобы они не влияли друг на друга и могли работать параллельно.
Мы работаем с ИТ-продуктами в сфере логистики и e-commerce. Большинство таких проектов крупные с точки зрения архитектуры – включают в себя множество сервисов, необходимых для исправной работы целостных систем.
Поговорим о том, как организовать взаимодействие микросервисов в большом продукте-долгожителе синхронно и асинхронно.
TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.
DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справиться (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.
? На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно ?
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.
Первым шагом dBrain.cloud на пути к построению кластеров большого объема стало разделение etcd. Далее мы взялись за controller-manager.
