Мартышка и АйТи: Парадокс сложной эффективности
Вы когда-нибудь задумывались, почему в IT всё циклично? Почему старые методы и технологии, которые когда-то были на пике популярности, возвращаются на сцену?
Давайте разберёмся, что такое Парадокс сложной эффективности на простом примере, а также посмотрим, как это работает в IT последние 30 лет.
Привет, Хабр! Я Артем, тимлид продуктовой команды. Я управляю кросс-функциональной командой, проектирую архитектуру и отвечаю за интеграции корпоративного приложения.
Сегодня расскажу, как мы выбирали архитектуру, чтобы быстро релизить, несмотря ни на что. Вы узнаете, как красиво интегрировать разные legacy-бэкенды без толпы разработчиков на проекте, и как продолжать доставлять важный функционал до пользователей, даже если вас удаляют из сторов.
Обсудим плюсы и минусы нативной и кросс-платформенной разработки и подробно разберём WebView, его преимущества и подводные камни.
FastStream - это относительно новая блестящая игрушка в руках Python'истов, которая создана специально для работы с брокерами сообщений.
В Python сложилось устойчивое убеждение, что если мы работаем с MQ - то нам нужен Celery, но он слегка устарел. Именно поэтому люди пытаются выкинуть "деда" и затащить вместо него любой новый многообещающий MQ-инструмент. Кроме того, культ Celery настолько силен в умах, что практически все новые библиотеки для работы с MQ пытаются стать его "убийцей" и заменой.
Однако, это не совсем верно. Существует огромный пласт проектов, которым нужен не фреймворк для менеджмента задач, а просто "голый" функционал Kafka/RabbitMQ/NATS/whatever для межсервисного взаимодействия. И все эти проекты вынуждены довольствоваться "сырыми" python-клиентами к своим брокерам, а всю обвязку вокруг этих клиентов писать самостоятельно. FastStream целится как раз в эту нишу.
В рамках статьи я хочу убедить вас, что не Celery мы едины, и для альтернативных инструментов найдется место под солнцем. А также рассмотрим фичи FastStream, которые он привносит в застоявшийся мир MQ-инструментов.
Статья родилась, как водится, из рабочей задачи — нужно было внедрить аудит-логирование в некоторые микросервисы на Java и Spring.
Всем привет. Меня зовут Нияз Кашапов, я AppSec Lead в СберМаркете. Улучшаю процессы безопасной разработки уже более 5 лет. Начинал карьеру в финтехе, где занимался безопасностью кода, фич и бизнес-процессов в онлайн-банкинге. А сейчас продолжаю начатое в одном из самых быстрорастущих игроков на рынке e-com.
Думаю, у многих в практике встречалась уязвимость, которую просто так не пофиксить — ведь она заложена глубоко внутри разрабатываемого решения, обвешана кучей зависимостей и требует полного ребилда самого решения. Чаще всего такие уязвимости остаются в проде навсегда и удерживаются от «падения» множеством костылей. Возникает резонный вопрос: «Как они возникли?» Чаще всего ответ — «Так исторически сложилось», а истоки проблемы давно забыты. Боролься с таким лучше превентивно, а как это сделать — попробую рассказать в этой статье.
Поговорим о том, как избегать ситуаций, когда уязвимость заложена на уровне архитектуры или бизнес-процесса и её исправление может стоить множество человеко-часов. Разберемся, когда фича становится багом и как прорабатывать архитектуру сервисов, не создавая дыры безопасности.
В России наблюдается интерес к комплексным системам автоматизации строительства, но их внедрение — долгий и сложный процесс. Поэтому чаще застройщики предпочитают точечные решения. Появился спрос на специализированные нейросетевые микросервисы для подключения к готовым системам заказчика.
Мы отметили эту тенденцию после одного примечательного проекта по мониторингу процесса строительства. Фактически сначала нас попросили сделать «то, не знаю что», причем в очень сжатые сроки. Ситуация могла обернуться провалом, но мы справились и нашли новую перспективную нишу для разработки новых продуктов. Сейчас расскажу, как это было.
Привет, Хабр! Меня зовут Сергей, я техлид в команде PT BlackBox. Мы с коллегами разрабатываем продукт, который позволяет обнаруживать уязвимости в приложениях методом черного ящика. Фактически мы сами и пишем веб-приложения, и именно о них пойдет речь в статье.
Я бы хотел с вами поделиться своими наработками по теме бэкенд-приложений и предоставить вам шаблон-прототип, который, как мне кажется, может закрыть подавляющее большинство потребностей при их разработке.
Для написания прототипа я буду использовать Litestar, FastStream и dishka. Эта статья будет особенно полезна тем, кто пишет на Tornado, Django, Flask или AIOHTTP и хочет перейти на более актуальные технологии для дальнейшего развития своих проектов на современных рельсах.
В процессе изучения Symfony Messenger мной было создано два самодостаточных примера, демонстрирующих его работу (описаны в отдельных статьях).
В каждом из этих учебных примеров в качестве транспорта сообщений для простоты была выбрана БД SQLite.
Готовой реализации транспорта именно для SQLite я не нашёл и пришлось её использовать через DBAL Doctrine.
И всё бы ничего, но внутренний перфекционист :-) нашёптывал, что использование целой Доктрины лишь для того, чтобы работать с одной-единственной таблицей с очередями сообщений — это явный перебор…
Бороться с затерроризировавшим меня внутренним перфекционистом ;-) я не стал и, решив поглубже разобраться с устройством транспорта сообщений в Symfony Messenger, создал такой транспорт для SQLite сам, с использованием PDO.
А заодно потестировал производительность самопального решения и решения на Doctrine (на HDD и на RAM drive).
Проверка юридических документов с помощью визуальных помощников может оказаться важной задачей. Если человек способен хранить в голове одновременно в зоне его мозговых вычислений 6-8 параметров, ну может и больше, если гений... А остальные держать в блокноте. То ИИ учитывает больше параметров, те же модели LLM доступны с количеством 70 миллиардов параметров. То есть мы-то тоже ежедневно принимаем решения на основе большого количества входных параметров: купить ли сегодня эту вещь, поехать ли отдыхать на море, бросив все, доехать на такси или на автобусе. Но учитываем не все сразу, хотя что-то учитывается на подсознательном уровне. Эдакое дело вкуса, когда просто чувствуешь, что так правильнее, и в итоге не прогадал.
Правда люди еще не научились влиять на решения сети. У нейросетей особенные вкусы. Если GAN-сеть создает нам девушку, у которой 2 руки, то для каких-нибудь художников эпохи Сюрреализма это могло бы показаться гениальным. Двумя руками обнимает парня, словно вцепилась в него всей душой и влюбилась всем сердцем... К сожалению или к счастью, в задачах создания юридических документов мало необходимости творить что-либо на уровне латентного вектора в цепочке между кодировщиком и декодировщиком. Но работа с юридическими документами – тот самый скоп задач, где важно найти судебную практику, предшествующие документы и просто оформить все примерно также.
Таким образом, работа с юридическими документами – лакомый кусочек уже лет так 5, особенно на зарубежном рынке, где задача автоматизации рутинной деятельности сводится именно к тому, чтобы из исторически предшествующих документов собрать что-то стоящее, применимое к текущему документу. По семантическому окрасу и истории работы с документом можно понимать, что именно перед тобой: проигрышная трактовка, выигрышная трактовка, доводы, играющие в пользу истца или аргументы, помогающие ответчику, если дело идет о судебных исках.
Введение
В наше время, с развитием бизнеса и увеличением объемов автоматизации и бизнес-процессов, эффективная автоматизация некоторых таких бизнес-процессов становится ключевым фактором успеха для многих компаний. Наша компания не является исключением. По мере роста и развития нашего бизнеса наша CRM-система столкнулась с проблемами медленной работы и увеличения блокировок в базе. Увеличившееся количество бизнес-процессов и интеграций привело к сильной загрузке системы, что начало вызывать блокировки в базе данных и временные остановки процессов внутри компании – ситуация, которую нельзя оставить без изменений.
Мы поняли, что для продолжения успешной работы нам необходимо решение, способное справиться с ежедневной нагрузкой, интегрировать новые сервисы и обрабатывать сложные процессы без задержек. Таким образом, мы столкнулись с вопросами: как избавиться от проблем блокировки, как оптимизировать интеграции и как эффективно обрабатывать сложные запросы, не загружая при этом базу данных.
В результате наших размышлений мы приняли решение разделить нашу CRM-систему на микросервисы. В этой статье я хотел бы поделиться с вами нашим опытом разгрузки CRM-системы и показать, какими путями мы шли для решения выше поставленных вопросов.
Самое начало
Изначально наша CRM-система была загружена не сильно. Было несколько бизнес-процессов, которые в основном отвечали за обновление суммы счета при изменении товара в нем. Все эти процессы были реализованы с использованием триггеров, поскольку наша система, к сожалению, не предоставляла других возможностей. Однако со временем количество таких бизнес-процессов, реализованных на триггерах, стало увеличиваться.
Недавно мной был создан самодостаточный пример совместной работы компонентов Symfony Messenger и Symfony Console, подробно описанный в статье https://habr.com/ru/articles/817425/.
Для демонстрации работы этого примера нужно вручную запустить несколько консолей (терминалов), а потом в каждой вручную запустить Worker.
Мой внутренний перфекционист :-) сильно против этого возражал и говорил «а вот бы все эти консоли-терминалы запускались одной командой, в нужном количестве, сразу с Worker’ами, а если какой Worker упадёт, то заново запускались в нужном количестве».
Возражать своему внутреннему перфекционисту я не стал и создал ещё один пример работы Symfony Messenger, который запускается Worker’ами из PHP фреймворка Workerman. При этом Symfony Console вообще не используется.
Привет, Хабр! Меня зовут Александр Митин, я работаю в Т1 на проектах одного крупного банка. Занимаюсь развитием продкутовых сервисов компании (проект по обслуживанию и проведению ЧДП/ПДП клиентов). Опыт разработки 13 лет, последние 5 лет — в финтехе.
Сегодня микросервисная архитектура используется во многих проектах. Зачастую в таких системах применяют журналирование, авторизацию и прочие служебные сервисы, общие для всех приложений. А при разработке возникает огромное желание не дублировать одну и ту же логику, а вынести её в отдельную библиотеку, тем самым переиспользовав код. Что мы имеем в итоге? В лучшем случае одну библиотеку «common», которая разрастается до огромных размеров и становится ядром распределённого монолита. В дальнейшем новые версии этой библиотеки теряют обратную совместимость, а каждое её обновление в проектах сильно осложняет поддержку. Более того, становится невозможным разобраться, где и какие классы используются, что делает архитектуру хрупкой и уязвимой.
Привет, Хаброжители!
Пришёл и мой черёд асинхронно и многопоточно средствами PHP кое-что пообрабатывать… И я, естественно, вспомнил про компонент Messenger фреймворка Symfony.
Ранее я никогда Symfony Messenger не использовал.
Чтобы понять, как с ним работать, я пытался найти какой-то простой, законченный и самодостаточный пример, понятный даже чайнику, но мне это не удалось...
Всё, что находилось, было либо слишком сложным, либо это были какие-то отдельные куски кода, понятные только тем, кто уже работал с Symfony Messenger. К тому же всё, что находилось, в основном было "заточено" либо под Redis, либо под RabbitMQ. установка которых как-то немного перебор для учебного примера…
В-общем, я создал и выложил на GitHub такой простой, законченный и самодостаточный пример работы Symfony Messenger совместно с Symfony Console.
Привет Хабр!
Меня зовут Алексей Пушкарёв, я – архитектор продуктовых решений компании ELMA. Наша команда разрабатывает одноименную Low-code платформу. В этой статье я расскажу, почему мы выбрали микросервисную архитектуру для Low-code системы вместо классической монолитной, которой до этого занимались много лет. Поясню, почему использовали именно такие технологии и решения, с какими недостатками сами столкнулись. Поговорим, как такая архитектура сказалась на Low-code разработчиках.
Для кого эта статья? Для архитекторов, аналитиков, внедренцев и тимлидов и всех тех, кому интересна тема Low-code. Мне кажется, что в публичном пространстве мало информации об архитектуре таких решений и применяемых технологиях. Для многих они до сих пор остаются черным ящиком, что нередко приводит к обманутым ожиданиям, и в целом недоверию к Low-code как к технологии. Хочу показать, что находится под капотом у таких систем на примере платформы, которую сами разрабатываем.
Добро пожаловать под кат!
Всем привет!
Меня зовут Сергей Максимов и я руковожу разработкой в Центре Управления Процессами (ЦУП) Московской Биржи. В статье я хочу рассказать о нашем опыте автоматизации бизнес-процессов (БП), когда система должна быть не только удобной бизнес-пользователям снаружи, но и надежной внутри.
Бизнес Биржи, с одной стороны, похож на обычный банковский финтех, но имеет ряд важных особенностей. Чтобы лучше представить специфику нашей работы, я приведу метафору. Представьте, что каждое утро с вашего корпоративного космодрома в космос отправляется ракета. В течение дня космический корабль автономно выполняет работу на орбите, а вечером возвращается на базу. В полёте связь с кораблем очень ограничена и успех его полёта на 99% определяется качественной подготовкой. Всё должно отработать точно и в срок. Досрочный спуск корабля с орбиты технически возможен, но влечет за собой огромные репутационные потери с отчетом регулятору и новостями в федеральных СМИ.
Продолжаем рецензии на книги по ИТ‑тематике с промокодом от нашего блога. Сегодня это перевод известной книги «Building Micro‑Frontends» O'REILLY по микросервисам, вышедший в издательстве БХВ‑Петербург весной 2024г. Книга рассчитана на широкий круг веб‑разработчиков, архитекторов и руководителей команд, работающих с веб‑приложениями. А в целом, полезна всем, кто столкнулся с проблемами масштабируемости, параллельной разработки и организации кодовой базы при создании сложных фронтенд‑приложений.
install, докер-образами, Yandex Cloud-образом и DEB-пакетами;