5 motivos para mudar para balanceamento de carga de software

Esta postagem foi adaptada de um webinar de Floyd Smith e Faisal Memon da NGINX, Inc. Nosso novo e-book sobre o assunto está disponível para download .

Índice

0:00 Introdução

Floyd Smith: Olá e bem-vindos à nossa apresentação. Estamos aqui na NGINX e falaremos hoje sobre meu e-book 5 Reasons to Switch to Software for Load Balancing .

Somos dois apresentando aqui hoje. Eu sou Floyd Smith, redator de marketing técnico da NGINX. Anteriormente, fui redator técnico sênior na Apple e fui 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 fazendo desenvolvimento em C. Engenheiro de Software na Cisco – desempenhei essa função por cerca de oito anos.

1:38 Quem é você?

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

Foi muito interessante ver os títulos das pessoas que estão participando. Temos Arquitetos de Soluções – vários tipos diferentes de arquitetos. Administradores Linux, Chefes de Engenharia, CEO, Gerente Sênior de Entrega Ágil, diversas pessoas com títulos de DevOps, Desenvolvedor de Software Full Stack, Engenheiro, Cientista, Desenvolvedor, Gerente de Operações de Marketing.

Temos uma gama muito boa de pessoas com inclinação técnica. Minha impressão é que as pessoas que estão neste webinar são realmente muito práticas com a tecnologia e enfrentarão diretamente os problemas sobre os quais estamos falando hoje.

Também temos uma gama muito boa e ampla de organizações representadas. Alguns de vocês podem estar analisando isso para orientar seus clientes a tomar decisões inteligentes, mas a maioria parece estar lidando com isso diretamente, internamente.

3:53 Do Hardware ao Software

O mercado de ADCs de hardware está em declínio, de acordo com relatórios financeiros, então as pessoas que vendem ADCs de hardware estão tentando aumentar a receita que recebem por cliente, mesmo com o declínio de sua base de clientes. Muitos clientes de ADC 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 ADC de hardware. Eles estão começando a perceber que podem fazer a mesma coisa melhor em software e ganhar mais flexibilidade. Aqueles que têm DevOps no título provavelmente sabem o que quero dizer.

O que vemos frequentemente aqui na NGINX é que as pessoas atingem a data de renovação do contato em seu ADC de hardware, ou têm um aumento repentino no tráfego e um aumento repentino nas cobranças, e então elas realmente estão lutando para sair do contrato. Então eles têm que tentar fazer as coisas muito rapidamente. Eles geralmente conseguem, mas é estressante, não é planejado e não é orçado. Com a ajuda desta apresentação, você pode iniciar um processo mais planejado.

A questão orçamentária não é tão crítica, porque você economiza muito dinheiro ao migrar para o software, mas os aborrecimentos operacionais são enormes. Você pode reduzir muito esses riscos apenas começando cedo.

NGINX é uma alternativa realmente sólida para um ADC de hardware. Ele foi criado originalmente para resolver o problema C10K . É um servidor web executado em um computador que atende 10.000 ou mais conexões simultâneas. Antes do NGINX isso era impossível. As pessoas criavam um site, ele se tornava popular e depois fracassava. Impedir que isso acontecesse foi muito, muito, muito difícil, mas com o NGINX ficou muito mais fácil.

Nosso primeiro lançamento de código aberto foi em 2004 na Rússia, onde o NGINX [o software] foi criado originalmente [Editor – Floyd diz “fundado” aqui; a NGINX, Inc. foi fundada em 2011] . NGINX Plus, a versão comercial com suporte, foi lançada 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 capital de risco de líderes do setor. Temos mais de 800 clientes e atingimos 100 funcionários no outro dia.

6:33 O servidor web líder para os sites mais movimentados do mundo

Há 160 milhões de sites no total em execução no NGINX.

Ele é usado em dois modos diferentes. Alguns sites executam o NGINX como um servidor web , que era seu propósito original. Mas muitos sites executam o NGINX como um servidor proxy reverso . É aí que você coloca o NGINX na frente da sua arquitetura atual, usando o NGINX para manipular o tráfego e rotear o tráfego para seus servidores de aplicativos. Ao fazer isso, você estará no caminho certo para fazer o balanceamento de carga , que é sobre o que falaremos hoje.

51 por cento dos 10.000 sites mais movimentados migraram para o NGINX. Agora, por que isso? Por que temos ainda mais uso entre os sites mais movimentados do que entre os sites como um todo?

O motivo é que o NGINX é a melhor solução para sites muito movimentados. Uma maneira rápida de salvar um site movimentado que está com problemas é instalar o NGINX como um servidor proxy reverso e executar o balanceamento de carga nele .

Com o tempo, você pode migrar seus aplicativos existentes para o NGINX ou, caso desenvolva novos, pode executar o NGINX como servidor web também para eles. E foi assim que conseguimos esse uso entre essas pessoas muito ocupadas, que não trocam de servidor web por capricho. Eles têm experiência com outros servidores web e sabem como usá-los, mas fazem essa mudança por causa de tudo o que o NGINX faz por eles.

36 por cento de todos os sites na Amazon Web Services usam NGINX. Está se tornando uma ferramenta padrão. Agora, as pessoas geralmente começam com o NGINX e continuam com ele durante todo o projeto.

Aqui estão alguns dos sites que nos utilizam. Claro, com 160 milhões de sites usando NGINX, não podemos colocá-los todos em um slide, mas alguns de nossos parceiros e amigos são Netflix, Airbnb, Uber e Amazon Web Services, como mencionei, Box, Pinterest, WordPress.

Todas essas empresas que fazem entregas pela internet para viver, onde isso tem que funcionar, migraram para o NGINX.

8:48 Onde o NGINX se encaixa

Vamos ver onde o NGINX se encaixa.

À direita, você vê o NGINX sendo executado como um servidor web. E como um servidor web, ele usa um gateway de aplicativo para permitir que diferentes tipos de servidores de aplicativo sejam executados com ele. O NGINX como servidor web pode lidar com 10.000 conexões simultâneas, mais ou menos, dependendo do que você está fazendo.

Mas o NGINX também é útil como um servidor proxy reverso, e é aí que você obtém cache, balanceamento de carga e uma série de outros recursos.

9:32 Arquitetura Web Moderna

O NGINX também ajuda você a migrar para uma arquitetura web moderna. Isso poderia ser arquiteturas de três camadas no estilo J2EE migrando para microsserviços. Podem ser protocolos complexos de HTML e SOAP migrando para protocolos mais leves, como REST e mensagens, que são uma parte importante dos microsserviços. Ou passar de implantações persistentes para implantações mutáveis executando contêineres ou VMs.

Em vez de uma infraestrutura fixa e estática, você geralmente tem um serviço que é seu. Temos coisas como SDN e NFV e a nuvem, especialmente a nuvem. Em vez de grandes lançamentos a cada poucos meses, você tem entregas contínuas a cada poucas horas. E em vez de equipes isoladas, onde você tem um grupo de desenvolvimento, um grupo de testes e um grupo de operações trabalhando por meio de seus próprios gerentes, você tem uma cultura DevOps de responsabilidade compartilhada, onde todos arregaçam as mangas e lidam com alguns aspectos de cada problema.

10:42 DevOps funciona muito bem com NGINX

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

A história do DevOps está intimamente interligada com o NGINX. Muitas pessoas do DevOps têm o NGINX em seus bolsos e, quando se deparam com uma implantação que está tendo problemas, eles trazem o NGINX.

Em certas implantações, você nem precisa se preocupar em alterar a configuração do aplicativo. Você coloca o NGINX na frente dele e obtém o tráfego para os servidores de aplicativos de uma forma que eles possam manipular. Você não alterou esse código e não arriscou sua funcionalidade principal quando estava com pressa para resolver um problema de desempenho.

Uma das coisas em que DevOps e NGINX tendem a trabalhar bem juntos é o balanceamento de carga de software, como discutiremos. Funciona muito bem com implantações em nuvem, mas também com seus próprios servidores. Ele apresenta uma variedade de métodos de balanceamento de carga. Aqui há uma diferença entre NGINX e NGINX Plus, que abordarei em um minuto.

O recurso de reconfiguração instantânea do NGINX oferece suporte à descoberta de serviços e ao tempo de atividade. A descoberta de serviços é essencial para microsserviços e automação e, com a reconfiguração instantânea, você não precisa expulsar pessoas de um servidor para configurá-lo, o que é uma grande vantagem para manter seus clientes online.

As verificações de integridade do aplicativo emitem alertas antecipados sobre problemas de entrega do aplicativo para que você possa encerrar um servidor problemático com elegância, em vez de deixá-lo travar e atrapalhar as pessoas. E então há um monitoramento robusto e personalizável. Novamente, isso permite que você saiba sobre os problemas à medida que eles surgem, para que você possa resolvê-los antes que afetem os clientes.

12:30 Recursos do NGINX Plus

O que há dentro do NGINX Plus?

Então, o NGINX de código aberto é o produto original, e o NGINX Plus é o produto comercial por cima dele. Nós aqui na NGINX gastamos pelo menos 70% do nosso tempo no lado do código aberto, mas essa também é a base para os recursos avançados do NGINX Plus.

O produto de código aberto inclui roteamento de solicitações, que é o cerne do que um servidor web faz; compactação porque isso minimizará a carga em um servidor web e também minimizará o tráfego pela rede, o que pode ser muito valioso. Possui suporte a SSL para segurança. Também temos uma linguagem de script incorporada, duas na verdade. Um é o nosso, o módulo NGINX JavaScript [anteriormente chamado de nginScript], e o outro é o Lua.

Há alguns recursos que são parcialmente de código aberto no NGINX, mas que foram aprimorados no NGINX Plus. Você pode fazer balanceamento de carga muito bem com o NGINX de código aberto, mas com o NGINX Plus, você obtém alguns recursos mais avançados. Da mesma forma, você pode usar o NGINX de código aberto como um cache de ponta e para streaming de mídia, e isso funciona ainda melhor no NGINX Plus.

O NGINX Plus também possui vários recursos próprios. Há monitoramento de integridade de aplicativos, visualização de GUI para seu monitoramento, monitoramento e análise, a API de configuração RESTful e algumas das técnicas de balanceamento de carga mais avançadas.

Com o NGINX Plus, você tem acesso aos engenheiros do NGINX para ajudar a dar suporte enquanto você faz seu trabalho. Se você estiver usando F5, Citrix ou um sistema similar, provavelmente está acostumado a esse tipo de suporte. Para sites maiores e mais movimentados, onde até mesmo um pequeno tempo de inatividade custa muito dinheiro, isso pode ser crucial – e pode facilmente compensar se você evitar até mesmo uma breve interrupção apenas uma vez por ano.

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

Vejamos alguns estudos de caso de clientes que fizeram a troca.

O WordPress.com estava usando o BIG-IP da F5 e eles se afastaram disso para o NGINX porque precisavam fazer balanceamento de carga com mais de 10.000 solicitações por segundo por servidor – esse é o problema C10k sobre o qual estávamos falando e que o NGINX vem resolvendo há mais de dez anos. Na época, eles estavam limitados a 1.000 solicitações por segundo por servidor. Você pode imaginar o quão trabalhoso isso era em comparação a 10.000 ou mais.

O Wordpress.com tinha vários sistemas F5 BIG-IP e eles iriam crescer para dez data centers. Para oferecer suporte à alta disponibilidade, basicamente para ter um backup ativo para cada data center, eles estavam analisando dez pares de servidores BIG-IP. Muito caro. Eles também precisavam de reconfiguração imediata para não desligar os usuários quando eles alterassem a configuração.

Eles começaram a migrar para o NGINX testando-o no Gravatar, um aplicativo que cria um avatar para os usuários. Isso os familiarizou com o NGINX. Então, eles fizeram a mudança de seus servidores F5 para o NGINX, e isso deu a eles uma pegada de memória pequena e previsível, bem como uma pegada de CPU pequena e previsível.

Agora eles lidam com mais de 70.000 solicitações por segundo e 15 gigabits por segundo [Gbps] em 36 servidores NGINX. Eles podem atingir um pico de 20.000 solicitações por segundo por servidor. E eles podem reconfigurar e atualizar rapidamente.

Se você vir a citação, eles estão apenas falando sobre a diferença de despesa entre uma pequena implementação, onde o NGINX economizará uma quantia significativa de dinheiro. Mas quando você usa dez pares de servidores, a diferença é gritante.

16:42 Estudo de caso do 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 para muitos serviços governamentais serem fornecidos online. Se você agendou uma consulta no seu departamento de veículos automotores ou similar, você saberá o que quero dizer. Esses sites podem ajudar você a votar, pagar seus impostos, etc.

Há uma quantidade enorme desses serviços governamentais essenciais, e Montana é um estado muito grande com um número relativamente pequeno de pessoas espalhadas por todo o lugar. Portanto, ter disponibilidade online para serviços é muito importante, em vez de os moradores terem que dirigir seis ou oito horas para chegar a um escritório do governo.

Montana estava migrando para serviços online de forma bastante robusta no início, mas conforme cresceu, começou a sofrer com quedas de sessões. Eles tiveram grandes picos trimestrais no tráfego de transações devido a um grande aplicativo de pagamento de impostos. No meio do preenchimento de um formulário grande, de repente alguém era abandonado e todo o seu trabalho era perdido. Se você está fazendo seus impostos, ou qualquer outro tipo de processo complexo, isso é bem estressante.

A solução para eles foi atualizar os servidores que executavam Pound para o NGINX Plus, colocar o NGINX Plus em diferentes hipervisores e data centers e operar como um proxy reverso dinâmico, roteando solicitações em tempo real, proporcionando melhor gerenciamento de tráfego. Como resultado da mudança para o NGINX Plus, eles viram grandes melhorias em velocidade, flexibilidade e facilidade de uso. Eles se beneficiaram da reconfiguração instantânea, transferiram seu processamento SSL para servidores NGINX e usaram o gerenciamento baseado em funções para melhorar as operações e a segurança.

James Ridle, da Montana Interactive, ficou impressionado com o poder do NGINX. Os benchmarks o surpreenderam e ele quase não conseguia acreditar na diferença no que ele conseguia lidar com os mesmos servidores com o NGINX.

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

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

BuyDig.com tinha um aplicativo .NET mais antigo. Eles não queriam mudá-lo, e não precisavam. Depois de sofrer um ataque DDoS em larga escala, eles perceberam que precisavam de um front-end 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 aplicativo frontend, hospedado na Amazon Web Services. Eles não fizeram nenhuma alteração em seus serviços de backend em execução no .NET. E isso é tão grande – nenhuma mudança – nem pequenas mudanças, nem pequenos aborrecimentos, nem pequenos riscos, mas nenhum.

Agora eles têm desempenho e segurança fantásticos. Eles usaram linguagens de configuração para o NGINX para personalizá-lo. Eles usam TLS SNI e logs personalizáveis para ajudá-los a permanecer seguros. Eles não tiveram nenhuma lentidão ou tempo de inatividade do site e estão muito felizes com o desempenho.

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

20:10 Ebook – 5 razões para mudar para software de balanceamento de carga

Agora, deixe-me mergulhar no e-book. Vou lhe dar um rápido resumo do que está no e-book e então Faisal vai lhe explicar os dois primeiros motivos para mudar, que são mais técnicos, e eu continuo depois disso. Há links. Você receberá esta apresentação e a gravação do webinar disponíveis depois que terminarmos. Acho que demora cerca de um dia para esse e-mail ser enviado.

E este link aqui levará você a um local para download deste e-book gratuito . Então, só para mencionar antecipadamente quais são os motivos: eles são para cortar custos; melhorar o ajuste do DevOps; implementar em qualquer lugar (seus próprios servidores locais, na nuvem, nuvem privada, qualquer coisa que você queira fazer); a capacidade de se adaptar rapidamente e nenhuma restrição contratual estranha, que explicarei em detalhes. Mas agora, deixe-me passar a palavra ao Faisal para falar sobre corte de custos.

21:22 Motivo #1 – Reduzir drasticamente os custos

Faisal: Obrigado, Floyd. O motivo nº 1 dos cinco motivos é que você pode reduzir drasticamente os custos migrando para o NGINX Plus para entrega de aplicativos de software.

Olhando para meados dos anos 90, a única maneira de escalar um site era comprar um servidor maior, o que era incrivelmente caro e também não confiável, porque aquele único servidor também era um único ponto de falha.

Foi nessa época que a F5 lançou o BIG-IP pela primeira vez, o que proporcionou uma arquitetura diferente para proprietários de sites; em vez de comprar um servidor maior, você poderia usar o BIG-IP para balancear a carga de uma série de servidores baratos. Isso reduz custos, porque é mais barato comprar o BIG-IP e os servidores baratos do que comprar aquele servidor gigantesco, e você também ganha alguma redundância porque eliminou o ponto único de falha.

Esta era uma grande arquitetura – revolucionária e realmente a única na cidade na época – mas muitas coisas mudaram nos últimos 20 anos. Uma grande mudança foi que o custo dos servidores caiu drasticamente. Hoje em dia, você pode comprar um servidor bastante robusto por menos do que o custo de um mês de aluguel aqui na área da baía de São Francisco.

A segunda grande mudança é a existência atual de software de código aberto como o NGINX, que fornece a mesma funcionalidade que você obtém do F5 BIG-IP ou do Citrix NetScaler. No caso do código aberto, você pode obter funcionalidades semelhantes às desses grandes e caros aparelhos de graça. Floyd apontou anteriormente que há mais de 160 milhões de sites usando NGINX. E se você olhar para os 10.000 principais sites, mais da metade deles está rodando em NGINX.

Então, agora temos este software de código aberto que não só tem todas as funcionalidades que você precisa em comparação ao F5, mas também é tão escalável e confiável quanto qualquer outro produto comercial.

23:19 NGINX Plus vs. F5 GRANDE IP

Fiz alguns testes comparativos e análises de custos no início deste ano e aqui está um trecho disso. Isso compara o software NGINX Plus executado em hardware de mercado. Neste caso, ele é fornecido pela Dell e [estamos] comparando isso com diferentes modelos do F5 BIG-IP.

Este exemplo em particular é o 2000S, que é o F5 BIG-IP de nível básico. Comparei-o com dois tamanhos diferentes de NGINX Plus em servidores Dell. Um que tem desempenho um pouco inferior ao F5 BIG-IP (você pode ver as métricas de desempenho ali embaixo) e outro que quase dobra o desempenho.

Olhando apenas para a coluna da direita, onde o NGINX Plus dobra o desempenho do 2000S, você obtém uma economia de 78% no Ano 1, incluindo o custo do hardware e o suporte de manutenção por um ano. E essas economias de custos continuam até o 5º ano. Mesmo depois de cinco anos, o custo total de propriedade do NGINX Plus com o servidor Dell é 58% mais barato que o F5.

24:37 NGINX Plus vs. Citrix NetScaler

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

A Citrix tem um licenciamento em que, se você quiser recursos básicos, como cache e compactação de conteúdo, será necessário atualizar sua licença para a licença Enterprise Edition. Com o NGINX, o cache e a compactação de conteúdo estão incluídos sem custo adicional tanto no código aberto quanto no NGINX Plus. Então, o que estamos comparando aqui é a Enterprise Edition do Citrix NetScaler, porque ela oferece melhor paridade de recursos com o que é fornecido no NGINX Plus, e vemos a mesma economia de custos aqui que vemos com o F5 quando você substitui o Citrix NetScaler pelo NGINX Plus.

Você obtém todos os mesmos recursos e desempenho que espera, mas paga 89% menos no Ano 1. Mesmo até o Ano 5, você ainda estará economizando 75% tanto no custo do hardware (neste caso, servidores Dell comuns) quanto no custo de uma assinatura do software NGINX Plus.

Uma métrica crítica, sobre a qual os fornecedores de hardware falam muito, são as transações SSL por segundo, ou o número de novas conexões SSL que podem ser feitas por segundo. Dentro dessas plataformas, esse número normalmente é acelerado pelo hardware, então o NetScaler e o F5 BIG-IP têm hardware especializado para acelerar transações SSL, o que aumenta o custo dessas plataformas.

O que estamos vendo é que mesmo com uma solução de software – sem aceleração de hardware, apenas usando o poder de processamento da CPU – podemos acompanhar o hardware personalizado. Oferecemos economias de custos drásticas com o desempenho que você obteria com soluções aceleradas por hardware.

Então, essa é a razão nº 1: você pode economizar muito dinheiro migrando para o NGINX Plus. Mas não se trata apenas de dinheiro.

26:52 Motivo #2 – DevOps requer entrega de aplicativos de software

Com uma solução baseada em software, você também obtém muita flexibilidade, e o motivo nº 2 para mudar para um balanceador de carga baseado em software é que, se você estiver migrando para DevOps, realmente precisará de software para entrega de aplicativos.

Com o F5 e o NetScaler, a maneira como esses dispositivos são normalmente implantados em grandes empresas é como um ponto de agregação. Então, muito tráfego não relacionado passa por ele. O mesmo F5 BIG-IP pode fazer o balanceamento de carga de firewalls de rede, pode fazer o balanceamento de carga de servidores de e-mail corporativos, pode fazer o balanceamento de carga de vários aplicativos corporativos de back-end diferentes e também pode fazer o balanceamento de carga de aplicativos corporativos front-end. Podem ser APIs de balanceamento de carga em uma arquitetura de microsserviços. Então, ele pode balancear muitas coisas.

À primeira vista, parece uma boa arquitetura porque é bem simples; você simplesmente executa tudo pelo F5. Por muito tempo isso funcionou, especialmente no início dos anos 2000, quando tudo girava em torno do data center privado, e executávamos todos os nossos aplicativos, tudo em que a empresa dependia, em um data center local. Mas as coisas mudaram nos últimos anos, e agora a maioria das coisas está sendo movida para a nuvem.

Quando digo nuvem, não estou falando apenas de hospedar um aplicativo da web front-face na Amazon, mas também de usar coisas como Salesforce e Office 365, em vez de sistemas de CRM e servidores de e-mail locais. Então, ter um dispositivo que pode fazer todas essas coisas pode ser um exagero para o que as pessoas realmente usam hoje em dia.

Um segundo problema que essa agregação representa é que ela faz com que esses aparelhos fiquem muito bem bloqueados. Você fica muito hesitante em fazer alterações, porque se você bagunçar a configuração do F5, poderá derrubar toda a rede corporativa. Pode ser balanceamento de carga de servidores de e-mail, firewalls de rede. Portanto, a configuração se torna um assunto arriscado e as alterações precisam ser muito restritas e bloqueadas.

Qualquer pessoa que queira fazer alterações normalmente precisa abrir um tíquete de TI, o que pode levar horas, dias ou semanas, dependendo da organização e da prioridade que a organização atribui à alteração solicitada.

Ter esse hardware extremamente bloqueado torna muito difícil migrar para o DevOps. Quando você está fazendo DevOps e está caminhando em direção à automação, você está caminhando em direção à integração contínua, você está caminhando em direção à liberação de código com muito mais frequência. E se você tiver que registrar um tíquete de TI toda vez que quiser fazer uma alteração, isso inibe e mata essa iniciativa.

O que vemos em muitas organizações é que as pessoas que são responsáveis pelo aplicativo e querem migrar para o DevOps e para o desenvolvimento ágil não conseguem lidar com a necessidade de abrir um tíquete toda vez, porque isso atrapalha as iniciativas de DevOps e ágeis. Então, às vezes, eles implantam o NGINX de código aberto e têm o F5 BIG-IP apontando para ele, e essa instância do NGINX será gerenciada pelo DevOps ou pela equipe do aplicativo, o que permite que eles façam automação e alterações sem complicações. Então essa é uma maneira de contornar a política corporativa de TI. Então vemos muitos clientes, é claro, depois de experimentarem isso, começarem a migrar para o NGINX Plus para obter recursos mais avançados junto com o suporte.

O NGINX oferece suporte a uma variedade de modelos de implantação flexíveis e diferentes, incluindo aqueles em que você pode manter seu F5 atual. Você pode usar o NGINX Plus para complementar e descarregar o balanceamento de carga e a entrega de aplicativos da Web front-face, APIs e microsserviços, mantendo o F5 em vigor para fazer o balanceamento de carga de rede de servidores de e-mail corporativos. Se você não precisa de serviços de rede e balanceamento de carga de rede, você pode obviamente substituir o F5 pelo NGINX Plus e ter uma única solução.

Oferecemos suporte a uma variedade de modelos de implantação diferentes para ajudar as organizações a migrarem em direção ao DevOps, à entrega contínua e à automação.

Pelo motivo nº 3, vou devolvê-lo ao Floyd.

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

Floyd: Obrigado, Faisal.

Com o NGINX, você pode implantar em qualquer lugar com uma solução ADC. O que significa “em todo lugar”? Isso significa que seus servidores locais, nuvem pública, nuvem privada ou nuvem híbrida funcionam em uma única solução. E há um aspecto prático e também arquitetônico nisso.

Em primeiro lugar, se você estiver usando servidores internos e não estiver usando a nuvem, tudo o que dissemos se aplica fortemente. Muitas pessoas que migram para o NGINX e o NGINX Plus para obter mais flexibilidade, mais recursos e economizar dinheiro estão exatamente nessa situação: estão implantando em servidores internos.

Se você estiver usando ou quiser considerar usar a nuvem conforme avança, não há comparação entre o NGINX e o ADC de hardware. Você não pode mover seu ADC de hardware para os data centers da Amazon. O ADC de hardware não vai ajudar você nisso.

Agora, os desenvolvedores de ADC de hardware têm algumas soluções baseadas em software, mas em alguns casos, eles recomendam apenas que você as use para desenvolvimento. Não é um substituto para o ADC de hardware. As vantagens que você pode ver em termos de simplicidade, ou "se não está quebrado, não conserte", desmoronam quando você quer migrar para a nuvem .

Com o NGINX e o NGINX Plus, a arquitetura do aplicativo é independente da plataforma de entrega. Certos provedores de nuvem estão começando a adicionar mais e mais serviços que você pode vincular por meio de APIs. Durante o desenvolvimento, é realmente uma ótima coisa de se ter, porque você não precisa se preocupar em como fazer algo; você apenas usa suas APIs para lidar com balanceamento de carga, cache ou outros recursos. Mas quando você escala, você paga uma pequena quantia por cada transação.

Bem, de repente, quando você está fazendo milhares, dezenas de milhares e centenas de milhares de transações, esses números começam a somar. O faturamento é muito confuso e difícil de prever, principalmente porque é baseado no tráfego, que está sempre variando.

Se você usar uma abordagem baseada em NGINX‑ ou NGINX Plus‑, basicamente fará a mesma coisa em qualquer plataforma, e haverá muito pouca diferença quando você mudar para um provedor de nuvem diferente ou voltar para casa.

Na verdade, temos clientes fazendo balanceamento de carga entre seus servidores internos e na nuvem. Então, como é isso? Eles recebem servidores internos suficientes para atender às suas necessidades em 80 ou 90 por cento do tempo. Então, quando eles precisam escalar, eles não precisam comprar ou mesmo conectar novos servidores; eles apenas escalam para a nuvem.

A nuvem geralmente é mais lenta do que seus servidores locais e, como tudo tem balanceamento de carga, apenas as sessões que seriam descartadas se você estivesse usando apenas seus servidores internos vão para a nuvem. Eles têm uma latência um pouco maior, mas são manipulados, não são colocados em uma fila ou descartados.

Financeiramente é ótimo porque você só paga pela nuvem em caso de emergência, como um pico repentino de tráfego. Isso pode acontecer por causa da cobertura da imprensa, se seu produto receber uma boa avaliação, ou você pode estar excedendo seu plano de negócios continuamente e ainda não expandiu internamente para atendê-lo, ou acontece de ser feriado e simplesmente não vale a pena ter o dobro de servidores dos quais você precisará apenas por algumas semanas do ano, quando você pode fazer isso escalando para a nuvem. Com o NGINX, tudo isso pode ser feito de forma flexível e até mesmo automática.

35:42 Razão #4 – Adapte-se rapidamente às demandas em mudança

O NGINX permite que você se adapte rapidamente para atender às demandas em constante mudança em seus aplicativos. Quando você precisa adicionar servidores rapidamente ou adicionar pares de servidores para alta disponibilidade, você não pode esperar que o hardware seja pedido, entregue, recebido, testado e faça suas iRules ou qualquer configuração de software que você precise fazer para eles. iRules também é proprietário – a única vez que você precisa de iRules é se você tiver um servidor F5. Não é um conjunto de habilidades que você pode contratar facilmente depois de sair da faculdade. Se a sua pessoa do iRules for embora, você terá dificuldade em encontrar outra.

Quando se trata de alterações de configuração, muitas vezes você não pode esperar que as operações de rede aprovem as alterações. Você realmente não quer que suas alterações sejam colocadas na fila com coisas menos urgentes.

Com o NGINX, há muito menos despesas gerais para aprovação de novos projetos. Com o NGINX e o NGINX Plus, você pode manter algum hardware extra em um armário quando estiver falando de servidores que custam US$ 2.000 ou US$ 3.000. Você não pode fazer isso quando está falando de várias dezenas de milhares de dólares em ADCs de hardware.

Esse tipo de flexibilidade, redundância e capacidade de fazer o que você precisa fazer, quando precisa, é um recurso essencial do NGINX e parte do motivo pelo qual as pessoas que nos usam nos amam tanto.

37:08 Motivo #5 – Sem restrições artificiais de desempenho

Por fim, com o NGINX não há restrições artificiais ou de contato no desempenho. Para o NetScaler Enterprise Edition, o limite contratual de taxa de transferência para esse servidor é de 0,5 Gbps. Bem, isso é ridículo em uma situação empresarial. A configuração NGINX comparável executada em hardware padrão da indústria suportará 20 Gbps. Isso é 40 vezes o limite da Citrix.

A outra coisa é que o número Citrix é uma restrição contratual. Se você ultrapassar esse valor, seus termos de pagamento aumentarão repentina e drasticamente. 20 Gbps é uma recomendação nossa. Então, isso significa que quando você chegar nessa área, você pode começar a notar que seu desempenho está caindo um pouco, e você pode pensar que é uma boa ideia obter outro servidor e balancear a carga nele. Mas você tem flexibilidade; você decide. Você não sofre uma redução repentina no seu orçamento.

Com a Citrix, é como bater em um sinal de parada. Nesse cenário, mais negócios podem ser uma má notícia. Mais um cliente pode custar muito dinheiro para você, mais alguns clientes podem custar muito dinheiro para você porque eles colocam você acima desses limites. Ao usar o NGINX, ter mais negócios é uma boa notícia, e seus custos aumentam constantemente com o aumento da receita proveniente da expansão da sua base de clientes.

Muitas vezes recebemos chamadas urgentes de pessoas que ultrapassaram esses limites e, de repente, elas ultrapassaram o orçamento. E eles não vão conseguir voltar ao orçamento sem fazer uma grande mudança. Depois, eles precisam se esforçar para entrar no NGINX e voltar a uma boa situação. Então, muitas vezes eles acabam ficando abaixo do orçamento porque economizaram muito dinheiro no NGINX.

Mas quem precisa dessa dor de cabeça? Assim como a incerteza e a sensação de pavor quando de repente você se depara com esse terrível conflito entre orçamento e desempenho? Mudar para o NGINX logo no início significa que você pode ficar completamente livre disso.

40:00 Recursos

• Estudo de caso – NGINX em WordPress.com/Automattic
• Estudo de caso – Montana Interactive melhora o desempenho do aplicativo e o atendimento ao cliente com NGINX Plus
• Estudo de caso – Como Buydig.com dimensiona e protege seu aplicativo Microsoft .NET sem alterar uma única linha de código
• Ebook – 5 razões para mudar para software de balanceamento de carga
• Blog – NGINX Plus vs. F5 GRANDE-IP: Uma comparação de preço e desempenho
• Blog – NGINX Plus vs. Citrix NetScaler: Uma comparação de preço e desempenho
• Teste gratuito do NGINX Plus