Тут соглашусь, микросервис тоже может быть legacy вполне. Подкорректировал слоган на главной, чтобы избежать двоякого толкования. Спасибо что обратили внимание.
Наиболее по нашему опыту не травматичный путь миграции с монолита на микросервисы - это постепенное отчуждение кусочков бизнес-логики в отдельные сервисы, запущенные рядом с монолитом. Здесь Deckhouse удобен тем, что позволяет, например, запустить виртуальную машину под монолит (или, скажем, под базу данных) в одном пространстве имён с контейнерами. Таким образом, вам не нужно на время миграции (которое, кстати говоря, может быть довольно продолжительным) поддерживать две разные инфраструктуры и решать вопросы сетевой связности между ними.
Всем привет, я из команды Deckhouse! Немного подушню по технической части:) Про похожесть хотел добавить, что Deckhouse тоже умеет развёртывать кластеры заранее описанной топологии «по кнопке» — за это отвечает Deckhouse Commander. Также в Deckhouse есть модули для настройки политик безопасности, аудита и поиска угроз, сканирования на уязвимости и запуска CIS Benchmark-проверок.
Второй момент. Deckhouse — это Open Source. То есть мы можем включать компоненты под GPL в состав своей платформы, и ту же Grafana не придется ставить отдельно. Здесь и плюшки вроде открытого роадмапа, возможности повлиять на разработку, контрибьютить в проект, использовать бесплатную Community-версию. В итоге никакого vendor lock и все довольно прозрачно.
У Deckhouse множество публично подтвержденных инсталляций на самых разных по нагрузке инфраструктурах — их можно увидеть на сайте проекта. А по GitHub и разным вопросам в чате можно судить о том, что его активно использует сообщество. При этом самый большой клиент Deckhouse — это мы сами, у нас в обслуживании более 250 клиентских кластеров. То есть тестировать и собирать фидбэк мы можем даже на своих проектах. В итоге мы просто вынуждены дописывать разные фичи вроде продвинутых дашбордов с разбивкой ответов ingress по http-кодам 1xx — 5xx, выпускать по десять-двадцать минорных релизов платформы в год, поддерживать в каждом релизе Deckhouse по пять последних версий Kubernetes, обновлять платформу целиком, а не каждый компонент по отдельности. Это для нас вопрос нормальной работы.
Ну и за пять лет мы успели дописать кучу фичей, которых в других российских заменителях OpenShift просто нет в силу их молодости. Тот же модуль виртуализации, который позволяет запускать legacy-код на виртуалках прямо рядом с контейнерами, реплицируемое блочное хранилище на базе LINSTOR или Service mesh на базе Istio.
Да, но не в сторону сравнения) После жарких внутренних диспутов мы в итоге отказались от подготовки публичных сравнений с конкурентами, т.к. все продукты не стоят на месте, и мы решили не тратить ресурсы на поддержание сравнения в актуальном состоянии. А без этого оно устареет примерно сразу, и это тем более waste of time. Вместо этого мы сосредоточились на решении пользовательских задач.
На самом деле зависит. По ссылке есть калькулятор, который показывает, что 10 VM входят в стоимость обслуживания сразу, а каждая последующая добавляет $20 к стоимости. Если посмотреть на красную линию на графике (а лучше не просто посмотреть, а приложить лист бумаги например;), то можно заметить, что линия переламывается и после десятой ноды цена начинает расти быстрее.
Тут соглашусь, микросервис тоже может быть legacy вполне. Подкорректировал слоган на главной, чтобы избежать двоякого толкования. Спасибо что обратили внимание.
Наиболее по нашему опыту не травматичный путь миграции с монолита на микросервисы - это постепенное отчуждение кусочков бизнес-логики в отдельные сервисы, запущенные рядом с монолитом. Здесь Deckhouse удобен тем, что позволяет, например, запустить виртуальную машину под монолит (или, скажем, под базу данных) в одном пространстве имён с контейнерами. Таким образом, вам не нужно на время миграции (которое, кстати говоря, может быть довольно продолжительным) поддерживать две разные инфраструктуры и решать вопросы сетевой связности между ними.
Всем привет, я из команды Deckhouse! Немного подушню по технической части:) Про похожесть хотел добавить, что Deckhouse тоже умеет развёртывать кластеры заранее описанной топологии «по кнопке» — за это отвечает Deckhouse Commander. Также в Deckhouse есть модули для настройки политик безопасности, аудита и поиска угроз, сканирования на уязвимости и запуска CIS Benchmark-проверок.
Второй момент. Deckhouse — это Open Source. То есть мы можем включать компоненты под GPL в состав своей платформы, и ту же Grafana не придется ставить отдельно. Здесь и плюшки вроде открытого роадмапа, возможности повлиять на разработку, контрибьютить в проект, использовать бесплатную Community-версию. В итоге никакого vendor lock и все довольно прозрачно.
У Deckhouse множество публично подтвержденных инсталляций на самых разных по нагрузке инфраструктурах — их можно увидеть на сайте проекта. А по GitHub и разным вопросам в чате можно судить о том, что его активно использует сообщество. При этом самый большой клиент Deckhouse — это мы сами, у нас в обслуживании более 250 клиентских кластеров. То есть тестировать и собирать фидбэк мы можем даже на своих проектах. В итоге мы просто вынуждены дописывать разные фичи вроде продвинутых дашбордов с разбивкой ответов ingress по http-кодам 1xx — 5xx, выпускать по десять-двадцать минорных релизов платформы в год, поддерживать в каждом релизе Deckhouse по пять последних версий Kubernetes, обновлять платформу целиком, а не каждый компонент по отдельности. Это для нас вопрос нормальной работы.
Ну и за пять лет мы успели дописать кучу фичей, которых в других российских заменителях OpenShift просто нет в силу их молодости. Тот же модуль виртуализации, который позволяет запускать legacy-код на виртуалках прямо рядом с контейнерами, реплицируемое блочное хранилище на базе LINSTOR или Service mesh на базе Istio.
С открытым исходным кодом в этом отношении их не так много...Deckhouse, например.
Да, но не в сторону сравнения) После жарких внутренних диспутов мы в итоге отказались от подготовки публичных сравнений с конкурентами, т.к. все продукты не стоят на месте, и мы решили не тратить ресурсы на поддержание сравнения в актуальном состоянии. А без этого оно устареет примерно сразу, и это тем более waste of time. Вместо этого мы сосредоточились на решении пользовательских задач.
На самом деле зависит. По ссылке есть калькулятор, который показывает, что 10 VM входят в стоимость обслуживания сразу, а каждая последующая добавляет $20 к стоимости. Если посмотреть на красную линию на графике (а лучше не просто посмотреть, а приложить лист бумаги например;), то можно заметить, что линия переламывается и после десятой ноды цена начинает расти быстрее.