5 motivos para migrar para o balanceamento de carga por software

Floyd SmithDiretor de Marketing de Conteúdo

Este post foi adaptado de um webinar de Floyd Smith e Faisal Memon, da NGINX, Inc. Nosso novo e-book sobre o tema está disponível para download.

Sumário

0:00 Introdução

Floyd Smith: Olá! Sejam bem-vindos à nossa apresentação. Estamos aqui na NGINX e hoje falaremos sobre meu e-book 5 motivos para adotar uma solução de software para balanceamento de carga.

Hoje, somos dois apresentadores. Eu sou Floyd Smith, redator de marketing técnico da NGINX. Anteriormente, fui redator técnico sênior na Apple e sou autor de vários livros sobre diferentes aspectos da tecnologia.

Faisal Memon: Olá, sou Faisal Memon e trabalho com Marketing de Produto aqui na NGINX. Estou aqui há cerca de um ano. Antes de vir para a NGINX, trabalhei como engenheiro de marketing técnico na Riverbed e também na Cisco. Comecei minha carreira trabalhando com desenvolvimento em C. Fui engenheiro de software na Cisco e exerci essa função por cerca de oito anos.

1:38 Quem é você?

Floyd: Recebemos as inscrições para nossos webinars antes de realizá-los e podemos ver os cargos, as organizações e os motivos para participar que cada um de vocês informou.

Foi muito interessante observar os cargos das pessoas que estão participando. Temos Arquitetos de Soluções — vários tipos diferentes de arquitetos. Administradores de Linux, Diretores de Engenharia, CEO, Gerente Sênior de Entregas Ágeis, várias pessoas com cargos de DevOps, Desenvolvedor de Software Full Stack, Engenheiro, Cientista, Desenvolvedor e Gerente de Operações de Marketing.

Temos uma ótima variedade de pessoas com perfil técnico. Tenho a impressão de que os participantes deste webinar realmente trabalham diretamente com a tecnologia e enfrentarão de forma direta as questões que estamos discutindo aqui hoje.

Também temos uma variedade muito boa e ampla de organizações representadas. Alguns de vocês talvez estejam analisando isso para orientar seus clientes a tomar decisões inteligentes, mas a maioria parece estar lidando com essa questão diretamente, dentro da própria organização.

3:53 Do hardware ao software

O mercado de ADCs de hardware está em declínio, segundo relatórios financeiros. Por isso, quem vende ADCs de hardware está tentando aumentar a receita obtida por cliente, mesmo com a redução da base de clientes. Muitos clientes de ADCs de hardware estão começando a perceber que não querem fazer parte desse grupo cada vez menor de pessoas que pagam cada vez mais por esses serviços fornecidos por ADCs de hardware. Eles estão começando a perceber que podem fazer a mesma coisa ainda melhor por meio de software e, de quebra, ganhar mais flexibilidade. Quem tem DevOps no cargo provavelmente sabe do que estou falando.

O que vemos com frequência aqui na NGINX é que as pessoas chegam à data de renovação do contrato do ADC de hardware ou enfrentam um aumento repentino no tráfego e, consequentemente, nos custos. Então, elas precisam correr para se livrar do contrato e fazer tudo às pressas. Geralmente conseguem, mas é um processo estressante, não planejado e sem orçamento previsto. Com a ajuda desta apresentação, você pode iniciar um processo mais bem planejado.

A questão orçamentária não é tão crítica, pois a migração para software gera uma economia significativa, mas os transtornos operacionais são enormes. Você pode reduzi-los bastante simplesmente começando com antecedência.

O NGINX é uma alternativa realmente robusta a um ADC de hardware. Ele foi criado originalmente para resolver o problema C10K. Trata-se de um servidor web executado em um único computador e atendendo a 10.000 ou mais conexões simultâneas. Antes do NGINX, isso era impossível. As pessoas colocavam um site no ar, ele se tornava popular e acabava saindo do ar. Evitar que isso acontecesse era muito, muito, muito difícil, mas, com o NGINX, ficou muito mais fácil.

Nossa primeira versão de código aberto foi lançada em 2004 na Rússia, onde o NGINX [o software] foi originalmente criado [Editor – Floyd diz “fundado” aqui; a NGINX, Inc. foi fundada em 2011]. O NGINX Plus, a versão comercial com suporte, foi lançado em 2013.

A empresa NGINX está sediada no Vale do Silício (São Francisco), e nossos escritórios de desenvolvimento ficam em Moscou. Também temos escritórios no Reino Unido. A empresa conta com o apoio de líderes do setor por meio de investimentos de capital de risco. Temos mais de 800 clientes e, recentemente, alcançamos a marca de 100 funcionários.

6:33 O principal servidor web dos sites mais acessados do mundo

Há um total de 160 milhões de sites executados no NGINX.

Ele é usado de duas formas diferentes. Alguns sites executam o NGINX como um servidor web, que era sua finalidade original. Mas muitos sites executam o NGINX como um servidor proxy reverso. Nesse caso, você coloca o NGINX à frente da sua arquitetura atual e o utiliza para gerenciar o tráfego e encaminhá-lo aos servidores da sua aplicação. Ao fazer isso, você já está a caminho de implementar o balanceamento de carga, que é o assunto que abordaremos hoje.

51% dos 10.000 sites mais acessados migraram para o NGINX. Mas por quê? Por que o uso é ainda maior entre os sites mais acessados do que entre os sites em geral?

O motivo é que o NGINX é a melhor solução para sites com tráfego realmente intenso. Uma maneira rápida de recuperar um site muito acessado que esteja enfrentando problemas é implementar o NGINX como servidor proxy reverso e, em seguida, executar o balanceamento de carga sobre ele.

Com o tempo, você pode migrar seus aplicativos existentes para o NGINX ou, caso desenvolva novos aplicativos, também pode usar o NGINX como servidor web para eles. Foi assim que alcançamos esse nível de adoção entre profissionais muito ocupados, que não trocam de servidor web por mero capricho. Eles têm experiência com outros servidores web e sabem como usá-los, mas fazem essa mudança por tudo o que o NGINX oferece.

36% de todos os sites na Amazon Web Services usam o NGINX. Ele está se tornando uma espécie de ferramenta padrão. Hoje, as pessoas geralmente começam usando o NGINX e continuam com ele durante todo o projeto.

Aqui estão alguns dos sites que usam o NGINX. É claro que, com 160 milhões de sites usando o NGINX, não podemos colocar todos em um único slide, mas entre nossos parceiros e amigos estão Netflix, Airbnb, Uber, Amazon Web Services, como mencionei, Box, Pinterest e WordPress.

Todas essas empresas, cujo negócio depende da entrega de conteúdo pela web e para as quais tudo precisa funcionar, migraram para o NGINX.

8:48 Onde o NGINX se encaixa

Vamos ver onde o NGINX se encaixa.

À direita, você vê o NGINX funcionando como um servidor web. E, como servidor web, ele usa um gateway de aplicações para permitir que diferentes tipos de servidores de aplicações sejam executados com ele. Como servidor web, o NGINX pode lidar com cerca de 10.000 conexões simultâneas, dependendo do que você estiver fazendo.

Mas o NGINX também é útil como servidor proxy reverso, oferecendo cache, balanceamento de carga e vários outros recursos.

9:32 Arquitetura Web Moderna

O NGINX também ajuda você a migrar para uma arquitetura web moderna. Isso pode significar a migração de arquiteturas de três camadas no estilo J2EE para microsserviços. Pode envolver a substituição de protocolos complexos de HTML e SOAP por protocolos mais leves, como REST e sistemas de mensagens, que são uma parte importante dos microsserviços. Ou ainda a transição de implantações persistentes para implantações mutáveis executadas em contêineres ou máquinas virtuais.

Em vez de uma infraestrutura fixa e estática, geralmente você tem um serviço que gerencia por conta própria. Temos tecnologias como SDN, NFV e a nuvem — especialmente a nuvem. Em vez de grandes lançamentos a cada poucos meses, você tem entrega contínua em intervalos de poucas horas. E, em vez de equipes isoladas, com grupos de desenvolvimento, testes e operações subordinados a seus respectivos gerentes, você tem uma cultura DevOps de responsabilidade compartilhada, na qual todos arregaçam as mangas e cuidam de alguns aspectos de cada problema.

10:42 O DevOps funciona muito bem com o NGINX

Metodologia DevOps, implantações na nuvem e descoberta automatizada de serviços” size-full wp-image-46723″ style=”border:2px solid #666666; padding:2px; margin:2px;” />

A história do DevOps está intimamente ligada ao NGINX. Muitos profissionais de DevOps têm o NGINX sempre à mão e, quando se deparam com uma implantação que está apresentando problemas, recorrem a ele.

Em determinadas implantações, você nem precisa se preocupar em alterar a configuração do aplicativo. Basta colocar o NGINX na frente dele para direcionar o tráfego aos servidores de aplicativos de uma forma que eles consigam processar. Assim, você não altera o código nem coloca em risco as funcionalidades essenciais quando precisa resolver rapidamente um problema de desempenho.

Uma das áreas em que DevOps e NGINX costumam funcionar bem em conjunto é o balanceamento de carga por software, como veremos. Ele funciona muito bem em implantações na nuvem, mas também em seus próprios servidores. Oferece diversos métodos de balanceamento de carga. Nesse aspecto, há uma diferença entre o NGINX e o NGINX Plus, que explicarei em breve.

A capacidade de reconfiguração dinâmica do NGINX oferece suporte à descoberta de serviços e à disponibilidade. A descoberta de serviços é essencial para microsserviços e automação e, com a reconfiguração dinâmica, não é necessário desconectar os usuários de um servidor para configurá-lo, o que representa uma enorme vantagem para manter seus clientes online.

As verificações de integridade dos aplicativos fornecem alertas antecipados sobre problemas na entrega de aplicativos, permitindo que você desative gradualmente um servidor com problemas, em vez de deixá-lo simplesmente travar e desconectar os usuários. Além disso, há um monitoramento robusto e personalizável. Mais uma vez, isso permite que você identifique os problemas à medida que surgem, para que possa resolvê-los antes que afetem os clientes.

12:30 Recursos do NGINX Plus

O que há no NGINX Plus?

Portanto, o NGINX de código aberto é o produto original, e o NGINX Plus é o produto comercial desenvolvido sobre ele. Aqui na NGINX, dedicamos pelo menos 70% do nosso tempo ao código aberto, que também serve de base para os recursos avançados do NGINX Plus.

O produto de código aberto inclui o roteamento de solicitações, que é a principal função de um servidor web, e a compactação, que reduz a carga no servidor web e também minimiza o tráfego na rede, o que pode ser muito útil. Ele oferece suporte a SSL para garantir a segurança. Também temos linguagens de script incorporadas — duas, na verdade. Uma delas é a nossa própria, o módulo JavaScript do NGINX [anteriormente chamado de nginScript], e a outra é Lua.

Há alguns recursos que estão parcialmente disponíveis no NGINX de código aberto, mas que são aprimorados no NGINX Plus. É possível fazer balanceamento de carga muito bem com o NGINX de código aberto, mas o NGINX Plus oferece alguns recursos mais avançados. Da mesma forma, você pode usar o NGINX de código aberto como cache de borda e para streaming de mídia, e isso funciona ainda melhor no NGINX Plus.

O NGINX Plus também conta com vários recursos próprios, como monitoramento da integridade de aplicações, visualização do monitoramento por meio de uma interface gráfica, monitoramento e análise, API de configuração RESTful e algumas das técnicas mais avançadas de balanceamento de carga.

Com o NGINX Plus, você tem acesso aos engenheiros da NGINX para auxiliá-lo em seu trabalho. Se você usa atualmente F5, Citrix ou um sistema semelhante, provavelmente já está acostumado com esse tipo de suporte. Para sites maiores e com mais tráfego, nos quais até mesmo um curto período de indisponibilidade pode custar muito dinheiro, isso pode ser crucial – e o investimento pode se pagar facilmente se você evitar uma única interrupção breve por ano.

14:41 Estudo de caso de cliente – WordPress.com

Vamos analisar alguns casos de sucesso de clientes que fizeram a mudança.

O WordPress.com usava o BIG‑IP da F5, mas migrou para o NGINX porque precisava fazer balanceamento de carga com mais de 10.000 requisições por segundo por servidor — esse é o problema C10k de que falamos e que o NGINX vem solucionando há mais de dez anos. Na época, o limite era de 1.000 requisições por segundo por servidor. Dá para imaginar como isso era oneroso em comparação com 10.000 ou mais.

O WordPress.com tinha vários sistemas F5 BIG‑IP e planejava expandir para dez data centers. Para garantir alta disponibilidade — basicamente, ter um backup ativo para cada data center —, eles estavam considerando dez pares de servidores BIG‑IP. Muito caro. Eles também precisavam de reconfiguração dinâmica para não desconectar os usuários quando alterassem a configuração.

Eles começaram a migração para o NGINX testando-o no Gravatar, um aplicativo que exibe um avatar para os usuários. Isso permitiu que se familiarizassem com o NGINX. Em seguida, migraram dos servidores F5 para o NGINX, o que resultou em um consumo de memória baixo e previsível, bem como em um uso de CPU baixo e previsível.

Agora, eles processam mais de 70.000 requisições por segundo e 15 gigabits por segundo [Gbps] em 36 servidores NGINX. Eles podem atingir picos de 20.000 requisições por segundo em cada servidor. Além disso, podem reconfigurar e atualizar tudo em tempo real.

Se você analisar a cotação, verá que eles estão falando apenas da diferença de custo em uma implementação pequena, na qual o NGINX permitirá uma economia significativa. Mas, quando se chega a dez pares de servidores, a diferença é enorme, como da noite para o dia.

16:42 Estudo de caso de cliente – Montana Interactive

A Montana Interactive escolhe o NGINX Plus para balanceamento de carga de alta disponibilidade. Na verdade, é mais fácil, mais barato e melhor que muitos serviços públicos sejam oferecidos online. Se você já agendou um atendimento no departamento de veículos automotores ou em um órgão semelhante, sabe do que estou falando. Esses sites podem viabilizar votações, o pagamento de impostos etc.

Há uma enorme quantidade desses serviços públicos essenciais, e Montana é um estado muito grande, com uma população relativamente pequena e dispersa por todo o território. Por isso, é muito importante disponibilizar os serviços online, em vez de fazer com que os moradores dirijam por seis ou oito horas para chegar a um órgão público.

No início, Montana avançava de forma bastante consistente na oferta de serviços on-line, mas, à medida que esses serviços cresceram, começaram a ocorrer interrupções nas sessões. Havia grandes picos trimestrais no tráfego de transações devido a um aplicativo de grande porte para o pagamento de impostos. No meio do preenchimento de um formulário extenso, a sessão de uma pessoa podia ser interrompida de repente, fazendo com que todo o trabalho fosse perdido. Se você estiver declarando seus impostos ou realizando qualquer outro processo complexo, isso é bastante estressante.

A solução foi migrar dos servidores que executavam o Pound para o NGINX Plus, implantar o NGINX Plus em diferentes hipervisores e data centers e usá-lo como um proxy reverso dinâmico, roteando solicitações em tempo real e proporcionando um melhor gerenciamento do tráfego. Com a migração para o NGINX Plus, eles obtiveram melhorias expressivas em velocidade, flexibilidade e facilidade de uso. Também se beneficiaram da reconfiguração em tempo real, transferiram o processamento de SSL para os servidores NGINX e usaram o gerenciamento baseado em funções para aprimorar as operações e a segurança.

James Ridle, da Montana Interactive, ficou impressionado com o poder do NGINX. Os resultados dos testes de desempenho o surpreenderam, e ele quase não conseguia acreditar na diferença no volume de tráfego que podia processar nos mesmos servidores com o NGINX.

18:43 Estudo de caso de cliente – BuyDig.com

Este é outro estudo de caso que trouxe enormes benefícios para o cliente – BuyDig.com, um site de comércio eletrônico que ganhou escalabilidade e segurança com o NGINX.

A BuyDig.com tinha um aplicativo .NET antigo. Eles não queriam alterá-lo e não precisaram fazer isso. Depois de sofrer um ataque de DDoS em larga escala, perceberam que precisavam de um frontend rápido, tolerante a falhas e fácil de configurar, com melhor desempenho, segurança e escalabilidade.

Eles colocaram o NGINX Plus na camada de aplicação do frontend, hospedada na Amazon Web Services. Não fizeram nenhuma alteração nos serviços de backend executados em .NET. E isso é muito importante: nenhuma alteração — nem pequenas mudanças, nem pequenos transtornos, nem pequenos riscos. Absolutamente nenhuma.

Agora, eles contam com desempenho e segurança excepcionais. Eles usaram linguagens de configuração para personalizar o NGINX. Eles usam TLS SNI e logs personalizáveis para ajudar a manter a segurança. Não tiveram uma única ocorrência de lentidão ou indisponibilidade do site e estão muito satisfeitos com o desempenho.

Então, esses são apenas alguns exemplos do que o NGINX Plus pode fazer.

20:10 Ebook – 5 motivos para migrar para um software de balanceamento de carga

Agora, vamos entrar no conteúdo do ebook. Vou fazer um breve resumo do que ele aborda e, em seguida, o Faisal vai explicar os dois primeiros motivos para fazer a migração, que são mais técnicos. Depois disso, eu retomo a apresentação. Há links disponíveis. Ao final, esta apresentação e a gravação do webinar serão disponibilizadas para vocês. Acredito que o e-mail leve cerca de um dia para ser enviado.

E este link levará você à página de download deste ebook gratuito. Então, só para adiantar quais são os motivos: reduzir custos; melhorar a integração com o DevOps; implantar em qualquer lugar (nos seus próprios servidores locais, na nuvem, em uma nuvem privada, onde você quiser); ter a capacidade de se adaptar rapidamente e não enfrentar restrições contratuais estranhas, que explicarei em mais detalhes. Mas agora vou passar a palavra ao Faisal para falar sobre redução de custos.

21:22 Motivo nº 1 – Reduzir drasticamente os custos

Faisal: Obrigado, Floyd. O primeiro dos cinco motivos é que você pode reduzir drasticamente os custos ao migrar para o NGINX Plus para a entrega de aplicações de software.

Voltando a meados dos anos 1990, a única maneira de aumentar a capacidade de um site era comprar um servidor maior, o que era extremamente caro e também pouco confiável, pois esse único servidor também representava um ponto único de falha.

Foi por volta dessa época que a F5 lançou o BIG‑IP pela primeira vez, oferecendo uma arquitetura diferente aos proprietários de sites: em vez de comprar um servidor maior, era possível usar o BIG‑IP para distribuir a carga entre um conjunto de servidores de baixo custo. Isso reduz os custos, pois é mais barato comprar o BIG‑IP e os servidores de baixo custo do que adquirir um único servidor gigantesco. Além disso, há um ganho de redundância, já que o ponto único de falha é eliminado.

Essa era uma excelente arquitetura — revolucionária e, na época, praticamente a única opção disponível —, mas muita coisa mudou nos últimos 20 anos. Uma das principais mudanças foi a queda drástica no custo dos servidores. Hoje em dia, é possível comprar um servidor bastante robusto por menos do que o valor de um mês de aluguel aqui na região da Baía de São Francisco.

A segunda grande mudança é a existência, hoje, de softwares de código aberto como o NGINX, que oferecem a mesma funcionalidade do F5 BIG‑IP ou do Citrix NetScaler. Com o código aberto, é possível obter gratuitamente funcionalidades semelhantes às desses appliances grandes e caros. Floyd mencionou anteriormente que mais de 160 milhões de sites usam o NGINX. E, entre os 10.000 sites mais acessados, mais da metade utiliza o NGINX.

Portanto, agora temos este software de código aberto que não só oferece todos os recursos de que você precisa em comparação com o F5, como também é tão escalável e confiável quanto qualquer outro produto comercial.

23:19 NGINX Plus vs. F5 BIG‑IP

Fiz alguns testes de desempenho e uma análise de custos no início deste ano, e aqui está um trecho desse trabalho. Esta é uma comparação entre o software NGINX Plus executado em hardware comum disponível no mercado — neste caso, fornecido pela Dell — e diferentes modelos do F5 BIG‑IP.

Este exemplo específico é o 2000S, o modelo de entrada do F5 BIG‑IP. Eu o comparei com duas configurações diferentes do NGINX Plus em servidores Dell: uma com desempenho ligeiramente inferior ao do F5 BIG‑IP (você pode ver as métricas de desempenho na parte inferior) e outra que praticamente dobra o desempenho.

Basta observar a coluna da direita, em que o NGINX Plus oferece o dobro do desempenho do 2000S: você economiza 78% no primeiro ano, incluindo o custo do hardware e do suporte de manutenção por um ano. E essa economia se mantém até o quinto ano. Mesmo após cinco anos, o custo total de propriedade do NGINX Plus com o servidor Dell é 58% menor que o do F5.

24:37 NGINX Plus vs. Citrix NetScaler

Fiz a mesma comparação de custos com o Citrix NetScaler. Aqui, estamos comparando o modelo básico do NetScaler, o MPX‑5550 Enterprise Edition.

O licenciamento da Citrix exige que, para ter acesso a recursos básicos, como cache e compactação de conteúdo, você atualize sua licença para a Enterprise Edition. Com o NGINX, o cache e a compactação de conteúdo estão incluídos sem custo adicional tanto na versão de código aberto quanto no NGINX Plus. Portanto, estamos comparando aqui a Enterprise Edition do Citrix NetScaler, pois ela oferece maior equivalência de recursos com o NGINX Plus. Ao substituir o Citrix NetScaler pelo NGINX Plus, observamos a mesma economia obtida com a substituição do F5.

Você obtém todos os recursos e o desempenho esperados, mas paga 89% menos no primeiro ano. Mesmo ao chegar ao quinto ano, você ainda economiza 75% tanto no custo do hardware (neste caso, servidores Dell convencionais) quanto no custo de uma assinatura do software NGINX Plus.

Uma métrica fundamental, e sobre a qual os fornecedores de hardware falam muito, é o número de transações SSL por segundo, ou seja, o número de novas conexões SSL que podem ser estabelecidas por segundo. Nessas plataformas, esse número geralmente é ampliado por aceleração de hardware. Por isso, o NetScaler e o F5 BIG‑IP contam com hardware especializado para acelerar as transações SSL, o que aumenta o custo dessas plataformas.

O que estamos observando é que, mesmo com uma solução de software — sem aceleração por hardware, usando apenas a capacidade de processamento da CPU —, conseguimos acompanhar o desempenho do hardware personalizado. Proporcionamos uma redução drástica de custos, com o mesmo desempenho que você obteria com soluções aceleradas por hardware.

Então, esse é o Motivo nº 1: você pode economizar muito ao migrar para o NGINX Plus. Mas não se trata apenas de dinheiro.

26:52 Motivo nº 2 – DevOps exige entrega de aplicações de software

Com uma solução baseada em software, você também ganha muita flexibilidade. E o motivo nº 2 para migrar para um balanceador de carga baseado em software é que, se você está adotando DevOps, realmente precisa de software para a entrega de aplicações.

Com o F5 e o NetScaler, esses appliances normalmente são implantados em grandes empresas como um ponto de agregação. Assim, muito tráfego não relacionado passa por eles. O mesmo F5 BIG‑IP pode balancear a carga de firewalls de rede, servidores de e-mail corporativos, diversos aplicativos empresariais de backend e também o aplicativo empresarial voltado ao público. Ele também pode balancear a carga de APIs em uma arquitetura de microsserviços. Portanto, pode balancear a carga de muitas coisas.

À primeira vista, essa parece ser uma boa arquitetura, pois é bastante simples: basta direcionar tudo pelo F5. Durante muito tempo, isso funcionou, especialmente no início dos anos 2000, quando tudo girava em torno do data center privado e executávamos todas as nossas aplicações — tudo aquilo de que a empresa dependia — em um data center local. Mas as coisas mudaram nos últimos anos, e agora a maior parte está sendo migrada para a nuvem.

Quando falo em nuvem, não estou me referindo apenas à hospedagem de uma aplicação web voltada ao público na Amazon, mas também ao uso de soluções como Salesforce e Office 365, em vez de sistemas de CRM e servidores de e-mail locais. Portanto, ter um dispositivo capaz de fazer tudo isso pode ser um exagero para o que as pessoas realmente utilizam hoje em dia.

Um segundo problema causado por essa agregação é que ela faz com que esses appliances fiquem extremamente restritos. Você acaba ficando muito receoso de fazer alterações neles, pois, se cometer algum erro na configuração do F5, poderá derrubar toda a rede corporativa. Ele pode estar fazendo o balanceamento de carga de servidores de e-mail e atuando como firewall de rede. Assim, a configuração se torna uma tarefa arriscada, e as alterações precisam ser muito restritas e rigorosamente controladas.

Normalmente, qualquer pessoa que queira fazer alterações precisa abrir um chamado de TI, o que pode levar horas, dias ou semanas, dependendo da organização e da prioridade que ela atribui à alteração solicitada.

Ter esse componente de hardware extremamente restrito torna muito difícil adotar o DevOps. Ao trabalhar com DevOps e avançar rumo à automação, à integração contínua e a lançamentos de código muito mais frequentes, ter que abrir um chamado de TI sempre que quiser fazer uma alteração acaba dificultando e inviabilizando essa iniciativa.

O que vemos em muitas organizações é que as pessoas responsáveis pela aplicação e que desejam avançar rumo ao DevOps e ao desenvolvimento ágil não conseguem lidar com a necessidade de abrir um chamado toda vez, pois isso atrapalha as iniciativas de DevOps e de desenvolvimento ágil. Por isso, às vezes elas implantam o NGINX de código aberto e fazem o F5 BIG‑IP direcionar o tráfego para ele. Essa instância do NGINX é gerenciada pela equipe de DevOps ou da aplicação, o que permite automatizar processos e fazer alterações sem complicações. Essa é uma forma de contornar a política corporativa de TI. Naturalmente, vemos muitos clientes que, depois de experimentar essa solução, começam a migrar para o NGINX Plus a fim de obter recursos mais avançados, além de suporte.

O NGINX oferece suporte a diversos modelos de implantação flexíveis, inclusive modelos que permitem manter o F5 atual. Você pode usar o NGINX Plus para complementar e aliviar a carga do balanceamento e da entrega de aplicações web, APIs e microsserviços voltados ao público, mantendo o F5 para realizar o balanceamento de carga de rede dos servidores de e-mail corporativos. Se você não precisar de serviços de rede nem de balanceamento de carga de rede, também poderá simplesmente substituir o F5 pelo NGINX Plus e contar com uma única solução.

Oferecemos suporte a diversos modelos de implantação para ajudar as organizações a avançar rumo ao DevOps, à entrega contínua e à automação.

Para o Motivo nº 3, passo a palavra novamente ao Floyd.

31:59 Motivo nº 3 – Implante em qualquer lugar com um único ADC

Floyd:Obrigado, Faisal.

Com o NGINX, você pode implantar em qualquer ambiente usando uma única solução de ADC. O que significa “qualquer ambiente”? Significa que seus servidores locais, a nuvem pública, a nuvem privada ou a nuvem híbrida funcionam com uma única solução. E isso envolve tanto um aspecto prático quanto arquitetônico.

Em primeiro lugar, se você usa servidores locais e não utiliza a nuvem, tudo o que dissemos se aplica perfeitamente. Muitas pessoas que migram para o NGINX e o NGINX Plus em busca de mais flexibilidade, mais recursos e economia estão exatamente nessa situação: elas fazem a implantação em servidores locais.

Se você usa ou pretende considerar o uso da nuvem daqui para frente, simplesmente não há comparação entre o NGINX e um ADC de hardware. Não é possível transferir seu ADC de hardware para os data centers da Amazon. O ADC de hardware não será útil nesse caso.

Agora, os desenvolvedores de ADCs de hardware oferecem algumas soluções baseadas em software, mas, em alguns casos, recomendam que elas sejam usadas apenas para desenvolvimento. Elas não substituem o ADC de hardware. As vantagens que você talvez perceba em termos de simplicidade, ou a ideia de que “em time que está ganhando não se mexe”, deixam de existir quando você quer migrar para a nuvem.

Com o NGINX e o NGINX Plus, a arquitetura da aplicação é independente da plataforma de entrega. Alguns provedores de nuvem estão começando a adicionar cada vez mais serviços que podem ser integrados por meio de APIs. Durante o desenvolvimento, isso é realmente muito útil, pois você não precisa se preocupar em como fazer algo; basta usar as APIs deles para lidar com balanceamento de carga, cache ou outros recursos. Porém, quando você aumenta a escala, acaba pagando um pequeno valor por cada transação.

De repente, quando você está realizando milhares, dezenas de milhares e centenas de milhares de transações, esses valores começam a se acumular. A cobrança é muito confusa e difícil de prever, principalmente porque se baseia no tráfego, que está sempre variando.

Se você usar uma abordagem baseada no NGINX ou no NGINX Plus, fará basicamente a mesma coisa em qualquer plataforma, com pouquíssima diferença ao migrar para outro provedor de nuvem ou trazer a operação de volta para a infraestrutura interna.

Na verdade, temos clientes que fazem balanceamento de carga entre seus servidores locais e a nuvem. Então, como isso funciona? Eles mantêm servidores locais suficientes para atender às suas necessidades em 80% ou 90% do tempo. Quando precisam aumentar a capacidade, não precisam comprar nem sequer instalar novos servidores; basta expandir para a nuvem.

A nuvem geralmente é mais lenta do que os servidores locais e, como tudo é balanceado, somente as sessões que seriam descartadas se você estivesse usando apenas os servidores internos são direcionadas para a nuvem. Elas apresentam uma latência um pouco maior, mas são processadas, em vez de entrarem em uma fila ou serem descartadas.

Financeiramente, isso é ótimo, pois você só paga pela nuvem em situações emergenciais, como um pico repentino de tráfego. Isso pode acontecer devido à cobertura da mídia, caso seu produto receba uma boa avaliação, ou porque você está excedendo continuamente o previsto no seu plano de negócios e ainda não ampliou sua infraestrutura interna para atender à demanda. Também pode ser época de festas, quando simplesmente não compensa manter o dobro de servidores que serão necessários apenas por algumas semanas no ano, já que é possível suprir essa demanda expandindo para a nuvem. Com o NGINX, tudo isso pode ser feito de forma flexível e até automática.

35:42 Motivo nº 4 – Adapte-se rapidamente às mudanças nas demandas

O NGINX permite que você se adapte rapidamente às mudanças nas demandas das suas aplicações. Quando é necessário adicionar servidores ou pares de servidores com rapidez para garantir alta disponibilidade, não dá para esperar que o hardware seja encomendado, entregue, recebido e testado, nem para configurar as iRules ou qualquer outro software necessário. Além disso, as iRules são proprietárias — você só precisa delas se tiver um servidor F5. Também não é fácil encontrar profissionais recém-formados com esse conjunto de habilidades. Se o profissional responsável pelas iRules sair da empresa, será muito difícil encontrar um substituto.

Quando se trata de alterações de configuração, muitas vezes não é possível esperar que a equipe de operações de rede as aprove. Você certamente não quer que suas alterações entrem na fila junto com outras menos urgentes.

Com o NGINX, há muito menos burocracia para aprovar novos projetos. Com o NGINX e o NGINX Plus, você pode manter alguns equipamentos extras guardados quando se trata de servidores que custam US$ 2.000 ou US$ 3.000. Isso não é possível quando se trata de ADCs de hardware que custam dezenas de milhares de dólares.

Esse tipo de flexibilidade, redundância e capacidade de fazer o que você precisa, quando precisa, é um recurso essencial do NGINX e parte do motivo pelo qual as pessoas que usam nossas soluções gostam tanto de nós.

37:08 Motivo nº 5 – Sem limitações artificiais de desempenho

Por fim, com o NGINX, não há restrições artificiais ou impostas por contrato ao desempenho. No NetScaler Enterprise Edition, o limite contratual de taxa de transferência desse servidor é de 0,5 Gbps. Bem, isso é absurdo em um ambiente corporativo. Uma configuração comparável do NGINX executada em hardware padrão do setor oferece suporte a 20 Gbps. Isso é 40 vezes o limite da Citrix.

Outro ponto é que o número da Citrix representa uma limitação contratual. Se você ultrapassá-lo, os valores a pagar aumentam de forma repentina e drástica. Os 20 Gbps são uma recomendação nossa. Isso significa apenas que, ao chegar nessa faixa, talvez você comece a notar uma pequena queda no desempenho e considere uma boa ideia adquirir outro servidor e distribuir a carga entre eles. Mas você tem flexibilidade; a decisão é sua. Seu orçamento não sofre um impacto repentino.

Com a Citrix, é como dar de cara com uma placa de pare. Nesse cenário, fazer mais negócios pode ser uma má notícia. Um único cliente a mais pode custar muito dinheiro, e alguns clientes adicionais também podem gerar um grande custo, pois fazem com que você ultrapasse esses limites. Ao usar o NGINX, fazer mais negócios é uma boa notícia, e seus custos aumentam de forma constante, acompanhando o crescimento da receita decorrente da expansão da sua base de clientes.

Muitas vezes, recebemos ligações urgentes de pessoas que ultrapassaram esses limites e, de repente, estouraram o orçamento. E elas não conseguirão voltar a ficar dentro do orçamento sem fazer uma grande mudança. Então, precisam correr para migrar para o NGINX e voltar a uma situação favorável. No fim, muitas vezes acabam até gastando menos do que o previsto, porque economizaram muito com o NGINX.

Mas quem precisa dessa dor de cabeça? Sem falar na incerteza e na sensação de apreensão quando, de repente, você se depara com esse terrível conflito entre orçamento e desempenho. Migrar para o NGINX desde o início significa que você pode ficar completamente livre disso.

40:00 Recursos

• Estudo de caso – NGINX na WordPress.com/Automattic
• Estudo de caso – A Montana Interactive melhora o desempenho dos aplicativos e o atendimento ao cliente com o NGINX Plus
• Estudo de caso – Como a Buydig.com dimensiona e protege seu aplicativo Microsoft .NET sem alterar uma única linha de código
• E-book – 5 motivos para migrar para um software de balanceamento de carga
• Blog – NGINX Plus vs. F5 BIG‑IP: uma comparação de preço e desempenho
• Blog – NGINX Plus vs. Citrix NetScaler: uma comparação de preço e desempenho
• Avaliação gratuita do NGINX Plus

Sobre o autor

Floyd SmithDiretor de Marketing de Conteúdo

Mais publicações de Floyd Smith