Привет, самое хардовое IT комьюнити Рунета, я Саша, главный архитектор в компании Quadcode. Мы пришли на Хабр для того, чтобы показать “кухню” Fintech - варимся мы во всем этом много лет, поэтому уже можем поделиться опытом. В блоге будем рассказывать об архитектурах, технологиях, инструментах и лайфхаках - то, что может пригодиться и вам. 

Этот пост - первый в списке, его можно считать знакомством. Под катом я расскажу про структуру нашей команды, про продукты Quadcode – это платформа для трейдинга, банкинг и внутренние разработки, а также про наши первые шаги на пути к IPO.  

Наша команда

Команда Quadcode уже 8 лет работает в финтехе. Цель компании - создавать удобные финтех-инструменты для B2B клиентов со всего мира.

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

Во главе каждой команды стоит Team Lead. Сами команды сгруппированы в отделы работающие над определенными предметными областями. Например, есть отдел Finance Development, в котором команды разрабатывают финансовые сервисы для платформы. Есть ветка, где располагаются владельцы продукта (product owners), задача которых развивать и улучшать наши продукты. Сейчас у нас в разработке 230+ опытных (реально опытных, у каждого много лет практики) специалистов. Это порядка 24 команд и 6 Product Owners. Джуниоров мы берем редко. Но с каждым годом искать опытных специалистов становится все сложнее, так что все больше в эту сторону смотрим, но тут нужно все грамотно подготовить.

Пролог

- Глянь, статью на Хабр подготовил.
- Эм... а почему заголовок на английском?
- "Предметно-ориентированное проектирование, Гексагональная архитектура портов и адаптеров, Внедрение зависимостей и Пайто..."

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

--

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

Kubernetes - это движок оркестрации контейнеров с открытым исходным кодом для автоматического развертывания, масштабирования и управления контейнеризированными приложениями. Под (Pod) – это базовое понятие при проектировании приложений в Kubernetes. Kubernetes оперирует подами, а не контейнерами, при этом поды включают в себя контейнеры. Под может содержать в себе описания одного или нескольких контейнеров, монтируемых разделов, IP-адресов и настроек того, как контейнеры должны работать внутри пода.

Под, содержащий один контейнер, относится к одно-контейнерным подам и это самый распространенный вариант их использования в Kubernetes. Под, который содержит несколько связанных контейнеров, относится к мульти-контейнерным подам. Есть несколько паттернов для мульти-контейнерных подов и один из них — это паттерн sidecar. В этом посте мы на примере проекта детально рассмотрим этот паттерн.

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

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

За пять предыдущих лет человечеством было произведено информации больше, чем за всю предшествующую историю (из них половина была произведена в нашем отделе УНП). 

Проблематика

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

Мы занимались разработкой именно такой системы, и сегодня речь пойдет о новой версии реализации системы, которую мы разработали совместно со Skirgus.

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

 Специально для статьи я подготовил два идентичных примера на Flask и Dash и выложил их на GitHub. В них иллюстрируется расчет и вывод показателей юнит-экономики абстрактного IT-маркета, который называется Хабр (а почему бы и нет, ведь сейчас все компании начали заниматься электронной коммерцией:).

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

Бессерверные вычисления (или serverless-технологии, как их иногда называют) — это перспективная технологическая модель облачных вычислений, появившаяся на горизонте прикладной разработки и архитектуры в последние годы. Именно благодаря стремлению воспользоваться огромным потенциалом бессерверных фреймворков многие крупные рыночные игроки оказались увлечены общим бумом облачных сервисов. Такие гиганты программной отрасли, как Google, Microsoft, IBM и Amazon, уже предлагают своим клиентам перенести локальные бизнес-процессы и обеспечить операционную эффективность на флагманских бессерверных платформах, таких как AWS Lambda и Azure Functions.

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

Более того, выбор бессерверных сервисов позволяет оптимизировать процессы разработки приложений и таким образом повысить результативность других практик по оптимизации бизнес-процессов, включая DevOps и Agile.

Привет, меня зовут Геннадий, я работаю в Ozon, занимаюсь разработкой backend-сервисов.

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

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

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

Фото Brian McGowan, Unsplash.com

Мы использовали Istio в продакшене почти два года, но больше не хотим. Я расскажу, чем мы недовольны и как выбрали другую service mesh.

В статье будет показано как создать gRPC сервер и клиент на Rust. Для большей наглядности клиент будет также Telegram ботом. В итоге будет получена следующая архитектура:

Статья является не всеобъемлющим руководством по gRPC в Rust, а скорее практическим гайдом, демонстрирующим основы и как создать приложение на основе gRPC.

Первая ассоциация, которая приходит при упоминании serverless-решений это облачные решения вроде AWS Lambda, Azure Functions или Google Functions, а на российском рынке Yandex Cloud Functions. У них имеются определенные бесплатные лимиты и это подкупает. В случаях когда вы уже используете в работе K8s, смысла выносить отдельные части вашего приложения за кластер нет. Если вам интересно познакомиться с возможностями использования функций, с вариантами serverless решений на Bare-metal Kubernetes, а также узнать, как и где можно развернуть свое PoC решение бесплатно на облачной виртуальной машине, то приглашаю под кат.

Вы больше не можете создать сервер авторизации с помощью @EnableAuthorizationServer, потому что Spring Security OAuth задеприкейтили, а проект Spring Authorization Server всё ещё экспериментальный? Выход есть! Напишем авторизацию своими руками... Что?.. Нет?.. Не хочется? И вообще получаются какие-то костыли и велосипеды? Ну ладно, тогда давайте возьмём уже что-то готовое. Например, Keycloak.

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

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

Итак, овсянка, сэр.

Статья об одном неудачном решении, которое распространено при переходе на микросервисы. Несмотря на то, что Microsoft и другие компании в своих руководствах рассматривают возможность создавать Entity Services, есть все основания считать его антипаттерном. Далее мы поговорим о том, что такое Entity Service и какими свойствами он обладает для конечной системы в целом.

Не писал на Хабре еще о том, как я пришел к мысли формирования компонентов для своих будущих проектов или текущий вместо прямого написания кода. Если очень коротко сказать про это, то было все примерно так... Много писал разных проектов, придумывал псевдо компоненты и каждый раз натыкался на то, что в одном проекте ужасно удобно это использовать, а в другом ужасно не удобно. Попробовал перенести "удобные" компоненты в проект и стало все еще более не удобно... Короче, руки не из того места, голова слишком амбициозная... Со временем я дошел до другой мысли: "Надо делать репозитории на GitHub с отдельными компонентами, которые не будут иметь зависимость от других компонентов"... Все шло хорошо, но дошел я до того самого компонента, которые хочет работать с другим компонентом... В итоге на помощь пришли интерфейсы с методами. И вот теперь поговорим о компоненте SQL миграций в том ключе, как я его вижу.

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

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

Цель этой статьи — показать как мы можем сконфигурировать два и более контейнеров, чтобы они могли взаимодействовать друг с другом. В этой статье мы сделаем следующее:

Создадим образ Docker используя простой веб-сервис с использованием Python и Flask.

Запустим два отдельных контейнера

Создадим сеть в Docker

Объединим контейнеры используя созданную сеть

Для кого предназначена эта статья?

Всем привет! За последние пять лет мы достаточно часто сталкивались с запросами на мониторинг Java приложений. Собрав основные моменты по мониторингу Java, мы решили написать данный пост.

Сегодня мы с вами рассмотрим, что такое Full Stack мониторинг и чем он отличается от привычного “уху” понятию мониторинга, нюансы Full Stack мониторинга для Java и сложности мониторинга микросервисных приложений на Java. Расскажем, как мы реализуем Full Stack мониторинг с помощью OpenSource стандартов и платной платформы. 

Давайте определимся, что мы называем Full Stack мониторингом?

Full stack мониторинг – это подход в мониторинге производительности приложений, который подразумевает под собой мониторинг всего стека, что включает в себя:

Мониторинг приложений – сбор метрик приложения, сбор трейсов транзакций, обеспечение видимости на уровне кода и т.д.

Мониторинг инфраструктуры – метрики хостов, процессов, контейнеров и т.д.

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