Чем хорош Open Source

Выпуск эпизода подкаста про проприетарный ETL инструмент от компании SAP под названием SAP BW вызвал не только заметные дискуссии в чате, но и заставил меня самого наконец-то задуматься о том что и почему я думаю о проприетарщине и чем хорош open source.

В начале хочется согласиться с мыслью, что консультант SAP может не хуже любого другого IT-работника прекрасно прокачать различные hard & soft skills и быть виртуозом своего дела и приносить огромную пользу компании, продолжая при этом развиваться в своей области. Знаю нескольких таких очень компетентных и уважаемых мной людей. Однако, при всем при этом нужно сделать очень важную оговорку относительно того, что кто-то, будучи незаинтересованным и некомпетентным, сможет гораздо легче спрятаться за всем этим корпоративным bullshit и разноцветными (иногда черно-серыми) "свистелками" в SAP проектах. И это не просто предположение, а к сожалению личные наблюдения на нескольких проектах SAP. При этом, заниматься тем же самым на проектах с заметной частью open source в стеке, где роли и ожидания от каждого (а следовательно и обязанности в команде) более четкие, таким "зайцам" становится очень сложно. А вот в проектах, где у тебя есть волшебник-консультант, который и требования соберет, и код напишет, и систему настроит, и демо для бизнеса потом проведет это таким "универсалам" побездельничать становится сильно проще. Поэтому я считаю, что объединение нескольких ролей в одну роль консультанта это скорее минус, который при этом может вначале казаться экономией для проекта. Но это все субъективное, у каждого конечно же будет свой взгляд на все эти вещи.

Теперь по поводу самих компаний-вендоров и их проприетарных продуктов в целом. Мое мнение такое, что основная их проблема это:
• излишняя сложность;
• плохая/дорогая масштабируемость;
• и дороговизна.

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

Дальше про масштабируемость. Я тут скорее больше про горизонтальную масштабируемость, потому я считаю именно там огромный корень проблем (опять для бизнеса, конечно же, не для вендора). Где-то есть лимиты на поддерживаемое железо, где хранение данных in memory... Это все не дает возможности организовать достойную параллелизацию нагрузки. Это кстати, пересекается и с предыдущим пунктом про дороговизну — расширять вертикально всегда дороже, чем закидывать дешевым железом горизонтально. И многие, кстати, готовы были бы закрыть на все сказанное глаза, будь возможность докопаться до внутренностей системы и попробовать сделать что-то самому. Но в виду закрытой экосистемы это буквально невозможно. Тебе даются в руки различные способы конфигурации систем под конкретный бизнес, без доступа к внутренностям самих системам. А это для меня немного странно. Я могу понять (принять) какие-то устоявшиеся в индустрии практики ведения бизнеса и необходимость их следования. Но делать вид, что ваш продукт следует последним практикам, и при этом не использует современные технологии и, получается, неоптимально тратит деньги, потраченные на железо — это в моей голове не укладывается. Получается закрытая архитектура и код — это способ спрятать массу проблем от лишних глаз. Многие тут могут сказать про know-how и супер секретные разработки, то давайте будем смотреть правде в глаза, а не выкрикивать заученные юридические реплики.

Ну и наконец подхожу к сложности. Сложность и overengineered архитектура на мой взгляд зашкаливает. Особенно это будет чувствоваться на старых продуктах, которые "как-то" дорабатывались за все годы после их первых релизов. "Как-то" потому что никто не знает как именно. Код-то закрытый! Но чтобы понять сложность не нужно даже заглядывать в код. Я лично знаю/участвовал в нескольких проектах с open source tooling, где работают сотни (в некоторых случаях тысячи) людей, а ETL инструмент и отчетность поддерживается 1-2 инженерами. И это прямо нормальная и легко осуществимая практика сегодня.

На меня возможно даже коллеги ведущие сейчас косо могут посмотреть, но я считаю, что средней компании не нужны даже какой-либо сервер и отдел админов/DBA/devops/etc. чтобы начать что-то делать. Нужен ровно один энтузиаст с заданием, который возьмет Docker, запустит локально нужные сервисы на своем ноутбуке, покажет кому надо. И это все осуществимо за один Agile спринт. Понятно, что для запуска в продакшн нужно будет перенести это куда-то еще. Но для этого в 95% случаев не надо будет ничего переделывать. Тот же (или другой) энтузиаст возьмет уже подготовленные Docker-образы, которые будут теперь крутиться не локально, а где-нибудь в облаке. И все счастливы. Осуществим ли такой Proof of Concept/Proof of Value с проприетарными продуктами при похожих вводных — $0 бюджет на лицензии, $0 бюджет на новое железо, и недельная зарплата инженера)? Для меня лично ответ очевиден.

Ну и в заключение надо добавить, что все выше сказанное хоть и было написано на волне разговоров про ETL-инструменты, но применимо и для любого другого сервиса и приложения. Да, в прошлом было с этим гораздо сложнее. Все эти попытки переноса кода на другой сервер/архитектуру спотыкались на огромное количество проблем и можно было потратить массу времени на исправление всего того и на то, чтобы заставить все работать (да будут благословенны души всех участников проекта Docker). Уверен, в старые времена коробочное решение, которое гарантированно заработает на указанном железе было возможно единственным правильным решением — оно позволяло бизнесу достичь желаемого в кратчайшие предсказуемые сроки с оптимальной для того времени тратой денег. Но, ребята, давайте честно. Те времена ушли. И времена планирования проектов по 2-4 года тоже ушли. Сейчас нужно двигаться, развиваться и меняться быстро. Новые подходы, библиотеки, ML-модели, ETL-инструменты появляются каждый месяц (а то и неделю). Нужно делать сейчас, определять value за один спринт, развивать или выбрасывать решение в следующем спринте в зависимости от текущей ситуации, результатов и удовлетворенности пользователя. Иначе прибыльный бизнес не построить.

Так вижу.

P.S.: кто-то наверное обязательно вспомнит про мою любовь к тому же проприетарному Snowflake, но так ребята, это же временный хайп. Он актуален и приятен сегодня. Ровно до того момента, как появится open source замена аналогичная по простоте, гибкости и удобству. В этот момент Snowflake за те же деньги будет дико невыгоден. И в тот момент нужно будет меняться. Именно о том и статья...