5 razones para cambiar al balanceo de carga de software

Esta publicación es una adaptación de un seminario web de Floyd Smith y Faisal Memon de NGINX, Inc. Nuestro nuevo libro electrónico sobre el tema está disponible para descargar .

Tabla de contenido

0:00 Introducción

Floyd Smith: Hola y bienvenido a nuestra presentación. Estamos aquí en NGINX y hoy hablaremos sobre mi libro electrónico 5 razones para cambiar a software para equilibrio de carga .

Somos dos los que nos presentamos aquí hoy. Soy Floyd Smith, redactor de marketing técnico de NGINX. Anteriormente, fui redactor técnico sénior en Apple y he escrito varios libros sobre diferentes aspectos de la tecnología.

Faisal Memon: Hola, soy Faisal Memon y trabajo en Marketing de Producto en NGINX. Llevo aquí aproximadamente un año. Antes de venir aquí a NGINX, trabajé como ingeniero de marketing técnico en Riverbed y también en Cisco. Comencé mi carrera realizando desarrollo en C. Ingeniero de software en Cisco: desempeñé ese rol durante aproximadamente ocho años.

1:38 ¿Quién eres tú?

Floyd: Recibimos las inscripciones para nuestros seminarios web antes de realizarlos, y podemos ver los puestos de trabajo, las organizaciones y los motivos de asistencia que cada uno de ustedes envió.

Fue realmente interesante ver los títulos de las personas que asisten. Tenemos arquitectos de soluciones: varios tipos diferentes de arquitectos. Administradores de Linux, jefes de ingeniería, directores ejecutivos, gerentes sénior de entrega ágil, varias personas con títulos de DevOps, desarrolladores de software de pila completa, ingenieros, científicos, desarrolladores, gerentes de operaciones de marketing.

Contamos con un grupo muy amplio de personas con inclinaciones técnicas. Tengo la sensación de que las personas que participan en este seminario web tienen un profundo conocimiento práctico de la tecnología y se enfrentarán directamente a los problemas que estamos tratando hoy aquí.

También contamos con una gama muy amplia y agradable de organizaciones representadas. Puede que algunos de ustedes estén mirando esto para poder guiar a sus clientes en la toma de decisiones inteligentes, pero la mayoría parece estar lidiando con esto directamente, internamente.

3:53 Del hardware al software

Según los informes financieros, el mercado de ADC de hardware está en declive, por lo que quienes venden ADC de hardware están tratando de aumentar los ingresos que obtienen por cliente incluso cuando su base de clientes disminuye. Muchos clientes de ADC de hardware están empezando a descubrir que no quieren formar parte de ese grupo cada vez más reducido de personas que pagan cada vez más dinero por estos servicios proporcionados por ADC de hardware. Están empezando a ver que realmente pueden hacer lo mismo mejor en el software y, además, ganar más flexibilidad. Aquellos de ustedes que tengan DevOps en su título probablemente sepan a qué me refiero.

Lo que vemos a menudo aquí en NGINX es que las personas llegan a la fecha de renovación del contrato en su hardware ADC, o sufren un aumento repentino en el tráfico y un incremento repentino en los cargos, y luego realmente luchan por salir del contrato. Luego tienen que intentar hacer las cosas muy rápidamente. Generalmente tienen éxito, pero es un proceso estresante, no planificado y sin presupuesto. Con la ayuda de esta presentación podrás iniciar un proceso más planificado.

La cuestión presupuestaria no es tan crítica, porque se ahorra mucho dinero al pasar al software, pero los problemas operativos son enormes. Puedes reducirlos mucho si empiezas temprano.

NGINX es una alternativa realmente sólida a un ADC de hardware. Se creó originalmente para resolver el problema C10K . Se trata de un servidor web que se ejecuta en una computadora y atiende 10.000 o más conexiones simultáneas. Antes de NGINX era imposible. La gente crearía un sitio web, se volvería popular y luego fracasaría. Evitar que esto sucediera fue muy, muy, muy difícil, pero con NGINX, se volvió mucho más fácil.

Nuestro primer lanzamiento de código abierto fue en 2004 en Rusia, donde se creó originalmente NGINX [el software] [Editor: Floyd dice “fundado” aquí; NGINX, Inc. se fundó en 2011] . NGINX Plus, la versión comercial con soporte, se lanzó en 2013.

La empresa NGINX tiene su sede en Silicon Valley (San Francisco) y nuestras oficinas de desarrollo están en Moscú. También tenemos oficinas en el Reino Unido. La empresa cuenta con respaldo de capital riesgo de líderes del sector. Tenemos más de 800 clientes y el otro día llegamos a 100 empleados.

6:33 El servidor web líder para los sitios más concurridos del mundo

Hay un total de 160 millones de sitios que se ejecutan en NGINX.

Se utiliza en dos modos diferentes. Algunos sitios ejecutan NGINX como servidor web , que era su propósito original. Pero muchos sitios ejecutan NGINX como un servidor proxy inverso . Ahí es donde colocas NGINX frente a tu arquitectura actual, usando NGINX para manejar el tráfico y enrutarlo a tus servidores de aplicação . Tan pronto como hagas eso, estarás en camino de realizar el equilibrio de carga , que es de lo que hablaremos hoy.

El 51 % de los 10 000 sitios web más activos se han migrado a NGINX. ¿A qué se debe esto? ¿Por qué tenemos un uso aún mayor entre los sitios web más activos que entre los sitios web en general?

La razón es que NGINX es la mejor solución para sitios web realmente concurridos. Una forma rápida de salvar un sitio web con mucho trabajo y que tiene problemas es instalar NGINX como servidor proxy inverso y luego ejecutar un equilibrio de carga sobre él .

Con el tiempo, puede migrar sus aplicaciones existentes a NGINX o, si desarrolla otras nuevas, puede ejecutar NGINX también como servidor web para ellas. Y así es como hemos logrado este uso entre estas personas muy ocupadas, que no cambian de servidor web por capricho. Tienen experiencia con otros servidores web y saben cómo utilizarlos, pero hacen este cambio por todo lo que NGINX hace por ellos.

El 36 % de todos los sitios en Amazon Web Services usan NGINX. Se está convirtiendo en una herramienta estándar. Actualmente, la gente suele empezar con NGINX y continuar usándolo durante todo el proyecto.

A continuación se muestran algunos de los sitios que nos utilizan. Por supuesto, con 160 millones de sitios web que usan NGINX, no podemos incluirlos a todos en una sola diapositiva, pero algunos de nuestros socios y amigos son Netflix, Airbnb, Uber y Amazon Web Services, como mencioné, Box, Pinterest, WordPress.

Todas estas empresas que se dedican a la distribución web para ganarse la vida, donde es necesario que funcione, se han mudado a NGINX.

8:48 Dónde encaja NGINX

Veamos dónde encaja NGINX.

A la derecha, puedes ver NGINX ejecutándose como servidor web. Y como servidor web, utiliza un portal de aplicação para permitir que distintos tipos de servidores de aplicaciones se ejecuten con él. NGINX como servidor web puede manejar 10.000 conexiones simultáneas, más o menos, dependiendo de lo que esté haciendo.

Pero NGINX también es útil como servidor proxy inverso, y ahí es donde se obtiene almacenamiento en caché, equilibrio de carga y una serie de otras capacidades.

9:32 Arquitectura web moderna

NGINX también le ayuda a migrar a una arquitectura web moderna. Podrían ser arquitecturas estilo J2EE de tres niveles que migren a microservicios. Podrían ser protocolos complejos de HTML y SOAP los que se trasladen a protocolos más ligeros como REST y mensajería, que es una gran parte de los microservicios. O pasar de implementaciones persistentes a implementaciones mutables que ejecutan contenedores o máquinas virtuales.

En lugar de una infraestructura fija y estática, normalmente tienes un servicio del que eres propietario. Tenemos cosas como SDN y NFV y la nube, especialmente la nube. En lugar de lanzamientos masivos cada pocos meses, tienes una entrega continua cada pocas horas. Y en lugar de equipos aislados, donde tienes un grupo de desarrollo, un grupo de pruebas y un grupo de operaciones trabajando a través de sus propios gerentes, tienes una cultura DevOps de responsabilidad compartida donde todos se arremangan y manejan algunos aspectos de cada problema.

10:42 DevOps funciona muy bien con NGINX

Metodología DevOps, implementaciones en la nube y descubrimiento automatizado de servicios” size-full wp-image-46723″ style=”border:2px solid #666666; padding:2px; margin:2px;” />

La historia de DevOps está estrechamente relacionada con NGINX. Muchos expertos en DevOps tienen NGINX a mano, y cuando se encuentran con una implementación con problemas, recurren a NGINX.

En ciertas implementaciones, es posible que ni siquiera sea necesario molestarse en cambiar la configuración de la aplicación. Colocas NGINX delante y obtienes el tráfico hacia los servidores de aplicaciones de una manera que ellos puedan manejar. No has cambiado ese código y no has puesto en riesgo tu funcionalidad principal cuando tienes prisa por resolver un problema de rendimiento.

Una de las cosas en las que DevOps y NGINX tienden a funcionar bien juntos es el equilibrio de carga del software, como analizaremos. Funciona muy bien con implementaciones en la nube, pero también con sus propios servidores. Cuenta con una variedad de métodos de equilibrio de carga. Aquí hay una diferencia entre NGINX y NGINX Plus, que explicaré en un minuto.

La capacidad de reconfiguración sobre la marcha de NGINX respalda el descubrimiento de servicios y el tiempo de actividad. El descubrimiento de servicios es esencial para los microservicios y la automatización, y con la reconfiguración sobre la marcha, no es necesario sacar a las personas de un servidor para configurarlo, lo que es una gran ventaja para mantener a sus clientes en línea.

Los controles de estado de las aplicação brindan una advertencia temprana sobre problemas en la entrega de aplicação para que pueda cerrar con elegancia un servidor problemático, en lugar de simplemente dejar que se bloquee y desconcertar a los usuarios. Y luego está el monitoreo robusto y personalizable. Nuevamente, esto le permite conocer los problemas a medida que surgen, para que pueda resolverlos antes de que afecten a los clientes.

12:30 Capacidades de NGINX Plus

¿Qué hay dentro de NGINX Plus?

Entonces, NGINX de código abierto es el producto original, y NGINX Plus es el producto comercial que lo sustenta. Aquí en NGINX dedicamos al menos el 70 por ciento de nuestro tiempo al código abierto, pero esa también es la base de las funciones avanzadas de NGINX Plus.

El producto de código abierto incluye enrutamiento de solicitudes, que es el núcleo de lo que hace un servidor web; compresión porque eso minimizará la carga en un servidor web y también minimizará el tráfico a través de la red, lo que puede ser muy valioso. Tiene soporte para SSL para seguridad. También tenemos un lenguaje de script incorporado, dos en realidad. Uno es nuestro, el módulo JavaScript NGINX [antes llamado nginScript], y el otro es Lua.

Hay un par de capacidades que son en parte de código abierto de NGINX pero que están mejoradas en NGINX Plus. Puedes equilibrar la carga bastante bien con NGINX de código abierto, pero con NGINX Plus obtienes un par de capacidades más avanzadas. De manera similar, puedes usar NGINX de código abierto como caché perimetral y para transmisión multimedia, y eso funciona aún mejor en NGINX Plus.

NGINX Plus también tiene varias características propias. Hay monitoreo del estado de la aplicação , visualización de GUI para su monitoreo, supervisión y análisis, la API de configuración RESTful y un par de las técnicas de equilibrio de carga más avanzadas.

Con NGINX Plus, obtiene acceso a ingenieros de NGINX que lo ayudarán mientras realiza su trabajo. Si actualmente utiliza F5, Citrix o un sistema similar, probablemente esté acostumbrado a ese tipo de soporte. Para sitios web más grandes y con más actividad, donde incluso un pequeño tiempo de inactividad cuesta mucho dinero, esto puede ser crucial y puede amortizarse fácilmente si evita incluso una interrupción breve solo una vez al año.

14:41 Caso práctico de un cliente – WordPress.com

Veamos algunos estudios de casos de clientes que hicieron el cambio.

WordPress.com estaba usando BIG-IP de F5 y lo dejaron de usar para NGINX porque necesitaban equilibrar la carga con más de 10 000 solicitudes por segundo por servidor: ese es el problema C10k del que estábamos hablando y que NGINX ha estado resolviendo durante más de diez años. En ese momento, estaban limitados a 1.000 solicitudes por segundo por servidor. Podéis imaginaros lo pesado que era eso comparado con 10.000 o más.

Wordpress.com tenía varios sistemas F5 BIG-IP y estaban destinados a crecer hasta alcanzar diez centros de datos. Para mantener una alta disponibilidad, básicamente para tener una copia de seguridad en vivo para cada centro de datos, estaban considerando diez pares de servidores BIG-IP. Muy caro. También necesitaban una reconfiguración sobre la marcha para no expulsar a los usuarios cuando cambiaban la configuración.

Comenzaron a realizar la migración a NGINX probándolo en Gravatar, que es una aplicación que coloca un avatar para los usuarios. Eso les permitió familiarizarse con NGINX. Luego, migraron sus servidores F5 a NGINX, lo que les proporcionó un consumo de memoria y de CPU reducido y predecible.

Actualmente manejan más de 70.000 solicitudes por segundo y 15 gigabits por segundo [Gbps] en 36 servidores NGINX. Pueden alcanzar un máximo de 20.000 solicitudes por segundo por servidor. Y pueden reconfigurarse y actualizarse sobre la marcha.

Si ves la cita, solo están hablando de la diferencia de gasto entre una implementación pequeña, donde NGINX te ahorrará una cantidad significativa de dinero. Pero cuando se trata de diez pares de servidores, la diferencia es enorme.

16:42 Caso práctico de cliente: Montana Interactive

Montana Interactive elige NGINX Plus para el equilibrio de carga de alta disponibilidad. En realidad es más fácil, más barato y mejor que muchos servicios gubernamentales se presten en línea. Si has concertado una cita en tu departamento de vehículos motorizados o similar, sabrás a qué me refiero. Estos sitios web pueden ayudarle a votar, pagar sus impuestos, etc.

Hay una enorme cantidad de estos servicios gubernamentales esenciales, y Montana es un estado muy grande con un número relativamente pequeño de personas distribuidas por todas partes. Por lo tanto, tener disponibilidad en línea para los servicios es muy importante, en lugar de que los residentes tengan que conducir seis u ocho horas para llegar a una oficina gubernamental.

Al principio, Montana estaba migrando hacia los servicios en línea con bastante fuerza, pero a medida que crecía, comenzó a sufrir interrupciones de sesiones. Tuvieron grandes picos trimestrales en el tráfico de transacciones debido a una gran aplicación de pago de impuestos. En medio de completar un formulario grande, de repente alguien se quedaba fuera y se perdía todo su trabajo. Si está haciendo sus impuestos o cualquier otro tipo de proceso complejo, eso es bastante estresante.

La solución para ellos fue actualizar los servidores que ejecutaban Pound a NGINX Plus, poner NGINX Plus en diferentes hipervisores y centros de datos, y operar como un proxy inverso dinámico, enrutando solicitudes en tiempo real y brindándoles una mejor gestión del tráfico. Como resultado de migrar a NGINX Plus, vieron mejoras masivas en velocidad, flexibilidad y facilidad de uso. Se beneficiaron de la reconfiguración sobre la marcha, descargaron su procesamiento SSL a servidores NGINX y utilizaron la gestión basada en roles para mejorar las operaciones y la seguridad.

James Ridle, de Montana Interactive, quedó maravillado con la potencia de NGINX. Los benchmarks lo dejaron atónito y casi no podía creer la diferencia que podía gestionar con los mismos servidores.

18:43 Caso práctico de cliente – BuyDig.com

Este es otro caso de estudio con enormes beneficios para el cliente: BuyDig.com, que es un sitio de comercio electrónico que obtuvo escalabilidad y seguridad con NGINX.

BuyDig.com tenía una aplicación .NET antigua. No querían cambiarla, ni tenían por qué hacerlo. Después de sufrir un ataque DDoS a gran escala, se dieron cuenta de que necesitaban una interfaz rápida, tolerante a fallas y fácil de configurar con mejor rendimiento, seguridad y escalabilidad.

Colocaron NGINX Plus en la capa de aplicação frontend, alojado en Amazon Web Services. No realizaron ningún cambio en sus servicios backend que se ejecutan en .NET. Y eso es tan grande: no hay cambios, no hay cambios pequeños, no hay molestias menores, no hay riesgos menores, pero ninguno.

Ahora obtienen un rendimiento y una seguridad fantásticos. Utilizaron lenguajes de configuración para NGINX para personalizarlo. Utilizan TLS SNI y registros personalizables para ayudarlos a mantenerse seguros. No han tenido ni una sola ralentización ni tiempo de inactividad del sitio y están muy contentos con el rendimiento.

Estos son solo algunos ejemplos de lo que NGINX Plus puede hacer.

20:10 Ebook – 5 razones para cambiar a software de equilibrio de carga

Permítanme ahora sumergirme en el libro electrónico. Te daré un resumen rápido de lo que hay en el libro electrónico y luego Faisal te explicará las dos primeras razones para cambiar, que son más técnicas, y continuaré después de eso. Hay enlaces. Recibirás esta presentación y la grabación del seminario web una vez que hayamos terminado. Creo que tarda aproximadamente un día en enviarse ese correo electrónico.

Y este enlace te llevará a un lugar de descarga para este libro electrónico gratuito . Entonces, solo para mencionar de antemano cuáles son las razones: son para reducir costos; mejorar el ajuste de DevOps; implementar en todas partes (sus propios servidores locales, en la nube, nube privada, cualquier cosa que desee hacer); la capacidad de adaptarse rápidamente y sin restricciones contractuales extrañas, que explicaré en cierto detalle. Pero ahora le cedo la palabra a Faisal para que hable sobre la reducción de costos.

21:22 Razón n.° 1: reducir drásticamente los costos

Faisal: Gracias, Floyd. La razón número uno de las cinco razones es que puede reducir drásticamente los costos al migrar a NGINX Plus para la entrega de aplicação de software.

Si miramos hacia mediados de los años 90, la única forma de escalar un sitio web era comprar un servidor más grande, lo cual era increíblemente caro y también poco confiable, porque ese único servidor también era un único punto de falla.

Fue en esa época cuando F5 lanzó por primera vez BIG-IP, lo que proporcionó una arquitectura diferente para los propietarios de sitios web: en lugar de comprar un servidor más grande, se podía usar BIG-IP para equilibrar la carga de una serie de servidores económicos. Esto reduce los costos, porque es más barato comprar BIG-IP y servidores económicos que comprar ese servidor gigantesco, y también se gana algo de redundancia porque se elimina el punto único de falla.

Fue una gran arquitectura, revolucionaria y realmente la única opción en la ciudad en ese momento, pero muchas cosas han cambiado en los últimos 20 años. Un cambio importante ha sido que el coste de los servidores ha disminuido drásticamente. Hoy en día se puede comprar un servidor bastante potente por menos del coste de un mes de alquiler aquí en el área de la Bahía de San Francisco.

El segundo cambio importante es la existencia ahora de open source software como NGINX, que proporciona la misma funcionalidad que se obtiene de F5 BIG-IP o Citrix NetScaler. En el caso del código abierto, puedes obtener funcionalidades similares a las de esos electrodomésticos grandes y costosos de forma gratuita. Floyd señaló anteriormente que hay más de 160 millones de sitios web que usan NGINX. Y si observamos los 10 000 sitios principales, más de la mitad se ejecutan en NGINX.

Ahora tenemos este open source software que no sólo tiene toda la funcionalidad que necesitas en comparación con F5, sino que también es tan escalable y confiable como cualquier otro producto comercial.

23:19 NGINX Plus frente a. F5 BIG‑IP

A principios de este año realicé un análisis comparativo y de costos, y aquí hay un extracto de ello. Se trata de una comparación del software NGINX Plus que se ejecuta en hardware comercial. En este caso lo proporciona Dell y lo estamos comparando con diferentes modelos del F5 BIG-IP.

Este ejemplo en particular es el 2000S, que es el modelo básico del F5 BIG-IP. Lo comparé con dos tamaños diferentes de NGINX Plus en servidores Dell. Uno que tiene un rendimiento ligeramente inferior al F5 BIG-IP (puede ver las métricas de rendimiento en la parte inferior) y otro que casi duplica el rendimiento.

Con solo mirar la columna de la derecha, donde NGINX Plus duplica el rendimiento del 2000S, se obtiene un ahorro del 78 % en el año 1, incluido el costo del hardware y el soporte de mantenimiento durante un año. Y esos ahorros de costos se mantienen hasta el quinto año. Incluso después de cinco años, el costo total de propiedad de NGINX Plus con el servidor Dell es 58% más barato que el F5.

24:37 NGINX Plus frente a. Citrix NetScaler

Hice la misma comparación de costos con Citrix NetScaler. Aquí, comparamos el NetScaler de nivel básico, el MPX‑5550 Enterprise Edition.

Citrix tiene un sistema de licencias que permite que, si desea funciones básicas como almacenamiento en caché y compresión de contenido, tenga que actualizar su licencia a la edición Enterprise. Con NGINX, el almacenamiento en caché y la compresión de contenido están incluidos sin costo adicional tanto en código abierto como en NGINX Plus. Entonces, lo que estamos comparando aquí es la Edición Enterprise de Citrix NetScaler, porque brinda una mejor paridad de características con lo que se proporciona en NGINX Plus, y vemos los mismos ahorros de costos aquí que con F5 cuando reemplaza Citrix NetScaler con NGINX Plus.

Obtendrás las mismas características y el rendimiento que esperas, pero pagarás un 89 % menos en el primer año. Incluso en el quinto año, todavía estás ahorrando un 75 % tanto en el costo del hardware (en este caso, servidores Dell básicos) como en el costo de una suscripción al software NGINX Plus.

Una métrica crítica, y de la que los proveedores de hardware hablan mucho, son las transacciones SSL por segundo, o la cantidad de nuevas conexiones SSL que se pueden realizar por segundo. Dentro de estas plataformas, ese número generalmente se acelera mediante hardware, por lo que NetScaler y F5 BIG-IP tienen hardware especializado para acelerar las transacciones SSL, lo que aumenta el costo de esas plataformas.

Lo que estamos viendo es que incluso con una solución de software, sin aceleración de hardware, solo usando la potencia de procesamiento de la CPU, podemos seguir el ritmo del hardware personalizado. Ofrecemos importantes ahorros de costes, con el rendimiento que obtendría de las soluciones aceleradas por hardware.

Entonces, esa es la razón n.° 1: puedes ahorrar mucho dinero al pasarte a NGINX Plus. Pero no es sólo cuestión de dinero.

26:52 Razón n.° 2: DevOps requiere la entrega de aplicação de software

Con una solución basada en software también se obtiene mucha flexibilidad, y la segunda razón para cambiar a un balanceador de carga basado en software es que, si se está migrando a DevOps, realmente se necesita software para la entrega de aplicação .

Con F5 y NetScaler, la forma en que estos dispositivos normalmente se implementan dentro de grandes empresas es como un punto de agregación. Por lo tanto, pasa por allí una gran cantidad de tráfico no relacionado. Ese mismo F5 BIG-IP puede equilibrar la carga de firewalls de red, puede equilibrar la carga de servidores de correo electrónico corporativos, puede equilibrar la carga de múltiples aplicações empresariales de back-end diferentes y también puede equilibrar la carga de aplicação empresariales front-end. Podrían ser API de equilibrio de carga en una arquitectura de microservicios. Por lo tanto, se puede equilibrar la carga de muchas cosas.

A primera vista, parece una buena arquitectura porque es bastante sencilla: todo se ejecuta simplemente a través de F5. Durante mucho tiempo esto funcionó, especialmente a principios de los años 2000, cuando todo giraba en torno al centro de datos privados y ejecutábamos todas nuestras aplicações, todo aquello de lo que dependía la empresa, desde un centro de datos local. Pero las cosas han cambiado en los últimos años y ahora la mayoría de las cosas se están trasladando a la nube.

Cuando digo nube, no me refiero solo a alojar una aplicação web frontal dentro de Amazon, sino también a usar cosas como Salesforce y Office 365, en lugar de sistemas CRM locales y servidores de correo electrónico locales. Por lo tanto, tener un dispositivo que pueda hacer todas esas cosas puede ser excesivo para lo que la gente utiliza actualmente.

Un segundo problema que plantea esta agregación es que lleva a que estos aparatos queden muy bloqueados. Dudas mucho en hacer cambios porque si arruinas la configuración de F5 podrías hacer caer toda la red corporativa. Podría tratarse de servidores de correo electrónico de equilibrio de carga o firewalls de red. Por lo tanto, la configuración se convierte en un asunto riesgoso y los cambios deben ser muy restringidos y muy controlados.

Cualquier persona que desee realizar cambios generalmente debe presentar un ticket de TI, lo que puede llevar horas, días o semanas según la organización y la prioridad que la organización le dé al cambio solicitado.

Tener esta pieza de hardware extremadamente bloqueada hace que sea realmente difícil migrar a DevOps. Cuando haces DevOps y avanzas hacia la automatización, avanzas hacia la integración continua y hacia la publicación de código con mucha más frecuencia. Y si tienes que presentar un ticket de TI cada vez que quieres hacer un cambio, eso inhibe y mata esa iniciativa.

Lo que vemos en muchas organizaciones es que las personas que son responsables de la aplicação y quieren avanzar hacia DevOps y hacia el desarrollo ágil no pueden lidiar con la necesidad de presentar un ticket cada vez porque eso obstaculiza las iniciativas DevOps y ágiles. Entonces, a veces implementarán NGINX de código abierto y harán que F5 BIG-IP apunte a eso, y esa instancia de NGINX será administrada por DevOps o el equipo de aplicação , lo que les permite realizar automatización y realizar cambios sin problemas. De modo que es una manera de eludir la política corporativa de TI. Luego vemos que muchos clientes, una vez que prueban eso, comienzan a moverse hacia NGINX Plus para obtener funciones más avanzadas junto con el soporte.

NGINX admite una variedad de modelos de implementación flexibles y diferentes, incluidos aquellos en los que puede mantener su F5 actual en su lugar. Puede utilizar NGINX Plus para complementar y aliviar la carga de equilibrio y entrega de aplicações web, API y microservicios front-frontales, manteniendo a F5 en su lugar para realizar el equilibrio de carga de red de los servidores de correo electrónico corporativos. Si no necesita servicios de red ni equilibrio de carga de red, obviamente también puede reemplazar el F5 con NGINX Plus y tener una única solución.

Admitimos una variedad de modelos de implementación diferentes para ayudar a las organizaciones a avanzar hacia DevOps, hacia la entrega continua y hacia la automatización.

Por la razón número 3, le devuelvo la palabra a Floyd.

31:59 Razón n.° 3: Implementar en todas partes con un solo ADC

Floyd: Gracias, Faisal.

Con NGINX, puedes implementar en todas partes con una sola solución ADC. ¿Qué significa ‘en todas partes’? Significa que sus servidores locales, su nube pública, su nube privada o su nube híbrida funcionan todos en una sola solución. Y hay un aspecto práctico y también arquitectónico en eso.

En primer lugar, si utilizas servidores internos y no usas la nube, todo lo que hemos dicho se aplica estrictamente. Muchas personas que se pasan a NGINX y NGINX Plus para obtener mayor flexibilidad, más funciones y ahorrar dinero se encuentran en esa misma situación: están implementando en servidores internos.

Si usa o desea considerar usar la nube en el futuro, no hay comparación entre NGINX y el ADC de hardware. No puede trasladar su ADC de hardware a los centros de datos de Amazon. El hardware ADC no te va a ayudar en eso.

Ahora bien, los desarrolladores de ADC de hardware tienen algunas soluciones basadas en software, pero en algunos casos solo recomiendan que se utilicen para el desarrollo. No reemplaza al ADC de hardware. Las ventajas que podrías ver en términos de simplicidad o de "si no está roto, no lo arregles", se desvanecen al migrar a la nube .

Con NGINX y NGINX Plus, la arquitectura de la aplicação es independiente de la plataforma de entrega. Algunos proveedores de nube están empezando a añadir cada vez más servicios que se pueden conectar mediante API. Durante el desarrollo, es realmente una gran cosa tenerlo, porque no tienes que preocuparte sobre cómo hacer algo; simplemente usas sus API para manejar el equilibrio de carga, el almacenamiento en caché u otras capacidades. Pero luego, cuando escalas, estás pagando una pequeña cantidad por cada transacción.

Bueno, de repente, cuando estás haciendo miles, decenas de miles y cientos de miles de transacciones, esos números empiezan a sumarse. La facturación es muy confusa y difícil de predecir, especialmente porque se basa en el tráfico, que siempre varía.

Si utiliza un enfoque basado en NGINX o NGINX Plus, básicamente hará lo mismo en cualquier plataforma y habrá muy poca diferencia cuando se migre a un proveedor de nube diferente o regrese a la empresa.

De hecho, tenemos clientes que equilibran la carga entre sus servidores internos y la nube. Entonces, ¿cómo se ve esto? Obtienen suficientes servidores internos para satisfacer sus necesidades el 80 o 90 por ciento del tiempo. Luego, cuando necesitan escalar, no tienen que comprar ni siquiera conectar nuevos servidores: simplemente escalan a la nube.

La nube suele ser más lenta que sus servidores locales y, como todo está equilibrado de carga, solo las sesiones que se interrumpirían si solo utilizara sus servidores internos van a la nube. Tienen una latencia ligeramente mayor, pero se gestionan, no se ponen en cola ni se descartan.

Financieramente es genial porque solo pagas por la nube en caso de emergencia, como por ejemplo cuando hay un aumento repentino en el tráfico. Esto puede suceder debido a la cobertura de noticias, si su producto recibe una buena crítica, o simplemente puede estar excediendo su plan de negocios de manera continua y aún no ha escalado internamente para cumplirlo, o resulta que son las vacaciones y simplemente no vale la pena tener el doble de servidores que solo necesitará durante unas pocas semanas al año, cuando puede hacerlo escalando a la nube. Con NGINX todo esto se puede hacer de forma flexible e incluso automática.

35:42 Razón n.° 4: adaptarse rápidamente a las demandas cambiantes

NGINX le permite adaptarse rápidamente para satisfacer las demandas cambiantes de sus aplicações. Cuando necesita agregar servidores rápidamente o agregar pares de servidores para una alta disponibilidad, no puede esperar a que se ordene el hardware, se entregue, se reciba, se pruebe y realice sus iRules o cualquier configuración de software que necesite hacer para ellos. iRules también es propietario: la única vez que necesita iRules es si tiene un servidor F5. No es un conjunto de habilidades que se puedan contratar fácilmente al salir de la universidad. Si tu persona de iRules se va, será difícil que encuentres otra.

Cuando se trata de cambios de configuración, a menudo no se puede esperar a que las operaciones de red aprueben los cambios. Realmente no quieres que tus cambios se pongan en cola con cosas que son menos urgentes.

Con NGINX hay muchos menos gastos generales para la aprobación de nuevos proyectos. Con NGINX y NGINX Plus, puedes guardar algo de hardware adicional en un armario cuando se trata de servidores que cuestan $2000 o $3000. No se puede hacer eso cuando se habla de ADC de hardware que valen decenas de miles de dólares.

Ese tipo de flexibilidad, redundancia, capacidad de hacer lo que necesita hacer, cuando lo necesita hacer, es una característica fundamental de NGINX y parte de la razón por la que las personas que nos usan nos aman tanto.

37:08 Razón n.° 5: Sin restricciones artificiales de rendimiento

Finalmente, con NGINX no existen restricciones artificiales o basadas en el contacto en el rendimiento. Para NetScaler Enterprise Edition, el límite contractual de rendimiento para ese servidor es de 0,5 Gbps. Bueno, eso es ridículo en una situación empresarial. La configuración comparable de NGINX que se ejecuta en hardware estándar de la industria admitirá 20 Gbps. Eso es 40 veces el límite de Citrix.

La otra cosa es que el número de Citrix es una restricción contractual. Si te excedes, tus condiciones de pago aumentarán repentina y drásticamente. Los 20 Gbps son una recomendación nuestra. Entonces, eso simplemente significa que cuando llegas a esa área, puedes comenzar a notar que tu rendimiento disminuye un poco y puedes pensar que es una buena idea conseguir otro servidor y equilibrar la carga en él. Pero tú tienes la flexibilidad; tú decides. No recibirás un golpe repentino en tu presupuesto.

Con Citrix, es como encontrarse con una señal de pare. En ese escenario, más negocios pueden ser malas noticias. Un cliente más puede costarte un montón de dinero, unos cuantos clientes más pueden costarte un montón de dinero porque te hacen superar esos límites. Cuando usa NGINX, tener más negocios es una buena noticia y sus costos aumentan de manera constante junto con el aumento de sus ingresos provenientes de una mayor base de clientes.

A menudo recibimos llamadas urgentes de personas que han superado esos límites y, de repente, han superado su presupuesto. Y no van a volver al presupuesto sin hacer un gran cambio. Luego tienen que esforzarse para entrar en NGINX y volver a una buena situación. Luego, muchas veces terminan por debajo del presupuesto porque ahorraron mucho dinero en NGINX.

¿Pero quién necesita ese dolor de cabeza? ¿Además de la incertidumbre y la sensación de pavor cuando de repente te encuentras con este terrible conflicto entre presupuesto y rendimiento? Si cambias a NGINX de forma temprana, podrás liberarte completamente de eso.

40:00 Recursos

• Estudio de caso: NGINX en WordPress.com/Automattic
• Caso práctico: Montana Interactive mejora el rendimiento de su aplicación y la atención al cliente con NGINX Plus
• Caso práctico: Cómo Buydig.com escala y protege su aplicación Microsoft .NET sin modificar una sola línea de código
• Libro electrónico: 5 razones para cambiar a software de equilibrio de carga
• Blog – NGINX Plus vs. F5 BIG‑IP: Una comparación de precio y rendimiento
• Blog – NGINX Plus vs. Citrix NetScaler: Una comparación de precio y rendimiento
• Prueba gratuita de NGINX Plus