¿El uso de Cloud PaaS resuelve automáticamente los problemas de escalabilidad?

Question

Actualmente estoy buscando un Cloud PaaS que me permita escalar una aplicación para manejar cualquier cosa entre 1 usuario y 10 millones de usuarios ... Nunca he trabajado en algo tan grande y la gran pregunta que no puedo parece que la respuesta es clara: si desarrolla, digamos una aplicación estándar con una base de datos relacional y servicios web de soap, ¿esta aplicación escalará automáticamente cuando se implemente en una solución de Paas o aún necesita construir la aplicación con caída de datos? sobre, redundancia y todas esas cosas en mente?

Digamos que despliego una aplicación Spring Hibernate a Amazon EC2 y creo una instancia única de Ubuntu Server con Tomcat instalado, ¿escalará esta aplicación de forma indefinida o necesitaré más instancias de Ubuntu? Si se necesita más de una instancia de Ubuntu, ¿se encarga Amazon de ejecutar la aplicación en ambas instancias o es responsabilidad del desarrollador? ¿Qué sucede con el almacenamiento de la base de datos, puedo instalar una base de datos en EC2 que se escalará a medida que crezca la base de datos o si necesito usar una de sus API si quiero que se amplíe indefinidamente?

CloudFoundry le permite crear localmente y simplemente implementarlo directamente en su PaaS, pero como está en beta, hay un límite en la cantidad de recursos que puede usar y las bases de datos están limitadas a 128MB si no recuerdo mal, entonces esto no por ahora. Algunos han sugerido instalar CloudFoundry en Amazon EC2, ¿cómo se escala y cómo se maneja la capa de la base de datos?

GAE (Google App Engine), ¿me permitirá implementar una aplicación y no tener que preocuparme de cómo escalar e implementar la redundancia? Parece que hay algunas limitaciones: lo que puede y no puede ejecutar GAE y su aumento de precio recientemente molestó a una gran cantidad de desarrolladores, ¿es realmente tan caro en comparación con otros proveedores?

Así que, básicamente, ¿se escalará y qué se debe hacer para que sea escalable?

Answer 1

Eso son muchas preguntas para una publicación. De todos modos:

1. Amazon EC2 no escala automáticamente con la carga. EC2 es básicamente una máquina virtual. Puede lograr escalar instancias EC2 con Auto Scaling y Elastic Load Balancing.

2. Las bases de datos SQL escalan mal. Es por eso que la gente comenzó a usar bases de datos NoSQL en primer lugar. Lo mejor es ver qué base de datos ofrece su proveedor de la nube como un servicio administrado: Datastore en GAE y DynamoDB en Amazon.

3. Instalar su propia base de datos en instancias EC2 es muy poco práctico ya que EC2 tiene ephemeral storage (pierde todos los datos en "disco" cuando se reinicia).

4. GAE Datastore es en realidad una base de datos grande para todas las aplicaciones que se ejecutan en él. Por lo tanto, es bastante escalable: su millón de usuarios no debería ser un problema. http://highscalability.com/blog/2011/1/11/google-megastore-3-billion-writes-and-20-billion-read-transa.html

5. Sí App Engine escala automáticamente, ambas instancias frontend y base de datos. No hay nada especial que deba hacer para que sea escalable, solo use su API.

6. hay limitaciones lo que puede hacer con AppEngine:

   R. No almacenamiento local (sistema de archivos) - es necesario utilizar el almacén de datos o almacén de blob.

   B.Comet solo es compatible a través de sus API propietarias de canales

   C. Datastore es una base de datos NoSQL: no se UNE, consultas limitadas, transacciones limitadas.

7. El costo de GAE no está nada mal. Hacemos solicitudes de 1 millón por día por alrededor de 5 dólares por día. El mayor ahorro proviene del hecho de que no necesita un administrador de sistema en GAE (pero sí necesita uno para EC2). Comparado con el costo de la mano de obra, GAE es increíblemente barato.

Algunos consejos para ahorrar dinero (una velocidad) GAE:

A. Uso conseguir en lugar de consulta en el almacén de datos (requiere creando cuidadosamente teclas natiral).

B. Use Memcache para almacenar en caché los datos que obtuvo del almacén de datos de formulario. Esto se puede hacer automáticamente con Objectify y es @Cached annotation.

C. Desnormalizar los datos. Lo que significa que escribe datos de forma redundante en varios lugares para llegar a él en la menor cantidad de operaciones posible.

D. Si tiene muchas solicitudes de REST de dispositivos, donde no usa cookies, entonces desactive el soporte de sesión (o enrolle el suyo como lo hicimos nosotros). Las sesiones usan el almacén de datos bajo el capó y para cada solicitud se obtiene y coloca.

E. Lea sobre adjusting app settings. Pruebe diferentes configuraciones (dependiendo de qué tan tolerante sea su aplicación para solicitar demoras y sus patrones de tráfico/picos). Pudimos reducir las instancias frontend en un 70%.