Cloudflare Flagship

 (developers.cloudflare.com)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Cloudflare Flagship é o serviço de feature flags da Cloudflare para controlar a exposição de funcionalidades de aplicações sem redistribuir código
  • As flags são definidas por regras de segmentação e rollout baseado em porcentagem, podendo ser avaliadas diretamente em bindings nativos do Workers
  • É compatível com OpenFeature e permite avaliar flags em Workers, Node.js e navegadores com o SDK @cloudflare/flagship
  • A segmentação oferece suporte a atributos de usuário, 11 operadores de comparação, agrupamento com AND/OR, avaliação sequencial e mantém valores com hash consistente
  • As variações suportam booleano, string, número e objeto JSON, e podem ser criadas, editadas e excluídas por aplicativo no dashboard da Cloudflare

Principais recursos

  • Bindings do Workers

    • Binding reference
    • Avalia flags com bindings nativos do Workers
    • Oferece métodos type-safe e fallback automático para valores padrão

  • SDK OpenFeature

    • View SDK docs
    • O provider OpenFeature @cloudflare/flagship permite avaliar flags em Workers, Node.js e navegadores
    • Ao migrar de outro provedor de flags, basta alterar uma linha de configuração

  • Regras de segmentação

    • Learn about targeting
    • Entrega valores de flag diferentes com base nos atributos do usuário
    • As regras oferecem suporte a 11 operadores de comparação, agrupamento lógico com AND/OR e avaliação sequencial

  • Rollout baseado em porcentagem

    • Learn about rollouts
    • Permite lançar funcionalidades gradualmente de acordo com uma porcentagem de usuários
    • O hash consistente garante que o mesmo usuário sempre receba o mesmo valor de flag

  • Variações de múltiplos tipos

    • Use Multi-type variations
    • As variações de flags podem ser booleanas, strings, números ou objetos JSON estruturados
    • Com variações de objeto, é possível passar um bloco inteiro de configuração em uma única flag

  • Gerenciamento de flags

    • Use Flag management
    • É possível criar, atualizar e excluir flags no dashboard da Cloudflare
    • As flags são organizadas em apps mapeados para projetos ou serviços
    • Sua primeira feature flag pode ser criada no guia de primeiros passos

Serviços relacionados da Cloudflare

  • Workers: constrói aplicações serverless na rede global da Cloudflare, e o Flagship tem integração nativa com Workers por meio de bindings
  • KV: armazena dados de chave-valor em toda a rede global da Cloudflare, e o Flagship usa essa infraestrutura para distribuir configurações de flags

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários no Hacker News

  • Não dá para subestimar a abstração com 0 idas e voltas de rede. Em cima de f(feature_name, context), o contexto pode ser ajustado de forma extremamente granular: um estoque específico, um fornecedor específico, um usuário específico de um cliente B2B específico, um subtipo específico de modelo de negócios, até a visibilidade em um horário específico
    Se você puder escrever a lógica diretamente e executá-la em um tight loop com velocidade de constante, a agilidade do negócio aumenta muito. Se achar que algum texto pode mudar para certos clientes, basta transformar isso em código configurável, e testes e flags vêm naturalmente junto
    Porém, esse tipo de composição 0-hop exige um motor de execução no cliente sofisticado, e não parece ser isso que a Cloudflare implementou aqui. Em Workers com restrições de memória, isso faz sentido, mas em infraestrutura tradicional parece menos convincente
    Gosto bastante da abordagem da Statsig: "Server SDKs hold the entire ruleset of your project in memory..."
    https://docs.statsig.com/sdks/how-evaluation-works
    Também dá para construir isso internamente. Basta sincronizar o conjunto de regras a cada poucos segundos em algumas estruturas de dados a partir de uma thread em segundo plano e trocar a referência de forma atômica. Depois disso, só é preciso uma interface CRUD para a dimensão das regras aplicadas
    Dito isso, é indispensável ter governança sobre quem pode mexer em quais candidatos a constantes. Grandes poderes trazem grandes responsabilidades

    • Ao ler isso, penso no padrão em que feature flags acabam sendo usadas indevidamente como configuração/customização da aplicação. É um antipadrão que já observei em várias organizações
      Vejo feature flags mais como algo usado junto com desenvolvimento trunk-based: ativar recursos em QA, ainda não expor em produção e permitir testes por PO/PM. O trunk-based development permite um DevOps rápido e simples sem estratégias de branching complexas
      Já a configuração da aplicação faz parte da própria aplicação e é o espaço para customizá-la de acordo com o contexto de negócio. Não sei se existem frameworks ou ferramentas voltados a isso, mas as duas coisas precisam ser claramente separadas
    • A implementação em si não é difícil. É basicamente algo como Mersenne Twister com uma operação de módulo por cima, e no meu trabalho recente Flipper com um endpoint opcional de “estado atual da tabela de flags” já foi suficiente
      Foi justamente essa combinação de módulo + aleatoriedade que obrigou ferramentas como LaunchDarkly a oferecer SDKs para várias linguagens, e os SDKs com que lidei simplesmente não se encaixavam bem nessas linguagens. Na minha visão, empurrar a avaliação para a edge tornou o sistema inteiro mais complexo do que precisava ser
      Na prática, em geral basta recarregar ocasionalmente a tabela atual de flags “para este cliente”, e isso é muito menos incômodo. Ainda bem que existe o Flipper, porque assim não preciso mais lidar com isso manualmente
    • Essa composição 0-hop nem precisa ser tão sofisticada, e a Cloudflare nem precisaria implementar isso por conta própria. Se apoiar em OpenFeature, já existe um motor simples de avaliação de regras de targeting integrado à biblioteca cliente
    • Bom conselho. E eu acrescentaria que feature flags, testes A/B e autorização são três conceitos diferentes. Achei útil a forma como este artigo enquadrou isso
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • Estamos usando Statsig com sucesso na empresa. É bem polido e cheio de recursos. A ferramenta que identifica flags não usadas como candidatas à remoção é bastante boa
      Contratualmente, a cobrança por assento é um pouco salgada, mas ainda administrável

  • Parece um Boolean-as-a-service com verniz

    • Já vi uma equipe inteira fracassar porque a empresa não conseguia oferecer esse tipo de Boolean-as-a-service direito. Existe um motivo para empresas como a LaunchDarkly existirem separadamente
      Se simplificar assim, qualquer serviço do mundo pode ser reduzido a bits-as-a-service. Na prática, há valor de negócio legítimo nisso e também complexidade na forma como é entregue
    • Acho ok. Não quero rastrear milhares de feature flags no banco de dados nem criar um dashboard administrativo
      Dá para chamar qualquer ferramenta SaaS de “excel-as-a-service”, e é mais ou menos esse o nível desse tipo de comentário
    • Entregar esse Boolean no lugar certo e na hora certa, com confiabilidade, não é trivial

  • Na documentação do SDK JS há este aviso: “O provider de cliente precisa de um token de API para buscar os valores das flags. Esse token não é limitado a um único app, então qualquer pessoa com o token pode avaliar as flags de todos os apps da conta. Use com cautela em aplicações públicas”
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    Fico me perguntando por que um SDK cliente projetado para ser distribuído no navegador exigiria esse tipo de cuidado. Isso significa que qualquer cliente pode enviar requisições com um novo targetingKey e observar as flags de outros usuários?
    As flags não deveriam conter informações sensíveis, mas parece uma escolha de design interessante

    • Provavelmente era algo usado internamente na Cloudflare e alguém achou que seria divertido tornar público
      Não parece plausível que, seis meses atrás, a Cloudflare tenha decidido seriamente criar um concorrente da LaunchDarkly
    • Sou engenheiro da equipe do Flagship. Tokens com escopo por app estão em desenvolvimento

  • Isso é bom, mas, ironicamente, ainda estou esperando sair esse recurso que provavelmente será oferecido usando o Flagship
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    Ainda não acho que tenha havido um único caso de recurso exclusivo de Enterprise descendo para contas pagas inferiores
    O que mais me interessa em particular é isto:
    https://developers.cloudflare.com/speed/optimization/content...

    • Sim. Eu preciso tanto de recursos Enterprise do Zero Trust que provavelmente vou acabar tendo que falar direto com um representante comercial Enterprise. Parece o tipo de estresse demorado que eu queria evitar

  • A Cloudflare tem mandado bem ultimamente, mas falta controle de permissões granular. Ainda preciso criar uma conta totalmente separada para produção, e como um domínio só pode ficar vinculado a uma única conta, isso bagunça o SSO

    • O produto é ótimo e usei com satisfação por muito tempo, mas o blog deles cometeu alguns deslizes recentemente. A estabilidade também pareceu balançar por um tempo, embora pareça ter melhorado mais recentemente
    • Usei AWS por alguns anos e depois experimentei Cloudflare; gostei da experiência do usuário, mas acabei voltando pelos mesmos receios. Está tão perto de chegar lá, uma pena
    • Mudei todos os meus projetos para a Cloudflare há alguns anos e não me arrependo. Uso Workers, D1, R2, Queues, Containers, KV
      Ainda uso AWS para envio de e-mail, então seria bom se a Cloudflare lançasse algo nessa área
    • Eu também abri hoje um ticket de suporte pedindo permissões mais granulares
    • Esse é exatamente o motivo que me impede de usar Cloudflare no trabalho real. Adoro a camada gratuita para hobby

  • Eu não conhecia o OpenFeature, achei muito legal. Alguém aqui tem experiência integrando isso? https://openfeature.dev

    • Já usei bastante OpenFeature e até fiz commits iniciais em algumas bibliotecas cliente. É mesmo o futuro dos feature flags, e o ecossistema está crescendo rápido
      Em transparência, sou CTO da Flagsmith. Nos últimos anos vimos uma curva clara de aumento na adoção do OpenFeature. Antes nós incentivávamos os clientes a experimentar; agora são os clientes que chegam exigindo OpenFeature como requisito
      O suporte dos vendors já está bem maduro e cobre praticamente todas as linguagens. Se você está integrando feature flags em um serviço novo ou migrando de uma implementação própria para uma solução de terceiros, eu recomendo OpenFeature
    • É bem útil. Usei na empresa anterior e criamos um backend customizado, mas usando a especificação e os SDKs do OpenFeature
      Levamos cerca de 2 semanas para construir um backend totalmente customizado. Os SDKs para várias linguagens funcionaram sem problemas. Encontrei um bug, mas reportei e ele foi corrigido no mesmo dia

  • Eu não entendo muito bem feature flags. Em essência, qual é a diferença para um Boolean no banco de dados?

    • Se o flag em si é Boolean, string, número ou qualquer outra coisa, essa é a parte fácil. O difícil são as regras de targeting e rollout — ou seja, quem vê qual flag e a exigência de avaliar essas regras de forma muito rápida e consistente
      Equipes que constroem isso por conta própria costumam descobrir que o problema cresce rápido quando produto, marketing e vendas querem fazer targeting com regras cada vez mais complexas
      Em termos gerais, não é um problema especialmente difícil, mas é grande. Você precisa de muita funcionalidade invisível no começo
      Feature flags são, na prática, mais parecidas com um sistema de permissões. Trata-se de dar acesso a certos recursos apenas a usuários específicos, e quem já lidou com sistemas de permissão sabe como filiação a grupos, grupos hierárquicos, papéis, ACLs etc. ficam complexos. Esses elementos são parecidos com os vários tipos de regras de targeting em um sistema de feature flags
    • Quando você adiciona rollout percentual, RBAC, trilha de auditoria, testes A/B e configurações multivariadas, a coisa complica rápido. Aquele único Boolean vira um sistema inteiro que precisa ser operado e mantido
    • Tem um texto detalhado aqui: https://martinfowler.com/articles/feature-toggles.html
    • Nem sempre é Boolean. Por exemplo, feature flags são usadas com frequência em rollouts A/B
      A própria Cloudflare também usa isso internamente para lançar novos recursos ou builds primeiro para clientes gratuitos e, após um período de estabilização, expandir gradualmente para clientes maiores
      Feature flags também podem ser ativadas aleatoriamente, quase como um tipo de fuzz testing. Não pense só em “coisa nova”; pode ser também “mudança de comportamento”
      Você pode pensar nisso como um Boolean em cima de todos os clientes, mas normalmente não é assim que se implementa
    • Dá para implementar com um Boolean no banco de dados, então isso é só um detalhe de implementação
      O principal atrativo de feature flags é permitir trabalhar em recursos grandes, que levariam meses e muitos commits, direto na branch principal. Para mim, isso cria um processo de desenvolvimento mais leve e iterativo
      Em contraste com manter branches separadas e até alvos de deploy separados para recursos em desenvolvimento grande

  • Feature flags muitas vezes acabam sendo excessivamente elaboradas
    Basta verificar um valor de configuração, valor no banco de dados ou variável de ambiente e seguir dinamicamente por um caminho ou outro
    É só isso. Você deve tornar os recursos pequenos ou refatorar o código para conseguir alterná-los facilmente em um nível alto
    Se isso não for fácil, uma implementação mais complexa de feature flags pode ajudar a coordenar a ativação do recurso entre microsserviços
    Se houver muitos recursos, um dashboard também pode ser útil
    Mas eu vejo ambos como sinais fortes de que talvez você devesse evitar feature flags. Elas funcionam melhor para mudanças locais e temporárias; caso contrário, a complexidade vai se acumulando e fica difícil de administrar e manter

    • Faz sentido para ativar um recurso para um segmento específico, por exemplo usuários italianos de baixa receita, para observar o impacto de negócio ou de performance
      Claro que você não vai querer que o usuário perca o recurso só porque passou do limite de receita ou cruzou uma fronteira, então é preciso algum tipo de implementação de rastreamento. Analytics e rastreamento de erros também precisam se comunicar com o serviço de feature flags
      Não é ciência de foguete, mas com certeza é mais complexo do que variável de ambiente
    • O cerne de feature flags é disciplina. Você as cria com propósito e deve removê-las assim que deixarem de agregar valor. KISS se aplica aqui

  • Sempre fico animado quando a Cloudflare começa a oferecer algo para o qual antes era preciso usar outro provedor. Passa confiança de que vai ser sólido
    Na Function, usamos Statsig. No começo, duas pessoas passaram a usar em um produto, mas em 12 meses uma boa parte do texto do produto e dos rollouts já era movida por Statsig
    O Statsig tem avaliação no lado do cliente, então dá para escrever regras e rollouts com base nos conceitos internos sem que os servidores do Statsig precisem processar os dados dos usuários
    Espero que a Cloudflare faça aqui um produto sofisticado, para que no futuro não seja mais preciso usar outro produto

    • Acho estranho terceirizar feature flags. Não sou do tipo que acha que tudo deve ser feito internamente, mas feature flags nunca pareceram algo difícil de construir por conta própria

  • Sou só um usuário comum que não conhece bem os detalhes técnicos, mas acho a Cloudflare relativamente fácil de usar. Espero que continue mandando bem

    • É o melhor registrador de DNS que já usei