Todo lo que ha mencionado, como el equilibrio de carga, el control y el escalado automático, son sin duda ventajas.
Sin embargo, tienes que pensarlo de esta manera: en un verdadero Platform as a Service (PAAS), el objetivo es separar la aplicación de la plataforma. Como desarrollador, solo te preocupas por tu aplicación. La plataforma se "alquila" a usted. Las "instancias" de plataforma se actualizan, administran, escalan, equilibran, etc. automáticamente para usted. Simplemente sube tu archivo WAR y simplemente funciona (al menos teóricamente).
EC2 por sí solo no es PAAS. Es más como IAAS (Infrastructure as a Service). Aún debe ocuparse de las instancias del servidor, instalar software en ellas, mantenerlas actualizadas, etc.
Elastic Beanstalk es un sistema PAAS. También lo son App Engine y Azure, entre muchos otros.
En un sistema PAAS verdadero, el DBMS es un componente separado del servidor o servidores de aplicaciones web. La razón es obvia: el DBMS no se puede instalar posiblemente en las instancias que se utilizan para el servidor de aplicaciones porque, como las instancias se crean y destruyen en función de su tráfico, ¡el DBMS se perderá! Tener el DBMS y el servidor de aplicaciones en la misma máquina/instancia generalmente no es una buena idea.
En un sistema PAAS, el DBMS es un servicio separado. Para Amazon, sería Amazon RDS. Al igual que con Elastic Beanstalk, donde no tiene que preocuparse por el servidor de aplicaciones y acaba de cargar su archivo WAR con RDS, no tiene que preocuparse por el DBMS y simplemente implementa su (s) base (s) de datos.
Elastic Beanstalk y RDS funcionan muy bien juntos, especialmente cuando se despliegan en la misma zona de disponibilidad, donde la latencia sería muy baja.
Finalmente, usar Elastic Beanstalk no cuesta nada más que los recursos desplegados (instancias EC2 y balanceador de carga). Sin embargo, RDS no es barato y definitivamente sería más costoso que usar una sola instancia de EC2 para el servidor de aplicaciones y el DBMS.
Bien puesto. Solo una adición: puede especificar un AMI personalizado para servir como base para cada creación de instancia. Así que puede personalizar una imagen Apache con todas las configuraciones y aplicaciones necesarias y usarla como base AMI (hay un campo ID de AMI personalizado en la configuración del entorno Beanstalk) Aún así, los datos generados en tiempo de ejecución serían borrados en cada terminación de instancia (¡y el equilibrador de carga lo hará!). –
Una cosa que me tomó por sorpresa fue el hecho de que Elastic Beanstalk crea un equilibrador de carga para cada entorno que se implementa. Los equilibradores de carga no son realmente caros de ejecutar pero cuestan aproximadamente el mismo costo que una microinstancia. –
@KenLiu, Load Balancer es más poderoso que una microinstancia. – BigSack