O LaunchDarkly deixa minha aplicação mais lenta?
Na minha palestra sobre Projetos Ágeis, Entrega Contínua e Feature Toggles no DevOps Summit Brasil 2017, uma das principais dúvidas foi “qual o overhead do LaunchDarkly na minha aplicação?”
Dada a curta duração da palestra, eu prometi um post de follow-up sobre o assunto. Eis a resposta à pergunta que ficou no ar após a palestra.
E a resposta é… Não, não deixa mais lenta!
“Impossível, Igor!”, você diria. “O LaunchDarkly é um serviço, e a minha aplicação precisa ficar chamando a API deles toda hora para saber se uma flag está ligada ou não!”
Sim, ele precisa chamar a API do SDK o tempo todo. Isso não quer dizer que ele precisa chamar o serviço o tempo todo.
O segredo?
As regras estão na memória do seu servidor!
Sim, é verdade. As regras estão na memória da sua aplicação o tempo todo!
Isso significa que, quanto você escreve um código como este que mostrei em minha palestra…:
1
if (LaunchDarklyHelper.Client.BoolVariation("nova-tela-de-clientes", LUser.WithKey("fulano@detal"), false)) { routes.MapRoute( "NewCustomers", // Route name "Customers/{action}/{id}", // URL with parameters new { controller = "NewCustomers", action = "Index", id = UrlParameter.Optional } // Parameter defaults ); }
… o if que testa sa a feature flag nova-tela-de-clientes é executado com um valor que está numa variável local, na memória do seu servidor Web.
Mas como isso é possível?!
SSE ao resgate
SSE (Server-sent events) é uma tecnologia de streaming de dados, muito usada no client-side de aplicações Web para o envio de dados do servidor através da API EventSource do Javascript.
Mas quem disse que servidores não podem também tirar proveito do conceito de SSE?
A ideia é relativamente simples: Quando o cliente do LaunchDarkly é inicializado mo trecho de código abaixo, sua aplicação recebe uma cópia inicial (um snapshot) das regras configuradas para sua aplicação no ambiente do LaunchDarkly.
1
var ldClient = new LaunchDarkly.Client.LdClient("chave-sdk-do-LaunchDarkly");
O ponto em questão é: daí por diante, essa cópia em memória precisa ser mantida atualizada, uma vez que você pode entrar a qualquer momento do dashboard do LaunchDarkly e, por exemplo, ligar uma “kill switch”. Só que, ao invés de sua aplicação ir até o serviço do LD para perguntar se uma regra mudou, o LD avisa sua aplicação quando uma regra muda! Em outras palavras, o ato de ligar uma kill switch no LD dispara um “evento” no serviço deles, que por sua vez notifica seus servidores (através da tecnologia de SSE) de modo que eles atualizam sua cópia local das regras, antes mesmo que sua aplicação precisa consultar uma feature flag de novo. Ou seja, o impacto no desempenho é desprezível, na casa dos microssegundos.
E para diminuir a latência entre sua aplicação e o LaunchDarkly (ou seja, para receber as atualizações no menor tempo possível), é usada uma rede de CDN (Fastly, com pontos de presença ao redor do mundo, inclusive em São Paulo) que ajuda até mesmo a proteger contra eventuais indisponibilidades do serviço.
Conclusão
E então? Agora que você sabe que o LaunchDarkly resolve de maneira bem esperta a questão de impacto no desempenho, que tal experimentar se feature toggles (ou feature flags; são a mesma coisa) podem ajudar em sua aplicação?
Ah, aproveite que eles oferecem um período de avaliação de trinta dias para experimentar de graça!
Se você resolver “brincar” com o LaunchDarkly, conte depois aqui nos comentários como foi sua experiência.
Um abraço,
Igor
03/04/2017 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 3 mins.
