5 razones para pasarse al balanceo de carga por software

Floyd SmithDirector de marketing de contenidos

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

Índice

0:00 Introducción

Floyd Smith: Hola y bienvenidos a nuestra presentación. Estamos aquí en NGINX y hoy hablaremos de mi libro electrónico «5 razones para pasarse al software para el balanceo de carga».

Hoy somos dos los ponentes. 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 distintos aspectos de la tecnología.

Faisal Memon: Hola, soy Faisal Memon y trabajo en Marketing de Producto aquí, en NGINX. Llevo aquí aproximadamente un año. Antes de incorporarme a NGINX, trabajé como ingeniero de marketing técnico en Riverbed y también en Cisco. Comencé mi carrera profesional desarrollando en C. Fui ingeniero de software en Cisco, puesto que desempeñé durante unos ocho años.

1:38 ¿Quién eres?

Floyd: Recibimos las inscripciones a nuestros seminarios web antes de celebrarlos, y podemos ver los cargos, las organizaciones y los motivos para asistir que cada uno de ustedes ha indicado.

Ha sido muy interesante ver los cargos de las personas que asisten. Tenemos arquitectos de soluciones —varios tipos de arquitectos—, administradores de Linux, responsables de ingeniería, directores ejecutivos, responsables sénior de entrega ágil, varias personas con cargos relacionados con DevOps, desarrolladores de software full stack, ingenieros, científicos, desarrolladores y responsables de operaciones de marketing.

Contamos con un grupo muy variado de personas con un perfil técnico. Tengo la impresión de que quienes participan en este seminario web trabajan directamente con la tecnología y se enfrentarán de primera mano a los problemas de los que estamos hablando hoy.

También contamos con la representación de una amplia y variada gama de organizaciones. Puede que algunos de ustedes estén analizando esta cuestión para orientar a sus clientes a la hora de tomar decisiones acertadas, pero parece que la mayoría la están abordando directamente de forma interna.

3:53 Del hardware al software

Según los informes financieros, el mercado de los ADC de hardware está en declive, por lo que quienes los venden intentan aumentar los ingresos que obtienen por cliente, aunque su base de clientes siga reduciéndose. Muchos clientes de ADC de hardware están empezando a darse cuenta de que no quieren formar parte de ese grupo cada vez más reducido de personas que pagan cada vez más por los servicios que ofrecen estos ADC de hardware. Están empezando a ver que, en realidad, pueden hacer lo mismo mejor mediante software y, además, ganar en flexibilidad. Quienes tengáis DevOps en vuestro cargo probablemente sepáis a qué me refiero.

Lo que vemos a menudo en NGINX es que, cuando llega la fecha de renovación del contrato de su ADC de hardware o se produce un aumento repentino del tráfico y, con él, una subida inesperada de los costes, los clientes se ven obligados a buscar desesperadamente una forma de rescindir el contrato. Entonces tienen que actuar con mucha rapidez. Por lo general lo consiguen, pero es un proceso estresante, imprevisto y no presupuestado. Con la ayuda de esta presentación, puede iniciar un proceso más planificado.

La cuestión presupuestaria no es tan crítica, porque al pasarse al software se ahorra mucho dinero, pero las complicaciones operativas son enormes. Puede reducirlas considerablemente con solo empezar pronto.

NGINX es una alternativa realmente sólida a un ADC de hardware. Se creó originalmente para resolver el problema C10K. Es decir, conseguir que un servidor web ejecutado en un único ordenador atienda 10 000 conexiones simultáneas o más. Antes de NGINX, esto era imposible. La gente publicaba un sitio web, este se hacía popular y acababa colapsando. Evitar que esto ocurriera era muy, muy, muy difícil, pero con NGINX se volvió mucho más fácil.

Nuestra primera versión de código abierto se publicó en 2004 en Rusia, donde NGINX [el software] se creó originalmente [Nota del editor: Floyd dice «fundó» 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 el respaldo de capital riesgo de líderes del sector. Tenemos más de 800 clientes y hace apenas unos días alcanzamos los 100 empleados.

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

En total, hay 160 millones de sitios web que utilizan NGINX.

Se utiliza de dos formas distintas. Algunos sitios ejecutan NGINX como servidor web, que era su propósito original. Sin embargo, muchos sitios ejecutan NGINX como servidor proxy inverso. En este caso, NGINX se coloca delante de la arquitectura existente para gestionar el tráfico y dirigirlo a los servidores de aplicaciones. En cuanto se hace esto, ya se está avanzando hacia el equilibrado de carga, que es de lo que hablaremos hoy.

El 51 % de los 10.000 sitios web con más tráfico se han pasado a NGINX. Ahora bien, ¿a qué se debe? ¿Por qué el uso es aún mayor entre los sitios web con más tráfico que entre los sitios web en general?

La razón es que NGINX es la mejor solución para sitios web con mucho tráfico. Una forma rápida de solucionar los problemas de un sitio web con mucho tráfico es implementar NGINX como servidor proxy inverso y, a continuación, utilizarlo para equilibrar la carga.

Con el tiempo, puede migrar sus aplicaciones existentes a NGINX o, si desarrolla otras nuevas, también puede utilizar NGINX como servidor web para ellas. Así es como hemos logrado este nivel de adopción entre profesionales con una gran carga de trabajo, que no cambian de servidor web por capricho. Tienen experiencia con otros servidores web y saben cómo utilizarlos, pero deciden cambiarse por todo lo que NGINX hace por ellos.

El 36 % de todos los sitios alojados en Amazon Web Services utilizan NGINX. Se está convirtiendo en una especie de herramienta estándar. Hoy en día, es habitual empezar con NGINX y seguir utilizándolo durante todo el proyecto.

Estos son algunos de los sitios que utilizan NGINX. Por supuesto, con 160 millones de sitios web que usan NGINX, no podemos incluirlos todos en una sola diapositiva, pero entre nuestros socios y amigos se encuentran Netflix, Airbnb, Uber, Amazon Web Services, como ya he mencionado, Box, Pinterest y WordPress.

Todas estas empresas, que se dedican profesionalmente a la distribución de contenidos web y para las que es imprescindible que funcione, se han pasado a NGINX.

8:48 Dónde encaja NGINX

Veamos dónde encaja NGINX.

A la derecha, puede ver NGINX funcionando como servidor web. Como servidor web, utiliza una puerta de enlace de aplicaciones que permite ejecutar distintos tipos de servidores de aplicaciones junto con él. NGINX, como servidor web, puede gestionar unas 10.000 conexiones simultáneas, dependiendo de lo que se esté haciendo.

Pero NGINX también resulta útil como servidor proxy inverso, ya que ofrece almacenamiento en caché, balanceo de carga y muchas otras funciones.

9:32 Arquitectura web moderna

NGINX también le ayuda a migrar a una arquitectura web moderna. Esto puede implicar pasar de arquitecturas de tres niveles al estilo J2EE a microservicios; de protocolos complejos de HTML y SOAP a protocolos más ligeros, como REST y la mensajería, que constituyen una parte importante de los microservicios; o de implementaciones persistentes a implementaciones mutables que ejecutan contenedores o máquinas virtuales.

En lugar de una infraestructura fija y estática, normalmente se dispone de un servicio propio. Contamos con tecnologías como SDN, NFV y la nube, especialmente la nube. En vez de grandes lanzamientos cada pocos meses, se realizan entregas continuas cada pocas horas. Y en lugar de equipos aislados, con grupos de desarrollo, pruebas y operaciones que trabajan bajo la dirección de sus respectivos responsables, existe una cultura DevOps de responsabilidad compartida, en la que todos se arremangan y se ocupan de distintos aspectos de cada problema.

10:42 DevOps funciona de maravilla con NGINX

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

La historia de DevOps está estrechamente ligada a NGINX. Muchos profesionales de DevOps tienen NGINX siempre a mano y, cuando se encuentran con un despliegue que está dando problemas, recurren a NGINX.

En determinadas implementaciones, ni siquiera es necesario cambiar la configuración de la aplicación. Basta con colocar NGINX delante para dirigir el tráfico a los servidores de aplicaciones de forma que puedan gestionarlo. No se modifica el código ni se pone en riesgo la funcionalidad principal cuando urge resolver un problema de rendimiento.

Uno de los ámbitos en los que DevOps y NGINX suelen complementarse bien es el balanceo de carga por software, como veremos. Funciona muy bien con implementaciones en la nube, pero también con servidores propios. Ofrece diversos métodos de balanceo de carga. En este aspecto hay una diferencia entre NGINX y NGINX Plus, que explicaré enseguida.

La capacidad de reconfiguración sobre la marcha de NGINX favorece el descubrimiento de servicios y la disponibilidad. El descubrimiento de servicios es esencial para los microservicios y la automatización y, gracias a la reconfiguración sobre la marcha, no es necesario desconectar a los usuarios de un servidor para configurarlo, lo que supone una enorme ventaja a la hora de mantener a sus clientes conectados.

Las comprobaciones del estado de las aplicaciones permiten detectar con antelación problemas en la entrega de aplicaciones, de modo que pueda retirar gradualmente un servidor problemático, en lugar de dejar que se bloquee sin más y expulse a los usuarios. Además, dispone de una supervisión sólida y personalizable. De nuevo, esto le permite detectar los problemas a medida que surgen para poder resolverlos antes de que afecten a los clientes.

12:30 Capacidades de NGINX Plus

¿Qué incluye NGINX Plus?

Así pues, NGINX de código abierto es el producto original, y NGINX Plus es el producto comercial desarrollado sobre esa base. En NGINX dedicamos al menos el 70 % de nuestro tiempo al código abierto, que también constituye la base de las funcionalidades avanzadas de NGINX Plus.

El producto de código abierto incluye el enrutamiento de solicitudes, que es la función principal de un servidor web, y la compresión, que reduce la carga del servidor web y también minimiza el tráfico en la red, lo que puede resultar muy útil. También admite SSL para garantizar la seguridad. Además, contamos con dos lenguajes de scripting integrados: uno propio, el módulo JavaScript de NGINX [anteriormente denominado nginScript], y Lua.

Hay un par de funcionalidades que están disponibles parcialmente en NGINX de código abierto, pero que se han mejorado en NGINX Plus. NGINX de código abierto permite equilibrar la carga bastante bien, pero NGINX Plus ofrece algunas funcionalidades más avanzadas. Del mismo modo, puede utilizar NGINX de código abierto como caché perimetral y para la transmisión de contenido multimedia, y estas funciones son aún mejores en NGINX Plus.

NGINX Plus también cuenta con varias funciones propias. Entre ellas se incluyen la supervisión del estado de las aplicaciones, la visualización de la supervisión mediante una interfaz gráfica, la monitorización y el análisis, la API de configuración RESTful y algunas de las técnicas de balanceo de carga más avanzadas.

Con NGINX Plus, tendrá acceso a ingenieros de NGINX que le ofrecerán asistencia mientras trabaja. Si actualmente utiliza F5, Citrix o un sistema similar, probablemente ya esté acostumbrado a este tipo de soporte. Para los sitios web más grandes y con más tráfico, en los que incluso un breve periodo de inactividad puede suponer grandes pérdidas económicas, esto puede ser crucial y amortizarse fácilmente con solo evitar una breve interrupción una vez al año.

14:41 Caso de éxito de un cliente – WordPress.com

Veamos algunos casos prácticos de clientes que dieron el paso.

WordPress.com utilizaba BIG‑IP de F5, pero lo sustituyó por NGINX porque necesitaba equilibrar la carga de más de 10.000 solicitudes por segundo y servidor. Ese es el problema C10k del que hablábamos y que NGINX lleva resolviendo desde hace más de diez años. En aquel momento, el límite era de 1.000 solicitudes por segundo y servidor. Puede imaginarse lo problemático que resultaba en comparación con 10.000 o más.

Wordpress.com tenía varios sistemas F5 BIG‑IP y planeaba ampliar su infraestructura hasta alcanzar diez centros de datos. Para garantizar una alta disponibilidad, es decir, disponer de una copia de seguridad activa para cada centro de datos, necesitaba diez pares de servidores BIG‑IP. Una solución muy cara. También necesitaba poder reconfigurarlos sobre la marcha para no desconectar a los usuarios al cambiar la configuración.

Empezaron a migrar a NGINX probándolo en Gravatar, una aplicación que muestra un avatar para los usuarios. Esto les permitió familiarizarse con NGINX. Después, migraron sus servidores F5 a NGINX, lo que les proporcionó un consumo de memoria reducido y predecible, así como un uso de CPU también reducido y predecible.

Ahora gestionan más de 70.000 solicitudes por segundo y 15 gigabits por segundo [Gbps] en 36 servidores NGINX. Pueden alcanzar picos de 20.000 solicitudes por segundo en cada servidor. Además, pueden reconfigurar y actualizar el sistema sobre la marcha.

Si se fijan en la cita, solo hablan de la diferencia de costes en una implementación pequeña, en la que NGINX les permitirá ahorrar una cantidad considerable de dinero. Pero cuando se pasa a diez pares de servidores, la diferencia es abismal.

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

Montana Interactive elige NGINX Plus para el balanceo de carga de alta disponibilidad. En realidad, es más fácil, barato y eficaz prestar muchos servicios públicos por Internet. Si alguna vez ha pedido cita en Tráfico o en un organismo similar, sabrá a qué me refiero. Estos sitios web pueden permitir votar, pagar impuestos, etc.

Hay una enorme cantidad de estos servicios públicos esenciales, y Montana es un estado muy extenso con una población relativamente pequeña y dispersa por todo el territorio. Por eso, es muy importante que los servicios estén disponibles en línea, en lugar de obligar a los residentes a conducir seis u ocho horas para llegar a una oficina pública.

Al principio, Montana avanzaba con paso firme hacia la prestación de servicios en línea, pero, a medida que estos crecían, empezaron a producirse interrupciones en las sesiones. Cada trimestre se registraban grandes picos en el tráfico de transacciones debido a una importante aplicación para el pago de impuestos. De repente, en mitad de la cumplimentación de un formulario extenso, la sesión de un usuario podía interrumpirse y todo su trabajo se perdía. Si estás haciendo la declaración de la renta o cualquier otro trámite complejo, resulta bastante estresante.

La solución consistió en actualizar los servidores que ejecutaban Pound a NGINX Plus, desplegar NGINX Plus en distintos hipervisores y centros de datos, y utilizarlo como proxy inverso dinámico para enrutar las solicitudes en tiempo real y gestionar mejor el tráfico. Tras migrar a NGINX Plus, experimentaron enormes mejoras en velocidad, flexibilidad y facilidad de uso. Se beneficiaron de la reconfiguración sobre la marcha, descargaron el procesamiento SSL en los servidores NGINX y utilizaron la gestión basada en roles para mejorar las operaciones y la seguridad.

James Ridle, de Montana Interactive, quedó asombrado por la potencia de NGINX. Los resultados de las pruebas de rendimiento lo dejaron impresionado y casi no podía creer la diferencia en la carga que podía gestionar con los mismos servidores gracias a NGINX.

18:43 Caso de éxito de cliente – BuyDig.com

Este es otro caso de éxito que aportó enormes beneficios al cliente, BuyDig.com, un sitio de comercio electrónico que consiguió escalabilidad y seguridad con NGINX.

BuyDig.com tenía una aplicación .NET antigua. No querían cambiarla y tampoco era necesario. Tras sufrir un ataque a gran escala de DDoS, se dieron cuenta de que necesitaban un frontend rápido, tolerante a fallos y fácil de configurar, con mayor rendimiento, seguridad y escalabilidad.

Implementaron NGINX Plus en la capa de aplicaciones frontend, alojada en Amazon Web Services. No hicieron ningún cambio en sus servicios backend ejecutados en .NET. Y eso es muy importante: ningún cambio; ni pequeños cambios, ni molestias menores, ni riesgos menores. Absolutamente ninguno.

Ahora disfrutan de un rendimiento y una seguridad fantásticos. Utilizaron los lenguajes de configuración de NGINX para personalizarlo. Usan TLS SNI y registros personalizables para reforzar la seguridad. No han sufrido ni una sola ralentización ni interrupción del sitio, y están realmente satisfechos con el rendimiento.

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

20:10 Ebook – 5 razones para pasarse al software de balanceo de carga

Permítanme entrar ahora en el contenido del ebook. Les haré un breve resumen de lo que incluye y, a continuación, Faisal les explicará los dos primeros motivos para cambiar, que son de carácter más técnico. Después, retomaré yo la presentación. Hay enlaces. Cuando terminemos, tendrán a su disposición esta presentación y la grabación del webinar. Creo que el correo tarda aproximadamente un día en enviarse.

Y este enlace os llevará a la página desde la que podéis descargar este ebook gratuito. Así que, por adelantar cuáles son los motivos: reducir costes; mejorar la integración con DevOps; poder desplegar en cualquier entorno (en vuestros propios servidores locales, en la nube, en una nube privada, donde queráis); poder adaptarse rápidamente y no tener restricciones contractuales extrañas, algo que explicaré con cierto detalle. Pero ahora cedo la palabra a Faisal para que hable de la reducción de costes.

21:22 Razón n.º 1: reducir drásticamente los costes

Faisal: Gracias, Floyd. La primera de las cinco razones es que puede reducir drásticamente los costes si se pasa a NGINX Plus para la entrega de aplicaciones de software.

Si nos remontamos a mediados de los 90, la única forma de ampliar la capacidad de un sitio web era comprar un servidor más potente, algo que resultaba increíblemente caro y, además, poco fiable, ya que ese único servidor también constituía un único punto de fallo.

Fue por aquel entonces cuando F5 lanzó por primera vez BIG‑IP, lo que ofreció a los propietarios de sitios web una arquitectura diferente: en lugar de comprar un servidor más potente, podían utilizar BIG‑IP para equilibrar la carga entre un conjunto de servidores económicos. Esto reducía los costes, ya que comprar BIG‑IP y los servidores económicos resultaba más barato que adquirir un único servidor gigantesco, y además aportaba cierta redundancia al eliminar el punto único de fallo.

Era una arquitectura excelente —revolucionaria y, en aquel momento, prácticamente la única opción disponible—, pero muchas cosas han cambiado en los últimos 20 años. Uno de los principales cambios ha sido la drástica caída del precio de los servidores. Hoy en día se puede comprar un servidor bastante potente por menos de lo que cuesta un mes de alquiler aquí, en el área de la bahía de San Francisco.

El segundo gran cambio es la existencia actual de software de código abierto como NGINX, que ofrece las mismas funciones que F5 BIG‑IP o Citrix NetScaler. Con el código abierto, se pueden obtener gratis funciones similares a las de esos grandes y costosos dispositivos. Floyd señaló anteriormente que hay más de 160 millones de sitios web que utilizan NGINX. Y, si nos fijamos en los 10.000 sitios principales, más de la mitad funcionan con NGINX.

Así pues, ahora contamos con este software de código abierto que no solo ofrece todas las funcionalidades que necesita en comparación con F5, sino que además es tan escalable y fiable como cualquier otro producto comercial.

23:19 NGINX Plus frente a F5 BIG‑IP

A principios de este año realicé algunas pruebas de rendimiento y un análisis de costes, y este es un extracto. Aquí se compara el software NGINX Plus ejecutado en hardware estándar disponible en el mercado —en este caso, suministrado por Dell— con distintos modelos de F5 BIG‑IP.

Este ejemplo concreto es el 2000S, el modelo básico de F5 BIG‑IP. Lo he comparado con dos configuraciones diferentes de NGINX Plus en servidores Dell: una con un rendimiento ligeramente inferior al de F5 BIG‑IP (puede ver las métricas de rendimiento en la parte inferior) y otra que prácticamente duplica el rendimiento.

Si nos fijamos en la columna de la derecha, donde NGINX Plus duplica el rendimiento del 2000S, se obtiene un ahorro del 78 % durante el primer año, incluido el coste del hardware y del soporte de mantenimiento durante un año. Este ahorro se mantiene hasta el quinto año. Incluso después de cinco años, el coste total de propiedad de NGINX Plus con el servidor Dell es un 58 % inferior al de F5.

24:37 NGINX Plus frente a Citrix NetScaler

Hice la misma comparación de costes con Citrix NetScaler. En este caso, comparamos el modelo básico de NetScaler, el MPX‑5550 Enterprise Edition.

Citrix utiliza un modelo de licencias en el que, si desea disponer de funciones básicas como el almacenamiento en caché y la compresión de contenido, debe actualizar su licencia a Enterprise Edition. Con NGINX, el almacenamiento en caché y la compresión de contenido se incluyen sin coste adicional tanto en la versión de código abierto como en NGINX Plus. Por tanto, aquí comparamos Citrix NetScaler Enterprise Edition, ya que ofrece una mayor equivalencia de funciones con NGINX Plus. Al sustituir Citrix NetScaler por NGINX Plus, observamos el mismo ahorro de costes que con F5.

Obtiene todas las funciones y el rendimiento que espera, pero paga un 89 % menos durante el primer año. Incluso al llegar al quinto año, sigue ahorrando un 75 % tanto en el coste del hardware (en este caso, servidores Dell estándar) como en el de la suscripción al software NGINX Plus.

Una métrica fundamental, de la que los proveedores de hardware hablan mucho, es el número de transacciones SSL por segundo, es decir, el número de nuevas conexiones SSL que se pueden establecer por segundo. En estas plataformas, esta cifra suele acelerarse mediante hardware, por lo que NetScaler y F5 BIG‑IP cuentan con hardware especializado para acelerar las transacciones SSL, lo que encarece dichas plataformas.

Lo que estamos viendo es que, incluso con una solución de software —sin aceleración por hardware y utilizando únicamente la capacidad de procesamiento de la CPU—, podemos igualar el rendimiento del hardware especializado. Ofrecemos un ahorro de costes considerable con el mismo rendimiento que se obtendría con las soluciones aceleradas por hardware.

Así pues, esta es la razón n.º 1: puede ahorrar mucho dinero migrando a NGINX Plus. Pero no se trata solo de dinero.

26:52 Razón n.º 2: DevOps requiere la entrega de aplicaciones de software

Con una solución basada en software también se obtiene una gran flexibilidad, y la razón n.º 2 para cambiar a un equilibrador de carga basado en software es que, si se está adoptando DevOps, se necesita software para la entrega de aplicaciones.

Con F5 y NetScaler, estos dispositivos suelen implementarse en las grandes empresas como punto de agregación. Por tanto, canalizan una gran cantidad de tráfico no relacionado. Un mismo F5 BIG‑IP puede equilibrar la carga de los cortafuegos de red, los servidores de correo electrónico corporativo, varias aplicaciones empresariales de backend y también la aplicación empresarial de cara al público. Asimismo, puede equilibrar la carga de las API en una arquitectura de microservicios. En definitiva, puede equilibrar la carga de muchos elementos.

A primera vista, esta parece una buena arquitectura porque es bastante sencilla: basta con canalizarlo todo a través de F5. Durante mucho tiempo funcionó, especialmente a principios de la década de 2000, cuando todo giraba en torno al centro de datos privado y ejecutábamos todas nuestras aplicaciones —todo aquello de lo que dependía la empresa— desde un centro de datos local. Sin embargo, las cosas han cambiado en los últimos años y ahora la mayoría se está trasladando a la nube.

Cuando hablo de la nube, no me refiero solo a alojar una aplicación web pública en Amazon, sino también a utilizar servicios como Salesforce y Office 365, en lugar de sistemas CRM y servidores de correo electrónico locales. Por tanto, disponer de un dispositivo capaz de hacer todo eso puede resultar excesivo para lo que se utiliza realmente hoy en día.

Un segundo problema que plantea esta agregación es que hace que estos dispositivos estén muy protegidos y restringidos. Uno se muestra muy reacio a realizar cambios, porque si se estropea la configuración de F5, podría dejar fuera de servicio toda la red corporativa. Podría estar equilibrando la carga de servidores de correo electrónico o actuando como cortafuegos de red. Por tanto, la configuración se convierte en una tarea arriesgada y los cambios deben estar muy restringidos y controlados.

Por lo general, cualquiera que quiera realizar cambios debe abrir un ticket de TI, cuya tramitación puede tardar horas, días o semanas, dependiendo de la organización y de la prioridad que esta asigne al cambio solicitado.

Tener este componente de hardware sometido a restricciones tan estrictas dificulta enormemente la transición a DevOps. Al adoptar DevOps, se avanza hacia la automatización, la integración continua y la publicación de código con mucha más frecuencia. Y si hay que abrir una incidencia de TI cada vez que se quiere realizar un cambio, se obstaculiza y acaba frustrándose esa iniciativa.

Lo que observamos en muchas organizaciones es que las personas responsables de la aplicación que quieren adoptar DevOps y el desarrollo ágil no pueden estar abriendo una incidencia cada vez que necesitan hacer un cambio, ya que esto obstaculiza las iniciativas de DevOps y metodologías ágiles. Por eso, a veces implementan NGINX de código abierto y hacen que F5 BIG‑IP dirija el tráfico hacia él. Esa instancia de NGINX queda bajo la gestión del equipo de DevOps o de aplicaciones, lo que les permite automatizar procesos y realizar cambios sin complicaciones. Es una forma de sortear, en cierto modo, la política corporativa de TI. Por supuesto, también vemos que muchos clientes, después de probar esta solución, empiezan a pasarse a NGINX Plus para obtener funcionalidades más avanzadas y soporte técnico.

NGINX admite diversos modelos de implementación flexibles, incluidos aquellos que permiten mantener su F5 actual. Puede utilizar NGINX Plus para complementar y descargar el balanceo de carga y la entrega de aplicaciones web, API y microservicios de cara al público, y mantener F5 para realizar el balanceo de carga de red de los servidores de correo electrónico corporativos. Si no necesita servicios de red ni balanceo de carga de red, también puede sustituir F5 por NGINX Plus y disponer de una única solución.

Ofrecemos distintos modelos de implementación para ayudar a las organizaciones a avanzar hacia DevOps, la entrega continua y la automatización.

Para explicar la razón n.º 3, le cedo de nuevo la palabra a Floyd.

31:59 Razón n.º 3: implemente en cualquier lugar con un único ADC

Floyd:Gracias, Faisal.

Con NGINX, puede realizar implementaciones en cualquier entorno con una única solución ADC. ¿Qué significa «cualquier entorno»? Significa que sus servidores locales, la nube pública, la nube privada o la nube híbrida funcionan con una única solución. Y esto tiene una vertiente práctica y otra arquitectónica.

En primer lugar, si utiliza servidores propios y no usa la nube, todo lo que hemos dicho resulta plenamente aplicable. Muchas de las personas que migran a NGINX y NGINX Plus para obtener mayor flexibilidad, disponer de más funciones y ahorrar dinero se encuentran precisamente en esa situación: realizan sus implementaciones en servidores propios.

Si utiliza la nube o quiere plantearse utilizarla en el futuro, no hay comparación posible entre NGINX y un ADC de hardware. No puede trasladar su ADC de hardware a los centros de datos de Amazon. El ADC de hardware no le servirá de ayuda en ese caso.

Ahora bien, los desarrolladores de ADC de hardware sí ofrecen algunas soluciones basadas en software, pero, en algunos casos, solo recomiendan utilizarlas para el desarrollo. No sustituyen al ADC de hardware. Las ventajas que podrían apreciarse en cuanto a simplicidad, o aquello de «si funciona, no lo toques», desaparecen cuando se quiere migrar a la nube.

Con NGINX y NGINX Plus, la arquitectura de la aplicación es independiente de la plataforma de entrega. Algunos proveedores de servicios en la nube están empezando a añadir cada vez más servicios que se pueden integrar mediante API. Durante el desarrollo, esto resulta muy útil, porque no hay que preocuparse por cómo hacer algo; basta con utilizar sus API para gestionar el balanceo de carga, el almacenamiento en caché u otras funciones. Sin embargo, al escalar, se acaba pagando una pequeña cantidad por cada transacción.

De repente, cuando se realizan miles, decenas de miles y cientos de miles de transacciones, esas cantidades empiezan a acumularse. La facturación es muy confusa y difícil de prever, sobre todo porque se basa en el tráfico, que varía constantemente.

Si utiliza un enfoque basado en NGINX o NGINX Plus, básicamente hará lo mismo en cualquier plataforma, y apenas habrá diferencias cuando cambie de proveedor de servicios en la nube o vuelva a alojarlo en sus propias instalaciones.

De hecho, tenemos clientes que realizan el balanceo de carga entre sus servidores locales y la nube. ¿Cómo funciona esto? Disponen de suficientes servidores locales para cubrir sus necesidades el 80 o el 90 % del tiempo. Cuando necesitan ampliar la capacidad, no tienen que comprar ni siquiera conectar nuevos servidores; simplemente escalan en la nube.

La nube suele ser más lenta que los servidores locales y, como todo está equilibrado mediante balanceo de carga, solo se envían a la nube las sesiones que se perderían si se utilizaran únicamente los servidores internos. Tienen una latencia ligeramente mayor, pero se procesan; no se ponen en cola ni se descartan.

Desde el punto de vista económico, es una opción excelente porque solo pagas por la nube cuando surge una necesidad puntual, como un aumento repentino del tráfico. Esto puede ocurrir debido a la cobertura mediática, porque tu producto reciba una buena reseña o porque estés superando de forma continuada las previsiones de tu plan de negocio y aún no hayas ampliado tu infraestructura local para responder a la demanda. También puede suceder durante las fiestas, cuando no compensa tener el doble de servidores si solo vas a necesitarlos unas semanas al año, ya que puedes cubrir esa demanda ampliando la capacidad en la nube. Con NGINX, todo esto puede hacerse de forma flexible e incluso automática.

35:42 Razón n.º 4: adaptarse rápidamente a los cambios en la demanda

NGINX le permite adaptarse rápidamente a las necesidades cambiantes de sus aplicaciones. Cuando necesita añadir rápidamente servidores o pares de servidores para garantizar una alta disponibilidad, no puede esperar a que se solicite, envíe, reciba y pruebe el hardware, ni a que se configuren las iRules o cualquier otro software necesario. Además, iRules es una tecnología propietaria: solo se necesita si se dispone de un servidor F5. No es fácil contratar a alguien recién graduado que cuente con esos conocimientos. Si la persona encargada de iRules deja la empresa, le resultará muy difícil encontrar a otra.

Cuando se trata de cambios de configuración, a menudo no puede esperar a que el equipo de operaciones de red los apruebe. Tampoco le conviene que sus cambios se pongan en la cola junto con otros asuntos menos urgentes.

Con NGINX, la aprobación de nuevos proyectos conlleva muchos menos trámites. Con NGINX y NGINX Plus, puede guardar algún equipo adicional en un armario cuando se trata de servidores que cuestan 2.000 o 3.000 dólares. Esto no es posible cuando se trata de ADC de hardware que cuestan varias decenas de miles de dólares.

Ese tipo de flexibilidad, redundancia y capacidad para hacer lo que necesite, cuando lo necesite, es una característica fundamental de NGINX y una de las razones por las que nuestros usuarios nos valoran tanto.

37:08 Razón n.º 5: sin limitaciones artificiales de rendimiento

Por último, con NGINX no existen limitaciones de rendimiento artificiales ni impuestas por contrato. En el caso de NetScaler Enterprise Edition, el límite contractual de rendimiento de ese servidor es de 0,5 Gbps. Esto resulta absurdo en un entorno empresarial. Una configuración comparable de NGINX ejecutada en hardware estándar del sector admite 20 Gbps, es decir, 40 veces el límite de Citrix.

El otro aspecto es que la cifra de Citrix constituye una limitación contractual. Si la supera, las condiciones de pago se encarecen de forma repentina y considerable. Los 20 Gbps son una recomendación nuestra. Esto solo significa que, al acercarse a esa cifra, quizá empiece a notar una ligera disminución del rendimiento y considere conveniente adquirir otro servidor y distribuir la carga entre ambos. Pero usted tiene la flexibilidad necesaria para decidir. Su presupuesto no sufrirá un incremento repentino.

Con Citrix, es como encontrarse con una señal de stop. En ese escenario, conseguir más negocio puede ser una mala noticia. Un cliente más puede costarle mucho dinero, y unos pocos clientes más pueden costarle mucho dinero porque hacen que supere esos límites. Cuando utiliza NGINX, conseguir más negocio es una buena noticia, y sus costes aumentan de forma constante en consonancia con el incremento de los ingresos derivado del crecimiento de su base de clientes.

A menudo recibimos llamadas urgentes de personas que han superado estos límites y, de repente, se encuentran por encima del presupuesto. Y no podrán volver a ajustarse al presupuesto sin hacer un cambio importante. Entonces tienen que darse prisa para pasarse a NGINX y volver a una situación favorable. De hecho, muchas veces acaban incluso por debajo del presupuesto porque han ahorrado muchísimo dinero con NGINX.

Pero ¿quién necesita semejante quebradero de cabeza? ¿Y la incertidumbre y la angustia que se sienten cuando, de repente, surge este terrible conflicto entre presupuesto y rendimiento? Cambiar a NGINX desde el principio permite evitar todo eso por completo.

40:00 Recursos

• Caso práctico – NGINX en WordPress.com/Automattic
• Caso práctico – Montana Interactive mejora el rendimiento de las aplicaciones y el servicio de atención al cliente con NGINX Plus
• Caso práctico – Cómo Buydig.com amplía y protege su aplicación Microsoft .NET sin cambiar una sola línea de código
• Libro electrónico – 5 razones para cambiar a un software de balanceo de carga
• Blog – NGINX Plus frente a F5 BIG‑IP: comparativa de precio y rendimiento
• Blog – NGINX Plus frente a Citrix NetScaler: comparativa de precio y rendimiento
• Prueba gratuita de NGINX Plus

Sobre el autor

Floyd SmithDirector de marketing de contenidos

Más artículos de Floyd Smith