La mejor respuesta
Escalable significa que el sistema puede, con relativa facilidad, adaptarse a una base de usuarios más amplia de lo que inicialmente se pretendía. . Los factores que determinan qué tan escalable es una aplicación incluirían:
- una buena estructura del programa (qué tan fácil es comprender y expandir el programa para admitir nuevos roles)
- provisión para múltiples usuarios y acceso y edición concurrente de la base de datos (para evitar el bloqueo de la base de datos, la denegación de acceso, la corrupción o la pérdida de datos)
- disposiciones de seguridad para el acceso de los usuarios y la integridad de la base de datos
- capacidad de ejecutarse como un aplicación distribuida en múltiples servidores y bases de datos en múltiples zonas horarias
- copia de seguridad, corrección y restauración de la base de datos
- disposiciones lingüísticas y culturales
- provisión para la intercomunicación con terceros aplicaciones ya sea exponiendo una interfaz de programa bien administrada o suscribiéndose a los estándares de la industria
- uso de recursos y dependencias de hardware / sistema operativo
- rendimiento en tiempo real
Existen otros factores, que dependen de dominios comerciales específicos, pero estos son los factores que vemos que se convierten habitualmente en una i Esto ocurre cuando una empresa intenta «escalar» o «extender» sus aplicaciones.
La escalabilidad generalmente se ve afectada cuando:
- el programa es concebido y escrito por alguien que no hábiles en las disciplinas del desarrollo de aplicaciones
- la responsabilidad de escribir un programa se contrata con una especificación que no explora todos los factores apropiados para las necesidades futuras del cliente (una especificación débil a menudo conduce a soluciones no escalables )
- no hay supervisión por parte de un ingeniero de software calificado que comprenda el dominio comercial
Un ejemplo simple de falla de escala es un programa de inventario de almacén en el que trabajé atrás en 1990 (ish).
El programa original fue escrito para un usuario, un servidor y copias de seguridad nocturnas (tiempo durante el cual el sistema no estuvo disponible). En orden sucesivo, el cliente quería:
- aumentar el número de usuarios de 1 a 50+ y promulgar varios roles y privilegios de acceso para cada usuario.
- expandir la aplicación para admitir múltiples almacenes dentro del mismo país
- expandir la aplicación para tener en cuenta los nuevos almacenes en el extranjero, lo que implicaba soporte para múltiples zonas horarias, idiomas, estándares legales y procedimientos operativos
El programa original nunca se había estructurado para un requisito de escalado tan fuerte. La base de datos sufrió bloqueos frecuentes de «adopción mortal», pérdida de datos y tiempo inaceptable debido a los procedimientos de respaldo de la base de datos. La aplicación no tenía provisión para la entrada de datos «fuera de línea» y, por supuesto, no fue escrita para ser tolerante a fallas de problemas de comunicación. Intentar actualizar el programa también resultó ser una pesadilla: básicamente todo el sistema se detuvo durante las varias horas que tomó instalar una actualización global.
Antes de que nos llamaran, como consultores, el programa fue «parcheado» por el codificador original (singular) que posteriormente se cerró y desapareció inconvenientemente.
El parche ofuscó la estructura y funcionalidad del código – sin embargo, dudo que el programa haya sido estructurado o documentado adecuadamente – ¡nadie sabía lo suficiente como para darse cuenta del riesgo que esto representaba para la empresa! El código fue escrito en C ++ y usó matrices de bytes en lugar de cadenas de conjuntos de caracteres multibyte (MBCS) estándar de la industria … ¡ya tiene una idea general!
Nos llamaron para «arreglar» el problemas. La verdad es que hubiera sido más simple y económico cambiar al cliente a un producto de administración de inventario comercial, sin embargo, tenían un modelo financiero profundamente integrado en el sistema y nadie entendía lo suficiente sobre cómo funcionaba transferir estas características a un comercial. programa (al menos sin un riesgo significativo).
Al final, a pesar de señalar soluciones más rentables, tuvimos que aplicar ingeniería inversa al producto y reescribir completamente la aplicación. Se necesitaron 2 diseñadores de sistemas, 4 ingenieros principales, 20 ingenieros de software, 5 ingenieros de validación y 2 ingenieros de metodología / herramientas para reescribir el producto, y casi 2 años de tiempo transcurrido para que la aplicación se lanzara en general.
Entonces ¿cómo se logra la escalabilidad?
- Comience por asegurarse de haber escrito sus requisitos de escalabilidad en la especificación del producto. Por lo general, la presión del tiempo y el costo más bajo causarán sacrificios en áreas que no se establecieron adecuadamente en la especificación.
- Trabaje con expertos en el dominio que puedan ayudarlo a desarrollar una estructura que satisfaga las (probables) necesidades futuras.
- Aproveche los patrones de diseño, bibliotecas, aplicaciones 4GL / AI y arquitecturas que fueron formuladas desde cero para evitar problemas de escalabilidad (muchos de los cuales se desarrollaron a partir de experiencias amargas).
- Lea todas las áreas clave, como bases de datos distribuidas y tolerantes a fallas para aplicaciones altamente concurrentes, arquitecturas de seguridad integradas, replicación de bases de datos, procesamiento en la nube, etc.
- Asegúrese de emplear ingenieros experimentados en puestos clave. Diría que casi el 50\% de los proyectos de rescate que emprendimos fueron consecuencia de ingenieros líderes y diseñadores de sistemas sin experiencia. El resto se debió a fallas en la administración o comunicaciones inadecuadas entre la ingeniería y el cliente.
Ahí lo tiene. En estos días, realmente no hay excusa para los problemas de escalabilidad en las empresas de tamaño mediano a grande, sin embargo, muchas empresas comienzan con un puñado de personas que piratean soluciones lo mejor que pueden. ¡Entonces la empresa crece y la escalabilidad se convierte en una pesadilla en lugar de la progresión ordenada que debería ser!
Respuesta
La escalabilidad en la ingeniería de software se refiere, normalmente, al diseño de sistemas de software de tal manera que , a medida que aumenta el número de usuarios del sistema (incluso en factores de 100x o más), el software seguirá funcionando con tiempos de respuesta comparables. Ahora, la siguiente pregunta es «¿cómo se logra esto?»
El software de escritorio independiente (p. Ej., Juegos) siempre es 100\% escalable porque cada usuario tiene su propia computadora. Esta es una forma trivial de escalabilidad.
Los sistemas de software cliente-servidor y basados en la web, sin embargo, dependen de servidores , que son computadoras que brindan servicios a múltiples usuarios. Debería ser obvio que cualquier servidor solo puede manejar un número limitado de usuarios simultáneos.
Hay dos técnicas generales que permiten que un sistema escale más allá de lo que puede manejar un solo servidor. Los sistemas altamente escalables combinarán ambas técnicas.
La primera es dividir la funcionalidad en diferentes partes. Una división común es tener un servidor separado para alojar la base de datos en la que se basa el sistema (casi siempre hay algún tipo de base de datos para almacenar información persistente). El servidor de base de datos tiene una gran cantidad de memoria y discos o matrices RAID muy rápidos, mientras que el otro tipo de servidor necesita menos memoria y relativamente poco espacio en disco.
Esto se puede extender a una arquitectura de n niveles, donde cada vez más funciones (y datos, para bases de datos) se dividen entre diferentes procesos. Cuando aumenta la carga, los procesos se migran a servidores separados para mantener el rendimiento. Tenga en cuenta que todos estos servidores están físicamente en la misma granja de servidores y están conectados mediante conexiones de red de muy alta velocidad.
La otra técnica utilizada para la escalabilidad es la replicación . Esto significa que, por ejemplo, se utilizan varios servidores web y cada usuario está conectado a solo uno de ellos. Para admitir más usuarios, el sistema solo necesita más hardware (sistemas de servidor web en este ejemplo). Las bases de datos también son capaces de replicarse, por lo que varios servidores de bases de datos pueden admitir clones de la base de datos (a veces es complicado mantener las diferentes copias de la base de datos actualizadas, pero los dba han estado manejando este problema durante años). Para sistemas más grandes, existen bases de datos que están diseñadas para ser escalables, distribuyendo sus datos a través de múltiples servidores.
A2A: «¿Qué se entiende por» escalabilidad «en la ingeniería de software?»