#интеграция #архитектура
Все, хватит салатов, просыпаемся.
Детальный разбор реализации Transactional Outbox, когда у тебя постгря с кафкой. Варианты реализации, проблемы, инструменты - просто и понятно. Отдельно можно скачать презу.
Здесь можно подробнее почитать, зачем нужны все эти аутбоксы, и что это такое.
Все, хватит салатов, просыпаемся.
Детальный разбор реализации Transactional Outbox, когда у тебя постгря с кафкой. Варианты реализации, проблемы, инструменты - просто и понятно. Отдельно можно скачать презу.
Здесь можно подробнее почитать, зачем нужны все эти аутбоксы, и что это такое.
✍11👍4🔥1
#интеграция
Ничего мы вам не гарантировали
Меня умиляют истории, как кто-то в очередной раз сделал надежную exactly once доставку с помощью XXX и YYY. Обычно это либо оголтелый маркетинг, либо техническая наивность.
Существует ровно двагендера гарантии доставки:
• at most once
• at least once
Все, третьего не дано.
Вы не реализуете exactly once доставку, потому что это фундаментальное ограничение мира, такое же как вечный двигатель или перемещение материи свыше скорости света. За доказательством рекомендую обратиться к задаче двух генералов - она во многих задачах IT проявляется, пусть и неявно.
Тогда что такое exactly once?
Это гарантия обработки. Если говорить просто, то это at least once доставка, где каждое взаимодействие обвешано ретраями и идемпотентностью. Единственный способ обработать сообщение строго один раз - это любой ценой донести его до получателя, а потом уже отсеять дубликаты.
Потому нам нужны transactional in/out-boxы - чтобы корректно донести сообщение до брокера, и строго один раз обработать его на консьюмере. И все это поверх at least once гарантии доставки.
Про аутбоксы можно почитать тут.
А здесь хардкорно про устройство брокеров, и как устроена запись-чтение сообщений.
Ничего мы вам не гарантировали
Меня умиляют истории, как кто-то в очередной раз сделал надежную exactly once доставку с помощью XXX и YYY. Обычно это либо оголтелый маркетинг, либо техническая наивность.
Существует ровно два
• at most once
• at least once
Все, третьего не дано.
Вы не реализуете exactly once доставку, потому что это фундаментальное ограничение мира, такое же как вечный двигатель или перемещение материи свыше скорости света. За доказательством рекомендую обратиться к задаче двух генералов - она во многих задачах IT проявляется, пусть и неявно.
Тогда что такое exactly once?
Это гарантия обработки. Если говорить просто, то это at least once доставка, где каждое взаимодействие обвешано ретраями и идемпотентностью. Единственный способ обработать сообщение строго один раз - это любой ценой донести его до получателя, а потом уже отсеять дубликаты.
Потому нам нужны transactional in/out-boxы - чтобы корректно донести сообщение до брокера, и строго один раз обработать его на консьюмере. И все это поверх at least once гарантии доставки.
Про аутбоксы можно почитать тут.
А здесь хардкорно про устройство брокеров, и как устроена запись-чтение сообщений.
👍23❤11🤔1
Don’t try to quit REST
Завтра вещаю на вебинаре, чтобы в очередной (третий) раз окончательно закрыть тему REST API. Наверное, это персональное проклятье. Вспомним, как появилась концепция, под какие задачи, и почему ее актуальность в 2025 стремится к нулю.
Приходите похоливарить, рега тут
Завтра вещаю на вебинаре, чтобы в очередной (третий) раз окончательно закрыть тему REST API. Наверное, это персональное проклятье. Вспомним, как появилась концепция, под какие задачи, и почему ее актуальность в 2025 стремится к нулю.
Приходите похоливарить, рега тут
nextway.timepad.ru
REST, что с тобой не так? / События на TimePad.ru
Проблемы и применимость концепции в современных системах.
👍11🤔4💩2
#интеграция #брокеры
Пока ты разбираешься с топиками и партициями в Кафке, они уже пилят кафка-очереди. Идея прикольная, кстати:
Пока ты разбираешься с топиками и партициями в Кафке, они уже пилят кафка-очереди. Идея прикольная, кстати:
The way that consumer groups assign partitions to members of the group gives a powerful combination of ordering and scalability, but it does introduce coupling between the number of consumers in a consumer group and the number of partitions. Users of Kafka often have to “over-partition” simply to ensure they can have sufficient parallel consumption to cope with peak loads.
...
This KIP introduces the concept of a share group as a way of enabling cooperative consumption using Kafka topics. It does not add the concept of a “queue” to Kafka per se, but rather that introduces cooperative consumption to accommodate these queuing use-cases using regular Kafka topics. Share groups make this possible. You can think of a share group as roughly equivalent to a “durable shared subnoscription” in existing systems.
This is indeed Queues for Kafka - queues done in a Kafka way, with no maximum queue depth and the ability to reset to a specific time for point-in-time recovery.
🔥10
#архитектура
В прошлом году мы запустили кейс-клуб, где регулярно собираемся и предаемся System Design’у здорового человека.
Что делаем:
• Разбираем реальные задачи из жизни, а не Key-Value Storage, URL Shortener и прочую дичь, которую вы никогда не будете пилить в реальной жизни
• Учимся использовать архитектурные паттерны и технологии там, где они действительно уместны
• Увеличиваем техническую насмотренность за счет кейсов из разных индустрий: финтех, ecomm, телеком и другие
Примеры кейсов:
- выпуск и доставка банковской карты
- история покупок и быстрый заказ на маркетплейсе
- программа лояльности в экосистеме
Ближайшая встреча в воскресенье, будет кейс три в одном: A/B-тесты, feature toggling, таргетированная реклама - все в одной архитектуре.
Ждем всех, кто хочет начать осознанно проектировать, а не судорожно вспоминать главы Хью на каждом проекте и собесе, заходите.
В прошлом году мы запустили кейс-клуб, где регулярно собираемся и предаемся System Design’у здорового человека.
Что делаем:
• Разбираем реальные задачи из жизни, а не Key-Value Storage, URL Shortener и прочую дичь, которую вы никогда не будете пилить в реальной жизни
• Учимся использовать архитектурные паттерны и технологии там, где они действительно уместны
• Увеличиваем техническую насмотренность за счет кейсов из разных индустрий: финтех, ecomm, телеком и другие
Примеры кейсов:
- выпуск и доставка банковской карты
- история покупок и быстрый заказ на маркетплейсе
- программа лояльности в экосистеме
Ближайшая встреча в воскресенье, будет кейс три в одном: A/B-тесты, feature toggling, таргетированная реклама - все в одной архитектуре.
Ждем всех, кто хочет начать осознанно проектировать, а не судорожно вспоминать главы Хью на каждом проекте и собесе, заходите.
nextway.pro
Клуб проектирования NextWay
Регулярные воркшопы для развития навыков проектирования архитектуры.
👍9❤6👌1
Прекрасное рядом. До истории с /getClientInfo не дотягивает, но тоже хорошо.
Интересно, а с кэшированием у них нет проблем?
Интересно, а с кэшированием у них нет проблем?
😁13🥴4
Модели потребления сообщений
- Чем топики отличаются от очередей?
- Если кратко - это разные модели потребления
Что такое модели потребления?
Здесь сложнее, т.к. это понятие не слишком популярно в индустрии. В данном контексте модель потребления - это логика работы брокера при передаче сообщения потребителю.
Мой вариант классификации, который подробно разбираю на вебинаре:
• Queue
• Pub-Sub
• Log
Модели определяет два признака:
• Сколько потребителей может прочитать одно сообщение
• Что происходит с сообщением после прочтения
Часто выделяют две модели вместо трех: queue-based, log-based - т.е. объединяют модели Queue и Pub-Sub. Мне эта версия кажется менее наглядной, но тоже хорошо подходит для осмысления вопроса. Можно познакомиться в статье или послушать подкаст о брокерах.
А топиками могут называть что угодно: как модель очереди в реббите, так и реализацию лога в кафке.
#брокеры #интеграция
- Чем топики отличаются от очередей?
- Если кратко - это разные модели потребления
Что такое модели потребления?
Здесь сложнее, т.к. это понятие не слишком популярно в индустрии. В данном контексте модель потребления - это логика работы брокера при передаче сообщения потребителю.
Мой вариант классификации, который подробно разбираю на вебинаре:
• Queue
• Pub-Sub
• Log
Модели определяет два признака:
• Сколько потребителей может прочитать одно сообщение
• Что происходит с сообщением после прочтения
Часто выделяют две модели вместо трех: queue-based, log-based - т.е. объединяют модели Queue и Pub-Sub. Мне эта версия кажется менее наглядной, но тоже хорошо подходит для осмысления вопроса. Можно познакомиться в статье или послушать подкаст о брокерах.
А топиками могут называть что угодно: как модель очереди в реббите, так и реализацию лога в кафке.
#брокеры #интеграция
YouTube
Брокеры сообщений. Модели потребления
Введение в работу брокеров сообщений для начинающих. Рассматриваем концепцию моделей передачи/потребления сообщений:
- Queue (очередь)
- Pub-Sub (подписка)
- Log (лог или журнал)
Курс по интеграции систем и архитектуре: https://clck.ru/3FqCbT
Курс по использованию…
- Queue (очередь)
- Pub-Sub (подписка)
- Log (лог или журнал)
Курс по интеграции систем и архитектуре: https://clck.ru/3FqCbT
Курс по использованию…
❤20👍3
В душе я немного китаец, поэтому оставлю авторитетный прогноз на год грядущий.
Ближайшие 2-3 года особым успехом будут пользоваться астрологи, тарологи, биоэнергетики - в серьезные кризисы люди обращаются к эзотерике.
Немного перепадет карьерным консультантам, коучам, психотерапевтам - за счет итшечки и около.
Не упусти свой шанс
Ближайшие 2-3 года особым успехом будут пользоваться астрологи, тарологи, биоэнергетики - в серьезные кризисы люди обращаются к эзотерике.
Немного перепадет карьерным консультантам, коучам, психотерапевтам - за счет итшечки и около.
Не упусти свой шанс
😁35❤5🔥5😱1
#ненависть #оффтоп
Глядя на околообразование, все больше прихожу к мысли, что лицензировать нужно не школы и программы, а преподавателей и авторов. Чтобы как с адвокатом или хирургом - нет лицензии, не подходи к людям. И какую-нибудь Клятву Аристотеля придумать.
Глядя на околообразование, все больше прихожу к мысли, что лицензировать нужно не школы и программы, а преподавателей и авторов. Чтобы как с адвокатом или хирургом - нет лицензии, не подходи к людям. И какую-нибудь Клятву Аристотеля придумать.
👍35😁22💯7🔥1🤔1
Кто ждал запись - вот она
Telegram
NextWay - анализ и проектирование в IT
Выложили запись вебинара REST, что с тобой не так?
📝 Основные тезисы:
— Концепция REST API создавалась под задачи простого Web'а конца 90х - начала 00х
— Взаимодействия в сервисной и микросервисной архитектуре, сложные пользовательские сценарии, работа…
📝 Основные тезисы:
— Концепция REST API создавалась под задачи простого Web'а конца 90х - начала 00х
— Взаимодействия в сервисной и микросервисной архитектуре, сложные пользовательские сценарии, работа…
🎉18
#API
В разговоре отличное сравнение возникло: уровни зрелости REST API это как нормальные формы БД - описывают подходы к проектированию, но никак не отвечают на вопрос эффективности. Зрелый и нормальный - не значит эффективный для текущей задачи.
Никому в голову не приходит начинать проектирование БД с шестой формы, но при этом люди всерьез бьются за правильный рест. Надо бы к понятию денормализации базы добавить дезрелость реста.
Хотя само слово “зрелость” выбрано максимально неудачно - Ричардсон, иди думай еще.
В разговоре отличное сравнение возникло: уровни зрелости REST API это как нормальные формы БД - описывают подходы к проектированию, но никак не отвечают на вопрос эффективности. Зрелый и нормальный - не значит эффективный для текущей задачи.
Никому в голову не приходит начинать проектирование БД с шестой формы, но при этом люди всерьез бьются за правильный рест. Надо бы к понятию денормализации базы добавить дезрелость реста.
Хотя само слово “зрелость” выбрано максимально неудачно - Ричардсон, иди думай еще.
👍18🔥14😁6💯1
#API #интеграция
GraphQL. Не язык ты мне
Что меня раздражает в итшечке - бесконечная любовь к словотворчеству. Разработал новую технологию или концепцию? Изобретай термин, который укажет, что это нечто совершенно новое и не подлежит сравнению с существующими.
Причины понятные:
◽️ Если автор человек - тщеславие и личный бренд
◽️ Опенсорсное решение - продвижение в массы в целях компании
◽️ Проприетарное решение - нужно больше золота
Обыкновенные маркетинг, если кратко.
Та же история “языком запросов к API”. Что говорят авторы:
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data”.
С их слов GraphQL это:
◽️ язык запросов к API, что бы это не значило
◽️ некий рантайм, в котором эти запросы обрабатываются
Начнем с языка, что видим:
1️⃣ Все запросы имеют определенную структуру, близкую к JSON
2️⃣ Ответы представлены в виде JSON, который имеет структуру из запроса с заполненными значениями
3️⃣ Не привязан к конкретному транспорту
4️⃣ Доступные действия и данные описывают с помощью своего Schema Definition Language - SDL
Ничего не напоминает?
Если брать п.1-3, то практически полной аналогией можно назвать JSON-RPC.
Если брать п.1-4, то все это SOAP.
Фактически, преред нами сетевой протокол уровня 7+ по модели OSI.
Ок, что там с рантаймом?
Для обработки запросов нужен некоторый компонент, который будет их парсить, валидировать, собирать/обновлять инфу из источников, публиковать SDL. Больше всех на слуху Apollo Server, но есть куча других опенсорсных и проприетарных решений.
Что, опять дежавю? Все так, тезисы полностью распространяются на тот же SOAP. Или gRCP, если сделать скидку на его бинарность.
В итоге получаем, что GraphQL это:
1️⃣ Протокол передачи данных
2️⃣ Технология с различными реализациями
3️⃣ Отчасти архитектурный подход к взаимодействию с фронтами
Вот и все, никакой мистики.
Здесь можно задать резонный вопрос: “Что ты придираешься, нормально звучит же: язык запросов”
◽️ Во-первых, реально встречаю недопонимание у людей в этом вопросе.
◽️ Во-вторых, если термин не несет новых смыслов, то зачем вообще его вводить?
А так, честный HATEOAS тоже можно языком запросов назвать, это даже корректнее будет.
Кто хочет копнуть глубже, посмотрите наш стрим с Денисом Лукьяновым, там еще куча материалов в описании.
GraphQL. Не язык ты мне
Что меня раздражает в итшечке - бесконечная любовь к словотворчеству. Разработал новую технологию или концепцию? Изобретай термин, который укажет, что это нечто совершенно новое и не подлежит сравнению с существующими.
Причины понятные:
Обыкновенные маркетинг, если кратко.
Та же история “языком запросов к API”. Что говорят авторы:
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data”.
С их слов GraphQL это:
Начнем с языка, что видим:
Ничего не напоминает?
Если брать п.1-3, то практически полной аналогией можно назвать JSON-RPC.
Если брать п.1-4, то все это SOAP.
Фактически, преред нами сетевой протокол уровня 7+ по модели OSI.
Ок, что там с рантаймом?
Для обработки запросов нужен некоторый компонент, который будет их парсить, валидировать, собирать/обновлять инфу из источников, публиковать SDL. Больше всех на слуху Apollo Server, но есть куча других опенсорсных и проприетарных решений.
Что, опять дежавю? Все так, тезисы полностью распространяются на тот же SOAP. Или gRCP, если сделать скидку на его бинарность.
В итоге получаем, что GraphQL это:
Вот и все, никакой мистики.
Здесь можно задать резонный вопрос: “Что ты придираешься, нормально звучит же: язык запросов”
А так, честный HATEOAS тоже можно языком запросов назвать, это даже корректнее будет.
Кто хочет копнуть глубже, посмотрите наш стрим с Денисом Лукьяновым, там еще куча материалов в описании.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Особенности использования GraphQL. Интервью с Денисом Лукьяновым
Стрим с Денисом Лукьяновым, руководителем отдела backend разработки Samokat.tech, о неочевидных задачах и вызовах при использовании GraphQL:
- Протокол, фреймворк или архитектура?
- Преимущества технологии, и влияние на архитектуру
- Проблемы кэширования…
- Протокол, фреймворк или архитектура?
- Преимущества технологии, и влияние на архитектуру
- Проблемы кэширования…
👍28❤1
#архитектура
Первое правило аритектурного клуба - никому не рассказывать о клубе.
Участница последней встречи нарушила его и дала развернутый непредвзятый фидбек в двух частях: раз и два. За что мы ей бесконечно благодарны.
◽️ Кто еще сомневается, можете почитать и решить, нужно ли это вам.
◽️ Кто не в теме - мы регулярно встречаемся в сисдизайн клубе, где проектируем архитектуру под реальные задачи, а не избитые выдуманные кейсы из книг и ютуба. В прошлый раз была система A/B-тестов, в следующий раз будет риалтайм борда, которые активно растут на волне импортозамещения в РФ. Следующий раз - это 16го февраля.
П - прозрачность.
Кейс-клуб - сисдизайн здорового человека.
P.S. Тайминги лечим, верим в победу.
Первое правило аритектурного клуба - никому не рассказывать о клубе.
Участница последней встречи нарушила его и дала развернутый непредвзятый фидбек в двух частях: раз и два. За что мы ей бесконечно благодарны.
П - прозрачность.
Кейс-клуб - сисдизайн здорового человека.
P.S. Тайминги лечим, верим в победу.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥1
#API #интеграция
REST и GraphQL
Продолжая прошлый пост. Если подумать, в REST и GraphQL заложены схожие идеи:
Граф объектов
◽️ Согласно HATEOAS клиент перемещается по графу от объекта к объекту за счет их слинкованности и выполняет необходимые действия над объектами. Таким образом достигается само документируемость API.
◽️ GraphQL сразу предоставляет схему графа, по которой клиент одним запросом получает необходимые объекты, заранее зная их структуру и связи между ними.
Разница в работе с графом определяет, возникают ли у нас проблемы с избыточными вызовами: N+1, получение разнородных объектов в одном ответе. Это корневая причина появления GraphQL.
Представления объектов
В обоих случаях клиент может получать объекты в нужном представлении. В ресте фокус на формат данных, в gql - на атрибутный состав.
Стандартизация допустимых действий
◽️ HTTP-глаголы в для реста
◽️ Query и mutations в GraphQL
При этом на практике GraphQL используют поверх HTTP, где он оказывается на нулевом уровне зрелости реста (или в RPC Swamp, как обозвал его Ричардсон), наследуя все проблемы RPC over HTTP.
В итоге идеи близки, реализации противоположны - забавный дуализм.
REST и GraphQL
Продолжая прошлый пост. Если подумать, в REST и GraphQL заложены схожие идеи:
Граф объектов
Разница в работе с графом определяет, возникают ли у нас проблемы с избыточными вызовами: N+1, получение разнородных объектов в одном ответе. Это корневая причина появления GraphQL.
Представления объектов
В обоих случаях клиент может получать объекты в нужном представлении. В ресте фокус на формат данных, в gql - на атрибутный состав.
Стандартизация допустимых действий
При этом на практике GraphQL используют поверх HTTP, где он оказывается на нулевом уровне зрелости реста (или в RPC Swamp, как обозвал его Ричардсон), наследуя все проблемы RPC over HTTP.
В итоге идеи близки, реализации противоположны - забавный дуализм.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1🥰1🤔1
#интеграция #брокеры
Ничего мы вам не гарантировали. Часть 2
Начало тут
Если еще можно смириться с тем, что exactly once доставки не существует, то с at least once начинается откровенная шизофрения.
Использование at least once гарантирует, что сообщение будет доставлено не менее одного раза, верно? Внимание, вопрос: сколько раз реально может быть доставлено сообщение?
Правильно, сколько угодно. Или вообще не придти. Почему так?
◽️ Гарантия доставки обеспечивается банальными ретраями и подтверждениями при взаимодействиях с брокером. Но никто не будет ретраить бесконечно, какие-то лимиты есть всегда. На этот случай нужно не забыть обвешаться мониторингом.
◽️ Все однажды падает, брокер в том числе. Даже получив от брокера подтверждение об успешном получении сообщения, у нас нет абсолютной гарантии, что он успел записать его на диск перед падением - по дороге к диску могут быть системные кэши, или его собственные.
Хотя таких случаев должно быть немного, на больших объемах может выстрелить. Но важно помнить - все врут.
Ничего мы вам не гарантировали. Часть 2
Начало тут
Если еще можно смириться с тем, что exactly once доставки не существует, то с at least once начинается откровенная шизофрения.
Использование at least once гарантирует, что сообщение будет доставлено не менее одного раза, верно? Внимание, вопрос: сколько раз реально может быть доставлено сообщение?
Правильно, сколько угодно. Или вообще не придти. Почему так?
Хотя таких случаев должно быть немного, на больших объемах может выстрелить. Но важно помнить - все врут.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤3👎1
the-websocket-handbook.pdf
1.1 MB
Классная мини книга про вебсокеты.
• История и проблематика
• Детали работы протокола
• Масштабирование и отказоустойчивость
#интеграция
• История и проблематика
• Детали работы протокола
• Масштабирование и отказоустойчивость
#интеграция
👍19💩1
#интеграция #архитектура
На фоне стабильной тенденции к переходу из аналитиков в архитектуру не менее стабильно возникает вопрос: “А как это делать вообще?”
Есть минимум два варианта:
— закопаться в книгах по архитектуре и штурмовать вакансии архитектора
— понять, что уже есть для нужной роли, и постепенно двигаться к ней, отбирая у кого-нибудь подходящие задачи
Я уже старый и ленивый, поэтому предпочитаю эволюцию. Допустим, есть богатый опыт в проектировании интеграций. Логично начать наращивать на него дополнительные скиллы, расширяя спектр задач.
Сначала копнем в работу сетей и инфры, чтобы понять влияние на выбор технологий. Здесь же разберемся, как и почему работает балансировка. Дальше начинаем думать о надежности, и учимся использовать circuit breaker’ы, адаптивные ретраи и другие паттерны отказоустойчивости. Где-то рядом придется задуматься о производительности и кэшировании, а там и выборе технологии под кэш. А потом потребуют развесистый бизнес-процесс реализовать на несколько сервисов, и вот вам проектирование распределенной системы с транзакциями.
Таким образом получаем трек: локальные интеграции -> интеграционная архитектура -> полноценный сисдизайн. Останется еще с хранилищами попрактиковаться.
По этой логике мы проектировали курс интеграция и архитектура в распределенных системах. Вместе пройдем путь от уверенной работы с API, до проектирования сложной интеграционной архитектуры в распределенных системах.
Первый поток зашел на удивление хорошо, некоторые успели даже собесы пройти в процессе.
На фоне стабильной тенденции к переходу из аналитиков в архитектуру не менее стабильно возникает вопрос: “А как это делать вообще?”
Есть минимум два варианта:
— закопаться в книгах по архитектуре и штурмовать вакансии архитектора
— понять, что уже есть для нужной роли, и постепенно двигаться к ней, отбирая у кого-нибудь подходящие задачи
Я уже старый и ленивый, поэтому предпочитаю эволюцию. Допустим, есть богатый опыт в проектировании интеграций. Логично начать наращивать на него дополнительные скиллы, расширяя спектр задач.
Сначала копнем в работу сетей и инфры, чтобы понять влияние на выбор технологий. Здесь же разберемся, как и почему работает балансировка. Дальше начинаем думать о надежности, и учимся использовать circuit breaker’ы, адаптивные ретраи и другие паттерны отказоустойчивости. Где-то рядом придется задуматься о производительности и кэшировании, а там и выборе технологии под кэш. А потом потребуют развесистый бизнес-процесс реализовать на несколько сервисов, и вот вам проектирование распределенной системы с транзакциями.
Таким образом получаем трек: локальные интеграции -> интеграционная архитектура -> полноценный сисдизайн. Останется еще с хранилищами попрактиковаться.
По этой логике мы проектировали курс интеграция и архитектура в распределенных системах. Вместе пройдем путь от уверенной работы с API, до проектирования сложной интеграционной архитектуры в распределенных системах.
Первый поток зашел на удивление хорошо, некоторые успели даже собесы пройти в процессе.
👍11🔥6
#интеграция
Я не раз писал, что для осмысленных рассуждений о выборе технологии интеграции нужно минимальное понимание сетей и инфры, которая лежит под знакомыми рестами и соапами. Поэтому решил сделать стрим на эту тему. Вторник 25.02, вечер, заходите.
Рега тут
Я не раз писал, что для осмысленных рассуждений о выборе технологии интеграции нужно минимальное понимание сетей и инфры, которая лежит под знакомыми рестами и соапами. Поэтому решил сделать стрим на эту тему. Вторник 25.02, вечер, заходите.
Рега тут
nextway.timepad.ru
Сетевые протоколы и технологии интеграции / События на TimePad.ru
Обсудим, что находится под капотом у популярных технологий на уровне сетей и инфры
🔥22
Эти выхи буду на WAW. Кто еще там? Го чай пить и знакомиться.
А завтра утром веду воркшоп по сисдизайну - заходите, чтобы посмотреть, чем мы в нашей архсекте занимаемся.
А завтра утром веду воркшоп по сисдизайну - заходите, чтобы посмотреть, чем мы в нашей архсекте занимаемся.
🔥9
Выложили запись собеса сисаналитика в Т-Банке. Наверное, лучший из всех, что видел на ютубе.
Очень продуманы задания и вопросы, отлично подготовлены материалы, максимально конструктивное и экологичное общение со стороны интервьюера. Общение происходит на примере сквозного кейса, а не очередных 100 вопросов для собеса.
Категорически рекомендую как нанимающим лидам, так и кандидатам.
У меня лишь один вопрос остался: если вот это все делает аналитик, то чем вообще занимается разработка?
Очень продуманы задания и вопросы, отлично подготовлены материалы, максимально конструктивное и экологичное общение со стороны интервьюера. Общение происходит на примере сквозного кейса, а не очередных 100 вопросов для собеса.
Категорически рекомендую как нанимающим лидам, так и кандидатам.
У меня лишь один вопрос остался: если вот это все делает аналитик, то чем вообще занимается разработка?
🔥25🤮6❤5👍4
WAW 2025
На выхах добрался до WAW, который оставил неожиданно приятные впечатления. За счет небольших размеров получилось очень лампово и душевно, было время обсудить интересное. Только 1,5 дня мало((
Выделялись три основных темы: сисдизайн, лидерско-манагерское, AI. Трек сисдизайна получился особо удачно, спасибо Ане Вичуговой, Зое Степчевой и скромному мне. Надеюсь, никого не упустил?
Зоя с Аней провели два воркшопа, раскрывающих темы работы с данными и безопасностью, которые получают не так много внимания среди аналитиков. Особенно зашла механика с трейдофами: есть ряд потребностей, несколько вариантов реализации и ограниченный бюджет, в рамках которого нужно выбрать элементы решения. Попробую утащить себе.
Увидите их воркшопы - заходите, не проходите.
Я же делал воркшоп по сисдизайну, где разбирали кейс доставки карты в сокращенном виде. Прошло бодро и активно, 5 из 6 команд дошли до конца, все довели решение до рабочей версии.
Несколько закономерностей, которые заметил еще в рамках нашего кейс-клуба:
Реализация НФТ
Характерное поведение аналитика: определить требования к нагрузке, доступности, масштабированию… и забыть про них. Не происходит валидации, как мы реализовали требования на уровне архитектуры, основное внимание уделяется бизнес сценариям. Не надо так;)
Легаси системы
Когда мы используем существующий ландшафт (т.е. почти всегда), нужно не забыть про характеристики и ограничения легаси систем. Иначе весь наш хайлоад рассыпется на какой-нибудь вендорской коробке.
Масштабирование
Нагруженные сервисы, стоит запускать в нескольких экземплярах. Если нет данных, чтобы оценить нагрузку и ресурсы, можно начинать с двух в качестве дефолтного варианта. Дальше будем смотреть, сколько нужно добавить. Ну и не забыть о балансировке.
На другие секции удалось только мельком заглянуть, ничего конкретного не скажу.
Спасибо оргам и всем участникам за конфу, встретимся через год ❤🔥
#конференции
На выхах добрался до WAW, который оставил неожиданно приятные впечатления. За счет небольших размеров получилось очень лампово и душевно, было время обсудить интересное. Только 1,5 дня мало((
Выделялись три основных темы: сисдизайн, лидерско-манагерское, AI. Трек сисдизайна получился особо удачно, спасибо Ане Вичуговой, Зое Степчевой и скромному мне. Надеюсь, никого не упустил?
Зоя с Аней провели два воркшопа, раскрывающих темы работы с данными и безопасностью, которые получают не так много внимания среди аналитиков. Особенно зашла механика с трейдофами: есть ряд потребностей, несколько вариантов реализации и ограниченный бюджет, в рамках которого нужно выбрать элементы решения. Попробую утащить себе.
Увидите их воркшопы - заходите, не проходите.
Я же делал воркшоп по сисдизайну, где разбирали кейс доставки карты в сокращенном виде. Прошло бодро и активно, 5 из 6 команд дошли до конца, все довели решение до рабочей версии.
Несколько закономерностей, которые заметил еще в рамках нашего кейс-клуба:
Реализация НФТ
Характерное поведение аналитика: определить требования к нагрузке, доступности, масштабированию… и забыть про них. Не происходит валидации, как мы реализовали требования на уровне архитектуры, основное внимание уделяется бизнес сценариям. Не надо так;)
Легаси системы
Когда мы используем существующий ландшафт (т.е. почти всегда), нужно не забыть про характеристики и ограничения легаси систем. Иначе весь наш хайлоад рассыпется на какой-нибудь вендорской коробке.
Масштабирование
Нагруженные сервисы, стоит запускать в нескольких экземплярах. Если нет данных, чтобы оценить нагрузку и ресурсы, можно начинать с двух в качестве дефолтного варианта. Дальше будем смотреть, сколько нужно добавить. Ну и не забыть о балансировке.
На другие секции удалось только мельком заглянуть, ничего конкретного не скажу.
Спасибо оргам и всем участникам за конфу, встретимся через год ❤🔥
#конференции
❤20🔥7👍2