Distribuzione manuale rispetto ad Amazon Elastic Beanstalk

Quali sono i vantaggi che otteniamo utilizzando Elastic Beanstalk rispetto alla creazione manuale di un'istanza EC2 e alla configurazione del server Tomcat e alla distribuzione di ecc. Per una tipica applicazione web java. Il bilanciamento del carico, il monitoraggio e la scalabilità automatica sono gli unici vantaggi?

Supponiamo che per la mia applicazione web che utilizza il database abbia installato il database nell'istanza EC2 stessa. Quando viene eseguita la scalabilità automatica, il database viene creato nell'istanza appena creata o accederà al database che ho creato nell'istanza master ... Se crea solo una replica quando viene eseguita la scalabilità automatica, come avverrà la sincronizzazione dei dati tra le istanze?

Tutte le cose che hai menzionato come il bilanciamento del carico, il monitoraggio e il ridimensionamento automatico sono sicuramente vantaggi.

Tuttavia, devi pensarci in questo modo: in una vera Platform as a Service (PAAS), l'obiettivo è separare l'applicazione dalla piattaforma. In qualità di sviluppatore, ti preoccupi solo della tua applicazione. La piattaforma ti viene "affittata". Le "istanze" della piattaforma vengono automaticamente aggiornate, amministrate, ridimensionate, bilanciate, ecc. Per te. Devi solo caricare il tuo file WAR e funziona (almeno in teoria).

EC2 di per sé non è PAAS. È più simile a IAAS ( Infrastructure as a Service ). Devi ancora occuparti delle istanze del server, installare software su di esse, tenerle aggiornate, ecc.

Elastic Beanstalk è un sistema PAAS. Così sono App Engine e Azure tra molti altri.

In un vero sistema PAAS, il DBMS è un componente separato dai server delle applicazioni web. Il motivo è ovvio: il DBMS non può essere installato sulle istanze che vengono utilizzate per il server delle applicazioni perché, poiché le istanze vengono create e distrutte in base al traffico, il DBMS andrebbe perso! In ogni caso, avere il DBMS e il server delle applicazioni sulla stessa macchina / istanza non è generalmente una buona idea.

In un sistema PAAS, il DBMS è un servizio separato. Per Amazon, sarebbe Amazon RDS . Proprio come con Elastic Beanstalk, dove non devi preoccuparti del server delle applicazioni e devi solo caricare il tuo file WAR, con RDS, non devi preoccuparti del DBMS e devi solo distribuire i tuoi database.

Elastic Beanstalk e RDS funzionano molto bene insieme, soprattutto se distribuiti nella stessa zona di disponibilità, dove la latenza sarebbe molto bassa.

Infine, l'utilizzo di Elastic Beanstalk non costa nulla di più delle risorse distribuite (istanze EC2 e bilanciamento del carico). Tuttavia, RDS non è economico e sarebbe sicuramente più costoso rispetto all'utilizzo di una singola istanza EC2 sia per il server delle applicazioni che per il DBMS.

Elastic Beanstalk non si limita al bilanciamento del carico, al monitoraggio e alla scalabilità automatica.

1) Gestisce le versioni dell'applicazione archiviando e gestendo diverse versioni dell'applicazione, consentendo di passare facilmente avanti e indietro tra le diverse versioni delle applicazioni.

2) Ha il concetto di "ambienti" per ogni applicazione, consentendo di distribuire diverse versioni dell'applicazione in ogni ambiente. Ciò è utile, ad esempio, se si desidera configurare ambienti QA e DEV separati e si desidera distribuire facilmente una build prima in DEV, quindi distribuire la stessa versione dell'applicazione in QA quando il team QA è pronto per la build successiva.

3) Esternalizza le importanti proprietà di configurazione del contenitore (le impostazioni di memoria Tomcat, ad esempio) alla console e all'API di Elastic Beanstalk. Per questo motivo è possibile salvare facilmente le impostazioni e copiarle tra gli ambienti.

4) Visualizza i file di registro dell'applicazione tramite la console e trascina e archivia automaticamente i file di registro su S3. (Devo ammettere che questa funzione è attualmente un po 'debole.)

Avevo un'app distribuita sia in EC2 dedicato (Nginx e Gunicorn) che in Beanstalk Environment (CentOS e Apache2).

Le mie osservazioni:

• BeanStalk è Paas. Creare manualmente un'istanza EC2 (IAAS) è come fare tutto da zero, ma hai un controllo solido.

• BeanStalk viene fornito con CentOS e Apache (Httpd) predefiniti. Puoi scegliere il sistema operativo in un'istanza dedicata.

• Queste cose che contavano per me

  • C'erano molti errori 504 visualizzati nell'ambiente Beanstalk.
  • È stato difficile eseguire il debug quando il server BeanStalk si è arrestato in modo anomalo, poiché anche i log non venivano visualizzati e non potevano ssh nella macchina. Questo è molto importante.
  • Installazione / configurazione di strumenti come Celery, Redis (è necessario eseguire un'altra porta) ecc.,. in un'istanza dedicata è molto più semplice.

• Nel mio caso, ho dovuto scalare il server (Beanstalk) per eseguire l'installazione di alcuni pacchetti (come pandoc). Queste cose sono più semplici in Ubuntu.

• Il ridimensionamento è molto più semplice in BeanStalk. La clonazione dei server è semplice in BeanStalk.

• Avevo preso micro in entrambi i casi (dedicato e Beanstalk). Ho sentito che la microistanza dedicata era migliore.

• Distribuzione automatizzata in Beanstalk. Ho dovuto scrivere script per automatizzare lo stesso, il che va bene, poiché è solo una volta.