Flynn: por que não tsuru?

Isso foi discutido em nozes de golang . Minha impressão é que, embora alguns dos recursos sejam semelhantes, os objetivos principais são diferentes.

/ cc @fsouza

@titanous eu vi esse tópico. Se a maior diferença entre tsuru e flynn é tsuru ser específico para web, com pouco esforço ele pode ser modificado.

Acredito que se os dois projetos se unirem será melhor para esses projetos e tornará mais fácil construir uma comunidade mais forte para fazer e manter este novo projeto (tsuru + flynn) como o que aconteceu com rails + merb.

No momento, estamos trabalhando em uma especificação mais completa que irá detalhar os componentes e objetivos que estamos planejando. Acho que seria construtivo adiar essa discussão até que empurremos esse documento.

Fechando, porque acho mais claro quais são as diferenças agora.

Quais são as diferenças? Não está claro para mim se existe alguma fonte que você possa recomendar que faça sentido para todo o trabalho de PaaS que está sendo feito?

Tenho tentado descobrir isso por meio de pesquisas, mas continuo aprendendo sobre mais e mais sistemas PaaS sendo feitos com o Docker, as coisas parecem realmente fragmentadas; é muito difícil acompanhá-lo ... Cada um desses sistemas requer tempo e dedicação para configurar e experimentar antes que se possa realmente saber o que é - existe uma maneira mais fácil de se familiarizar com todos os projetos que acontecem neste espaço sem demorar tanto e ser uma toca de coelho sem fim?

Pelo que vi até agora, Flynn parece muito fofo - estou animado para experimentá-lo em breve.

PS Eu cheguei aqui pesquisando "tsuru flynn" no Google

@keyvanfatehi Obrigado pelo seu interesse.

É difícil manter-se atualizado com todos os projetos de PaaS que existem, especialmente porque muitos seguem roteiros particulares ou inconsistentes. Em geral, aqui está o que achamos que são as diferenças entre Flynn e a maioria dos outros projetos PaaS (não uma comparação direta com tsuru, apenas o espaço em geral):

Flynn é mais ambicioso. Flynn pode executar qualquer coisa que seja executada no Linux, incluindo serviços com monitoração de estado. Aproveitamos essa capacidade de empacotar bancos de dados comuns junto com Flynn, para que a maioria dos usuários e projetos nunca mais gerencie manualmente os bancos de dados. Os componentes da Flynn são modulares, o que facilita a reutilização, modificação e substituição para criar a solução certa para suas necessidades. Nós realmente queremos que Flynn seja um único kit de ferramentas que "resolva" operações para cada projeto e organização. Há muito mais por vir, incluindo agregação de log, métricas, integração contínua junto com soluções de próxima geração para fluxos de trabalho de rede e desenvolvimento.

A maioria dos outros projetos de PaaS são pelo menos um dos seguintes: difícil / lento para configurar e implantar, útil apenas para tipos específicos de aplicativos, exige que os desenvolvedores re-arquitetem seus aplicativos e monolítico. Resumindo, acreditamos que Flynn tenta resolver os problemas difíceis e a maioria dos outros projetos não, por causa de sua idade, bases de usuários existentes e motivações de design.

À medida que Flynn atinge a estabilidade de produção e a conclusão de recursos, tentaremos documentar as diferenças por projeto.

@danielsiders obrigado! Estou ansioso para ver vocês inovando neste espaço. Eu definitivamente sofro por ter muitas operações caindo sobre meus ombros (é por isso que estou olhando para o Docker e as ferramentas ao redor dele). Eu gostaria de acreditar que as operações podem ser resolvidas, por assim dizer ...

Até agora, minha experiência tem usado o flynn-demo (com sucesso) que parecia ser como deis (que eu não tentei diretamente, mas eles têm um bom vídeo em loop mostrando comportamento semelhante ao do heroku). Portanto, neste nível raso, deis, flynn e heroku parecem idênticos.

Esse é um bom ponto sobre roteiros privados - acho que talvez seja um pouco cedo para eu esperar entender tudo isso. Parece muito mais fácil se comprometer com um esforço ou outro do que tentar acompanhar, discernir as diferenças e tentar julgar cada esforço ... cada um sendo inovador e interessante!

de qualquer forma, tempos emocionantes - obrigado por fazer parte de fazer tudo isso acontecer, mesmo que eu não consiga entender totalmente ainda :)

@keyvanfatehi a maioria dos PaaS oferece suporte à implantação de aplicativos no estilo Heroku (git push). Onde as coisas realmente diferem são os tipos de aplicativos que podem ser implantados e o que acontece depois que um aplicativo é implantado.

(nota: Flynn também oferece suporte a muitos outros paradigmas de implantação, como docker pull e git pull e qualquer outra coisa que você queira construir. Mesmo o FTP não seria difícil)

@keyvanfatehi , na Tsuru acreditamos que seria mais eficiente exigir algumas pequenas mudanças no aplicativo (como configuração por ambiente e uso de um armazenamento de objeto para arquivos estáticos), porque inevitavelmente você precisará projetar seu aplicativo para se ajustar a um paradigma de nuvem ( por exemplo: ele precisa ser dimensionado horizontalmente sem problemas). Mas fizemos tão bem que nossos usuários conseguiram em um ritmo muito rápido, já temos produtos rodando em produção aqui (na Globo.com).
Sobre os serviços, eles são específicos demais para serem bem tratados com um único aplicativo (imagine como seria difícil lidar com bancos de dados, nosql, redis, memcached, elasticsearch, armazenamento de objetos, etc.). Preferimos especificar uma API de serviço (onde será colocada a lógica de negócios para lidar com o serviço) e tsuru vai lidar da mesma forma com qualquer serviço, não importa quão diferentes sejam.

Somos muito amigáveis ​​e totalmente abertos a contribuições e novas ideias. Ainda achamos que seria ótimo trabalhar com flynn em uma única solução (poderíamos estender tsuru para se encontrar com o ideal flynn no futuro), mas respeitamos totalmente sua opinião e visão, pois são tão ambiciosas quanto as nossas :-)

TL; DR
Sabemos como os serviços são importantes, por isso desenvolvemos uma maneira elegante de lidar com essa necessidade. Tsuru pode lidar com qualquer serviço com uma API de serviço bem definida (com alguns pontos de entrada simples como criar, remover, vincular, planejar). Assim, toda a complexidade de um determinado serviço será tratada por sua própria API de serviço. Vamos dar um exemplo sobre nossa API Redis: ao executar # tsuru service-add redis (servicename) redis_blognews (serviceinstancename) plus (plan), ele criará uma instância redis com o nome redis_blognews e o plano plus (que fornece 2 instâncias de redis com alta disponibilidade). O Tsuru não sabe como será criado (mesmo se tiver alta disponibilidade), será totalmente gerenciado pela API de serviço. Também possibilita o uso de serviços externos (mesmo proprietários) apenas criando uma API de serviço para isso sem tocar no código tsuru. Assim, será muito mais flexível lidar com os serviços e evitar o aumento dessa complexidade no Tsuru. Depois disso, você pode usar # tsuru bind redis_blognews --app yourblognewsapp e tsuru injetará as credenciais de serviço em seu aplicativo

Eu sou novo no PaaSes e isso é confuso. Eu escolhi Tsuru e estou mexendo um pouco com ele. Parece-me que não é muito diferente dos objetivos de Flynn. Você pode executar coisas com estado usando sua API de serviço e é muito modular, onde você tem tsuru-api, docker-cluster, gandalf, etc.

Ainda me pergunto se a combinação de esforços traria um produto melhor.

Devo concordar com @msabramo aqui, ainda não vejo nenhum ponto positivo sobre o porquê de construir um novo PaaS que tenha todos os recursos do Tsuru. Também concordo que a combinação de esforços daria um produto incrível.