Комментарии 10
мы наблюдаем тренд на микросервисную архитектуру....
Отдельный сервер Redis
Отдельный сервер MySQL
Отдельный сервер PHP
- всё это - не микросервисы.
В целом статья разочаровала. Много воды, мало по теме. Частные претензии:
Однако, если покопаться в настройках MySQL, то вы получите те же значения, что и на физическом сервере
Это, в лучше случае, самообман. Возьмите физический сервер с SSD‑ или NVMe‑дисками, а затем возьмите облачный, и сравните показатели вставки/изменения/удаления записей.
Сейчас, за счет кэширования базы данных
Кэширование не решает проблем скорости. Кэширование решает проблемы масштабирования. Если у Вас промахи кэша - это 99 случаев из 100, то кэш бесполезен.
использовать микросервисную архитектуру
В случае Битрикса это нерелеватно - функционал "из коробки" не имеет микросервисной архитектуры.
Это, в лучше случае, самообман. Возьмите физический сервер с SSD‑ или NVMe‑дисками, а затем возьмите облачный, и сравните показатели вставки/изменения/удаления записей.
Да вы можете взять физический сервер и получить в нем возможно большие значения чем в облаке. Но будет ли это создавать ощутимую разницу - большой вопрос.
Статья же ведет к проектам, которые уже не могут существовать на монолите и требуют кластеризации. Внедрения кластера БД, распределения запросов, haproxy для отслеживания состояния ноды и какого-нибудь proxySQL для распределения трафика. И вот в этом случае куда проще развернуть облачное решение, чем тянуть его на физических серверах в каком-нибудь ДЦ. При этом облако также несет ответственность за SLA вашего проекта.
Естественно, что если у вас магазин или форум с минимальным количеством трафика, вам не требуется переезжать в облако, вы прекрасно можете существовать на монолите и экономить средства.
Кэширование не решает проблем скорости. Кэширование решает проблемы масштабирования. Если у Вас промахи кэша - это 99 случаев из 100, то кэш бесполезен.
Здесь мы говорим о нашем опыте переезда Битрикс проектов в облачные кластера, и можем вам смело сказать, что потери производительности проекта не было как таковой.
В случае Битрикса это нерелевантно - функционал "из коробки" не имеет микросервисной архитектуры.
Из коробки может Bitrix и не умеет в микросервисную архитектуру. Хотя здесь я не совсем понимаю что вы имеете в виду. Он прекрасно упаковывается в docker контейнеры, перевозится в k8s при должном внимании разработчиков и администраторов, у нас также был и такой опыт в компании.
Здесь все зависит от команд разработки и администрирования, а также требования бизнеса. Если все три понимают, что им нужно масштабирование, то все возможно.
Повторюсь, речь не о проектах, которые имеют минимальный RPS и не имеют потребности в высоком SLA или масштабировании.
Пример 1: У вас магазин экипировки для зимних видов спорта. Летом посещаемость крайне мала, а зимой — наоборот. Соответственно иметь в запасе сервер 96 CPU 256 RAM 365 дней в году нет необходимости.
По поводу цен, - приукрашиваете так, что можно сказать, даже не краснеете.
Во первых, по поводу примера: если сравнить сценарий того, как облачный сервер увеличивает CPU & RAM только на "нагруженный" период, а в остальное время - откатывается к более слабой конфигурации, то постоянно иметь физический сервер с сильной конфигурацией всё равно будет дешевле, чем цена облачного сервера, который меняет конфигурацию. И не надо возиться с изменением конфигурации. И кстати, кто там говорил, что нужно платить специалисту, который будет админить? Вот в случае облачного сервера вы и будете платить спецу, который будет менять настройку облачного сервера, а с физическим сервером этого не требуется.
Во вторых, в статье довольно лукаво сравниваются цены облачных и физических серверов:
16GB RAM у Timeweb Cloud сравниваются с 32GB на физическом сервере
не говорится о том, что на физических серверах трафик обычно неограниченный, а вот на облачных вы будете платить и за сервер и ещё за трафик.
Из личного опыта:
работа в облаке повышает сложность. Требуется дорогие "облачные" специалисты.
цены за услуги становятся непредсказуемыми. Потому что за физический сервер обычно платиться $X/месяц, а за облачный - $A за сервер + $B за трафик + $C за API calls + + +
Сценарии, когда работать в облаке выгодней - существуют, но обычно это когда разрабатывается продукт, которые использует облачные сервисы - S3 бакеты, очереди данных, автоскейлеры, и т.д. А вот просто виртуалку перенести с физического хостинга на виртуальный - бессмысленное занятие.
Во вторых, в статье довольно лукаво сравниваются цены облачных и физических серверов:
Да, прошу прошения. Исправил цену.
И кстати, кто там говорил, что нужно платить специалисту, который будет админить? Вот в случае облачного сервера вы и будете платить спецу, который будет менять настройку облачного сервера, а с физическим сервером этого не требуется.
Изменения конфигурации занимает 1-5 минут и не требует большой квалификации специалиста. Все делается по нажатию кнопки в личном кабинете.
цены за услуги становятся непредсказуемыми. Потому что за физический сервер обычно платиться $X/месяц, а за облачный - $A за сервер + $B за трафик + $C за API calls + + +
Это все можно просчитать и оплачивать по выставленному счету.
Ограничение на трафик было ранее. Сейчас все Дата Центры отказываются от данного ограничения.
Простите за коммент, я не специалист. Занимаюсь канализацией. Но разве это нормально сравнивать and intel просто cpu… ?
да и в целом подача материала, скромно говоря, странная.
статья ради статьи. Облака актуальны уже второй десяток лет. Битрикс и микросервисы в разных вселенных.
Облачный Bitrix: оно того стоит