Por que o Flux não está morrendo depois do Weaveworks

PARIS – O fluxo não está morrendo. O futuro do Flux como plataforma GitOps de código aberto líder para Kubernetes pode ter sido questionado entre algumas operações subsequentes de encerramento da Weaveworks. Mas para quem está familiarizado com o projeto, tem havido pouca preocupação com a vida futura do Flux.

Embora o Flux tenha perdido colaboradores do Flux empregados pela Weaveworks, a maioria deles continuou seu trabalho no projeto. Ele continua a ter uma base de colaboradores e usuários significativa e ativa, incluindo suporte e seu uso por Aenix, Aviator, Microsoft Azure, GitLab, Teracloud e outros que a CNCF listou em uma postagem de blog durante a KubeCon.

Pode-se dizer que, após a enorme quantidade de investimentos que a comunidade fez no Flux, e como a Microsoft, AWS e outros dependem do Flux até certo ponto para sua infraestrutura, seria altamente improvável que essas organizações tivessem desligado o plug-in. seu apoio e uso do Flux. Verifica-se agora que não faltaram contribuições e mantenedores após a decisão da Weaveworks de descontinuar seu suporte e a versão empresarial.

Em uma resposta por e-mail após a KubeCon, Andrew Block, arquiteto ilustre do Escritório de Tecnologia de Serviços Globais da Red Hat, que participou de uma palestra sobre o assunto, disse: “Não fiquei apenas surpreso, mas encorajado como membro da comunidade Open Source e GitOps ver tantas pessoas presentes em apoio ao projeto. A sala estava lotada”, disse Block. “Se esta sessão foi uma indicação do apoio que a comunidade tem ao projeto Flux, está claro que ‘não vai passar a noite silenciosamente’.”

No entanto, é necessário que haja algum incentivo por parte das organizações que utilizam o Flux “para suas aplicações de missão crítica, para permitir que seus desenvolvedores possam contribuir”, disse Block. “Com o infeliz desaparecimento da Weaveworks, uma das principais partes interessadas do Flux não tem mais o conjunto de desenvolvedores para poder aproveitar o pagamento para ajudar a levar o projeto adiante.”

Dito isto, Block continua confiante sobre o futuro do Flux, que ele também descreveu em uma postagem no blog.

“O projeto Flux continuará – a comunidade e o apoio do ponto de vista empresarial estão presentes”, disse Block. “Agora falta montar as estruturas que permitirão a continuidade do projeto”.

Diapositivo 1

Além disso, o ControlPlane continua a oferecer suporte ao ControlPlane Enterprise com uma versão empresarial para organizações que buscam usar o Flux por meio de um provedor de plataforma terceirizado para integração e continua a oferecer contribuições para o projeto graduado.

Diapositivo 2

“O projeto Flux continuará – a comunidade e o suporte de uma perspectiva empresarial estão lá”, disse Block ao The New Stack por e-mail. “Agora falta montar as estruturas que permitirão a continuidade do projeto”.

Diapositivo 3

Na KubeCon, Stefan Prodan, mantenedor do Flux, e Alexis Richardson, cofundador da Weaveworks que primeiro cunhou o termo “GitOps”, forneceram detalhes sobre o status do Flux durante sua palestra “Flux and the Wider Ecosystem Planning BoF”. Eles discutiram seu status atual, seu futuro e como as pessoas podem se envolver com este popular projeto de GitOps processado no Kubernetes. Prodan e Richardson também abordaram como o FluxCD e outros projetos como Flux-IaC com Terraform estão vendo um aumento no número de mantenedores.

O projeto Flux cresceu para “se tornar uma peça importante da plataforma CNCF e” se beneficia de integrações importantes “, como OCI e Terraform, disse Richardson ao The New Stack após sua palestra. “Os membros da comunidade têm trabalhado juntos em um ritmo impressionante para fazer a transição do antigo modelo liderado pela Weaveworks para um modelo liderado pela comunidade, com vários fornecedores desempenhando um papel”, disse Richardson. “Esta é a prova de que o modelo CNCF é robusto diante de tais mudanças e só pode ser uma boa notícia para os usuários finais”.

Existem atualmente 600 contribuidores do Flux. Desses 11 são mantenedores ativos. Como explicou Prodan, o Flux compreende vários controladores e pacotes Go, “tornando-o um sistema complexo”. Um mantenedor tem a tarefa de contribuir para um componente específico do Flux e assume voluntariamente a responsabilidade de supervisionar esse componente. Um mantenedor principal, por outro lado, possui uma compreensão abrangente do Flux como um todo. Seu papel principal é ajudar com contribuições, recrutar colaboradores para se tornarem mantenedores de subprojetos e “em última análise, orientá-los para se tornarem mantenedores principais, mantendo assim a supervisão de todo o projeto”, disse Prodan.

O projeto

Flux compartilha seu status de liderança como plataforma GitOps com Argo CD. Ambos vistos como facilitadores de GitOps, agora são considerados componentes críticos da infraestrutura nativa da nuvem, à medida que se juntam às fileiras graduadas do próprio Kubernetes, Prometheus e Envoy.

Enquanto isso, o GitOps emergiu como o processo de fato para implantação de aplicativos em ambientes nativos da nuvem.

De acordo com o GitLab, GitOps é “uma estrutura operacional que pega as melhores práticas de DevOps usadas para desenvolvimento de aplicativos, como controle de versão, colaboração, conformidade e CI/CD, e as aplica à automação de infraestrutura”. Ele é baseado no software de controle de versão git de código aberto.

Uma descrição mais precisa e consensual do GitOps foi lançada pelo OpenGitOps – um grupo de trabalho GitOps sob o CNCF App Delivery SIG. Consiste em um conjunto de padrões de código aberto, melhores práticas e educação focada na comunidade para ajudar as organizações a adotar uma abordagem estruturada e padronizada para implementar GitOps. Ele descreve os Princípios do GitOps como:

1. Declarativo: Um sistema gerenciado por GitOps deve ter seu estado desejado expresso declarativamente.
2. Versionado e imutável: o estado desejado é armazenado de uma forma que impõe imutabilidade e controle de versão e mantém um histórico de versão completo.
3. Extraído automaticamente: os agentes de software extraem automaticamente as declarações de estado desejadas da fonte.
4. Reconciliado continuamente: os agentes de software observam continuamente o estado real do sistema e tentam aplicar o estado desejado.

O Flux pode ser utilizado na camada principal que instrumentaliza as funcionalidades do GitOps conforme descrito em seus princípios. Conforme explicou Prodan, o Flux funciona como uma “infraestrutura invisível em seus clusters” e pode ser usado para construir uma plataforma de entrega contínua e plataformas internas, disse Prodan. “O Flux não foi projetado para ser abrangente: em vez disso, ele serve como uma camada fundamental sobre a qual você pode construir sua infraestrutura de entrega. O Flux é altamente opinativo, oferecendo várias opções de implantação, como a montagem de peças de Lego”, disse Prodan. “Você pode misturar e combinar componentes para adaptar sua plataforma de acordo. ”

Você consegue

Os usuários de código aberto, na minha opinião, também deveriam procurar retribuir à comunidade. Contribuir para um projeto por interesse intelectual ou porque apoia o trabalho da sua organização e você pode ser pago para contribuir são motivos válidos para se envolver. Para quem usa e trabalha com o Flux ou se deixa seduzir pelo seu potencial, existem projetos piores para se envolver.

“Há uma oportunidade significativa dentro do ecossistema para desenvolver ferramentas e serviços complementares além do Flux. Ao contribuir para o projeto e fornecer ofertas comerciais, como versões SaaS, organizações e indivíduos podem sustentar o desenvolvimento do Flux”, disse Prodan. “Embora existam inúmeras soluções disponíveis, é essencial reconhecer que o Flux não é um produto acabado por si só.”

Outras maneiras de contribuir para o projeto incluem adquirir suporte da ControlPlane, disse Richardson. Alternativamente, como um fornecedor que oferece algo diferente do que o ControlPlane oferece, é possível utilizar seus produtos e serviços e depois revendê-los ou integrá-los em soluções maiores.

Além disso, você pode ter identificado outro aspecto do projeto no qual focar; por exemplo, segurança, aplicação de políticas, observabilidade, painéis ou gestão de frotas, disse ele. “Existem inúmeras áreas onde as contribuições são valiosas e apresentaremos vários trechos de código nos quais você pode trabalhar nesses domínios.”

Num futuro próximo, os mantenedores do projeto Flux esperam aumentar o número de mantenedores sem “sobrecarregá-los com todas as responsabilidades de uma vez”, disse Prodan. “Atualmente, temos um grande grupo de pessoas fazendo contribuições, mas um número muito pequeno de mantenedores”, disse ele. “Ao conceder gradualmente mais responsabilidades aos indivíduos, esperamos que eles se tornem mais conhecedores do Flux ao longo do tempo e assumam papéis maiores dentro do projeto.”

A postagem Por que o Flux não está morrendo depois do Weaveworks apareceu pela primeira vez no The New Stack.