Почему крупному бизнесу невыгодно поддерживать интернет-магазин на Битриксе: выбираем альтернативу
В статье на примерах проанализируем затраты на обслуживание крупного интернет-магазина на 1С-Битрикс и на фреймворке Python. Сравним стоимость и выгоды, связанные с внедрением новых функций, оценим стоимость содержания команд на разных стеках и разберём, на чём экономически выгодно поддерживать и расширять крупный интернет-магазин. Дополнительн…
16K16K показов
3.3K3.3K открытий
33 репоста
Большинство тезисов в вашей статье мне кажутся сугубо рекламными:
1. Любой крупный магазин тяжело поддерживать, действительно крупные магазины сейчас идут по связке микросервисы: GO + Docker + Kubernetes.
Не PHP (Bitrix) и не Python (Django). Но здесь вопрос что считать действительно крупным магазином и откуда в вашем понимании начинается HighLoad.
2. При наличии более-менее "пряморуких" программистов нет никаких проблем с проверкой гипотез на Битрикс.
В Битрикс есть Маркетплейс, в котором большое кол-во модулей на все случаи жизни почти, скачивай и пользуйся, да их нужно проверять на производительность и безопасность.
3. "когда 1С-Битрикс уже кастомизирован настолько, что готовые модули нельзя брать, потому что логика оплаты переписана целиком."
На мой взгляд нельзя "полностью" кастомизировать ключевые вещи:
- Платежные системы
- Способы доставки
- Корзина
- Каталог
- Работу с заказами
- Работу с пользователями
- Работу с ядром CMS
Вы просто потом не сможете обновлять Битрикс, что крайне нежелательно.
В значительном числе случаев вы сможете взять модуль поставщика из маркетплейса, если он есть там, а у всех крупных сервисов он есть, и кастомизировать его под свои цели,
так как практически всегда идет взаимодействие по REST API с сервисами поставщика.
И это не потребует точно тех расходов что у вас указаны в часах работы для интеграции условного Mindbox, а если и потребует, то сумма итоговая точно не больше чем для Django будет.
По поиску разработчиков с Битриксом как раз ситуация гораздо проще, так как вся основная бизнес логика прописана и вам не надо "изобретать" архитектурных решений, так как всё изобрели за вас.
Т.е. условный middle разработчик в большинстве случаев понимает что и как должно работать.
И смена разработчиков гораздо проще, если делали более менее по их стандартной архитектуре.
Мне не очень понятны ваши выкладки по стоимости работы разработчиков, очень сильно сомневаюсь что разработчик на Django будет дешевле чем на Битрикс.
Я понимаю для чего это делается, вы придумаете полностью свое решение, в котором только вы будете понимать что и как работает с 50 страницами схем в miro
и сотнями страниц тех документации. Модернизировать это сможете только вы и ваша команда, и вас будет нереально заменить как подрядчика, только опять писать полностью новый сайт.
1. Это из вашего опыта или можно где-то ещё про это почитать? Интересно стало
2. Тут ещё вопрос стоит с точки зрения, где искать "более-менее пряморуких программистов". Я довольно часто слышу о том, как тяжело их найти) Если у вас небольшой ИМ, где стандартные задачи — наверное больших проблем не будет, а если надо делать реально сложные штуки, задача сильно усложняется.
3. У нас был кейс клиента как раз такой, у него были довольно сложные бизнес-процессы и ИМ на битриксе, под которые нужно было сильно менять ключевые вещи, часть из перечисленных. Они их меняли до какого-то момента, а потом стало очень сложно. И в будущем требовалось сильно масштабировать интернет-магазин. В итоге приняли решение перенести его на Симфони, для клиента это принесло ряд ощутимых преимуществ)
https://creonit.ru/cases/novex/
Я понимаю для чего это делается, вы придумаете полностью свое решение, в котором только вы будете понимать что и как работает с 50 страницами схем в miro и сотнями страниц тех документации.
Абсолютли. Мне кажется, что только вот эта часть даже на 90% нигде не реализована. Это такой геморой, все это сначала описать, потом поддерживать актуальность информации. По сути несколько отдельных человек, которые будут просто крыжить закрытые таски, и выдергивать из них информацию что сделали, где сделали, и когда сделали. И не джуны, а мидл-сеньеры которые не кодят, а только пишут доки. И над ними кто-то, кто валидирует эту информацию на выходе. То есть с точки зрения бизнеса, такая структура скорее всего будет послана нафиг (если это не майкрософт, у которого очень много денег)