Quali sono i pro e i contro di AWS Elastic Beanstalk rispetto ad altre strategie di implementazione?

Sono piuttosto nuovo all'intero stack OSS di Netflix e alle distribuzioni in generale. Come sfondo per il mio attuale livello di conoscenza dal punto di vista operativo, il mio ruolo principale è quello di ingegnere applicativo front-end. Tuttavia, mi piace il lato operativo delle cose, quindi sto tentando di impostare una nuova strategia di distribuzione e gli strumenti per un nuovo progetto.

I nostri obiettivi

• Distribuzioni semplicissime (vogliamo premere un pulsante per aggiornare la produzione)
• Distribuzioni automatizzate per testare ambienti (usando Jenkins)
• Facilità di manutenzione (abbiamo un'app da scrivere, non vogliamo passare il tempo a armeggiare con problemi di produzione)
• Capacità di gestire un'architettura orientata ai servizi (molte piccole app, varie lingue e archivi dati)
• Abbastanza flessibilità per garantire che non dovremo cambiare strategia in qualunque momento presto (stiamo già cercando di allontanarci da RightScale)

Siamo d'accordo con un po 'più di tempo di installazione iniziale, se così facendo ci risparmieremo qualche mal di testa in futuro.

Quindi, seguendo queste linee, ho ascoltato podcast, guardato i talk di Ops e letto tonnellate di post sul blog e sulla base dei nostri obiettivi e di quelli che ho preso per formare alcune best practice, abbiamo iniziato a formare un piano usando Asgard, arrotolando il nostro pacchetto in un barattolo e trasformandolo in un AMI.

Avevamo pianificato tutto questo e apprezziamo i vantaggi del processo rispetto all'utilizzo di un server Chef e istanze convergenti al volo (ritenevamo che questo fosse soggetto a errori, data la nostra timeline limitata e la mancanza di comprensione intorno al flusso di lavoro di un server Chef). Tuttavia, un collega si è guardato un po 'in giro da solo e ha sentito che l'Elastic Beanstalk ha soddisfatto i nostri bisogni.

L'ho esaminato e ho creato un ambiente di test con un file WAR e un database RDS allegato. Le cose sembrano funzionare e credo che possiamo automatizzare le distribuzioni in un ambiente di test usando Jenkins tramite l'API AWS. Sembra abbastanza semplice ... forse troppo semplice.

Quello che mi chiedo è, qual è il trucco? Se l'Elastic Beanstalk è così semplice ed efficace, perché non ne parla più? Sto facendo fatica a trovare abbastanza opinioni e fatti oggettivi sulle due diverse strategie di schieramento, quindi ho pensato di chiedere in giro.

Usi Elastic Beanstalk? In tal caso, perché e quali fattori portano a tale decisione? Cosa ti piace e non ti piace?

Se non usi l'Elastic Beanstalk ma lo consideri, cosa usi e perché non hai usato l'Elastic Beanstalk?

Quali sono i vantaggi e gli svantaggi di una strategia di implementazione basata su Elastic Beanstalk per una SOA? Cioè, Elastic Beanstalk funzionerà bene con molte piccole applicazioni che si basano l'una sull'altra per funzionare?

Ho valutato Elastic Beanstalk in aggiunta ad altre offerte AWS mentre provavo a migliorare le nostre istanze AWS arrotolate a mano. I motivi per cui ho scelto di non usarlo erano dovuti a complicazioni che avrebbero causato la migrazione della mia applicazione esistente e non con l'offerta stessa. Il problema è che non hai il massimo controllo sulla distribuzione / configurazione delle applicazioni dei server. Se stai avviando una nuova applicazione, potrebbe essere utile non occuparsi di queste cose in questo momento, se hai un'applicazione esistente, è più una sfida adattarsi al modello Beanstalk.

Beanstalk offre un'offerta simile a Heroku e ad altri fornitori di PaaS, ma non è un grande vantaggio per coloro che vogliono solo concentrarsi sulla realizzazione della propria applicazione. Almeno riesci a determinare le risorse virtualizzate in misura maggiore rispetto agli altri fornitori PaaS.

Problemi che stavo incontrando con le mie applicazioni:

• Distribuzioni basate su Git: le adoro, ma il nostro repository è 1+ GB. Piuttosto grande da spingere su base regolare. Questo repository contiene anche circa 40 applicazioni (che in realtà dovrebbero essere divise) ma ciò richiederebbe del tempo. Il caricamento di qualsiasi tipo di pacchetto potrebbe funzionare, ma la maggior parte delle nostre applicazioni richiederebbe una grande quantità di lavoro per trasformarlo in un pacchetto.

• Integrazione con altri servizi - Da quello che ho visto Beanstalk suppone che qualsiasi cosa a cui ti stai connettendo sia un singolo servizio. Questo funziona bene se i tuoi servizi sono in ritardo e ELB ma i nostri erano nodi separati che abbiamo colpito attraverso HAProxy in esecuzione su ciascun server delle applicazioni. Se si eseguono archivi dati e altri servizi come un singolo endpoint, si dovrebbe andare bene.

Nella mia valutazione ho incluso anche OpsWorks e CloudFormation. OpsWorks ha problemi di integrazione simili con il funzionamento dell'automazione esistente per queste applicazioni. CloudFormation non ha fatto molto di più di quello che alcuni script di Python e Chef si stavano già occupando di noi.

Ho deciso di utilizzare AWS Autoscaling Groups invece con l'automazione fornita da Asgard . Questa è stata la più piccola modifica al codice di configurazione / applicazione esistente e ci ha fornito i vantaggi che stavamo cercando, una semplice gestione di più server disponibili tramite l'API AWS.

Le restrizioni poste da Elastic Beanstalk sulla tua applicazione sono molto utili. Dovrai assicurarti che la tua applicazione sia per lo più senza stato, fornisca un endpoint per un servizio e faccia affidamento su altri servizi per lo stato. Se stai cercando di rendere i servizi autonomi riutilizzabili, più applicazioni in Beanstalk sono un ottimo inizio.

Se / quando arrivi al punto di volere più configurazioni, OpsWorks è un grande passo successivo. I ruoli predefiniti dovrebbero facilitare la transizione e fornire un framework di automazione attorno a Chef per aiutare a coordinare il provisioning di più server.

Vedo il punto di perdita del controllo, ma non vedo necessariamente l'apolidia obbligatoria. Tutto ciò che eb fa davvero è distribuire l'automazione, il che è fantastico. Vedo il punto di un grande repository. In generale, penso che separare le funzioni delle app logiche in app bean separate, e quindi avere "staging" e ambienti "prod" sottostanti, sia davvero bello. Abbiamo ambienti di moduli come l'uploader, non fa molto e in teoria aggiunge molti costi, ma poi stai usando istanze più piccole solo di più. Abbiamo eseguito un nginx centralizzato e abbiamo dovuto scrivere un sacco di handle di messaggi sns personalizzati per notificare a ngnix i cambiamenti nella politica di ridimensionamento automatico. Un altro grosso problema di eb è l'incapacità di eliminare i saldi di carico, dal momento che usiamo ngnix, perché? elb non supporta websocket.