Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
Обычная и самая распространенная ошибка новых стартапов — плохая начальная проработка архитектуры. По-принципу — «быстренько начнем писать, а потом разберемся». Как правило в последствии — это ведет к краху проекта.
А можно узнать есть ли у вас какя-то статистика на этот счёт?
Я в вопросе не очень разбираюсь, но неоднократно слышал, что причны провала стартапов не технические. Например, направильное понимание рынка, решение несуществующих проблем, плохоая модель монетизации и т.д.
Т.е. архитектура проекта — это, конечно, хорошо, но на успех или неуспех стартапа влияет слабо.
Более того, оверинжиринг (хороший пример показан в статье) зачастую приводит к тому, что разработка mvp затягивается на какие — то неадекватные сроки из-за необходимости поддерживать все эти навороты.
При том, что я сильно на стороне бизнеса (в противоположной от архитектурных стронафтов), не увидел в статье явного overengineering. Нормальная архитектура, не сильно сложнее ХХИВП, но заметно стабильнее.
Хотя на ровном месте, мускуль кластер, lxc вместо докера, выбор компонентов исходя из производительности, а не удобства, решение несуществующих проблем, введение технологий по принципу «чтобы было». Как это все вы называете? по мне так это классический оверинжиринг, — код писать ещё не начал, а инфраструктуру уже поддерживать надо.
> мускуль кластер
это что, сложно?
> lxc вместо докера
честно говоря, я под lxc подразумевал докер. если нет — зря
> выбор компонентов исходя из производительности, а не удобства
где?
> решение несуществующих проблем, введение технологий по принципу «чтобы было»
детали плз
это что, сложно?
> lxc вместо докера
честно говоря, я под lxc подразумевал докер. если нет — зря
> выбор компонентов исходя из производительности, а не удобства
где?
> решение несуществующих проблем, введение технологий по принципу «чтобы было»
детали плз
> это что, сложно?
Проблема не в кластере, проблема в мускуле. Вы выбрали базу, потому что у нее есть воркбенч. Выбирать базу исходя из инструментария, а не из из схемы хранения — считаете допустимо для «высоконагруженных» ситстем?
> я под lxc подразумевал докер
lxc != docker. Докер — это инструментарий для управления контейнерами. lxc — это технология, на которой не только докер основан. И вы что, автор чтобы что-то там подразумевать?
> выбор компонентов исходя из производительности, а не удобства
тут
> решение несуществующих проблем
решается конфигом композера
А вот и конкретное обозначение проблемы, решение которой в рамках поставленной задачи не требуется, более того далее по статье предполагается разнесение по разным машинам контейнеров, а значит вся эта работа — в помойку.
Проблема не в кластере, проблема в мускуле. Вы выбрали базу, потому что у нее есть воркбенч. Выбирать базу исходя из инструментария, а не из из схемы хранения — считаете допустимо для «высоконагруженных» ситстем?
> я под lxc подразумевал докер
lxc != docker. Докер — это инструментарий для управления контейнерами. lxc — это технология, на которой не только докер основан. И вы что, автор чтобы что-то там подразумевать?
> выбор компонентов исходя из производительности, а не удобства
тут
Обмен сообщениями между компонентами системы происходит не на классическом RabbitMQ, а на NATS — последний показал бенчмарки на сервере который сейчас используется, 1M сообщений (+360К при кластеризации) в секунду против 40К у зайца. Да и кластеризуется он быстрее и легче чем RabbitMQ.
> решение несуществующих проблем
Масштабирование: все компоненты системы собраны в LXC контейнерах, пока перед которыми стоит балансер HAProxy.
решается конфигом композера
И всю схему проекта необходимо создавать изначально закладывая легкий перенос на более мощное и распределенное оборудование. Это позволит в будущем легко найти баланс между масштабированием «железом» и кодом, не увеличивая кратно расходы.
А вот и конкретное обозначение проблемы, решение которой в рамках поставленной задачи не требуется, более того далее по статье предполагается разнесение по разным машинам контейнеров, а значит вся эта работа — в помойку.
> Вы выбрали базу
Я?
> считаете допустимо для «высоконагруженных» ситстем
Возможно я излишне вольно трактую посыл автора статьи, но мне кажется нормальным выбрать достаточно универсальное мейнстримное решение на этапе, когда специфика проекта еще не выявлена. Я трактую примерно в духе «взять что-то, что в среднесрочной перспективе не доставит геморроя, при этом не тратя на это много времени». Честно не понимаю, где тут люди видят сложность и перенавороченность предлагаемого набора.
> lxc != docker
Я это прекрасно понимаю.
> И вы что, автор чтобы что-то там подразумевать?
Подразумевал при прочтении. Если автор имеет в виду именно голый LXC — соглашусь, зря он так.
> выбор компонентов исходя из производительности, а не удобства
> Да и кластеризуется он быстрее и легче чем RabbitMQ.
Ээээ
Я?
> считаете допустимо для «высоконагруженных» ситстем
Возможно я излишне вольно трактую посыл автора статьи, но мне кажется нормальным выбрать достаточно универсальное мейнстримное решение на этапе, когда специфика проекта еще не выявлена. Я трактую примерно в духе «взять что-то, что в среднесрочной перспективе не доставит геморроя, при этом не тратя на это много времени». Честно не понимаю, где тут люди видят сложность и перенавороченность предлагаемого набора.
> lxc != docker
Я это прекрасно понимаю.
> И вы что, автор чтобы что-то там подразумевать?
Подразумевал при прочтении. Если автор имеет в виду именно голый LXC — соглашусь, зря он так.
> выбор компонентов исходя из производительности, а не удобства
> Да и кластеризуется он быстрее и легче чем RabbitMQ.
Ээээ
> мне кажется нормальным выбрать достаточно универсальное мейнстримное решение на этапе, когда специфика проекта еще не выявлена.
Ну если вам кажется что базу надо выбирать исходя из «универсальности» и «мейнстримности», а не исходя из организации хранения, миграций, надежности, необходимых типов данных и прочих технических требований к нагруженным системам, то пусть кажется дальше. Только не лезьте, пожалуйста в вопросы в которых вы не компетентны.
> Ээээ
Что эээ? Вы привели цитату где человек решает несуществующую проблему. Как это опровергает мою цитату, поясните, пожалуйста.
Ну если вам кажется что базу надо выбирать исходя из «универсальности» и «мейнстримности», а не исходя из организации хранения, миграций, надежности, необходимых типов данных и прочих технических требований к нагруженным системам, то пусть кажется дальше. Только не лезьте, пожалуйста в вопросы в которых вы не компетентны.
> Ээээ
Что эээ? Вы привели цитату где человек решает несуществующую проблему. Как это опровергает мою цитату, поясните, пожалуйста.
> и прочих технических требований к нагруженным системам
Обычно на начальном этапе _технических_ требований почти никаких, и надо чтобы оно просто работало и не создавало геморрой.
> Только не лезьте, пожалуйста в вопросы в которых вы не компетентны.
Хехе, забавный вывод, оставлю без комментариев.
> разработка mvp затягивается на какие — то неадекватные сроки
> выбор компонентов исходя из производительности, а не удобства
а теперь вы мне доказываете что на этапе mvp надо выбирать исходя из производительности? где логика? и где логика в том, что вы критикуете выбор NATS как выбор исходя из производительности, при том, что автор указал, что и по удобству ему NATS кажется более предпочтительным
Обычно на начальном этапе _технических_ требований почти никаких, и надо чтобы оно просто работало и не создавало геморрой.
> Только не лезьте, пожалуйста в вопросы в которых вы не компетентны.
Хехе, забавный вывод, оставлю без комментариев.
> разработка mvp затягивается на какие — то неадекватные сроки
> выбор компонентов исходя из производительности, а не удобства
а теперь вы мне доказываете что на этапе mvp надо выбирать исходя из производительности? где логика? и где логика в том, что вы критикуете выбор NATS как выбор исходя из производительности, при том, что автор указал, что и по удобству ему NATS кажется более предпочтительным
чтобы нам понять друг друга, надо ввести временные, а еще точнее этапные горизонты. На горизонте стартапа — вы правы однозначно. А вот на горизонте, когда это уже проект в продакшене — я видел прекрасные проекты, которые умирали из-за архитектуры. Становились не рентабельны и легко обходились конкурентами.
И ещё вопрос.
Почему вы считаете представленную архитектуру удачной?
(хотя мне кажется, что это не архитектура вовсе, а просто набор технологий)
Почему вы считаете представленную архитектуру удачной?
(хотя мне кажется, что это не архитектура вовсе, а просто набор технологий)
а что по вашему IT архитектура, если не набор технологий — картинка с домом?))
Часто под архитектурой системы подразумевает разбиение всей системы на компоненты, определение правил взаимодействия между компонентами. Выбор конкретной технологии для реализации компонентов и связей — тоже часть архитектуры, но это уже второй шаг (хоть и тесно связан с первым).
Если проводить аналогию со строительством, то вы вместо плана здания составили список возможных материалов для использования.
Фактически вы взяли уже готовую архитектуру проекта Billingolang и заменили в ней используемые части. Исследование интересное, но как-то неправильно называть это «созданием архитектуры».
Если проводить аналогию со строительством, то вы вместо плана здания составили список возможных материалов для использования.
Фактически вы взяли уже готовую архитектуру проекта Billingolang и заменили в ней используемые части. Исследование интересное, но как-то неправильно называть это «созданием архитектуры».
почему удачной — потому что она быстрее из всех других перепробованных 6 моделей. И не дорога как в создании, так и в обслуживании.
Архитектура — это не про перечисление используемых языков/фреймворков, а про взаимосвязь компонентов. Компонентами могут быть как элементы бизнес-процессов в общем виде, так и модули/интерфейсы в более конкретном виде.
На самом деле, это просто наметки какие-то, а не архитектура. И да, к краху стартапа ведет прежде всего бизнесовые просчеты — неспособность продать пусть даже невостребованный сервис, или неспособность найти инвесторов. А технические проблемы будут в любом случае. Как бы не продумывали архитектуру.
Символичнее всего то, что при всех технических наворотах в репозитории нет ни строчки кода.
Болтать — не мешки ворочить…
Болтать — не мешки ворочить…
Мускуль, lxc контейнеры, масштабирование горутинами. Не знаю, какая у вас нагрузка, но когда она станет действительно высокой, вас ждут сюрпризы. Хотя один с горутинами вы уже обнаружили.
стартап на то и стартап, чтобы быстро начать, реализовать первые фичи, и т.п… пока все обдумается и архитектура построится — идея станет не актуальной, или ктото перед вами займет этот стул…
… не стартапом единым… а вообще, самая распространенная ошибка — решать проблемы которых не существует…
На предыдущей работе была задача сделать последовательную очередь обработки данных (golang):
1. массив структур через канал заполняется данными одной горутиной
2. другая горутина постепенно выбырает данные по таймауту
3. самому главному программисту\со-овнеру показалось, что это класическая очередь, начали городить сначала Redis + RabbitMQ, потом уговорил их что редиса достаточно (хотя по факту ни то ни другое не нужно)
4. основной аргумент главного в пользу редиса+ребита, внимание: мы не хотим показаться лохами, нужно заюзать крутые технологии… (дословно из чата)… понятно да?
5. самое интересное, чуть позже кейс изменился, из пачки данных (то что в стеке), нужно было выбрать сначала самые свежие… и все что строилось пришлось выбросить и сделать как полагалось изначально: тупая структура с 3мя методами (читать, писать, взять первый), на ребит, в пустую, ушло 2 недели (!!!)… потому что решали выдуманые задачи…
так и с масштабированием или предвременной оптимизацией бывает…
PS: а архитектуры в статье так и не увидел… вы бы потрудились хотя бы на схеме проиллюстрировать.
Обычная и самая распространенная ошибка новых стартапов ...
… не стартапом единым… а вообще, самая распространенная ошибка — решать проблемы которых не существует…
На предыдущей работе была задача сделать последовательную очередь обработки данных (golang):
1. массив структур через канал заполняется данными одной горутиной
2. другая горутина постепенно выбырает данные по таймауту
3. самому главному программисту\со-овнеру показалось, что это класическая очередь, начали городить сначала Redis + RabbitMQ, потом уговорил их что редиса достаточно (хотя по факту ни то ни другое не нужно)
4. основной аргумент главного в пользу редиса+ребита, внимание: мы не хотим показаться лохами, нужно заюзать крутые технологии… (дословно из чата)… понятно да?
5. самое интересное, чуть позже кейс изменился, из пачки данных (то что в стеке), нужно было выбрать сначала самые свежие… и все что строилось пришлось выбросить и сделать как полагалось изначально: тупая структура с 3мя методами (читать, писать, взять первый), на ребит, в пустую, ушло 2 недели (!!!)… потому что решали выдуманые задачи…
так и с масштабированием или предвременной оптимизацией бывает…
PS: а архитектуры в статье так и не увидел… вы бы потрудились хотя бы на схеме проиллюстрировать.
Rust, же не смотря на формальное отсутствие состояния гонки, все-таки более подходит не для написания приложений, но драйверов и операционных систем.
Не совсем понимаю, почему вы так считаете. Аргументируйте это пожалуйста. Потому что на мой взгляд это не так и вот почему:
1) Rust подходит для разработки во многих других областях, помимо написания драйверов и операционных систем. Для того, чтобы убедиться в этом, можно взглянуть, какие компании используют его: https://www.rust-lang.org/production/users. У него есть все необходимые инструменты для этого.
2) Хорошая статья с более подробной аргументацией: https://habr.com/en/post/434200/
Просто оставлю здесь цитату:
Концепции раста очень мощные, и отлично работают на уровне прикладных приложений, которые не задумываются о производительности, но скорее только о продуктивности разработчиков, скорости внедрения новых фич и простоты поддержки. Очень грустно наблюдать, что такой отличный во всех отношениях язык всё больше получает клеймо "странного и сложного языка для низкоуровневых гиковских задач". Надеюсь, я немного пошатнул этот вредный миф, и в мире станет на сколько-то более продуктивных и счастливых разработиков больше.
3) В нашей компании успешно используется Rust в продакшене, и это не разработка ОС и драйверов. И используется не в стиле "написали утилиту небольшую", это огромнейший кусок серверной части.
Изначально были откинуты однопоточные системы. Выбирать пришлось между Erlang, Golang и Rust.
1. Это не системы, а языки
2. Выбирать пришлось явно не из-за ограниченности остальных ЯПов. Можно было сразу написать — проект написан на Golang
рутинг будет переделан на kataras/muxie — он в два раза быстрее.Обратите внимание на минимальное значение вертикальной оси на графиках. Не в 2 раза быстрее, а примерно на 5-10%.
> высоконагруженные системы
> MySQL
Вы серьёзно? :) В действительно высоконагруженных системах MySQL если и используется, то редко и в связке с кучей других nosql решений для горячих данных.
Пассаж про самую распространённую ошибку тоже неверен. Даже с технической точки зрения, самая распространённая ошибка — это плохая коммуникация между бизнесом и техотделом. В итоге первые плохо формулируют хотелки, а вторые их плохо реализуют. Неудачная архитектура лишь одна из частностей. В целом качество кода для успеха проекта сильно переоценено.
Ну и да, выше уже написали что архитектура это не технологии, а общая структура решения и взаимодействие между компонентами (гуглить «системное мышление», уже потом — книги по архитектуре IT-проектов)
> MySQL
Вы серьёзно? :) В действительно высоконагруженных системах MySQL если и используется, то редко и в связке с кучей других nosql решений для горячих данных.
Пассаж про самую распространённую ошибку тоже неверен. Даже с технической точки зрения, самая распространённая ошибка — это плохая коммуникация между бизнесом и техотделом. В итоге первые плохо формулируют хотелки, а вторые их плохо реализуют. Неудачная архитектура лишь одна из частностей. В целом качество кода для успеха проекта сильно переоценено.
Ну и да, выше уже написали что архитектура это не технологии, а общая структура решения и взаимодействие между компонентами (гуглить «системное мышление», уже потом — книги по архитектуре IT-проектов)
MySQL — а uber? https://habr.com/ru/company/southbridge/blog/322624/
В Убере наверняка ещё много других решений используется помимо MySQL. Да и в целом я бы не стал приводить в пример компанию, которая за три года до этого перешла с MySQL на PostgreSQL, а теперь делает обратный переход. Ребята просто видимо слабо понимают что им нужно, либо застряли в парадигме прошлого опыта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание архитектуры для нового высоконагруженного стартапа в 2019