Это список с ресурса db-engines. Там есть вопросы к классификации, но как правило на этом ресурсе сами вендоры указывают к какому классу относить их БД.
Для этого лучше использовать данные с синтетических тестов для производительности. А вот параметры удобства и т.д., наверное, лучше смотреть в сравнениях конкретных СУБД. Но сама идея взять несколько кейсов и сделать сравнение по типам хорошая, хотя скорее всего будут явные лидеры и много исключений, не попадающих в методологию сравнения.
Никто, но причем тут Data Observability. Elastic (он же Opensearch) - это СУБД + поиск, которая заточена на хранение и поиск по текстовым данным. Так можно хоть в PostgreSQL все сохранять и потом обрабатывать. Просто ни то ни то, не специализированные решения для потоковой алгоритмической обработки данных для поиска разных аномалий.
Скорее специализированными алгоритмами обработки данных (временных рядов, распределений). Airflow - это ETL, для широкого стека задач. А в данных решениях более узкоспециализированные продуктовые кейсы решаются. Правда у всех разные, видимо, под Data Observability каждый свое понимает.
То, как они забили выдачу рекламой, колдунщиками и т.д., явно в долгую не очень конкурентноспособно. Особенно, когда у Google теперь при поиске из РФ вообще нет рекламы. Но будет интересно посмотреть на то, как изменятся доли поисковиков через пару лет. Эксперимент - поисковик загруженный рекламой против поисковика с исключительно органической выдачей.
Юрий, я вам в личные сообщения и в комментарии той статьи написал, что код не приходит либо из-за неверного формата (не +7...), либо у вас иностранный номер (мы добавляем номера стран, но это не быстро. И да - мы начинающая компания, у нас есть недоработки и именно поэтому у на Бета-Тест и мы НЕ берем деньги с пользователей. Мы понимаем, что если вам нужно полностью доработанное решение, то такие есть на рынке, но и условия использования(стоимость) там соответствующие.
Как вариант, можно вместо yaml, Dockerfile использовать. Чуть сложнее чем генератором yaml делать, но можно любое окружение использовать. Это комментарий на случай, если у кого-то не Python, Java или Node JS. Можно дополнить инструкцию еще случаем с Dockerfile - многим будет полезно.
Heroku сейчас недоступна (в плане оплаты) из РФ. Как вариант - можно воспользоваться Amvera Cloud. Это отечественный аналог. Есть поддержка проектов на Java.
Zabbix больше для физических серверов и виртуалок. У нас это решено тем, что часть низкоуровневой инфраструктуры мы используем от крупного провайдера, который за этим следит. Но согласен - Zabbix нужное решение во многих случаях.
Ну тут ведь вопрос не только в цене. Есть и вообще бесплатные VPS/VDS со всеми вытекающими. Классические VPS вам не дадут способа доставки обновлений через push в GIT, и горизонтальной и вертикальной масштабируемости инстанса. А классические облака обычно стоят как "чугунный мост". Тут скорее вопрос в нише. Для "статичных" проектов типа сайтов визиток подойдет любой VPS, для чего-то высоконагруженного и очень сложного облако по типу AWS, а для стейджинга сложного проекта или просто чего-то, что нужно регулярно обновлять Heroku-подобные сервисы c доставкой обновлений одной командой через push.
Ох уж эти новые маркетинговые термины для обозначения старых вещей) Кто-то BaaS называет сервисы "бэкенд как сервис". В этой статье "B" это и Бизнес и Банк. Проще без сокращений обойтись, чтобы когнитивный диссонанс не возникал. А вообще - все что вы описали называется просто - "white label" и известно уже лет 30, и зачем придумывать новые поняти для этого мне лично не понятно!
Если говорить про экономию затрат на DevOps, то это все-таки актуально для крупный проектов, как правило. И тут уже нужен managed k8s, со всем, что вы описали (мониторинг, хелсчеки и т.д.). А это немного другая история. На том же Heroku большинство проектов - это вообще прерываемые контейнеры с холодным стартом и т.д., где крутятся разные боты. Т.е. тут наверное от кейса зависит.
Наш сервис это не аналог kubernetes. У нас размещают небольшие проекты из 1-5 контейнеров (боты и т.д.). И основное в чем фишка - это доствка обновлений через push в GIT. Мы не пересекаемся с потребителями kubernetes, поэтому можем его и ругать и хвалить без задней мысли. Задачи решаемые нашими пользователями и пользователями k8s просто совсем разные.
Может так звучит в статье, и надо бы как-то переформулировать, но конечно нет. Тут же вопрос не в размере, а в архитектуре. И для каких случаев какая подходит лучше.
Это список с ресурса db-engines. Там есть вопросы к классификации, но как правило на этом ресурсе сами вендоры указывают к какому классу относить их БД.
Для этого лучше использовать данные с синтетических тестов для производительности. А вот параметры удобства и т.д., наверное, лучше смотреть в сравнениях конкретных СУБД. Но сама идея взять несколько кейсов и сделать сравнение по типам хорошая, хотя скорее всего будут явные лидеры и много исключений, не попадающих в методологию сравнения.
Никто, но причем тут Data Observability. Elastic (он же Opensearch) - это СУБД + поиск, которая заточена на хранение и поиск по текстовым данным. Так можно хоть в PostgreSQL все сохранять и потом обрабатывать. Просто ни то ни то, не специализированные решения для потоковой алгоритмической обработки данных для поиска разных аномалий.
Elastic это же про обработку/хранение логов и поиск. Т.е. скорее относится к мониторингу работы инфраструктуры.
Скорее специализированными алгоритмами обработки данных (временных рядов, распределений). Airflow - это ETL, для широкого стека задач. А в данных решениях более узкоспециализированные продуктовые кейсы решаются. Правда у всех разные, видимо, под Data Observability каждый свое понимает.
Напишите на support@amvera.ru имя пользователя. Скорее всего там проблема с портом или чем-то подобным.
То, как они забили выдачу рекламой, колдунщиками и т.д., явно в долгую не очень конкурентноспособно. Особенно, когда у Google теперь при поиске из РФ вообще нет рекламы. Но будет интересно посмотреть на то, как изменятся доли поисковиков через пару лет. Эксперимент - поисковик загруженный рекламой против поисковика с исключительно органической выдачей.
Спасибо!)
Юрий, я вам в личные сообщения и в комментарии той статьи написал, что код не приходит либо из-за неверного формата (не +7...), либо у вас иностранный номер (мы добавляем номера стран, но это не быстро. И да - мы начинающая компания, у нас есть недоработки и именно поэтому у на Бета-Тест и мы НЕ берем деньги с пользователей. Мы понимаем, что если вам нужно полностью доработанное решение, то такие есть на рынке, но и условия использования(стоимость) там соответствующие.
У нас пока бесплатно (пока бета-тест). Планируемые тарифы есть в ЛК - пока планируем их оставить, после включения биллинга.
Как вариант, можно вместо yaml, Dockerfile использовать. Чуть сложнее чем генератором yaml делать, но можно любое окружение использовать. Это комментарий на случай, если у кого-то не Python, Java или Node JS. Можно дополнить инструкцию еще случаем с Dockerfile - многим будет полезно.
Heroku сейчас недоступна (в плане оплаты) из РФ. Как вариант - можно воспользоваться Amvera Cloud. Это отечественный аналог. Есть поддержка проектов на Java.
Zabbix больше для физических серверов и виртуалок. У нас это решено тем, что часть низкоуровневой инфраструктуры мы используем от крупного провайдера, который за этим следит. Но согласен - Zabbix нужное решение во многих случаях.
Мы MongoDB и т.д. используем у себя внутри, а не "перепродаем", поэтому тут нет проблемы с лицензией. Для внутренних целей использовать можно)
Ну тут ведь вопрос не только в цене. Есть и вообще бесплатные VPS/VDS со всеми вытекающими. Классические VPS вам не дадут способа доставки обновлений через push в GIT, и горизонтальной и вертикальной масштабируемости инстанса. А классические облака обычно стоят как "чугунный мост". Тут скорее вопрос в нише. Для "статичных" проектов типа сайтов визиток подойдет любой VPS, для чего-то высоконагруженного и очень сложного облако по типу AWS, а для стейджинга сложного проекта или просто чего-то, что нужно регулярно обновлять Heroku-подобные сервисы c доставкой обновлений одной командой через push.
Ох уж эти новые маркетинговые термины для обозначения старых вещей) Кто-то BaaS называет сервисы "бэкенд как сервис". В этой статье "B" это и Бизнес и Банк. Проще без сокращений обойтись, чтобы когнитивный диссонанс не возникал. А вообще - все что вы описали называется просто - "white label" и известно уже лет 30, и зачем придумывать новые поняти для этого мне лично не понятно!
Это скорее инструмент для использования в связке с VPS. Но да, его для облегчения CD можно использовать.
Если говорить про экономию затрат на DevOps, то это все-таки актуально для крупный проектов, как правило. И тут уже нужен managed k8s, со всем, что вы описали (мониторинг, хелсчеки и т.д.). А это немного другая история. На том же Heroku большинство проектов - это вообще прерываемые контейнеры с холодным стартом и т.д., где крутятся разные боты. Т.е. тут наверное от кейса зависит.
Наш сервис это не аналог kubernetes. У нас размещают небольшие проекты из 1-5 контейнеров (боты и т.д.). И основное в чем фишка - это доствка обновлений через push в GIT. Мы не пересекаемся с потребителями kubernetes, поэтому можем его и ругать и хвалить без задней мысли. Задачи решаемые нашими пользователями и пользователями k8s просто совсем разные.
Может так звучит в статье, и надо бы как-то переформулировать, но конечно нет. Тут же вопрос не в размере, а в архитектуре. И для каких случаев какая подходит лучше.