Привет!

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

Чем я могу помочь:

Услуги для компаний

• Построение эффективной внутренней разработки: найм и рост кросс-функциональных команд, формирование гибких процессов, культуры коммуникации между бизнесом/менеджером/владельцем продукта и разработчиками.
• Помощь в выборе стека технологий и стратегии его развития в рамках поставленных краткосрочных и долгосрочных целей.
• Аудит состояния разработки, технической документации и репозиториев кода на языках Python, Rust, Go, Ruby, Elixir.
• Внедрение аутентификации и авторизации на базе OpenID Connect и Keycloak.

Услуги для разработчиков и HR

• Мок-интервью разработчиков и тимлидов на языках Python, Rust, Go → получение обратной связи и рекомендаций по прохождению собеседований.
• Консультирование по вопросам релокации в Европу (в особенности в Германию): стоит ли переезжать, сложности и перспективы, с чего начать.

Некоторые кейсы

• Архитектура и разработка cloud-native платформы для распределенной генерации синтетических данных на основе privacy SDK для statice.ai (PWC) → новый продукт компании.
• Управление разработкой в стартапе food.ru внутри корпорации (X5 Retail Group): определил стек технологий → спроектировал масштабируемую архитектуру веб-платформы в разрезе сервисов (несколько млн.активных пользователей) → сформировал команды, процессы разработки и коммуникации в распределенных командах успешно выпустив MVP и последующие релизы.
• Консультирование fintech-компании из Германии (NDA) и взаимодействие с консалтингом из Швейцарии → интегрировал платформу оценки рисков в основной продукт, перевел сервисы на AWS.
• Разработка в Clark.de → разработал новый сервис в партнерстве с N26.com → компания получила рост пользовательской базы на несколько тысяч новых клиентов.
• CTO в Payler → помог компании открыть офис разработки и вырасти в разы → прошел сертификацию PCI DSS с продуктом → запустил платежный шлюз маленькой командой → продукт стал приносить прибыль и выходить на самоокупаемость.

Слова для привлечения внимания

• Python
• FastAPI
• SQLAlchemy
• Pydantic
• Celery
• Rust
• PostgreSQL
• Apache Kafka
• Keycloak
• Kubernetes
• Google Cloud Platform
• AWS
• Web 3
• Smart Contracts
• DeFi

В любом современном проекте, где появляется необходимость обрабатывать какие-то события (поток сообщений или данных), в качестве инфраструктурного решения разработчики практически сразу предлагают Apache Kafka®. В моей практике довольно редко встречались команды, которые взвешенно подходили к сравнению брокеров сообщений и event-streaming платформ. Там, где можно было обойтись ActiveMQ или RabbitMQ, тащили сразу кластер Apache Kafka® и дальше мучались с поддержкой кластера или его отдельных компонент (привет, ZooKeeper!).

Но сейчас не об этом. Допустим, вы обдуманно пришли к выбору Apache Kafka® или же ваша централизованная инфраструктура не оставила вам выбора. На какие вопросы стоит ответить перед тем, как начать писать продюсеры, консьюмеры и настраивать какие-то параметры кластера? Мой наивный чеклист ниже:

1. Объем данных, который планируется “генерировать” продьюсерами → хватит ли вашего сетевого канала для всей системы и ее критичных компонент.
2. Как долго вам необходимо хранить данные (Data Retention Policy) → бизнес-требования + стоимость (см. в том числе пункт 1) + комплаенс.
3. Нужны ли гарантии после отправки сообщения (acks) → баланс между временем ожидания (latency) и надежностью в рамках репликации (durability).
4. Гарантия доставки → насколько критично для нашей бизнес задачи потеря или дублирование сообщений, важна ли идемпотентность / транзакционность.
5. Какая стратегия партиционирования планируется использоваться продьюсерами — подходит ли стратегия по умолчанию.
6. Для выбранного топика важно ли нам хранить весь лог сообщений или достаточно последних изменений → см. Compacted Topics.
7. Потребуется ли консьюмер-группа для ваших топиков / как вы планируете масштабировать консьюмеры и их пропускную способность / что будет в случае ребаласировки группы.

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

Сон — это мегаважно. Не только его количество, но и качество. Если по количеству, все плюс-минус понятно — спи себе минимум 8 часов, то на качество влияет довольно много факторов. Один из них — ваша подушка и положение во сне.

Общие советы:

• Простая пухо-перьевая подушка, не сентипоновая
• Размер 50x70, т. е. не квадратная
• Наволочка не должна стискивать подушку
• Для ребенка подушка должна быть мягкой и тонкой — больше пуха или всего 30% пера
• Спать на спине или на боку, не на животе, чтобы не выкручивать шею
• Лежа на боку плечо не должно лежать на подушке — подушка под шеей (как валик), рука на плече
• Лежа на спине, подушка должна образовывать валик в области шеи
• Ортопедическая подушка пригодна только для сна на боку
• Подушка должна проветриваться/сохнуть, а не лежать постоянно накрытой

Один из способов подключить к Keycloak провайдер существующих пользователей — механизм, который называется User Federation. Он позволяет используя Kerberos или LDAP синхронизировать учетные записи из корпоративного хранилища. Если пользователей в хранилище много, и оргструктура организации предполагает вложенность, то это может усложнить получение подмножества учетных записей.

Так, например, в Active Directory используются следующие сущности:

• CN = Common Name
• OU = Organizational Unit
• DC = Domain Component

Документация по LDAP с расшифровкой аббревиатур есть на сайте Microsoft.

В настройках LDAP провайдера необходимо указать User DN. Самый простой вариант — когда все учетные записи разложены по организационным единицам:

OU=Main,DC=Orgname,DC=ru

В этом случае Keycloak с легкостью найдет все учетные записи в юните, даже если внутри него есть какая-то вложенная структура. Для этого, правда, придется включить дополнительный параметр Search Scope: Subtree.

Но что делать если администраторы AD вместо создания OU сущностей добавляют нужных вам пользователей в CN? Другого способа, как дополнить описанное выше решение дополнительным фильтром для LDAP, я не нашел. В настройке Custom User LDAP Filter можно прописать все CN группы через оператор или |:

(&(objectCategory=Person)(sAMAccountName=*)(|(memberOf=CN=CMS_EDITOR,OU=Security,OU=Groups,OU=Central,OU=Main,DC=Orgname,DC=ru)))

В примеры указана только одна группа CMS_EDITOR.

В нескольких рабочих проектах я использую в качестве сервиса аутентификации Keycloak. Проект спонсируется компанией RedHat, активно развивается и адаптирован для cloud-native окружения. Хотя документация у Keycloak достаточная для основных пользовательских сценариев, иногда ее не хватает для решения специфичных вопросов. Последнее с чем я столкнулся — подключение Active Directory как User Federation через протокол LDAPS (LDAP over SSL).

Как и полагается внутренним корпоративным сервисам, наш сервер LDAPS предоставляет самоподписанный сертификат. Keycloak в этом случае для успешного соединения с ldaps://ldap.orgname.com:636 требует, чтобы сертификат находился в truststore. Вариантов конфигурирования несколько:

1. глобальный cacerts ОС, в которой запускается сервис
2. cacerts из каталога установленного JDK
3. системное свойство javax.net.ssl.trustStore для JVM
4. truststore в каталоге Keycloak

Если вам необходимо просто добавить самоподписанный сертификат или root.crt, то самым простым способом будет добавление его в источники на уровне ОС и обновление списка доверенных сертификатов. Тогда вам не придется каждый раз искать где находиться JDK в системе, переписывать startup-скрипты сервиса или заботиться о безопасной работе с паролями для своего truststore.

Для разворачивания в Kubernetes или OpenShift можно собрать образ следующим способом:

FROM jboss/keycloak:13.0.0

USER root

ARG CERT="root.crt"

COPY $CERT /etc/pki/ca-trust/source/anchors/
RUN update-ca-trust

USER 1000

Убедиться, что сертификат был добавлен в список доверенных:

$ cd /etc/pki/ca-trust/extracted/java
$ keytool -list -keystore cacerts

Your keystore contains 137 entries. В оригинальном образе их 136.