Но смотрите.
Оркестрация помогает и нужна тогда, когда имеется ряд повторяющихся (!) действий с инфраструктурой, который требует большого количества усилий технических специалистов.
Например, каждый деплой занимает человеко-дни, а хотелось бы минуты или в крайнем случае часы с учетом подготовки.
Добавление нового сервера — боль.
И т.д. и т.п.
И занимается этим всем штат в Н человек.
Что же мы видим:
Что у вас есть? У вас есть on premise решение на фиксированном и маленьком (!) числе серверов.
Какие проблемы и сложности вы испытывали? Нагрузка. Об остальном ни слова
Сколько типов различных нагрузок у вас есть? Скорее всего ровно 3 — посетители, обновление контента, какая-нибудь статистика.
Какое поле для маневра имеется? А никакого. Вы не можете отрезать мощности, например, от расчета статистики в тот момент когда она у вас не считается… Все что вы можете это подстраивать обновление и статистику под основную нагрузку которую вам создают пользователи.
Вам точно тут прямо кровь из носу нужна оркестрация ценой 8 человеко-месяцев (это без учета усилий команды)?
И ваши специалисты стоят явно не дешевле типового мидла на фултайм, верно?
Так что мы имеем в итоге?
Какую техническую проблему вы решили?
А какую проблему бизнеса?
P.S. чисто для справки CDN снижает до 90% нагрузку на типичный новостной сайт/блог.
Заводится за пару дней усилиями 1.5 землекопов
А это означает что в общем случае существовавшего решения продукту хватило бы еще на годы с учетом развития (если там действительно 75к хитов в сутки)
Вот уже после сентенции о переезде на k8s как способе повышения производительности решения можно смело увольнять авторов идеи.
Переезд можно рассматривать как способ улучшения управления инфраструктурой — да. Но об этом внезапно в целях ни слова…
Дальше больше. Сервера в один клик и быстро докупить выйдет не у каждого провайдера. В общем случае время реакции до пары недель играючи… Вы для кого "раз и подкинули сервер" пропагандируете?
Для идиотов?
Таким образом можно и метрики производительности иметь на единицу деплоя.
И знать сколько ресурсов потребуется.
И настроить алертинг на количество запросов/занятых воркеров, чтобы получить сигналы о том, что нужно подкинуть дровишек (железа, виртуалок, подов).
Да нет, пожалуй. Это с таким уровнем абстрагирования действительно сложно понять разницу между первым и вторым.
Нас не интересует разомкнутая цепь или нет. Равно как и с кем там общается данная конкретная розетка.
Для внешнего мира она представляет рабочий интерфейс доступа к электрической сети.
Эта электрическая сеть может быть и 110 и 220, постоянного или переменного тока — для розетки в целом не суть важно.
Она либо выполняет свою функцию, либо не выполняет. На жизнь прочих розеток она не влияет (отсутствие иерархии).
В случае же с автомобилем, то отказ двигателя превращает весь автомобиль в тыкву (наличие иерархии).
Вам выше уже указали, что основная ваша сложность — это неспособность разделить когда именно монолит может состоять более чем из одной части и продолжать быть монолитом
Если красиво спрятать провода, то будет монолит получается?
Это ваши выводы. И они ошибочны как и предыдущие.
Вот розетки в рамках нормальной сети одной квартиры вполне себе микросервисы.
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко.
Вы не поверите, но и автомобиль, и электроника — это зачастую куча разных микросервисов,
Не поверю.
Потому что именно из такого понимания, которое на самом деле непонимание и вырастают проблемы при работе с микросервисами.
Большинство подсистем в автомобиле несамостоятельны и встроены в иерархию. Именно поэтому он в целом монолит.
Тогда как клубок проводков с картинки выше это именно клубок независимых проводков.
Так что, как мы только что выяснили, одной лишь логики (возможно конкретно вашей) совсем недостаточно для тех трех утверждений, которые вы себе позволили.
Если вкратце.
То нет — не взлетят ваши микросервисы с таким пониманием.
Вопросы к переосмыслению вами ваших же тезисов:
Откуда взяты «шансы»? Можно ознакомиться с этим статистическим анализом?
Чем большая непонятно как работающая, но одна штуковина сложнее в управлении десятков простых непонятно как связанных штуковин? Hint:
vs
Откуда информация про сложности добавления новых возможностей не завязанных на уже существующие реализации?
И да, что дороже функциональное тестирование монолитного приложения или связки из десятков/сотни микросервисов? А почему?
Далеко ходить не надо. На одном соседнем проекте, изначально разрабатывавшемся как микросервисный, через год разработки пошли разговоры о том что надо все переписать заново.
Как-то это крайне далеко от идеологии микросервисов.
Старая картинка
Так вот точка пересечения по моим личным практическим ощущениям лежит где-то за десятками человек-лет разработки проекта.
Много у нас таких проектов встречает среднестатистический разработчик?
Но смотрите.
Оркестрация помогает и нужна тогда, когда имеется ряд повторяющихся (!) действий с инфраструктурой, который требует большого количества усилий технических специалистов.
Например, каждый деплой занимает человеко-дни, а хотелось бы минуты или в крайнем случае часы с учетом подготовки.
Добавление нового сервера — боль.
И т.д. и т.п.
И занимается этим всем штат в Н человек.
Что же мы видим:
Вам точно тут прямо кровь из носу нужна оркестрация ценой 8 человеко-месяцев (это без учета усилий команды)?
И ваши специалисты стоят явно не дешевле типового мидла на фултайм, верно?
Так что мы имеем в итоге?
Какую техническую проблему вы решили?
А какую проблему бизнеса?
P.S. чисто для справки CDN снижает до 90% нагрузку на типичный новостной сайт/блог.
Заводится за пару дней усилиями 1.5 землекопов
А это означает что в общем случае существовавшего решения продукту хватило бы еще на годы с учетом развития (если там действительно 75к хитов в сутки)
Вот уже после сентенции о переезде на k8s как способе повышения производительности решения можно смело увольнять авторов идеи.
Переезд можно рассматривать как способ улучшения управления инфраструктурой — да. Но об этом внезапно в целях ни слова…
Дальше больше. Сервера в один клик и быстро докупить выйдет не у каждого провайдера. В общем случае время реакции до пары недель играючи… Вы для кого "раз и подкинули сервер" пропагандируете?
Для идиотов?
В таком ключе даже пример блого-апи предложенного в статье как, якобы каноничный не соответствует определению REST данному в статье же.
Другой вопрос, что определение дано неверное…
А в суде сидят не «какие-то мужики» внезапно?
Таким образом можно и метрики производительности иметь на единицу деплоя.
И знать сколько ресурсов потребуется.
И настроить алертинг на количество запросов/занятых воркеров, чтобы получить сигналы о том, что нужно подкинуть дровишек (железа, виртуалок, подов).
Хайлоад это когда вы не в состоянии обычным кодом обслужить все на одном сервере приложения.
И, да, это жутко раздражает.
Из любимого как раз тот самый http-client
Удобный интерфейс решения конфликтов.
И функции рефакторинга.
Нас не интересует разомкнутая цепь или нет. Равно как и с кем там общается данная конкретная розетка.
Для внешнего мира она представляет рабочий интерфейс доступа к электрической сети.
Эта электрическая сеть может быть и 110 и 220, постоянного или переменного тока — для розетки в целом не суть важно.
Она либо выполняет свою функцию, либо не выполняет. На жизнь прочих розеток она не влияет (отсутствие иерархии).
В случае же с автомобилем, то отказ двигателя превращает весь автомобиль в тыкву (наличие иерархии).
Вам выше уже указали, что основная ваша сложность — это неспособность разделить когда именно монолит может состоять более чем из одной части и продолжать быть монолитом
А независимость и одноранговость при небольшой функциональности.
Миллиарды инсталяций windows не делают ее микросервисом.
И, да, если у вас без корзины не работает магазин — не делайте ее микросервисом. Это в целом бессмысленно.
Разве что для единообразности подхода.
Это ваши выводы. И они ошибочны как и предыдущие.
Вот розетки в рамках нормальной сети одной квартиры вполне себе микросервисы.
От того что откажет одна/пять/десять из розеток всем остальным не холодно и не жарко.
Не поверю.
Потому что именно из такого
понимания, которое на самом деле непонимание и вырастают проблемы при работе с микросервисами.Большинство подсистем в автомобиле несамостоятельны и встроены в иерархию.
Именно поэтому он в целом монолит.
Тогда как клубок проводков с картинки выше это именно клубок независимых проводков.
Так что, как мы только что выяснили, одной лишь логики (возможно конкретно вашей) совсем недостаточно для тех трех утверждений, которые вы себе позволили.
То нет — не взлетят ваши микросервисы с таким пониманием.
Вопросы к переосмыслению вами ваших же тезисов:
vs
Далеко ходить не надо. На одном соседнем проекте, изначально разрабатывавшемся как микросервисный, через год разработки пошли разговоры о том что надо все переписать заново.
Как-то это крайне далеко от идеологии микросервисов.
Старая картинка
Так вот точка пересечения по моим личным практическим ощущениям лежит где-то за десятками человек-лет разработки проекта.
Много у нас таких проектов встречает среднестатистический разработчик?
Пока мой потолок по нагрузке в карьере это 7млн уникальных посетителей в сутки (у хабра меньше, существенно меньше).
И да, это был обычный монолит на десятках инстансов со временем эволюционировавший в SOA.
P.S. Даже онлайн-магазин может состоять более чем из одной частей — склад, бухгалтерия, логистика, crm…
Сложный вопрос.
Как лучше?
Один метод save() или два add() & update()?
Конкретно по enum решение простое.
Объявить первым undefined и появится возможность определить было оно задано или нет