La escalabilidad es un componente esencial del software empresarial. Priorizarla desde el principio conduce a menores costes de mantenimiento, mejor experiencia de usuario y mayor agilidad.

El diseño de software es un acto de equilibrio en el que los desarrolladores trabajan para crear el mejor producto dentro de las limitaciones de tiempo y presupuesto del cliente.

No hay que evitar la necesidad de compromiso. Hay que hacer concesiones para cumplir con los requisitos de un proyecto, ya sean técnicos o financieros.

Sin embargo, con demasiada frecuencia, las empresas priorizan el coste sobre la escalabilidad o incluso descartan su importancia por completo. Esto es desgraciadamente común en las iniciativas de big data, donde los problemas de escalabilidad pueden hundir un proyecto prometedor.

La escalabilidad no es una «característica extra». Es la calidad que determina el valor de la vida útil del software, y construir teniendo en cuenta la escalabilidad ahorra tiempo y dinero a largo plazo.

¿Qué es la escalabilidad?

Se considera que un sistema es escalable cuando no necesita ser rediseñado para mantener un rendimiento eficaz durante o después de un fuerte aumento de la carga de trabajo.

«Carga de trabajo» podría referirse a los usuarios simultáneos, la capacidad de almacenamiento, el número máximo de transacciones manejadas, o cualquier otra cosa que empuja el sistema más allá de su capacidad original.

La escalabilidad no es un requisito básico de un programa, ya que un software no escalable puede funcionar bien con una capacidad limitada.

Sin embargo, sí refleja la capacidad del software para crecer o cambiar con las demandas del usuario.

Cualquier software que pueda expandirse más allá de sus funciones básicas -especialmente si el modelo de negocio depende de su crecimiento- debería estar configurado para ser escalable.

Los beneficios del software escalable

La escalabilidad tiene beneficios tanto a largo como a corto plazo.

Al principio permite a una empresa comprar sólo lo que necesita inmediatamente, y no todas las funciones que podrían ser útiles más adelante.

Por ejemplo, una empresa que lanza un programa piloto de inteligencia de datos podría elegir un paquete de análisis empresarial masivo, o podría empezar con una solución que sólo maneje las funciones que necesita al principio.

Una opción popular es un cuadro de mandos que extrae los resultados de sus fuentes de datos primarias y del software empresarial existente.

Cuando crecen lo suficiente como para utilizar más programas de análisis, esos flujos de datos pueden añadirse al cuadro de mando en lugar de obligar a la empresa a hacer malabares con múltiples programas de visualización o a construir un sistema completamente nuevo.

Construir de esta manera prepara para el crecimiento futuro, al tiempo que crea un producto más ligero que se adapta a las necesidades actuales sin complejidad adicional.

También requiere un menor desembolso financiero inicial, que es una consideración importante para los ejecutivos preocupados por el tamaño de las inversiones en big data.

La escalabilidad también deja espacio para cambiar las prioridades. Ese paquete de análisis estándar podría perder relevancia cuando una empresa cambia para satisfacer las demandas de un mercado en evolución.

La elección de soluciones escalables protege la inversión tecnológica inicial. Las empresas pueden seguir utilizando el mismo software durante más tiempo porque fue diseñado para crecer con ellas.

Cuando llega el momento de cambiar, construir sobre un software sólido y escalable es considerablemente menos costoso que tratar de adaptar programas menos ágiles.

También hay un tiempo de «rampa» más corto para poner en línea nuevas características que para implementar un software completamente nuevo.

Como beneficio adicional, el personal no necesitará mucha formación o persuasión para adoptar ese sistema actualizado. Ya están familiarizados con la interfaz, por lo que trabajar con las características adicionales se ve como una ventaja en lugar de una tarea.

Las consecuencias de los fallos de escalado

Entonces, ¿qué sucede cuando el software no es escalable?

Al principio, la debilidad es difícil de detectar. La carga de trabajo es ligera en las primeras etapas de una aplicación. Con relativamente pocos usuarios simultáneos no hay mucha demanda en la arquitectura.

Cuando la carga de trabajo aumenta, surgen los problemas. Cuantos más datos se almacenan o más usuarios simultáneos recoge el software, más se exige a la arquitectura del mismo.

Las limitaciones que no parecían importantes al principio se convierten en una barrera para la productividad. Los parches pueden aliviar algunos de los primeros problemas, pero los parches añaden complejidad.

La complejidad hace que el diagnóstico de los problemas de forma continua sea más tedioso (traducción: más caro y menos eficaz).

A medida que la carga de trabajo aumenta más allá de la capacidad de escala del software, el rendimiento disminuye.

Los usuarios experimentan tiempos de carga lentos porque el servidor tarda demasiado en responder a las solicitudes. Otros problemas potenciales incluyen la disminución de la disponibilidad o incluso la pérdida de datos.

Todo esto desalienta el uso futuro. Los empleados encontrarán soluciones para un software poco fiable con el fin de hacer su propio trabajo.

Eso pone a la empresa en riesgo de una violación de datos o algo peor.

Cuando el software está orientado al cliente, la falta de fiabilidad aumenta el potencial de deserción.

Google descubrió que el 61% de los usuarios no darán una segunda oportunidad a una aplicación si tuvieron una mala primera experiencia. El 40% se va directamente a un producto de la competencia.

Los problemas de escalabilidad no son sólo un error de novato cometido por las pequeñas empresas. Incluso Disney tuvo problemas con el lanzamiento original de su aplicación Applause, que pretendía ofrecer a los espectadores una forma adicional de interactuar con los programas favoritos de Disney. La aplicación no pudo soportar la avalancha de usuarios de vídeo en streaming simultáneo.

Los fans frustrados dejaron críticas negativas hasta que la aplicación tenía una sola estrella en la tienda Google Play. Los responsables de Disney tuvieron que retirar la aplicación para reparar el daño, y la publicidad negativa fue tan intensa que nunca volvió a estar en línea.

Establecer prioridades

Algunas empresas no priorizan la escalabilidad porque no ven su utilidad inmediata.

La escalabilidad se deja de lado en favor de la velocidad, los ciclos de desarrollo más cortos o el menor coste.

En realidad, hay algunos casos en los que la escalabilidad no es una prioridad principal.

El software que está destinado a ser un prototipo o una prueba de concepto de bajo volumen no llegará a ser lo suficientemente grande como para causar problemas.

Así mismo, el software interno para pequeñas empresas con un límite fijo bajo de usuarios potenciales puede establecer otras prioridades.

Por último, cuando el cumplimiento de ACID es absolutamente obligatorio, la escalabilidad pasa a un segundo plano frente a la fiabilidad.

Sin embargo, como regla general, la escalabilidad es más fácil y requiere menos recursos si se tiene en cuenta desde el principio.

Por un lado, la elección de la base de datos tiene un gran impacto en la escalabilidad. La migración a una nueva base de datos es costosa y requiere mucho tiempo. No es algo que pueda hacerse fácilmente a posteriori.

Principios de escalabilidad

Varios factores afectan a la escalabilidad general del software:

El uso

El uso mide el número de usuarios o conexiones simultáneas posibles. No debería haber límites artificiales en el uso.

Aumentarlo debería ser tan sencillo como poner más recursos a disposición del software.

Máximo de datos almacenados

Esto es especialmente relevante para los sitios que presentan muchos datos no estructurados: contenido subido por los usuarios, informes del sitio y algunos tipos de datos de marketing.

Los proyectos de ciencia de datos también entran en esta categoría. La cantidad de datos almacenados por este tipo de contenido podría aumentar de forma dramática e inesperada.

Si el máximo de datos almacenados puede escalar rápidamente depende en gran medida del estilo de la base de datos (servidores SQL vs NoSQL), pero también es fundamental prestar atención a la indexación adecuada.

Código

Los desarrolladores sin experiencia tienden a pasar por alto las consideraciones sobre el código cuando planifican la escalabilidad.

El código debe escribirse de forma que pueda añadirse o modificarse sin refactorizar el código antiguo. Los buenos desarrolladores tratan de evitar la duplicación de esfuerzos, reduciendo el tamaño total y la complejidad de la base de código.

Las aplicaciones crecen en tamaño a medida que evolucionan, pero mantener el código limpio minimizará el efecto y evitará la formación de «código espagueti».

Escalar hacia fuera frente a escalar hacia arriba

La escalada hacia arriba (o «escalado vertical») implica crecer utilizando un hardware más avanzado o más fuerte. Se utiliza espacio en disco o una unidad central de procesamiento (CPU) más rápida para gestionar el aumento de la carga de trabajo.

La ampliación ofrece un mejor rendimiento que la reducción. Todo está contenido en un solo lugar, lo que permite un rendimiento más rápido y una menor vulnerabilidad.

El problema de la ampliación es que sólo hay un cierto espacio para crecer. El hardware es más caro a medida que se vuelve más avanzado. En cierto punto, las empresas se enfrentan a la ley de los rendimientos decrecientes en la compra de sistemas avanzados.

También lleva tiempo implementar el nuevo hardware.

Debido a estas limitaciones, el escalado vertical no es la mejor solución para el software que necesita crecer rápidamente y con poco aviso.

El escalado hacia fuera (o «escalado horizontal») es mucho más utilizado para fines empresariales.

Cuando se amplía la escala, el software crece utilizando más hardware, no más avanzado, y distribuyendo el aumento de la carga de trabajo en la nueva infraestructura.

Los costes son menores porque los servidores o CPU adicionales pueden ser del mismo tipo que se utiliza actualmente (o de cualquier tipo compatible).

La escala también es más rápida, ya que no hay que importar ni reconstruir nada.

Sin embargo, hay una pequeña compensación en cuanto a la velocidad. El software escalado horizontalmente está limitado por la velocidad con la que los servidores pueden comunicarse.

Sin embargo, la diferencia no es lo suficientemente grande como para que la mayoría de los usuarios la noten, y existen herramientas para ayudar a los desarrolladores a minimizar el efecto. Como resultado, el escalamiento hacia afuera se considera una mejor solución cuando se construyen aplicaciones escalables.

Directrices para construir sistemas altamente escalables

Es más barato y más fácil considerar la escalabilidad durante la fase de planificación. Estas son algunas de las mejores prácticas para incorporar la escalabilidad desde el principio:

Utilizar software de equilibrio de carga

El software de equilibrio de carga es fundamental para los sistemas con infraestructura distribuida (como las aplicaciones de escala horizontal).

Este software utiliza un algoritmo para repartir la carga de trabajo entre los servidores y garantizar que ningún servidor se vea sobrecargado. Es una necesidad absoluta para evitar problemas de rendimiento.

La ubicación importa

El software escalable hace todo lo posible cerca del cliente (en la capa de la aplicación). Reducir el número de veces que las apps deben navegar por el tráfico más pesado cerca de los recursos del núcleo conduce a velocidades más rápidas y menos estrés en los servidores.

La computación de borde es algo más a considerar. Con más aplicaciones que requieren recursos intensivos, mantener todo el trabajo posible en el dispositivo disminuye el impacto de las zonas de baja señal y los retrasos de la red.

Caché siempre que sea posible

Sea consciente de los problemas de seguridad, pero el almacenamiento en caché es una buena forma de evitar tener que realizar la misma tarea una y otra vez.

Llevar a cabo la API

Los usuarios se conectan a través de una variedad de clientes, por lo que llevar a cabo una API que no asuma un tipo de cliente específico puede servir a todos ellos.

Procesamiento asíncrono

Se refiere a los procesos que están separados en pasos discretos que no necesitan esperar a que el anterior se complete antes de procesar.

Por ejemplo, a un usuario se le puede mostrar una notificación de «¡enviado!» mientras el correo electrónico sigue siendo técnicamente procesado.

El procesamiento asíncrono elimina algunos de los cuellos de botella que afectan al rendimiento del software a gran escala.

Limita el acceso concurrente a recursos limitados

No dupliques esfuerzos. Si más de una solicitud pide el mismo cálculo del mismo recurso, deje que la primera termine y sólo utilice ese resultado. Esto añade velocidad a la vez que reduce la tensión en el sistema.

Utilice una base de datos escalable

Las bases de datos NoSQL tienden a ser más escalables que SQL. SQL escala las operaciones de lectura lo suficientemente bien, pero cuando se trata de operaciones de escritura entra en conflicto con las restricciones destinadas a hacer cumplir los principios ACID.

El escalado de NoSQL requiere una adhesión menos estricta a esos principios, por lo que si el cumplimiento de ACID no es una preocupación, una base de datos NoSQL puede ser la elección correcta.

Considere las soluciones PaaS

La plataforma como servicio alivia muchos de los problemas de escalabilidad ya que el proveedor de PaaS gestiona el escalado. Escalar puede ser tan fácil como actualizar el nivel de suscripción.

Considere FaaS

La función como servicio evolucionó a partir de PaaS y está muy relacionada. La computación sin servidor proporciona una manera de utilizar sólo las funciones que se necesitan en un momento dado, reduciendo las demandas innecesarias en la infraestructura de back-end.

FaaS todavía está madurando, pero podría valer la pena mirar como una forma de reducir los costos operativos al tiempo que mejora la escalabilidad.

No se olvide del mantenimiento

Configure el software para que las pruebas y el mantenimiento sean automatizados, de modo que cuando crezca, el trabajo de mantenimiento no se le vaya de las manos.

Construya con la vista puesta en el futuro

Priorizar la escalabilidad prepara a su empresa para el éxito. Considérelo con antelación y cosechará los beneficios de la agilidad cuando más se necesite.

¿Busca un software que pueda crecer con su empresa? Concierte una cita gratuita con uno de nuestros desarrolladores para hablar sobre dónde necesita ir y cómo podemos llevarle hasta allí.