Все началось с простого вопроса, заданного Ерахмиэлем Фельцманом: Эксперты по DBT — знаете ли вы SQLMesh? Как они сравниваются? Имеет ли смысл начинать с ним новый (небольшой) проект вместо DBT, чтобы воспользоваться преимуществами DBT, в которых отсутствуют функции, включенные в SQLMesh, как указано в ссылке ниже? «https://sqlmesh.readthedocs.io/en/stable/comparisons/»
Как часть элитных программистов, работающих в Тикале, я часто сталкиваюсь с подобным вопросом. Я не имею в виду обычный вопрос о сравнении двух зрелых проектов, таких как Liquibase или Flyway. Вопрос, о котором я говорю, заключается в сравнении зрелого программного продукта с альтернативным, но менее известным программным продуктом.
Вопрос ниже
В интернете полно статей, сравнивающих что-либо сравнимое и даже несравнимое. Итак, когда кто-то задает подобный вопрос, что он на самом деле спрашивает? На мой взгляд, чаще всего основной вопрос звучит так:
«Что я упускаю из того, что видят все остальные?»
Обычная дилемма
Давайте поставим два программных продукта рядом и перечислим плюсы и минусы.
Зрелое программное обеспечение, ну, оно зрелое. Меньше ошибок, надеюсь, большое сообщество, большая поддержка поставщиков, много знаний и статей в Интернете, вы поняли. Одним словом: Уверенность!
Более новое программное обеспечение, ну, оно новое! Не на 100% отшлифовано, еще не все функции, есть баги, но реальная проблема - отсутствие документации. Я не имею в виду «документацию», я имею в виду статьи, блоги и твиты, с помощью которых люди делятся проблемами, хитростями и обходными путями. Это проблема. Одним словом: Раннее внедрение!
Так зачем вообще это рассматривать?
Мой ответ на его вопрос (выше) был следующим:
«Выглядит интересно, но давно проиграл гонку с DBT. Поскольку все внедряют DBT, а инструментарий растет взрывными темпами, я думаю, что SQLMesh, каким бы интересным и/или хорошим он ни был, будет отставать только по этой причине. Настоящий вопрос заключается в том, нужны ли вам «отсутствующие» функции в DBT и без чего вы не можете жить, и не была ли эта функция решена/добавлена с помощью какого-либо инструмента.».
Давайте разберем ответ очень быстро. С моей точки зрения, нет ничего плохого в том, чтобы опробовать новое программное обеспечение или не использовать зрелое программное обеспечение, если причина такого решения основана на заслугах, а не на предвзятости.
Выбирая стек технологий, вы фактически выбираете путь, который, по вашему мнению, лучше всего подходит для вашего продукта с течением времени.
Намного легче плыть по течению. Вы просто используете зрелое и хорошо документированное программное обеспечение, вы знаете то, что знаете, и почти ничего не знаете. Даже если выбранное программное обеспечение не совсем соответствует вашим потребностям, оно может быть даже излишним для вашего варианта использования, вы все равно чувствуете себя в безопасной зоне, и это главное! Или это?
Пища для размышлений
Помимо упомянутых выше недостатков, необходимо учитывать и другие проблемы, которые могут пролить более позитивный свет на новое программное обеспечение.
Будучи новым, разработчики нового программного обеспечения могли иметь
- Учился на ошибках и проблемах, с которыми приходилось сталкиваться сообществу при использовании предыдущего программного обеспечения.
- Устранено множество проблем, существовавших в предыдущем продукте.
Новое программное обеспечение может удивить и в других областях:
- это может даже выглядеть как улучшенная версия предыдущего программного обеспечения,
- он может даже точно соответствовать вашим потребностям.
Более того, это может прийти с новым, свежим, хотя и небольшим, но ярким и энтузиастом сообщества.
Я имею в виду
Был когда-то этот клиент, которому нужна была очередь сообщений. Никаких очередей сообщений в стиле сумасшедшего трафика с низкой задержкой и высокой доступностью. Что-то простое. Они выбрали Кафку, конечно. Почему? Потому что сегодня это де-факто стандартная очередь сообщений. И им даже не нужна была настойчивость, или ровно один раз, или что-то в этом роде.
Почему все до сих пор настаивают на использовании Apache Kafka, когда есть много других жизнеспособных вариантов, таких как Apache Pulsar, NATS или даже RabbitMQ?
Или например
Я работаю с Apache Airflow уже некоторое время. Это отличное программное обеспечение. Действительно великолепный. Я помню, как организации начали его использовать, несмотря на то, что он был полон ошибок и вылетал через день. Но даже сегодня я не могу определить разные кодовые базы для Airflow, и у меня даже нет тестовой среды на моей единственной установке Airflow. И есть еще более неприятные основные проблемы, которые давно решили другие, более новые оркестраторы рабочих процессов.
Почему мы все еще используем Apache Airflow, когда есть много других альтернатив, таких как Prefect, Dagster, Flyte и Mage, и это лишь некоторые из них?
Что, если бы вы могли просто пойти по менее проторенной дороге и дать шанс новому стеку технологий?
Мы не знаем, чего мы не знаем
Вот что он написал в ответ:
Интересная точка зрения. Это более или менее тот же аргумент против Polars (по Pandas), Mage, Prefect и Dagster (по Airflow), Redpanda (по Kafka)… ну вы поняли.
Тем не менее, люди по какой-то причине продолжают продвигать эти новые инструменты. и в конце концов они могут одержать верх. Кстати, стоит знать, что DBT Labs тоже пришлось уволить много людей... так что кто знает, что готовит будущее.
«https://www.getdbt.com/blog/dbt-labs-update-a -сообщение-от-генерального директора-тристана-хэнди/. Если мне действительно нужен инструмент, похожий на DBT, я бы начал с DBT, так как в настоящее время он используется по умолчанию, но я бы попытался сравнить постфактум. (Насколько мне известно, в SQLMesh есть встроенный преобразователь DBT-в-SQLMesh :-))”
Главный вывод из его ответа заключается в том, что он тоже не воспринимает стек зрелых технологий как должное, а скорее обсуждает все доступные варианты, исходя из достоинств и потребностей. Выбрать менее проторенную дорогу может быть непросто. Это путешествие в неизвестность, решение проблем, на которые вы можете не найти ответа в Stackoverflow. Но, с другой стороны, это может быть правильным решением для вас!
Страх выставить себя дураком не может быть фактором в процессе принятия решений.
Нижняя граница
Я всегда буду рассматривать новый стек технологий, если он соответствует следующим условиям:
- Программное обеспечение активно поддерживается, и есть своевременные выпуски
- Это FOSS с текущими активными клиентами/пользователями крупных брендов.
- Все основные необходимые функции поддерживаются, чтобы я мог даже подумать об этом.
- Он точно соответствует моим потребностям, а не только как побочный эффект.
- Он решает одну или несколько проблем, с которыми сталкивается стек основных технологий.
Лучшие практики
Это то, что отличает элитных программистов. Мы готовы пробовать что-то новое, и мы готовы решать новые проблемы по мере их возникновения и бросать нам вызов. Страх неудачи не диктует нашу приверженность совершенству. Для нас выбор основного варианта только потому, что он является основным, не является достаточной причиной для выбора стека технологий.
Я многому научился за свои 25 с лишним лет, занимаясь этим. Независимо от того, какой стек технологий вы выберете, за него всегда придется платить. Вопрос только в том, получите ли вы, заплатив цену, технологический стек, который отчасти соответствует вашим потребностям, или же вы получите технологический стек, который соответствует вашим потребностям на 100%.
