¿Por qué la escalabilidad es un problema para el inicio tecnológico cuando existen servicios como Amazon Web Services o Google App Engine?

La escalabilidad es mucho más que simplemente usar un servicio escalable, es una mentalidad completamente diferente.

Al diseñar un sistema escalable, debe abstraer el sistema, tomar cada desafío como un proyecto separado y comprender cuál es el patrón de uso, la unidad de escala a la que apunta, qué interfaz de alta concurrencia usar (egyaws, node.js, etc.) qué infraestructura de datos, qué interfaces con otros sistemas internos, planificar el mecanismo de inserción, calentamiento, actualización y consulta, POC todo, organizar el monitoreo adecuado para que todo esté bajo control y repetir eso para cada desafío.

Como joven startup, rara vez tiene el tiempo, la inclinación o los recursos para dedicar tanto tiempo a cada subsistema. Por lo tanto, elige una solución simple que le servirá hasta que llegue el momento y tenga suficientes usuarios y dinero para justificar el esfuerzo.

El uso de servicios escalables de Amazon como DynamoDB, ElastiCache y AutoScale de EC2 puede ayudar mucho en el departamento rápido y sucio, pero no es suficiente si el servicio que los consulta o actualiza no es escalable. Sin una planificación y ejecución adecuadas, su sistema semiescalable alcanzará su eslabón débil en poco tiempo.

La buena noticia es que una vez que decide agregar una escalabilidad decente, es un proceso que se puede hacer gradualmente, tomando un desafío a la vez.

Yo diría que la escalabilidad no es una ocurrencia tardía. Si se apega a algunos principios fundamentales, puede probar su aplicación en el futuro, independientemente del conjunto de herramientas que utilice:

• Tienes que distribuir. Los datos, el procesamiento, los mensajes, el front-end web: todos deben ser capaces de aprovechar múltiples núcleos y servidores y no tener ningún punto central de contención. Algunos servicios de Amazon lo harán por usted en secreto (por ejemplo, dynamoDB), otros no (por ejemplo, RDS). Según la ley de Amdahl (que incluso supone memoria infinita y ancho de banda de red), su límite de escalabilidad es 1/1-p, siendo p el paralelismo de grado I en su aplicación. Entonces, si, por ejemplo, la mitad de su carga de trabajo llega a un punto central de contención y tiene que procesarse en serie (por ejemplo, al leer el mismo bloque de disco de varios subprocesos), solo puede escalar dos veces, sin importar cuántos servidores / núcleos arroje a la cosa.
• Datos sabios: en algún momento no tiene más opción que desnormalizar. Tiene que pensar las cosas desde una perspectiva de caso de uso en lugar de una perspectiva de modelado de datos. Esta presentación de la ingeniería de Twitter es un gran ejemplo de eso: cómo pasaron de un modelo de datos relacional centralizado a un modelo distribuido desnormalizado: http://www.slideshare.net/nkalle …
• Acerque el procesamiento a los datos: una vez que haya distribuido sus datos, tendría sentido procesarlos en los nodos en los que reside. es decir, envíe el código o impleméntelo junto con sus datos, y no los datos, que pueden ser mucho más pesados. Es algo así como los procedimientos almacenados en una base de datos, solo que las herramientas modernas le permiten invocar / enviar código sin problemas a través de un clúster.
• Use RAM tanto como sea posible. Cuantas más cosas hagas en la memoria, menos contención y más paralelismo tendrás. La memoria es infinitamente más rápida que el disco, pero también es mucho más concurrente que el disco.