AO
Wordpress до сих пор пользуется огромной популярностью, куча инсталляций в 2020
Size: a a a
2020 May 22
AZ
я бы сказал, что если есть задача сделать быстро что-то работающее, то микросервисы не подходят
p
мы спорим про то, что ты предлагаешь выбирать технологии исходя из их подходящести для микросервисной архитектуры, но не можешь точно сформулировать, какую проблему эта архитектура решает и в каких проектах эта проблема есть, а где нет. пока ты приводил только примеры решений задач, порождаемых самой этой архитектурой
+ много. Особенно, на стадии mvp
AO
микросервисы когда полезны? когда нужно масштабировать что-то одно отдельно от чего-то другого.. и когда разработчиков слишком много и все они начинают копаться в том же самом коде и им не нравится следить за изменениями, которые делает каждый из них, они хотят поделить проект между собой и не лезть друг к другу, с микросервисами это проще
AZ
микросервисы когда полезны? когда нужно масштабировать что-то одно отдельно от чего-то другого.. и когда разработчиков слишком много и все они начинают копаться в том же самом коде и им не нравится следить за изменениями, которые делает каждый из них, они хотят поделить проект между собой и не лезть друг к другу, с микросервисами это проще
когда ты делаешь стартап и у тебя разработчиков слишком много, то половину надо уволить, потому что ты тратишь деньги впустую
p
микросервисы когда полезны? когда нужно масштабировать что-то одно отдельно от чего-то другого.. и когда разработчиков слишком много и все они начинают копаться в том же самом коде и им не нравится следить за изменениями, которые делает каждый из них, они хотят поделить проект между собой и не лезть друг к другу, с микросервисами это проще
Как часто ты занимался масштабированием на стадии mvp?
AZ
то есть изначально их не надо столько нанимать
AO
Как часто ты занимался масштабированием на стадии mvp?
на стадии mvp это не требуется
AO
а вот второй пункт (много разработчиков сразу делают 1 большой проект) - вполне валидный кейс, а почему нет?
p
при определённой структуре микросервисы будут вполне естественны с самого начала (если разработчиков больше 1,5 человек, конечно)
this
AO
если их работу можно распараллелить, так критический путь будет короче
AO
ну то есть смотрим на критический путь, если он с 5 разработчиками короче, чем с 2, то лучше 5 разработчиков, чем 2
AO
а почему нет?
p
если их работу можно распараллелить, так критический путь будет короче
Зачем?
AO
чтобы сделать mvp быстрее
AO
если что, я не агитирую за такой подход в каждом проекте, я просто говорю, что есть у такого подхода свои сторонники
AZ
а почему нельзя этих пять разработчиков попросить прекратить ныть и жаловаться, что кто-то из них поменял три строчки в модуле, который написал другой?
AO
когда люди пилят вместе 1 проект, возникает больше холиваров, чем когда каждый пилит свой
AO
когда каждый сам себе царь - делают как им нравятся, споры только про то, что пересекается, вот про API, например, про взаимодействие, а внутри там уже каждый сам себе хозяин
AO
вот Black - это круто или фу?