История изменений

А кто сказал преимущества? Ну первое реальное преимущество(а может и последнее), что я знаю и с чем сталкивались - проект получил сильно льготные условия для размещения в aws. Его выбили инвесторы по какой-то программе, так глубоко в шоубизнес я не проникал, у меня отчество не Борисович, а фамилия не Шаломов, поэтому не знаю как получают такие льготы. Но по сути, где-то год проект не достигая определённой нагрузки, пользовался aws почти бесплатно.

Ну а дальше не то чтобы преимущества, а целый ад и израиль:) Система состоит из сервисов(которые почему-то зовут микросервисами, но настоящие(то есть микро, потому что пишут то микро, то жирнющие сервисы с мегатоннами логики и простынями) микросервисы писать никто не умеет, поэтому пишут сервисы по стилю всё это напоминает старую добрую CORBA, но на nodejs и kafka. Каждый сервис в своём контейнере, сервисов штук 200-300. Каждый деплоится отдельно, для поддержания работоспособности всего этого нужно хотя бы 3х девопсов фултайм, потому что кто-то может заболеть и вообще работы ручной там вагон. И там не то что админить, devops он всё это дело программирует, то есть он полноценный член комманды, занимающийся написанием кода для инфраструктуры. Тут работает простое правило - чем больше сущностей, тем больше работы. Помимо того, что из-за количества сущностей это бешеный ад с точки зрения развёртывания, так это ещё ад с точки зрения разработки, потому что поднять весь этот рой сервисов локально для разработки - та ещё задачка и отнимает слишком много времени. Поэтому добро пожаловать в https://www.telepresence.io/ .

Стоит ли оно того? Ну теоретически, если комманда и правда из хороших кадров, разбитие среднего проекта на скажем не 300, а 10-20 сервисов, которые могут иметь множество инстансев и согласованно работать с базами - даст возможность держать очень высокую нагрузку. Но так работают издревле все высоконагруженные проекты задолго до моды микросервисов. А вот если сервисов у среднего проекта 300 и более, то факапов будет дохрена, а выхлопа мало. Потому что слишком много сущностей, наверняка один, два или десять сервисов вообще не будут уметь работать согласованно с базой в количестве 10 или 20 экземпляров. Вплоть до забивания базы говнов или просто отказа в обслуживании из-за гонок.

На практике, если комманда и правда из хороших кадров, то грамотное профилирование среднего или крупного проекта, затем выделение узких мест и переписывание их в зависимости от условий нужным образом(где-то может просто надо код php переписать на С, а базу поменять скажем на oracle, а где-то код выделить в сервисы и заставить работать нужное количество экземпляров сервисов в зависимости от нагрузки) - решит все проблемы. При этом и разработка будет удобной, и аренда обычных серверов будет дешевле обходится и обслуживать удастся больше клиентов в минуту. Иными словами ничего нового не придумали за последние лет 30.

А кто сказал преимущества? Ну первое реальное преимущество(а может и последнее), что я знаю и с чем сталкивались - проект получил сильно льготные условия для размещения в aws. Его выбили инвесторы по какой-то программе, так глубоко в шоубизнес я не проникал, у меня отчество не Борисович, а фамилия не Шаломов, поэтому не знаю как получают такие льготы. Но по сути, где-то год проект не достигая определённой нагрузки, пользовался aws почти бесплатно.

Ну а дальше не то чтобы преимущества, а целый ад и израиль:) Система состоит из сервисов(которые почему-то зовут микросервисами, но настоящие микросервисы писать никто не умеет, поэтому пишут сервисы по стилю всё это напоминает старую добрую CORBA, но на nodejs и kafka. Каждый сервис в своём контейнере, сервисов штук 200-300. Каждый деплоится отдельно, для поддержания работоспособности всего этого нужно хотя бы 3х девопсов фултайм, потому что кто-то может заболеть и вообще работы ручной там вагон. И там не то что админить, devops он всё это дело программирует, то есть он полноценный член комманды, занимающийся написанием кода для инфраструктуры. Тут работает простое правило - чем больше сущностей, тем больше работы. Помимо того, что из-за количества сущностей это бешеный ад с точки зрения развёртывания, так это ещё ад с точки зрения разработки, потому что поднять весь этот рой сервисов локально для разработки - та ещё задачка и отнимает слишком много времени. Поэтому добро пожаловать в https://www.telepresence.io/ .

Стоит ли оно того? Ну теоретически, если комманда и правда из хороших кадров, разбитие среднего проекта на скажем не 300, а 10-20 сервисов, которые могут иметь множество инстансев и согласованно работать с базами - даст возможность держать очень высокую нагрузку. Но так работают издревле все высоконагруженные проекты задолго до моды микросервисов. А вот если сервисов у среднего проекта 300 и более, то факапов будет дохрена, а выхлопа мало. Потому что слишком много сущностей, наверняка один, два или десять сервисов вообще не будут уметь работать согласованно с базой в количестве 10 или 20 экземпляров. Вплоть до забивания базы говнов или просто отказа в обслуживании из-за гонок.

На практике, если комманда и правда из хороших кадров, то грамотное профилирование среднего или крупного проекта, затем выделение узких мест и переписывание их в зависимости от условий нужным образом(где-то может просто надо код php переписать на С, а базу поменять скажем на oracle, а где-то код выделить в сервисы и заставить работать нужное количество экземпляров сервисов в зависимости от нагрузки) - решит все проблемы. При этом и разработка будет удобной, и аренда обычных серверов будет дешевле обходится и обслуживать удастся больше клиентов в минуту. Иными словами ничего нового не придумали за последние лет 30.