Cuando se trata de escalabilidad y rendimiento, cuestione a sus proveedores. Puede que no se lo estén contando todo.
Introducción
En el contexto del software, ¿qué significa escalabilidad? Esta pregunta aparentemente simple está rodeada de información incorrecta y marketing poco claro, y se ha usado de forma errónea, lo que genera confusión en cuanto a un tema de suma importancia. Me gustaría ayudar a aclarar parte de esta confusión con un análisis reflexivo de la escalabilidad.
Qué es y qué no es la escalabilidad
Lo primero que debemos hacer es entender a qué nos referimos cuando decimos que un software es escalable.
Qué es
Las definiciones de escalabilidad varían mucho. Por ejemplo, la definición de Wikipedia es: "La escalabilidad es la propiedad de un sistema para manejar una cantidad creciente de trabajo al agregar recursos al sistema". Gartner define la escalabilidad como "[l]a capacidad de un sistema para aumentar o disminuir el rendimiento y el costo en respuesta a los cambios en las demandas de procesamiento de aplicaciones y sistemas". Y hay muchas más.
A pesar de las muchas formas de definir la escalabilidad, todas las definiciones comparten algunos elementos similares. Por ejemplo, la escalabilidad se centra en dos aspectos de un sistema: el hardware y el software.
Cada plataforma tendrá diferentes límites de rendimiento en función del hardware en el que se ejecuta. Y cada máquina o red de máquinas opera con una cantidad limitada de CPU, de RAM, de espacio en disco, etc. Para el hardware, la escalabilidad mide cuántos recursos tiene.
Con el software, la escalabilidad implica las bibliotecas y el código que este necesita para desempeñar su función. Cada programa informático requiere cierta cantidad de recursos del servidor para funcionar. La escalabilidad del software mide cuánto cuesta ejecutarlo.
Además, la escalabilidad tiene que ver con cómo un sistema responde a los requisitos actuales y futuros. Si bien muchos escenarios están relacionados con esta característica, también son muchas la organizaciones que quieren asegurarse de que lo que desarrollen hoy continuará satisfaciendo las demandas del mañana.
Qué no es
En pocas palabras, cualquier cosa que no tenga relación con la capacidad de un sistema para gestionar solicitudes con una cantidad determinada de recursos, no tiene nada que ver con la escalabilidad. Estos son algunos de los ejemplos de información errónea con respecto a la escalabilidad que he encontrado al examinar Internet:
- La escalabilidad incluye la seguridad. A pesar de que la seguridad es absolutamente fundamental para cualquier solución, debe seguir las políticas y prácticas de seguridad adecuadas independientemente del resto de la implementación. Por lo tanto, puede dejar de lado las consideraciones de seguridad en un cálculo de escalabilidad.
- Una alta disponibilidad influye en la escalabilidad . Nada más lejos de la realidad. La alta disponibilidad refleja la confiabilidad de su plataforma, no cuál es su rendimiento con determinadas cargas de trabajo.
- El escalado automático proporciona escalabilidad. Este ejemplo complicado. La capacidad para escalar de forma automática es beneficiosa, pero no implica eficacia. De hecho, una arquitectura de escalado automático puede funcionar sin tener en cuenta la eficacia.
- La escalabilidad se refiere a las características de su plataforma. Solo debe evaluar las características de una plataforma en comparación con las de otras plataformas; no debe tenerlas en cuenta en los cálculos de escalabilidad. Cada uno de los conjuntos de características influirá en el rendimiento, pero no en el rendimiento integral del sistema.
Cuando escuche cosas como estas de un proveedor, dude de él. Busque proveedores que estén dispuestos a ayudarlo a comprender cómo se escalará su solución en particular.
Recomendaciones a la hora de determinar la escalabilidad
Al determinar la escalabilidad de una plataforma de software, debe tener en cuenta cuatro variables:
- El número de usuarios simultáneos. ¿Cuántos usuarios necesitarán acceder al sistema a la vez? Asegúrese de incluir las transacciones solicitadas por cuentas de servicio u otros medios automatizados.
- El promedio de solicitudes por usuario. Esto incluye cosas como la cantidad de llamadas a un servicio concreto o la comunicación interna entre los servicios de la plataforma.
- El tamaño medio de cada solicitud. ¿Cómo de grande es la solicitud? Las solicitudes casi nunca tienen el mismo tamaño. Una estimación incorrecta de los requisitos de tamaño reales puede sesgar en gran medida los cálculos de escalabilidad.
- El tamaño de la máquina en la que se ejecuta la plataforma. Diferentes configuraciones de hardware tendrán un rendimiento distinto. Pruebe en un sistema que se parezca mucho a lo que usará. Considere la cantidad de procesadores, el tamaño de la memoria RAM y el espacio en disco. Es importante acertar el tamaño, tanto para escalar como para reducir verticalmente.
Estas variables le ayudan a evaluar la escalabilidad de un sistema. Por ejemplo, supongamos que tengo 10 usuarios simultáneos que ejecutan 100 operaciones al día, y que cada operación usa de media 1 MB de datos. Imaginemos también que esta cantidad de servicio consume el 10 % de los recursos del hardware. Si agrego 10 usuarios adicionales, ¿consumirán solamente otro 10 % de los recursos del sistema? En caso afirmativo, esta plataforma se puede escalar de forma lineal.
El software puede pasar de la escalabilidad lineal a la paralelización, pero de este tema hablaremos otro día. También es importante tener en cuenta que, el hecho de que una solución siga la linealidad en un momento dado, no significa que siempre seguirá esta tendencia. La linealidad tiene un límite y, una vez alcanzado, la adición de recursos adicionales generará menos rendimiento.
Todo depende del precio
El motivo por el que comprobamos la escalabilidad de una plataforma es por el dinero. ¿Cuánto trabajo puede hacer de la manera más eficaz posible? Incluso si una solución muestra un buen rendimiento, debe darse de manera rentable.
Recientemente, analicé los datos de escalabilidad publicados de otro proveedor. Sus cifras eran realmente impresionantes, pero estaba ejecutando las pruebas en un servidor de 26 millones de dólares. Tenga en cuenta en Amazon que puede obtener una solución en la nube de primera calidad por aproximadamente 4,50 dólares la hora; y hasta que no la usara durante 660 años, no le saldría rentable el servidor de 26 millones de dólares. Para sus propósitos, no importa si el sistema del proveedor puede alojar a 10 000 o a 100 000 personas. Sigue sin merecer la pena.
Otra "trampa" la encontramos al trabajar con proveedores que crean desafíos de escalabilidad artificiales. Se presenta en forma de tasas por transacción o tasas por unidad de soluciones. Las opciones con este tipo de tarifas pueden parecer una buena idea para comenzar, pero usted, el cliente, se verá obligado a tomar malas decisiones de diseño.
Imagine que se le cobra por cada llamada a la API. ¿No intentaría aumentar la carga útil de cada llamada para maximizar la eficacia? Claro, pero ¿qué pasa si su caso de uso requiere muchas llamadas durante un largo período de tiempo? Deberá decidir si desea crear una solución sobredimensionada, porque tiene que transportar una sola carga útil muy grande, o pagar las tasas adicionales para desarrollar su solución de forma adecuada.
Las tarifas basadas en objetos plantean un escenario similar. Si paga por objeto, intentará reducir su diseño a la menor cantidad posible de pasos. Esto crea una necesidad artificial de diseñar en exceso los elementos de su solución, lo que puede conducir a un rendimiento poco óptimo.
De las variables descritas anteriormente, la carga de las llamadas y la cantidad de transacciones son con las que más se pueden ofuscar los resultados de rendimiento. Los proveedores son muy perspicaces. Saben que cobrar tasas en estas áreas es una forma eficaz de ocultar los costos reales de una solución.
Cómo resolver este problema
Vamos a enlazar todo esto. Dando por hecho que la información anterior es verdadera, a continuación tenemos algunas prácticas recomendadas bastante universales para evaluar la escalabilidad de una plataforma.
Establecer una línea de base
Es fundamental saber por dónde empezar. Para cada caso de uso, debe saber el número de usuarios y lo que necesita hacer. A partir de ahí, calcule los recursos que requiere cada persona. Finalmente, elija una configuración de hardware que cree que ejecutará esta solución.
Probar, probar y probar
Ponga a prueba su línea de base. ¿Cuál ha sido su rendimiento? Una vez que haya probado eso, modifique su variable y vuelva a realizar la prueba. ¿Cómo funciona la solución con el doble de usuarios? ¿Con 10 veces más usuarios? ¿Y con 50 veces más usuarios? Descubra qué sucede cuando introduce una nueva operación para aumentar el número de llamadas y o la carga de las llamadas. ¿Cuándo empieza a ser deficiente el rendimiento del hardware que usa? ¿Qué ocurre si aumenta el tamaño del hardware al escalarlo vertical u horizontalmente?
Conocer los costes ocultos
Recuerde, la escalabilidad no solo son resultados de pruebas. Una prueba le dirá si una solución es escalable, pero no si esa solución es rentable. Tenga cuidado con los costes ocultos como los cargos por transacción o las tasas adicionales por objeto o unidad. Aunque el sistema podría asumir la carga de trabajo, puede que su bolsillo no.
¿Quién es responsable de garantizar una solución escalable?
Voy a decirle algo que nunca pensó que diría de un proveedor de software: la escalabilidad es su problema. Tanto si desarrolla la solución usted mismo como si paga a un tercero para que se encargue de ello, tendrá que vivir con las consecuencias del diseño general.
Cualquier plataforma de software se puede escalar de forma deficiente. Por el contrario, con un presupuesto ilimitado en hardware, puede hacer que cualquiera de esas soluciones funcione.
Si un proveedor le dice que su solución es escalable y que no necesita preocuparse, cuestiónelo. Creo que Appian tiene una de las plataformas con mayor rendimiento del mercado. Nuestros servicios están inscritos en un marco más eficiente en comparación con nuestros competidores. Además, las evaluaciones de Appian se pueden realizar en paralelo, algo que no admiten otros proveedores. Incluso con estas ventajas, no quiero hacerle pensar que ahí se acaba todo. Más allá del poder del back-end de nuestra plataforma, queremos trabajar con usted para garantizar que está creando las aplicaciones más escalables posibles.
Cómo puede ayudarle Appian
Appian quiere ayudarle a crear la solución más escalable y rentable disponible. Podríamos decirle que somos los mejores, pero preferimos demostrárselo.
Si desea conocer las cifras del rendimiento de Appian, consulte nuestro informe de escalabilidad. En él descubrirá lo bien que funciona nuestra plataforma en tres instancias de hardware independientes.
Después de leer el documento, póngase en contacto con nuestro equipo de ventas. Creo que se sorprenderá al descubrir lo interesados que estamos en ganarnos su confianza y convertirnos en su proveedor preferido. Estamos más que dispuestos a guiarle a través de nuestra plataforma y a ayudarle a descubrir la forma más eficaz de usar nuestro producto.
No es fácil escalar aplicaciones empresariales en sistemas críticos. Cuéntenos su caso y le ayudaremos a comprender mejor cómo puede escalar de manera eficaz con Appian.
