Kuby-core: Какие приложения мы должны (не) развертывать с помощью Kuby?

Созданный на 8 окт. 2020  ·  5Комментарии  ·  Источник: getkuby/kuby-core

Привет,

было бы неплохо сказать где-нибудь (я нигде не видел, поправьте меня, если я ошибаюсь), какое приложение мы должны и не должны развертывать с Kuby.

Я полагаю, развертывание хобби-приложения в EKS может обойтись дорого? Никогда не использовал его, но на их веб-сайте написано: You pay $0.10 per hour for each Amazon EKS cluster that you create. , что составляет около 72 долларов США в месяц, верно? Не уверен, что это связано с серверами, базами данных и прочим.

В этом случае что-то вроде Dokku или Heroku обойдется намного дешевле.

В любом случае, такой разговор, вероятно, должен быть не только о деньгах, но и о технических излишествах в целом и так далее.

Все 5 Комментарий

Привет, @hovancik. Вы абсолютно правы, в документации не так много информации о различных облачных провайдерах и их стоимости. Я подумывал добавить в документацию матрицу ценообразования, но решение по развертыванию на самом деле не имеет ничего общего с облачным провайдером. Представьте, например, что вы задаете тот же вопрос Капистрано :)

Kuby предназначен для развертывания вашего приложения в любом кластере Kubernetes, независимо от облачного провайдера и его стоимости. Вы, как разработчик, должны быть свободны в выборе облачного провайдера, который лучше всего соответствует вашим потребностям. Например, я бы не стал выбирать EKS или Azure для хобби или личного проекта — это слишком дорого. Для EKS 72 доллара в месяц, о которых вы упомянули, буквально только для плоскости управления Kubernetes и не включают стоимость каких-либо вычислительных ресурсов, блочного хранилища и т. д. Вместо этого я бы выбрал DigitalOcean или Linode, которые намного дороже -эффективный (около 20 долларов США в месяц за экземпляр с 4 ГБ ОЗУ и 2 ЦП) и дает вам плоскость управления бесплатно. Если вы являетесь частью бизнеса, который хочет использовать некоторые из других многочисленных сервисов AWS или Azure, то, возможно, EKS — правильное решение для вас. Дело в том, что вы можете выбирать. Куби это не волнует — он предназначен для работы везде.

Тем не менее, было бы полезно увидеть матрицу ценообразования в документации? Я не решаюсь добавить его, потому что 1) причины, перечисленные выше, 2) цены часто меняются и 3) я не хочу заниматься рекомендацией облачных провайдеров или восприниматься как предпочтение одного перед другим.

Мысли?

Привет @camertron , да, матрица ценообразования - плохая идея.

Как говорится в заголовке, я пытаюсь спросить: какие приложения нам (не) следует развертывать с помощью Kuby? В некотором смысле: опишите инструмент с точки зрения работы :)

Я начал с hobby vs professional ( =money) , потому что это просто, но я хотел бы услышать больше о том, какие приложения вы ищете. Является ли это излишним для простого серверного приложения rails с db? Или это идеальный кандидат? Или чем сложнее приложение, тем лучше этот инструмент будет для разработчиков?

Может быть, я неправильно понимаю, и это предназначено для всех видов приложений? Вы знаете, я ищу такие страницы, где написано use this tool if и don't use this tool if :)

Ах хорошо, я понимаю, что вы имеете в виду. Я бы сказал, что Kuby предназначен для всех типов приложений, но, безусловно, есть некоторые типы, которые выиграют от него больше, чем другие. Вам, вероятно, лучше использовать бесплатный динамометр Heroku для очень маленького приложения, которое не видит много трафика и которое управляет только несколькими сотнями (или меньше) строк базы данных. Дело не в том, что Kuby — плохой выбор для таких типов приложений, просто вы, скорее всего, потратите меньше денег и меньше умственных способностей на настройку Heroku. Их довольно сложно превзойти по простоте. Однако Heroku начинает дорожать, когда вам нужно больше ресурсов, и я обнаружил, что, вообще говоря, управляемый кластер Kubernetes с одним узлом, развернутым с помощью Kuby, более рентабельн, чем эквивалентная установка Heroku. Да, Kuby требует больше интеллектуальных усилий для настройки (опять же, довольно сложно превзойти git push heroku master ), но гибкость, которую вы получаете в результате, того стоит, ИМХО.

Kuby также может оказаться неправильным выбором для очень больших, сильно настраиваемых приложений, которые значительно отклоняются от соглашений Rails. Я уверен, что вы могли бы заставить Kuby работать с такими приложениями, но это, вероятно, означало бы большую настройку Kuby. Для этого вам, вероятно, потребуется более глубокое понимание того, как работают Docker, Kubernetes и Kuby. Я предполагаю, что это сводится к тому, насколько вы готовы инвестировать время в изучение технологий.

Возможно, лучше всего сказать, что Kuby был разработан, чтобы обслуживать ту же аудиторию, что и сам Rails, и его следует рассматривать как находящийся на том же уровне, что и активная запись, активное хранилище и т. д. очень маленькое приложение, и вы также можете разумно сказать, что оно мешает вам в большом, сделанном на заказ приложении. Active Record разработан для того, чтобы абстрагироваться от сложностей взаимодействия с базой данных, и Kuby предназначен для того, чтобы сделать то же самое для развертывания. Оба поставляются, как любит говорить DHH, с включенными батареями.

Спасибо! Какая-то форма этого, вероятно, должна быть где-то в Интернете :)

Согласен, спасибо, что подняли этот вопрос @hovancik :)

Была ли эта страница полезной?
0 / 5 - 0 рейтинги