Согласен со статьей - по сути речь идёт о том, чтобы быть зрелым человеком и соблюдать баланс между мифами IT, бизнесом, общением с людьми, своей мотивацией и здоровьем.
Кода как такого в IT нет - разумнее организовать процессы и выбирать решения
Кажется, попытка k8s усидеть на 2-х стульях такое себе. Если идете в облака, то зачем бояться сложности, нужно удовлетворять требованиям пользователей - настройка таких решений должна лежать на плечах крупных вендоров. Что касается среднего бизнеса, который покупает свое железо, то k8s слишком сложен в обслуживании и так, гораздо удобнее vm с docker
Отличный сбор всех экспериментов и корректная интерпретация с точки зрения физики. Интересно использование квантовых аналогий для объяснения сознания - недавно наткнулся в сети на Пенроуза у Черниговской
Не обязательно, используем паттерн - вынесенный интерфейс.
Главное в модульной концепции - данные общие, а сервисы инкапсулируют сильно связанный функционал. Ещё практичный прием - не использовать общие репозитории вокруг сущностей, а использовать - доменные в контексте модуля
Открываю для себя мир медитации - отличная возможность прислушаться к себе и получить разумные ответы на свои вопросы, очистив их от своего Эга и чего-то навязанного другим. По сути медитация - это глубокое размышление философского характера.
Хорошая статья. Мне кажется здесь проблема не только в angular, сложность системы диктуется бизнесом. До react/angular фронты пилили не поддерживаемые костыли.
Здесь 2 подхода как на бэке - пишем на фреймворке (spring java), либо на библиотеках для опытных (ФП scala).
Здесь есть проблема с определением стабильных границ между микросервисами - без них сложно получить профит с независимым деплоем частей и не свалиться в распределённый монолит. Если следовать Сэму Ньюману, то нужно начинать с монолитов и по мере стабилизации домена решить, какая конкретно часть в нем применения архитектуры микросервисов. Например увелечение производительности определенного слля или ускорение введения изменений в определенную часть.
Пардон за поток сознания - что-то и хочу в этом роде - смешать базу и Kafka и получить все из "коробки": расширить возможности ACID-транзакций базы транзакциями Kafka (как-то заюзать https://habr.com/ru/company/badoo/blog/333046/).
В своих проектах тоже использовал ключи идемпотентности, но всегда хотелось как-то более бесшовно интегрировать Kafka в бизнес-процессы. Например, можно было "забить" на poller + таблицу очередь и сразу отправлять события, если использовать гарантии доставки exactly once - в этом случае события, кот. отправляет продюсер маркируются транзакцией Kafka и будут доступны всем коньюмерам уже после фиксации офсетов консьюмеров. А если добавить офсеты в базу, то ключи идемпотентности вообще не нужны чисто теоретически.
Имел ввиду, что организация распределенных транзакций через Кафка имеет много болерплейта и сложностей (вы их разобрали)
Хочется что-то вроде гарантии exactly ones для событий + единая транзакция для бизнес моделей в БД. Наткнулся на интересную статью, которая решает ряд проблем за счёт хранения offsets-ов Kafka вне брокера прям в БД
Еще есть интересный вариант - хранить offset-ы Kafka в БД, который позволяет не делать poller. Но наверное имеет проблемы с масштабированием, т.к. вы замыкаетесь на одну БД.
Согласен со статьей - по сути речь идёт о том, чтобы быть зрелым человеком и соблюдать баланс между мифами IT, бизнесом, общением с людьми, своей мотивацией и здоровьем.
Кода как такого в IT нет - разумнее организовать процессы и выбирать решения
Отличные наблюдения - мы в нашей команде придумали специальные RnD спринты:
Копим ижесы в течение определенного времени
Объединяем их в вехи - прорабатываем задачи
Проводим что-то вроде защиты, на которой принимаем решение достаточно ли экспертизы для промышленной реализации
Потом уже запускаем стандартный процесс через скрам
Спасибо за отличную статью!
Спасибо за статью - полезно.
Кажется, попытка k8s усидеть на 2-х стульях такое себе. Если идете в облака, то зачем бояться сложности, нужно удовлетворять требованиям пользователей - настройка таких решений должна лежать на плечах крупных вендоров. Что касается среднего бизнеса, который покупает свое железо, то k8s слишком сложен в обслуживании и так, гораздо удобнее vm с docker
Отличный сбор всех экспериментов и корректная интерпретация с точки зрения физики. Интересно использование квантовых аналогий для объяснения сознания - недавно наткнулся в сети на Пенроуза у Черниговской
Не обязательно, используем паттерн - вынесенный интерфейс.
Главное в модульной концепции - данные общие, а сервисы инкапсулируют сильно связанный функционал. Ещё практичный прием - не использовать общие репозитории вокруг сущностей, а использовать - доменные в контексте модуля
Клево что в финтехе крутые технологии крутят - молодцы
Открываю для себя мир медитации - отличная возможность прислушаться к себе и получить разумные ответы на свои вопросы, очистив их от своего Эга и чего-то навязанного другим. По сути медитация - это глубокое размышление философского характера.
Хорошая статья. Мне кажется здесь проблема не только в angular, сложность системы диктуется бизнесом. До react/angular фронты пилили не поддерживаемые костыли.
Здесь 2 подхода как на бэке - пишем на фреймворке (spring java), либо на библиотеках для опытных (ФП scala).
Тогда ждём и будем переезжать ✌️
Немного оффтоп. Интересно, а проект Loom будет встраиваться в новые jdk
Здесь есть проблема с определением стабильных границ между микросервисами - без них сложно получить профит с независимым деплоем частей и не свалиться в распределённый монолит. Если следовать Сэму Ньюману, то нужно начинать с монолитов и по мере стабилизации домена решить, какая конкретно часть в нем применения архитектуры микросервисов. Например увелечение производительности определенного слля или ускорение введения изменений в определенную часть.
Пардон за поток сознания - что-то и хочу в этом роде - смешать базу и Kafka и получить все из "коробки": расширить возможности ACID-транзакций базы транзакциями Kafka (как-то заюзать https://habr.com/ru/company/badoo/blog/333046/).
В своих проектах тоже использовал ключи идемпотентности, но всегда хотелось как-то более бесшовно интегрировать Kafka в бизнес-процессы. Например, можно было "забить" на poller + таблицу очередь и сразу отправлять события, если использовать гарантии доставки exactly once - в этом случае события, кот. отправляет продюсер маркируются транзакцией Kafka и будут доступны всем коньюмерам уже после фиксации офсетов консьюмеров. А если добавить офсеты в базу, то ключи идемпотентности вообще не нужны чисто теоретически.
Имел ввиду, что организация распределенных транзакций через Кафка имеет много болерплейта и сложностей (вы их разобрали)
Хочется что-то вроде гарантии exactly ones для событий + единая транзакция для бизнес моделей в БД. Наткнулся на интересную статью, которая решает ряд проблем за счёт хранения offsets-ов Kafka вне брокера прям в БД
https://medium.com/p/91042e81c095
Еще есть интересный вариант - хранить offset-ы Kafka в БД, который позволяет не делать poller. Но наверное имеет проблемы с масштабированием, т.к. вы замыкаетесь на одну БД.
Скажите, даунтаймы при ребалансировке насколько критичны - в Kafka с этим есть проблемы
Смелая работа, думал в банках все по старинке - через оракл и хранимки делается) Молодцы
С точки зрения ООП или ФП оформлено слабовато, но главное идея автоматизации