Свою ответственность перед зрителями лучше выражать в качестве сервиса. Последние разы, когда я платил за фильмы на оке, мне приходилось их досматривать на пиратских сайтах, так как в вашем стриме то звук отваливался, то видео зависало. А поддержки пользователей у вас нет как класса — дозвониться вам очень сложно.
Пару лет назад у вас был хороший сервис, но видимо со сменой акционеров вы и на технике и инженерах стали экономить.
Хорошо, безусловно, будет опенсорс вариант доступный on-premises. Все-таки в чем привлекательность опенсорс в данном конкретном случае, если сам вигин изначально предполагается как сервис, который из облака? По такой модели работает, например, bitnami, который тоже имеет доступ ко всему в вашем облаке.
Спасибо за поздравления) Так и есть — смысл wigin именно в том, что он сервис, который не нужно деплоить и поддерживать самостоятельно. При этом при желании, можно развернуть его у себя, он же опенсорсный. Такая концепция интересна? Собственно мы его сюда и выложили, чтобы спросить комьюнити, интересен ли такой сервис.
Wigin будет Open Source. Просто мы сначала запустили его как сервис, чтобы проверить жизнеспособность самой идеи. Сейчас доделаем деплоилку и выложим на github.
Этот сервис для тех, кто деплоит куб на публичные облака. Если серверы и их данные должны быть в изолированном периметре, то это, понятное дело, другой вопрос. Что же касается публичного облака, Вы же не думаете, что провайдеры не имеют доступ к Вашим данным?)
Мы везде по-умолчанию используем пользователя root. Собственно, пользователя может потребоваться вводить только, если вы добавляете ключи на сервер вручную.
К сожалению, там все не так просто, чтобы поднимать композом и в готовых докер контейнерах. Фич то тьма, компонентов соответственно тоже. Может в личных некоммерческих целях лучше пробовать у провайдера? У Русоникса 3 месяца бесплатного использования, потом переходите на Free план, который достаточно вольготный, чтобы запускать не очень нагруженные приложения. При этом вы свободны — захотелось свое, можно поставить свое.
На домашнем сервере это все можно развернуть бесплатно — за некоммерческое (или если вы самостоятельный разработчик и не используете swifty в интересах компании) использование денег не берут. В скором времени зарелизим тулзу, которая позволит развернуть swifty на любое облако, нужно будет лишь скормить ей IP адреса.
Swifty ставится поверх голых ubuntu/fedora, kuber и его окружение мы ставим свой и настраиваем его так, как считаем оптимальным для наших кейсов. Почему мы приносим свой кубер можно посмотреть, например, здесь https://youtu.be/aP_bw255fD4 В принципе, можем поставить и на ваш кубер, но тогда преимуществ описанных в видео выше у вас не будет.
Минимальное число нод зависит от сервисов, которыми вы хотите пользоваться. Полный комплект с HA и мониторингом займет 6 нод или виртуальных машин. На четырех t2.medium на AWS вполне можно потестить. Ставится все парочкой ansible плейбуков, никакого rocket science.
Мы предлагаем Swifty по двум моделям: SaaS и on-premises. Если вам удобнее использовать serverless on prem, то мы с удовольствием поможем вам его развернуть.
Ну извините, мы пишем про свою систему, так как считаем, что она во многих кейсах лучше перечисленных;) А чем свой виск поверх кубера интереснее? Сложностью? Неудобностью? Траблшутингом? А лямбда чем интереснее? Необходимостью делать 10 действий там, где можно сделать одно?)
Вы имеете ввиду несколько функций в одном бинарнике? Или код функции + библиотеки? Вообще концепция serverless предполагает, что отдельная функция выполняет конкретную задачу в приложении и объединять ее с другими в один package особо смысла нет. Как, собственно, и паковать ее в бинарник, так как это делает сама serverless платформа.
Если нужно разворачивать сложное приложение с множеством функций, то для этого у нас есть сущность deployment. Deployment это шаблон, описывающий несколько функций и их обвязку. Пример deploy config для todo приложения github.com/swiftycloud/swifty.demo/blob/master/todoapp.yaml
Свою ответственность перед зрителями лучше выражать в качестве сервиса. Последние разы, когда я платил за фильмы на оке, мне приходилось их досматривать на пиратских сайтах, так как в вашем стриме то звук отваливался, то видео зависало. А поддержки пользователей у вас нет как класса — дозвониться вам очень сложно.
Пару лет назад у вас был хороший сервис, но видимо со сменой акционеров вы и на технике и инженерах стали экономить.
Backend: gitlab.com/wiginio/wigin-core
Dashboard: gitlab.com/wiginio/wigin-ui
Велкам!
Backend: https://gitlab.com/wiginio/wigin-core
Dashboard: https://gitlab.com/wiginio/wigin-ui
Велкам!
Хорошо, безусловно, будет опенсорс вариант доступный on-premises. Все-таки в чем привлекательность опенсорс в данном конкретном случае, если сам вигин изначально предполагается как сервис, который из облака? По такой модели работает, например, bitnami, который тоже имеет доступ ко всему в вашем облаке.
При таком раскладе будет интересно?
Минимальное число нод зависит от сервисов, которыми вы хотите пользоваться. Полный комплект с HA и мониторингом займет 6 нод или виртуальных машин. На четырех t2.medium на AWS вполне можно потестить. Ставится все парочкой ansible плейбуков, никакого rocket science.
Да, так испортить uber, как это сделал яндекс — такого действительно никто не делал.
Мы предлагаем Swifty по двум моделям: SaaS и on-premises. Если вам удобнее использовать serverless on prem, то мы с удовольствием поможем вам его развернуть.
Ну извините, мы пишем про свою систему, так как считаем, что она во многих кейсах лучше перечисленных;) А чем свой виск поверх кубера интереснее? Сложностью? Неудобностью? Траблшутингом? А лямбда чем интереснее? Необходимостью делать 10 действий там, где можно сделать одно?)
Если нужно разворачивать сложное приложение с множеством функций, то для этого у нас есть сущность deployment. Deployment это шаблон, описывающий несколько функций и их обвязку. Пример deploy config для todo приложения github.com/swiftycloud/swifty.demo/blob/master/todoapp.yaml
Планируем сделать для андроид. Пойдет?