opensource проект может быть хобби, как в описанном случае. Устал, надоело итд - занялись другими активностями (семья, друзья, игры, путешествия итд итп). Какие то обязательства по общению с community, устранению ошибок итд - только в вашей голове. Расслабьтесь, найдите комфортный вам work-life balance. При таких условиях безвозмездная работа вполне себе жизнеспособна и называется for fun (мне по приколу).
Совсем другое дело когда это бизнес. И здесь главный и далекий от навыков разработчика вопрос - модель монетизации. При этом появляется возможность нанять программистов для работы над продуктом.
Первая волна opensource - "время идеалистов бессребреников" давно прошла. Хорошо, что компании нашли подходы к монетизации, без этого бы вряд ли мы увидели что то толковое с открытым кодом в товарных количествах.
В целом интересная статья, как на базе opensource технологий начать строить решения, сравнимые с коммерческими аналогами.
Хороший старт.
Так, например, в одном международном банке наша шина обеспечивает передачу более 100 тыс. платежных транзакций в день между различными системами с временем ожидания отклика не более 0,5 секунды по критическим транзакциям для бизнеса.
Так например, в одном не самом крупном российском банке на шине, построенной на похожих opensouce технологиях, обеспечивается передача 3000 вызовов в секунду с задержкой от 0,3 до 0,5 секунд. И это не предел желаний по нагрузке.
Оправдала себя не микросервисная архитектура и low code, а работа с эффективным использованием вычислительных мощностей, обеспечением доступности кластеров, DR с гео резервированием, мониторинг, трассировка и другая observability. До выполнения этих требований про low code заказчик даже не хотел слушать.
Мы выделили такие компоненты, как коннектор (подключается к источнику или адресату), адаптер (отвечает за маппинг, трансформацию и валидацию данных)
Для ИТ-ландшафта с необходимостью интеграции коробочных/вендорских систем это адекватный подход.
В случае, если развитие интегрируемых систем и разработка интеграций на шине управляется заказчиком, то мы дошли до ровно обратного подхода
Транспортный протокол каждого интеграционного взаимодействия выбирается на основе нефункциональных требований. К интеграционному потоку все системы подключаются по одному протоколу. "Адаптеры протоколов - это не есть хорошо".
Если системы не могут договориться и обеспечить для интеграционного потока обмен в едином формате, то шина как посредник только усложняет дело. "Почтальон (шина) в конверт (в передаваемые данные) не лезет".
Для http взаимодействий шина не приносит значимого value, при этом создает еще один участок задержек и потенциальных сбоев. "Шина без value - деньги на ветер".
Расскажите, а какой у вас опыт перехода с западных привычных шин на российские? Какого функционала не хватает больше всего, и есть ли позитивная практика использования разработок из Реестра российского ПО?
Общение с потенциальными вендорами замирало на "кто конкретно и в каких финансовых объемах готов нести ответственность за отсутствие сбоев в проде".
С собственной разработкой опыт положительный. Сошлись на формулировке "если без сбоев работает, то всем премию. Если сбоит - без нытья шагаете за ворота".
Цитата: Объем глобального рынка ИТ-аутсорсинга по итогам 2021 года достиг $360 млрд, увеличившись почти на 13% в сравнении с 2020-м. Такие данные в конце апреля 2022 года обнародовали аналитики Statista.
Я Вам всячески намекаю, что описанное решение не универсально и имеет ограниченную область применения. Многие в комментариях пишут про эти ограничения.
Ограничения вызваны размером компании, особенностями бизнес модели, однородностью ИТ-ладншафта итд итп.
Предлагаю по части Банков остановить дискуссию. Слишком разный у нас опыт работы в этой части.
Про Oracle см Ваши выводы про Яндекс, ситуация один в один.
Фирма-аутсорсер не производит ИТ-продукт
А результатом заказной разработки что является?
Концепция проста и незатейлива - "запилил" ровно то и ровно так, как было в ТЗ и давай до свидания до следующего тендера на развитие ИТ-системы. И не факт, что следующий тендер выиграет этот же аутсорсер. Если вдруг аутсорсеру захочется начать продавать результат "запила" или целиком релиз ИТ-системы заказчика as is другим заказчикам, то набираем попкорн и смотрим битву юристов. Свои три рубля ставлю на на отдел договоров и юридическую службу крупного заказчика.
Какой тут ИТ-продукт у аутсорсера? Зачем аутсорсеру делать больше/лучше/по-другому чем в ТЗ. Стараемся любыми путями сдать работу вовремя и не пронести сроки. Режем косты (в том числе, жонглируя разработчиками, если есть угроза из-за проноса сроков влететь на штрафы).
При этом не надо путать аутсорсера с вендрором или системным интегратором.
Как говорится, one size fit them all. Везде библиотечный подход, типовые кубики.
Вот как раз таки мало где. О чем и речь.
Зачастую мало где, не потому что, там сидят недогадливые/ленивые менеджеры, а наоборот, догадливые менеджеры понимают, что для их случая подход работать не будет. Возвращаемся к ограничениям подхода.
Рекомендовано к использованию в крупных компаниях.
Ну примерно так и делаем, но спасибо за совет.
Хм. Тут же был сарказм во весь рост с моей стороны.
Так делать можно в маленькой и потому гибкой компании. После нескольких неудач подход начинает быстро эволюционировать. Об этом ниже.
В итоге советую хотя бы мысленно прикинуть, какие проблемы в вашей компании данный подход может решить
В крупных компаниях давно уже "прикидывают" гораздо более структурированно, чем "мысленно". Приблизительный алгоритм:
Идея. Идеолог бодро формулирует "плюсы представленного подхода сильно перевешивают его минусы (по моему мнению)"
Обоснование актуальности идеи для всей компании или четкое понимание в какой части компании идея может выстрелить. Поиск похожих кейсов в отрасли.
Формализация правил и сроков оценки эффекта от внедрения идеи
Предварительный расчет потенциальных затрат/прибыли/экономии/рисков с учетом, что изменения будут проведены не за день, а эффект может проявиться или быть измерен ощутимо позже окончания изменений
Составление детализированного календарного и ресурсного плана, списка контрольных точек, перечня рисков и методов управления рисками
Принятие решения делаем/не делаем. С зонами и размерами ответственности участников внедрения идеи
Выполнение изменений с оценкой прогресса в промежуточных контрольных точках
Финальная оценка эффекта
Подведение итогов. Иногда совмещенное с увольнениями особо отличившихся "героев-иделогов" и поверивших в них лиц, принимающих решения. Но это случается очень очень редко.
Вся эта тяжелая бюрократия ради того, что есть риск так навнедрять "универсальных" идей в широких масштабах крупной компании, что никакие фе-фе-фе, публичный позор, лишения идеологов премий/бонусов, а так же увольнения не компенсируют убытков.
Итог (на мой взгляд).
Автор молодец, что самостоятельно придумал и удачно внедрил идею (хотя она не совсем оригинальна) в своей фирме.
Что можно сделать лучше:
Явно выделить ключевые факторы успешности кейса. Почему получилось в этой фирме, какие именно условия должны быть выполнены, чтобы повторять успех устойчиво и независимо от личных качеств повторяющих в других фирмах.
Описать ограничения подхода. При каких условиях успеха не добиться. Частично в статье это уже сделано.
Сразу хочу принести свои извинения за сарказм в ответах. Не судите строго, постарайтесь найти рациональное зерно
Устройство ИТ сильно отличается от приведенных Вами схем
Можно пример?
Банк не производит ИТ-продукт, вернее не продает его на рынке, у него ИТ направлено на обеспечение финансовых услуг. Проектное управление ИТ-разработками, закупки ИТ-продуктов и найм интеграторов для адаптации/внедрения купленных продуктов/платофрм с последующим взращиванием собственной экспертизы, годовое бюджетирование итд. Внутри контура проектного управления резвитесь в Agile, но в срок заранее зафиксированный результат, за фикс денег при фикс ресурсах чтобы был. И каждый Project Manager за выданные проекту людские ресурсы стоит горой, каждый Product Manager стоит горой за людские ресурсы в его ИТ-системе, мнение пользователей не главный приоритет, главное нахватать больше функционала и расширить штат под собой. Строгое разделение команд разработки различных ИТ-систем, свой огородик с заборчиком трехметровой высоты, колючая проволока и мины для соседей.
Фирма-аутсорсер не производит ИТ-продукт, а продает услуги заказной разработки ПО. ИТ-продукта нет, а разработка есть. Милое дело жонглировать разработчиками между разными заказами для тушения пожаров и перепродажи одного разработчика в разные заказы одновременно. Совсем другой стиль управления.
Фирмы-аутстаферы вообще отдельная песня.
И все это непродуктовая разработка и не очень продуктовый подход.
Тут скорее про количество продуктов или их величину
На этом спринте команда напилит фичу в Oracle Siebel CRM, на следующем спринте их уже ждет PM, отвечающий за Oracle ERP, а самой продуктивной команде дадут покоммитить в ядро Oracle Database два спринта подряд. Вечером можно в Java virtual machine пару оптимизаций впилить. И ведь есть ИТ-продукты в полный рост и продуктовый подход к разработке есть.
А в Яндексе хоть каждый день меняй команды между поисковиком и такси.
Как говорится, one size fit them all. Везде библиотечный подход, типовые кубики.
Потому что подход на стадии внедрения.
Сначала проведем задуманные организационные изменения, потом договоримся о правилах оценки их результатов, а уж затем по факту посчитаем сколько на это ушло денег/времени и какая случилась выгода/экономия. Если в конце случится fail и ситуация станет хуже чем до, то строго посмотрим на того, кто придумал эти изменения и не будем слушать его идеи три месяца. Best practices менеджмента. Рекомендовано к использованию в крупных компаниях.
Работал в трех больших компаниях. Устройство ИТ сильно отличается от приведенных Вами схем.
Большие компании (мы же обсуждаем компании со штатом развития ИТ в несколько тысяч сотрудников и более?) с разным бизнесом (а бизнес бывает не только продуктовым) по-разному структурируют и управляют своим ИТ. Было бы здорово четко описать границы применимости Вашей идеи.
В статье, к большому сожалению, не приведено ни одного измеримого показателя "лучше/хуже" при сравнении подходов, а так же статистики, показывающей, что описанные ограничения действительно являются ключевыми/критичными для бизнеса значимого количества ИТ компаний.
Как уже писали в других комментариях, было бы здорово почитать о результатах применения описанного подхода в Вашей компании
>producer.send(new ProducerRecord(topicName, split[0]));
Вот так записывать в Кафку плохо. Вы не анализируете результат работы метода send. Либо нужно вторым параметром передать Callback, либо у полученной в результате вызова Future вызвать метод get.
И да, Windows — неподдерживаемая платформа и на ней из-за особенностей файловой подсистемы кафка вряд ли будет нормально работать в ближайшее время.
Добрый день
opensource проект может быть хобби, как в описанном случае. Устал, надоело итд - занялись другими активностями (семья, друзья, игры, путешествия итд итп). Какие то обязательства по общению с community, устранению ошибок итд - только в вашей голове. Расслабьтесь, найдите комфортный вам work-life balance. При таких условиях безвозмездная работа вполне себе жизнеспособна и называется for fun (мне по приколу).
Совсем другое дело когда это бизнес. И здесь главный и далекий от навыков разработчика вопрос - модель монетизации. При этом появляется возможность нанять программистов для работы над продуктом.
Первая волна opensource - "время идеалистов бессребреников" давно прошла. Хорошо, что компании нашли подходы к монетизации, без этого бы вряд ли мы увидели что то толковое с открытым кодом в товарных количествах.
Пришел, увидел, начал кардинально менять. Ну ок, все мы любим на новом месте "сделать хорошо".
А если бы провели 128 архитектурных советов и 256 концептуальных архитектур запустили, то стало бы еще лучше! Только не понятно кому и в чем лучше.
Добрый день
В целом интересная статья, как на базе opensource технологий начать строить решения, сравнимые с коммерческими аналогами.
Хороший старт.
Так например, в одном не самом крупном российском банке на шине, построенной на похожих opensouce технологиях, обеспечивается передача 3000 вызовов в секунду с задержкой от 0,3 до 0,5 секунд. И это не предел желаний по нагрузке.
Оправдала себя не микросервисная архитектура и low code, а работа с эффективным использованием вычислительных мощностей, обеспечением доступности кластеров, DR с гео резервированием, мониторинг, трассировка и другая observability. До выполнения этих требований про low code заказчик даже не хотел слушать.
Для ИТ-ландшафта с необходимостью интеграции коробочных/вендорских систем это адекватный подход.
В случае, если развитие интегрируемых систем и разработка интеграций на шине управляется заказчиком, то мы дошли до ровно обратного подхода
Транспортный протокол каждого интеграционного взаимодействия выбирается на основе нефункциональных требований. К интеграционному потоку все системы подключаются по одному протоколу. "Адаптеры протоколов - это не есть хорошо".
Если системы не могут договориться и обеспечить для интеграционного потока обмен в едином формате, то шина как посредник только усложняет дело. "Почтальон (шина) в конверт (в передаваемые данные) не лезет".
Для http взаимодействий шина не приносит значимого value, при этом создает еще один участок задержек и потенциальных сбоев. "Шина без value - деньги на ветер".
Общение с потенциальными вендорами замирало на "кто конкретно и в каких финансовых объемах готов нести ответственность за отсутствие сбоев в проде".
С собственной разработкой опыт положительный. Сошлись на формулировке "если без сбоев работает, то всем премию. Если сбоит - без нытья шагаете за ворота".
Ждем инфы о внедрении подхода из Яндекса и других Майкрософтов с Ораклами
Это раз https://www.tadviser.ru/index.php/Статья:ИТ-аутсорсинг_(мировой_рынок)
Цитата: Объем глобального рынка ИТ-аутсорсинга по итогам 2021 года достиг $360 млрд, увеличившись почти на 13% в сравнении с 2020-м. Такие данные в конце апреля 2022 года обнародовали аналитики Statista.
Это два: https://www.tadviser.ru/index.php/Статья:ИТ-аутсорсинг_(рынок_России)
Тройка аутсорсеров-лидеров по выручке в РФ за 2020
Ланит - 24,9 млрд рублей
Айтеко - 14,9 млрд рублей
Инфосистемы Джет - 14,8 млрд рублей
У вышеуказанных фирм дела на грани разорения?
А на мировом рынке тоже не знают, что аутсорсинг не торт и они не такие как надо профи?
Вопросы риторические.
Я Вам всячески намекаю, что описанное решение не универсально и имеет ограниченную область применения. Многие в комментариях пишут про эти ограничения.
Ограничения вызваны размером компании, особенностями бизнес модели, однородностью ИТ-ладншафта итд итп.
Предлагаю по части Банков остановить дискуссию. Слишком разный у нас опыт работы в этой части.
Про Oracle см Ваши выводы про Яндекс, ситуация один в один.
Концепция проста и незатейлива - "запилил" ровно то и ровно так, как было в ТЗ и давай до свидания до следующего тендера на развитие ИТ-системы. И не факт, что следующий тендер выиграет этот же аутсорсер. Если вдруг аутсорсеру захочется начать продавать результат "запила" или целиком релиз ИТ-системы заказчика as is другим заказчикам, то набираем попкорн и смотрим битву юристов. Свои три рубля ставлю на на отдел договоров и юридическую службу крупного заказчика.
Какой тут ИТ-продукт у аутсорсера? Зачем аутсорсеру делать больше/лучше/по-другому чем в ТЗ. Стараемся любыми путями сдать работу вовремя и не пронести сроки. Режем косты (в том числе, жонглируя разработчиками, если есть угроза из-за проноса сроков влететь на штрафы).
При этом не надо путать аутсорсера с вендрором или системным интегратором.
Зачастую мало где, не потому что, там сидят недогадливые/ленивые менеджеры, а наоборот, догадливые менеджеры понимают, что для их случая подход работать не будет. Возвращаемся к ограничениям подхода.
Хм. Тут же был сарказм во весь рост с моей стороны.
Так делать можно в маленькой и потому гибкой компании. После нескольких неудач подход начинает быстро эволюционировать. Об этом ниже.
В крупных компаниях давно уже "прикидывают" гораздо более структурированно, чем "мысленно". Приблизительный алгоритм:
Идея. Идеолог бодро формулирует "плюсы представленного подхода сильно перевешивают его минусы (по моему мнению)"
Обоснование актуальности идеи для всей компании или четкое понимание в какой части компании идея может выстрелить. Поиск похожих кейсов в отрасли.
Формализация правил и сроков оценки эффекта от внедрения идеи
Предварительный расчет потенциальных затрат/прибыли/экономии/рисков с учетом, что изменения будут проведены не за день, а эффект может проявиться или быть измерен ощутимо позже окончания изменений
Составление детализированного календарного и ресурсного плана, списка контрольных точек, перечня рисков и методов управления рисками
Принятие решения делаем/не делаем. С зонами и размерами ответственности участников внедрения идеи
Выполнение изменений с оценкой прогресса в промежуточных контрольных точках
Финальная оценка эффекта
Подведение итогов. Иногда совмещенное с увольнениями особо отличившихся "героев-иделогов" и поверивших в них лиц, принимающих решения. Но это случается очень очень редко.
Вся эта тяжелая бюрократия ради того, что есть риск так навнедрять "универсальных" идей в широких масштабах крупной компании, что никакие фе-фе-фе, публичный позор, лишения идеологов премий/бонусов, а так же увольнения не компенсируют убытков.
Итог (на мой взгляд).
Автор молодец, что самостоятельно придумал и удачно внедрил идею (хотя она не совсем оригинальна) в своей фирме.
Что можно сделать лучше:
Явно выделить ключевые факторы успешности кейса. Почему получилось в этой фирме, какие именно условия должны быть выполнены, чтобы повторять успех устойчиво и независимо от личных качеств повторяющих в других фирмах.
Описать ограничения подхода. При каких условиях успеха не добиться. Частично в статье это уже сделано.
Сразу хочу принести свои извинения за сарказм в ответах. Не судите строго, постарайтесь найти рациональное зерно
Банк не производит ИТ-продукт, вернее не продает его на рынке, у него ИТ направлено на обеспечение финансовых услуг. Проектное управление ИТ-разработками, закупки ИТ-продуктов и найм интеграторов для адаптации/внедрения купленных продуктов/платофрм с последующим взращиванием собственной экспертизы, годовое бюджетирование итд. Внутри контура проектного управления резвитесь в Agile, но в срок заранее зафиксированный результат, за фикс денег при фикс ресурсах чтобы был. И каждый Project Manager за выданные проекту людские ресурсы стоит горой, каждый Product Manager стоит горой за людские ресурсы в его ИТ-системе, мнение пользователей не главный приоритет, главное нахватать больше функционала и расширить штат под собой. Строгое разделение команд разработки различных ИТ-систем, свой огородик с заборчиком трехметровой высоты, колючая проволока и мины для соседей.
Фирма-аутсорсер не производит ИТ-продукт, а продает услуги заказной разработки ПО. ИТ-продукта нет, а разработка есть. Милое дело жонглировать разработчиками между разными заказами для тушения пожаров и перепродажи одного разработчика в разные заказы одновременно. Совсем другой стиль управления.
Фирмы-аутстаферы вообще отдельная песня.
И все это непродуктовая разработка и не очень продуктовый подход.
На этом спринте команда напилит фичу в Oracle Siebel CRM, на следующем спринте их уже ждет PM, отвечающий за Oracle ERP, а самой продуктивной команде дадут покоммитить в ядро Oracle Database два спринта подряд. Вечером можно в Java virtual machine пару оптимизаций впилить. И ведь есть ИТ-продукты в полный рост и продуктовый подход к разработке есть.
А в Яндексе хоть каждый день меняй команды между поисковиком и такси.
Как говорится, one size fit them all. Везде библиотечный подход, типовые кубики.
Сначала проведем задуманные организационные изменения, потом договоримся о правилах оценки их результатов, а уж затем по факту посчитаем сколько на это ушло денег/времени и какая случилась выгода/экономия. Если в конце случится fail и ситуация станет хуже чем до, то строго посмотрим на того, кто придумал эти изменения и не будем слушать его идеи три месяца. Best practices менеджмента. Рекомендовано к использованию в крупных компаниях.
Добрый день, коллега
И Вам искреннее спасибо за труд.
Хочется ж сразу ./gradlew build и чтобы работало.
Готов дальше пробовать и помочь написать кусочек документации, чтобы сделать жизнь пользователей проще.
Шикарно. Рад Вас встретить.
Спасибо за Ваш труд.
Если сподвигнусь продолжить писать продолжение статьи, то приду к вам на github обсудить текущий дизайн и идеи по улучшению/изменению.
Уважаемый автор
Работал в трех больших компаниях. Устройство ИТ сильно отличается от приведенных Вами схем.
Большие компании (мы же обсуждаем компании со штатом развития ИТ в несколько тысяч сотрудников и более?) с разным бизнесом (а бизнес бывает не только продуктовым) по-разному структурируют и управляют своим ИТ. Было бы здорово четко описать границы применимости Вашей идеи.
В статье, к большому сожалению, не приведено ни одного измеримого показателя "лучше/хуже" при сравнении подходов, а так же статистики, показывающей, что описанные ограничения действительно являются ключевыми/критичными для бизнеса значимого количества ИТ компаний.
Как уже писали в других комментариях, было бы здорово почитать о результатах применения описанного подхода в Вашей компании
>producer.send(new ProducerRecord(topicName, split[0]));
Вот так записывать в Кафку плохо. Вы не анализируете результат работы метода send. Либо нужно вторым параметром передать Callback, либо у полученной в результате вызова Future вызвать метод get.
И да, Windows — неподдерживаемая платформа и на ней из-за особенностей файловой подсистемы кафка вряд ли будет нормально работать в ближайшее время.