sistema - Implementación manual frente a Amazon Elastic Beanstalk

para que sirve elastic beanstalk

Question

¿Cuáles son las ventajas que obtenemos con el uso de Elastic Beanstalk sobre la creación de instancias de EC2 y la configuración del servidor de tomcat y la implementación de una aplicación Java web típica? ¿El balanceo de carga, monitoreo y autoescalamiento son las únicas ventajas?

Supongamos que para mi aplicación web que usa la base de datos, instalé la base de datos en la instancia EC2 misma. Cuando tenga lugar la Llamada automática, la base de datos se creará en la instancia recién creada o accederá a la base de datos que creé en la instancia maestra ... Si solo se crea una réplica cuando se produce la autoescala, ¿cómo ocurrirá la sincronización de datos entre las instancias?

Answer 1

Elastic Beanstalk hace más que simplemente equilibrar la carga, controlar y ajustar el autoescalado.

1) Administra las versiones de las aplicaciones almacenando y administrando diferentes versiones de su aplicación, lo que le permite cambiar fácilmente de una a otra versión de sus aplicaciones.

2) Tiene el concepto de "entornos" para cada aplicación, lo que le permite implementar diferentes versiones de su aplicación en cada entorno. Esto es útil, por ejemplo, si desea configurar entornos separados de QA y DEV, y desea desplegar fácilmente una compilación primero en DEV y luego implementar la misma versión de la aplicación en QA cuando su equipo de control de calidad está listo para la siguiente compilación.

3) Externaliza las propiedades importantes de configuración del contenedor (configuraciones de memoria Tomcat, por ejemplo) a la consola y API de Elastic Beanstalk. Debido a esto, puede guardar fácilmente las configuraciones y copiarlas entre entornos.

4) Ver archivos de registro de la aplicación a través de la consola y automáticamente rodar y archivar archivos de registro a S3. (Es cierto que esta característica es actualmente un poco débil.)

Answer 2

Todas las cosas que mencionaste, como el equilibrio de carga, el monitoreo y el escalado automático, son definitivamente ventajas.

Sin embargo, debe pensarlo de esta manera: en una verdadera plataforma como servicio (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í mismo no es PAAS. Es más como IAAS ( Infraestructura como Servicio ). 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 verdadero sistema PAAS, el DBMS es un componente separado de los 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ía! 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 implementan 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 implementados (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.