Flynn: почему не цуру?

Об этом говорили на голанг-орешках . У меня сложилось впечатление, что, хотя некоторые функции похожи, основные цели различны.

/ cc @fsouza

@titanous Я видел эту

Я считаю, что объединение двух проектов будет лучше для этого проекта и упростит создание более сильного сообщества для создания и поддержки этого нового проекта (tsuru + flynn), как это произошло с rails + merb.

В настоящее время мы работаем над более полной спецификацией, в которой будут подробно описаны компоненты и цели, которые мы планируем. Я думаю, что было бы конструктивно отложить это обсуждение до тех пор, пока мы не продвинем этот документ.

В заключение, я думаю, теперь более ясно, в чем разница.

Какие отличия? Мне непонятно, есть ли какой-нибудь источник, который вы могли бы порекомендовать, который объясняет всю выполняемую работу PaaS?

Я пытался понять это путем исследований, но я продолжаю узнавать о том, что все больше и больше систем PaaS создается с помощью Docker, все кажется действительно фрагментированным; очень сложно за ней угнаться ... Каждая из этих систем требует времени и самоотверженности для настройки и опробования, прежде чем можно будет действительно узнать, что это такое - есть ли более простой способ познакомиться со всеми проектами, происходящими в этой пространство без того, чтобы оно длилось так долго и не превратилось в бесконечную кроличью нору?

Судя по тому, что я видел до сих пор, Флинн выглядит довольно мило - я очень рад его скоро попробовать.

PS Я попал сюда, погуглил "tsuru flynn"

@keyvanfatehi Спасибо за

Трудно быть в курсе всех существующих проектов PaaS, тем более что многие следуют частным или непоследовательным дорожным картам. В общем, вот в чем, по нашему мнению, различия между Flynn и большинством других проектов PaaS (не прямое сравнение с tsuru, а просто пространство в целом):

Флинн более амбициозен. Флинн может запускать все, что работает в Linux, включая службы с отслеживанием состояния. Мы пользуемся этой возможностью для упаковки общих баз данных вместе с Flynn, поэтому большинство пользователей и проектов больше никогда не будут управлять базами данных вручную. Компоненты Flynn имеют модульную структуру, что упрощает их повторное использование, изменение и замену для создания правильного решения для ваших нужд. Мы действительно хотим, чтобы Флинн был единым набором инструментов, который «решает» задачи для каждого проекта и организации. Впереди еще много всего, включая агрегирование журналов, метрики, непрерывную интеграцию, а также решения нового поколения для работы в сети и разработки.

Большинство других проектов PaaS относятся как минимум к одному из следующих: сложно / медленно настраивать и развертывать, полезно только для определенных типов приложений, требует от разработчиков повторной архитектуры своих приложений и является монолитным. Короче говоря, мы считаем, что Флинн пытается решить сложные проблемы, а большинство других проектов этого не делает из-за своего возраста, существующей базы пользователей и мотивации к дизайну.

По мере того, как Флинн достигает производственной стабильности и завершения функций, мы постараемся задокументировать различия для каждого проекта.

@danielsiders спасибо! Я с нетерпением жду возможности увидеть, как вы, ребята, вводите новшества в этой сфере. Я определенно страдаю от того, что на мои плечи ложится слишком много операций (вот почему я смотрю на Docker и инструменты вокруг него). Хочется верить, что опс можно как бы решить ...

До сих пор мой опыт использовал flynn-demo (успешно), который, казалось, был похож на deis (который я не пробовал напрямую, но у них есть хорошее зацикленное видео, показывающее поведение, подобное герою). Итак, на этом поверхностном уровне deis, flynn и heroku кажутся идентичными.

Это хороший момент в отношении частных дорожных карт - я думаю, что, может быть, для меня еще немного рано ожидать, что я буду обдумывать все это. Кажется, намного проще просто посвятить себя тому или иному усилию, чем пытаться отслеживать, различать различия и пытаться оценивать каждое усилие ... каждое из них является инновационным и интересным!

в любом случае, захватывающие времена - спасибо за участие в том, чтобы все это произошло, даже если я еще не могу полностью это понять :)

@keyvanfatehi большинство PaaS поддерживает развертывание приложений в стиле Heroku (git push). На самом деле все отличается от типа приложений, которые можно развернуть, и того, что происходит после развертывания приложения.

(Примечание: Флинн также поддерживает многие другие парадигмы развертывания, такие как docker pull и git pull и все, что вы хотите создать. Даже FTP не составит труда)

@keyvanfatehi , в Tsuru мы считаем, что было бы более эффективно требовать некоторых небольших изменений приложения (например, конфигурации по среде и использования объектного хранилища для статических файлов), потому что вам неизбежно придется спроектировать свое приложение так, чтобы оно соответствовало парадигме облака ( например: его нужно без проблем масштабировать по горизонтали). Но мы сделали это так хорошо, что наши пользователи получают это в очень быстром темпе, у нас уже есть продукты, работающие здесь (на Globo.com).
Что касается сервисов, они слишком специфичны, чтобы их можно было хорошо обрабатывать с помощью одного приложения (представьте, насколько сложно будет иметь дело с базами данных, nosql, redis, memcached, elasticsearch, хранилищем объектов и т. Д.). Мы предпочли указать api службы (где будет размещена бизнес-логика для обработки службы), и tsuru будет работать с любой службой одинаково, независимо от того, насколько они разные.

Мы очень дружелюбны и полностью открыты для предложений и новых идей. Мы по-прежнему думаем, что было бы здорово работать с flynn в едином решении (мы могли бы расширить tsuru, чтобы в будущем встретить идеал flynn), но мы полностью уважаем их мнение и видение, поскольку они такие же амбиции, как и наши :-)

TL; DR
Мы знаем, насколько важны услуги, поэтому разрабатываем элегантный способ удовлетворить это требование. Tsuru может обрабатывать любую службу с четко определенным API службы (с некоторыми простыми точками входа, такими как создание, удаление, привязка, планирование). Таким образом, вся сложность конкретной службы будет обрабатываться ее собственным service-api. Давайте рассмотрим пример нашего Redis API: когда вы запускаете # tsuru service-add redis (servicename) redis_blognews (serviceinstancename) plus (plan), он создает экземпляр redis с именем redis_blognews и планом плюс (который предоставляет 2 экземпляра Redis с высокой доступностью). Цуру не знает, как он будет создан (даже если он будет иметь высокую доступность), он будет полностью обрабатываться service-api. Это также позволяет использовать внешние (даже проприетарные) сервисы, просто создав для этого сервис-api, не касаясь кода tsuru. Таким образом, будет гораздо более гибко работать со службами и избежать увеличения сложности в Tsuru. После этого вы можете использовать # tsuru bind redis_blognews --app yourblognewsapp, и tsuru добавит учетные данные службы в ваше приложение.

Я новичок в PaaSes, и это сбивает с толку. Я выбрал Цуру и немного возился с этим. Мне кажется, это не так уж и отличается от целей Флинна. Вы можете запускать объекты с сохранением состояния, используя их сервисный API, и он очень модульный, где у вас есть tsuru-api, docker-cluster, gandalf и т. Д.

Я все еще сомневаюсь, что объединение усилий принесет лучший продукт.

Я должен согласиться с @msabramo здесь, я все еще не вижу ничего хорошего в том, зачем создавать новый PaaS, который имеет все функции Tsuru. Я также согласен с тем, что объединение усилий даст отличный продукт.