Юрий, я вам в личные сообщения и в комментарии той статьи написал, что код не приходит либо из-за неверного формата (не +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 просто совсем разные.
Может так звучит в статье, и надо бы как-то переформулировать, но конечно нет. Тут же вопрос не в размере, а в архитектуре. И для каких случаев какая подходит лучше.
Я согласен, что микросервисы и Kubernetes не обязательны друг с другом. Как и что и у контейнеров есть свои преимущества, и у виртуалок. Мысль была в том, что вот есть у вас конкретный проект - для него оптимален определенный технологический стек, и не всегда он самый модный. Т.е. лучше ответить себе на вопрос - оно правда нужно? Часто - преимущества перевешивают недостатки, но не всегда. А если принимать решение исходя из моды, можно добавить излишнюю сложность в свой проект не получив преимуществ.
Все можно и нужно, но для разных задач разные инструменты. Можно и монолит в kubernetes запускать, но вопрос - а зачем? Логи, метрики и т.д. вообще полезны, но если у вас простой сервис, который не обновляется и нет "движущихся" частей, скорее всего вы про них не вспомните после настройки. А вот когда что-то сложное, их не использовать - самоубийство. Да и если у вас сервис на одной виртуалке - кажется нанимать SRE в 99% это несколько избыточно, хотя редкие исключения, подтверждающие правило есть всегда.
Чтобы не засыпало и работало всегда - можно воспользоваться Heroku или его Российским аналогом - Amvera Cloud. Это и проще и главное, проект будет приватным и всегда работающим.
Да, инфляция высокая, ФРС поднимает ставку, деньги становятся дорогими. Там деньги сильно дешевле чем у нас, но уже не совсем "бесплатные" как раньше. Рынок сразу охлаждается. Хотя такое охлаждение как там, для СНГ это невиданное эльдорадо доступных ресурсов.
С одной стороны да. Но тут вопрос в долгосрочных перспективах. Кажется, что этичность важна для тех, кто играет вдолгую, на перспективу. Хотя иногда смотришь на некоторые успешные компании, и начинаешь сомневаться в этом утверждении.
Что свои сервера дешевле - это только кажется. Проблема в том, что если вам нужно развернуть отказоустойчивый кластер kubernetes, распределенную СУБД, настроить мониторинг и т.д. для этого нужны узкоспециализированные и дорогие специалисты. И это намного дороже облака где уже все сложное работает "из коробки". Но если у вас "монолит", то да - аренда bare-metal будет сильно дешевле.
Спасибо!)
Юрий, я вам в личные сообщения и в комментарии той статьи написал, что код не приходит либо из-за неверного формата (не +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 просто совсем разные.
Может так звучит в статье, и надо бы как-то переформулировать, но конечно нет. Тут же вопрос не в размере, а в архитектуре. И для каких случаев какая подходит лучше.
Я согласен, что микросервисы и Kubernetes не обязательны друг с другом. Как и что и у контейнеров есть свои преимущества, и у виртуалок. Мысль была в том, что вот есть у вас конкретный проект - для него оптимален определенный технологический стек, и не всегда он самый модный. Т.е. лучше ответить себе на вопрос - оно правда нужно? Часто - преимущества перевешивают недостатки, но не всегда. А если принимать решение исходя из моды, можно добавить излишнюю сложность в свой проект не получив преимуществ.
Все можно и нужно, но для разных задач разные инструменты. Можно и монолит в kubernetes запускать, но вопрос - а зачем? Логи, метрики и т.д. вообще полезны, но если у вас простой сервис, который не обновляется и нет "движущихся" частей, скорее всего вы про них не вспомните после настройки. А вот когда что-то сложное, их не использовать - самоубийство. Да и если у вас сервис на одной виртуалке - кажется нанимать SRE в 99% это несколько избыточно, хотя редкие исключения, подтверждающие правило есть всегда.
Как вариант, можно еще на Render разместить.
Чтобы не засыпало и работало всегда - можно воспользоваться Heroku или его Российским аналогом - Amvera Cloud. Это и проще и главное, проект будет приватным и всегда работающим.
Да, инфляция высокая, ФРС поднимает ставку, деньги становятся дорогими. Там деньги сильно дешевле чем у нас, но уже не совсем "бесплатные" как раньше. Рынок сразу охлаждается. Хотя такое охлаждение как там, для СНГ это невиданное эльдорадо доступных ресурсов.
С одной стороны да. Но тут вопрос в долгосрочных перспективах. Кажется, что этичность важна для тех, кто играет вдолгую, на перспективу. Хотя иногда смотришь на некоторые успешные компании, и начинаешь сомневаться в этом утверждении.
Что свои сервера дешевле - это только кажется. Проблема в том, что если вам нужно развернуть отказоустойчивый кластер kubernetes, распределенную СУБД, настроить мониторинг и т.д. для этого нужны узкоспециализированные и дорогие специалисты. И это намного дороже облака где уже все сложное работает "из коробки". Но если у вас "монолит", то да - аренда bare-metal будет сильно дешевле.