Perché le persone usano Heroku quando AWS è presente? Cosa distingue Heroku da AWS?

Sono un programmatore RoR per principianti che sta pianificando di distribuire la mia app usando Heroku. La parola del mio altro advisor dice che Heroku è veramente facile, buono da usare. L’unico problema è che non ho ancora idea di cosa faccia Heroku …

Ho guardato il loro sito Web e in poche parole, quello che Heroku fa è aiutare con il ridimensionamento ma … perché questo importa? Come aiuta Heroku a:

  1. Velocità – La mia ricerca ha implicato che l’implementazione di AWS sulla costa est degli Stati Uniti sarebbe la più veloce se mi rivolgo a un pubblico statunitense / asiatico.

  2. Sicurezza: quanto sono sicuri?

  3. Ridimensionamento – Come funziona davvero?

  4. Efficienza dei costi – C’è qualcosa come un banco di prova che lo rende facile da scalare.

  5. Come vanno contro i loro concorrenti? Ad esempio, Engine Yard e bluebox ?

Si prega di utilizzare termini laici in inglese per spiegare … Sono un programmatore principiante.

AWS / Heroku sono entrambi gratuiti per piccoli progetti di hobby (per cominciare).

Se vuoi avviare subito un’applicazione, senza molta personalizzazione dell’architettura, quindi scegli Heroku .

Se si desidera concentrarsi sull’architettura e poter utilizzare server Web diversi, scegliere AWS . AWS richiede più tempo in base a quale servizio / prodotto si sceglie, ma può valerne la pena. AWS include anche molti servizi e prodotti plug-in.


Heroku

  • Piattaforma come servizio (PAAS)
  • Buona documentazione
  • Ha strumenti e architettura integrati.
  • Controllo limitato dell’architettura durante la progettazione dell’app.
  • La distribuzione è gestita da (solo tramite comandi git).
  • Non richiede tempo.

AWS

  • Infrastruttura come servizio (IAAS)
  • Versatile: ha molti prodotti come EC2, LAMBDA, EMR, ecc.
  • È ansible utilizzare un’istanza dedicata per un maggiore controllo sull’architettura, ad esempio scegliendo il sistema operativo, la versione del software e così via. Esistono più livelli di back-end.
  • Elastic Beanstalk è una funzionalità simile al PAAS di Heroku.
  • Può utilizzare la distribuzione automatizzata o eseguire il rollover.

Per prima cosa, AWS e Heroku sono cose diverse. AWS offre Infrastructure as a Service ( IaaS ) mentre Heroku offre una piattaforma come servizio ( PaaS ).

Qual è la differenza? Molto approssimativamente, IaaS ti fornisce i componenti di cui hai bisogno per build cose su di esso; PaaS ti offre un ambiente in cui devi solo inserire codice e alcune configurazioni di base e ottenere un’applicazione in esecuzione. IaaS può darti più potenza e flessibilità, al costo di dover build e mantenere più te stesso.

Per far funzionare il tuo codice su AWS e sembrare un po ‘come una distribuzione di Heroku, ti serviranno alcune istanze EC2: ti verrà installato un layer di bilanciamento del carico / cache (ad esempio Varnish ), ti occorreranno istanze che eseguono qualcosa come Passenger e nginx per servire il tuo codice, ti consigliamo di distribuire e configurare un’istanza di database in cluster di qualcosa come PostgreSQL . Avrai bisogno di un sistema di distribuzione con qualcosa come Capistrano e qualcosa che faccia aggregazione dei log.

Non è una quantità insignificante di lavoro da impostare e mantenere. Con Heroku, lo sforzo richiesto per arrivare a quel tipo di palcoscenico è forse qualche riga di codice dell’applicazione e una git push .

Quindi sei così lontano e vuoi scalare. Grande. Stai usando Puppet per la tua implementazione EC2, giusto? Così ora puoi configurare i tuoi file Capistrano in istanze di spin up / down secondo necessità; Riavviare la configurazione di Puppet in modo che Varnish sia a conoscenza delle istanze di web worker e si unirà automaticamente tra di loro. O tu heroku scale web:+5 .

Spero che questo ti dia un’idea del confronto tra i due. Ora per indirizzare i tuoi punti specifici:

Velocità

Attualmente Heroku funziona solo su istanze AWS in us-east e eu-west . Per te, questo suona come quello che vuoi comunque. Per gli altri, è potenzialmente più di una considerazione.

Sicurezza

Ho visto molti server di produzione mantenuti internamente che sono molto indietro sugli aggiornamenti di sicurezza o, in generale, mal messi insieme. Con Heroku, hai qualcun altro che gestisce quel genere di cose, che è una benedizione o una maledizione a seconda di come la si guarda!

Quando ti schieri, stai effettivamente consegnando il tuo codice direttamente a Heroku. Questo potrebbe essere un problema per te. Il loro articolo su Dyno Isolation descrive dettagliatamente le loro tecnologie di isolamento (sembra che vengano eseguiti più dynos su singole istanze EC2). Diversi colleghi hanno express problemi con queste tecnologie e la forza del loro isolamento; Non sono, purtroppo, in una posizione di conoscenza / esperienza sufficienti per commentare veramente, ma le mie attuali distribuzioni di Heroku lo considerano “abbastanza buono”. Potrebbe essere un problema per te, non lo so.

scalata

Ho toccato come si potrebbe implementare questo nel mio confronto IaaS vs PaaS sopra. Approssimativamente, la tua applicazione ha un Procfile , che ha le linee del modulo dyno_type: command_to_run , quindi ad esempio (criptato da http://devcenter.heroku.com/articles/process-model ):

 web: bundle exec rails server worker: bundle exec rake jobs:work 

Questo, con un:

 heroku scale web:2 worker:10 

comporterà l’esecuzione di 2 dynos web e 10 dynos di worker . Bello, semplice, facile. Nota che il web è un tipo di dyno speciale, che ha accesso al mondo esterno, ed è dietro il loro bel multiplexer del traffico web (probabilmente una sorta di combinazione Varnish / nginx) che instraderà il traffico di conseguenza. I tuoi dipendenti probabilmente interagiscono con una coda di messaggi per routing simile, da cui otterranno la posizione tramite un URL nell’ambiente.

Efficienza dei costi

Molte persone hanno molte opinioni diverse su questo. Attualmente è $ 0,05 / ora per un’ora di prova, rispetto a $ 0,025 / ora per un’istanza micro AWS o $ 0,09 / ora per un’istanza di piccole dimensioni AWS.

La documentazione sul dyno di Heroku dice che hai circa 512 MB di RAM, quindi probabilmente non è troppo irragionevole considerare un dinamismo un po ‘come un’istanza micro EC2. Vale la pena raddoppiare il prezzo? Quanto apprezzi il tuo tempo? La quantità di tempo e di sforzo necessari per build in cima a un’offerta IaaS per arrivare a questo standard non è sicuramente economica. Non posso davvero rispondere a questa domanda per te, ma non sottovalutare i “costi nascosti” di installazione e manutenzione.

(Un po ‘a parte, ma se mi collego a un banco da qui ( heroku run bash ), un look superficiale mostra 4 core in /proc/cpuinfo e /proc/cpuinfo di RAM – questo mi porta a credere che io sia su un ” Doppia memoria extra grande di memoria ” La documentazione di Heroku Dyno dice che ogni banco riceve 512 MB di RAM, quindi sto potenzialmente condividendo con altri 71 dynos. (Non ho abbastanza dati sull’omogeneità delle istanze AWS di Heroku, quindi la tua miliardaria può variare))

Come vanno contro i loro concorrenti?

Questo, temo di non poterti davvero aiutare. L’unico concorrente a cui ho mai assistito è stato Google App Engine : all’epoca stavo cercando di implementare applicazioni Java e la quantità di restrizioni su framework e tecnologie utilizzabili era incredibilmente sproporzionata. Questo è più che “solo una cosa di Java”: la quantità di restrizioni generali e le considerazioni necessarie ( le FAQ suggeriscono a molti) sembrava meno che conveniente. Al contrario, schierare a Heroku è stato un sogno.

Conclusione

Spero che questo risponda alle tue domande (ti preghiamo di commentare se ci sono lacune / altre aree che vorresti indirizzare). Sento che dovrei offrire la mia posizione personale. Amo Heroku per “implementazioni rapide”. Quando avvio un’applicazione e voglio un hosting economico (il livello gratuito di Heroku è fantastico – essenzialmente se hai bisogno di un solo dyno web e 5MB di PostgreSQL, è gratuito per ospitare un’applicazione), Heroku è la mia posizione di partenza . Per “Serious Production Deployment” con diversi clienti paganti, con un accordo sul livello di servizio, con dedicato tempo da dedicare alle operazioni, eccetera, non riesco a convincermi a scaricare quel tanto di controllo su Heroku e quindi su AWS o i nostri server sono stati la piattaforma di hosting di scelta.

In definitiva, si tratta di ciò che funziona meglio per te. Dici di essere un “programmatore principiante” – potrebbe essere semplicemente che usare Heroku ti permetterà di concentrarti sulla scrittura di Ruby, e non dover perdere tempo a build tutta l’altra infrastruttura attorno al tuo codice. Ci proverei senz’altro.


Nota, AWS ha in realtà un’offerta PaaS, Elastic Beanstalk , che supporta Ruby, Node.js, PHP, Python, .NET e Java. Penso che in genere la maggior parte delle persone, quando vedono “AWS”, salti su cose come EC2 e S3 ed EBS, che sono sicuramente offerte IaaS

Come ha detto Kristian Glass, non c’è paragone tra IaaS ( AWS ) e PaaS ( Heroku , EngineYard ).

In pratica, PaaS aiuta gli sviluppatori a velocizzare lo sviluppo di app, risparmiando così denaro e soprattutto innovando le loro applicazioni e business invece di configurare configurazioni e gestire cose come server e database. Altre caratteristiche che acquistano per utilizzare PaaS è il processo di distribuzione dell’applicazione come agilità, disponibilità elevata, monitoraggio, scalabilità / decalcificazione, necessità limitata di esperienza, facilità di implementazione e riduzione dei costi e dei tempi di sviluppo.

Ma c’è ancora un lato oscuro del PaaS che ostacola l’adozione del PaaS:

  • Meno controllo su server e database
  • I costi saranno molto alti se non gestiti correttamente
  • Prematura e dubbia nell’attuale giorno ed età

Oltre a questo, dovresti avere abbastanza skill per permetterti di farti fare IaaS:

  • Acquisizione hardware
  • Sistema operativo
  • Software server
  • Ambiente di scripting lato server
  • server web
  • Sistema di gestione dei database (Mysql, Redis ecc.)
  • Configurare il server di produzione
  • Strumento per test e implementazione
  • App di monitoraggio
  • Alta disponibilità
  • Load Blancing / Http Routing
  • Criteri di backup del servizio
  • Collaborazione in team
  • Ricostruisci la produzione

Se hai affari su piccola scala, PaaS sarà l’opzione migliore per te:

  • Paga come vai
  • Basso costo di avviamento
  • Lascia l’impianto idraulico all’esperto
  • PaaS gestisce scaling / descaling automatico, bilanciamento del carico, disaster recovery
  • PaaS gestisce tutti i requisiti di sicurezza
  • PaaS gestisce affidabilità, alta disponibilità
  • Paas gestisce molti componenti aggiuntivi di terze parti per te

Sarà una scelta totalmente individuale basata sui requisiti. Puoi avere i dettagli sulle mie app PPT Hosting Rails .

Ci sono molti modi diversi di considerare questa decisione da obiettivi di sviluppo, IT e business, quindi non sentirti male se sembra schiacciante. Ma anche – non pensare troppo alla scalabilità.

Pensa alle tue esigenze .

Ho progettato siti Web che hanno servito oltre 8 milioni di utenti unici al giorno e fornito terabyte di video a settimana basati su infrastrutture a partire da $ 250.000 di hardware in conto capitale di un enorme staff di lavoro IT di $ MM.

Ma ho anche avuto siti web più piccoli che sono stati progettati per generare $ 10- $ 20k all’anno, non hanno avuto molto traffico, db o requisiti di elaborazione, e li ho scaricati da un account di hosting generico da $ 10 / mese senza compromessi.

In futuro, la distribuzione sembrerà più simile a Heroku di AWS, proprio a causa dei progressi. C’è un valore zero nella rotazione IT delle infrastrutture Internet di ridimensionamento, che non è sempre più automatizzabile e nulla ha a che fare con il valore del prodotto o del servizio che offri.

Inoltre, tieni presente un sito Web commerciale: la scalabilità è ciò che spesso definiamo un “buon problema da avere”, anche se i problemi di scalabilità con siti come Facebook e Twitter erano di alto profilo, non avevano alcun effetto negativo sul loro successo – le notizie potrebbe anche aver contribuito a più iscrizioni (tutta la stampa è buona stampa).

Se possiedi un servizio che genera un numero unico di 100k + al giorno e problemi di ridimensionamento, sarei lieto di portarlo a portata di mano per te indipendentemente dalla lingua, db, piattaforma o infrastruttura su cui stai lavorando!

La scalabilità è un problema di implementazione risolvibile: non avere clienti è un problema esistenziale.

In realtà puoi utilizzare entrambi: puoi sviluppare un’app con i server Amazon ec2. Quindi spingerlo (con git) a heroku gratuitamente per un po ‘(usa il livello gratuito di heroku per servirlo al pubblico) e testarlo in questo modo. È molto conveniente rispetto al noleggio di un server, ma dovrai parlare con una heroku api più restrittiva che è qualcosa a cui dovresti pensare. Fonte: questo metodo è stato adottato per uno dei miei corsi online “Startup engineering from Coursera / Stanford di Balaji S. Srinivasan e Vijay S. Pande

Aggiunto uno schema così la mia spiegazione sarà più facile da capire

Le risposte esistenti sono ampiamente accurate:

  • Heroku è molto facile da usare e distribuire, può essere facilmente configurato per l’implementazione automatica di un repository (ad es. GitHub), ha molti componenti aggiuntivi di terze parti e carica più per istanza.

  • AWS offre una gamma più ampia di servizi di prima parte a prezzi competitivi tra cui DNS, bilanciamento del carico, archiviazione di file a basso costo e funzionalità aziendali come la possibilità di definire politiche di sicurezza.

Per il tl; dr salta alla fine di questo post.

AWS ElasticBeanstalk è un tentativo di fornire un autoscaling simile a Heroku e una piattaforma di facile implementazione. Poiché utilizza istanze EC2 (che crea automaticamente) i server EB possono fare tutto ciò che può fare qualsiasi altra istanza EC2 ed è economico da eseguire.

La distribuzione con EB è molto lenta; la distribuzione di un aggiornamento può richiedere 10-15 minuti per server e la distribuzione in un cluster più grande può richiedere la parte migliore di un’ora, rispetto a solo pochi secondi per la distribuzione di un aggiornamento su Heroku. Anche le implementazioni su EB non vengono gestite in modo particolarmente fluido, il che può imporre limitazioni alla progettazione dell’applicazione.

Puoi utilizzare tutti i servizi che ElasticBeanstalk utilizza dietro le quinte per creare il tuo sistema personalizzato (con CodeDeploy, Elastic Load Balancer, Auto Scaling Groups e CodeCommit, CodeBuild e CodePipeline se vuoi andare all in) ma puoi sicuramente spendere un buon un paio di settimane che lo impostano la prima volta perché è piuttosto complicato e leggermente più complicato della semplice configurazione di EC2.

AWS Lightsail offre un’opzione di hosting a prezzi competitivi, ma non aiuta con la distribuzione o il ridimensionamento – è in realtà solo un wrapper per la loro offerta EC2 (ma costa molto di più). Permette di eseguire automaticamente uno script bash durante l’installazione iniziale, il che è piacevole ma è costoso rispetto al costo di una semplice istanza EC2 (che puoi anche programmare a livello di programmazione).

Alcuni pensieri sul confronto (per cercare di rispondere alle domande, anche se in modo indiretto):

  1. Non sottovalutare la quantità di amministrazione del sistema di lavoro, incluso tenere aggiornato tutto ciò che è stato installato con patch di sicurezza (e aggiornamenti occasionali del SO).

  2. Non sottovalutare quanto sia vantaggioso il deployment automatico, il ridimensionamento automatico e il provisioning e la configurazione di SSL.

    La distribuzione automatica quando si aggiorna il repository Git è semplice con Heroku. È quasi istantaneo, aggraziato quindi non ci sono interruzioni per gli utenti finali e può essere impostato per l’aggiornamento solo se i test / Integrazione continua passano in modo da non interrompere il sito se si distribuisce codice non funzionante.

    È anche ansible utilizzare ElasticBeanstalk per l’implementazione automatica, ma essere pronti a passare una settimana al primo avvio – potrebbe essere necessario modificare la modalità di distribuzione e creazione di risorse (come CSS e JS) per lavorare su come ElasticBeanstalk gestisce le distribuzioni o la logica di creazione nella tua app per gestire le distribuzioni.

    Essere consapevoli di stimare i costi che per una distribuzione senza interruzioni senza interruzione su EB è necessario eseguire più istanze – EB distribuisce gli aggiornamenti a ciascun server singolarmente in modo che il servizio non sia degradato – dove Heroku gira un nuovo banco di prova per te e sconsiglia il vecchio servizio fino a quando tutte le richieste ad esso sono state gestite (quindi lo elimina).

    È interessante notare che il costo dell’hosting per l’esecuzione di più server con EB può essere più economico di una singola istanza di Heroku, soprattutto se si include il costo dei componenti aggiuntivi.

Alcuni altri problemi non espressamente richiesti, ma sollevati da altre risposte:

  1. Utilizzare un fornitore diverso per la produzione e lo sviluppo è una ctriggers idea.

    Sono preoccupato che la gente lo stia suggerendo. Mentre idealmente il codice dovrebbe funzionare perfettamente su qualsiasi piattaforma ragionevole in modo che sia il più portabile ansible, le versioni del software su ciascun host variano notevolmente e solo perché il codice viene eseguito nella staging non significa che verrà eseguito in produzione (ad esempio Node.js principale / Le versioni di Ruby / Python / PHP / Perl possono differire in modi che rendono il codice incompatibile, spesso in modi silenziosi che potrebbero non essere rilevati anche se si dispone di una copertura di test decente).

    Una buona idea è quella di sfruttare qualcosa come Heroku per la prototipazione, i progetti più piccoli e i micrositi – in modo da poter build e distribuire le cose rapidamente senza investire molto tempo in configurazione e manutenzione.

    Assicurati di tenere conto del costo di esecuzione delle istanze di produzione e di pre-produzione quando prendi questa decisione, senza dimenticare il costo della replica dell’intero ambiente (inclusi servizi di terze parti come archivi di dati / componenti aggiuntivi, installazione e configurazione di SSL, ecc.) .

  2. Se utilizzi AWS, fai attenzione alle istanze preconfigurate di AWS da venditori come Bitnami: sono un incubo per la sicurezza. Possono esporre molte applicazioni notoriamente vulnerabili per impostazione predefinita senza menzionarle nella descrizione.

    Considera invece solo l’uso di una distribuzione mainstream ben supportata, come Ubuntu o Debian (o CentOS se hai bisogno del supporto RPM).

    Nota: l’offerta Amazon ha una propria distribuzione chiamata Amazon Linux, che utilizza RPM, ma è specifica per EC2 e meno ben supportata da software di terze parti / open source.

  3. È anche ansible impostare un’istanza EC2 su AWS (o Lightsail) e configurarla con qualcosa come Flynn o Dokku su di essa – su cui è ansible quindi distribuire facilmente più siti, che può valerne la pena se si mantengono molti servizi o si desidera essere in grado di far girare facilmente nuove cose. Tuttavia, impostarlo non è automatico come se si stesse semplicemente usando Heroku e si può finire per passare un sacco di tempo a configurarlo e mantenerlo (al punto che ho trovato la distribuzione usando il cluster Amazon e Docker Swarm per essere più facile che configurarlo; YMMV).

Ho utilizzato istanze AWS EC (solo e in cluster), Elastic Beanstalk e Lightsail e Heroku allo stesso tempo, a seconda delle esigenze del progetto su cui sto lavorando.

Odio passare il tempo a configurare i servizi, ma il mio conto Heroku sarebbe di migliaia all’anno se lo avessi usato per tutto e AWS funzionasse a una frazione del costo.

tl; dr

Se il denaro non fosse mai stato un problema, userei Heroku per quasi tutto, dato che è un enorme risparmio di tempo, ma vorrei comunque utilizzare AWS per progetti più complicati in cui ho bisogno della flessibilità e di servizi più avanzati che Heroku non offre.

Lo scenario ideale per me sarebbe se ElasticBeanstalk funzionasse più come Heroku, cioè con una configurazione più semplice e un meccanismo di distribuzione più veloce e migliore.

Un esempio di un servizio che è quasi questo è now.sh , che in realtà utilizza AWS dietro le quinte, ma rende le distribuzioni e il clustering così semplici come su Heroku (con SSL automatico, DNS, installazioni eleganti, configurazione dei cluster estremamente semplice e gestione).

L’ho usato parecchio sia per l’app Node.js che per le distribuzioni di immagini Docker, il principale avvertimento è che le istanze sono condivise (qualcosa si riflette nel loro costo inferiore) e al momento nessuna opzione per acquistare istanze dedicate. Tuttavia, il loro strumento di implementazione open source “now” può anche essere utilizzato per la distribuzione in istanze dedicate su AWS e Google Cloud e Azure.

Bene, la gente di solito fa questa domanda: Heroku o AWS quando inizia a schierare qualcosa.

Il mio esperimento sull’utilizzo di entrambi Heroku e AWS, ecco la mia recensione e il mio confronto rapidi:

Heroku

  • Un comando per distribuire qualsiasi tipo di progetto: Ruby on Rails, Nodejs
  • Tanti clic su 1 per integrare plug-in e terze parti: è semplicissimo iniziare con qualcosa.
  • Non avere auto-ridimensionamento; ciò significa che è necessario aumentare / ridurre manualmente
  • Il costo è costoso, soprattutto quando il sistema richiede più risorse
  • Istanza gratuita disponibile
  • L’istanza gratuita va in stop se è intriggers.
  • Data center: solo Stati Uniti e UE
  • PU dive entrare e accedere al livello della macchina usando Heroku run bash (Grazie, MJafar Mash per il consiglio) ma è un po ‘limitato! Non hai pieno accesso!
  • Non c’è bisogno di sapere troppo su DevOps

AWS – EC2

  • Questo proprio come una macchina con sistema operativo pre-configurazione (o meno), quindi è necessario installare software, libreria per rendere online il proprio sito Web / servizio.
  • Plugin e libreria devono essere integrati manualmente, o script di automazione (script pubblici e scritti da te)
  • Il ridimensionamento automatico e il bilanciamento del carico sono i servizi supportati, basta imparare come configurare e integrare il sistema
  • Il costo è abbastanza economico, dipende da quali servizi e dal numero di ore di utilizzo
  • Ci sono diverse ore gratuite per le istanze di T2.micro, ma di solito pagherai pochi dollari ogni mese (se usi ancora T2.micro)
  • La tua istanza gratuita non andrà a dormire, disponibile 24 ore su 24 (perché potresti pagare per questo :))
  • Data center: in tutto il mondo. Scegli la regione che è più adatta a te.
  • Immergiti nel livello della macchina. Quindi puoi godertelo
  • Qualche conoscenza su DevOps, ma va bene, Stackoverflow è utile lì!

AWS Elastic Beanstalk un’alternativa di Heroku, ma più economica

  • Elastic Beanstalk è stato annunciato come beta pubblica dal 2010; ci aiuta a lavorare più facilmente con la distribuzione. Per i dettagli, vai qui

  • Beanstalk è gratuito, il costo che pagherai sarà per i servizi che utilizzi e il numero di ore di utilizzo.

  • Uso Elastic Beanstalk da molto tempo e penso che possa essere la sostituzione di Heroku e meno costoso!

Sommario

  • Heroku: Facile all’inizio, istanza GRATUITA , ma costoso dopo
  • AWS: Non facile, ore libere disponibili, una specie di più economico , Beanstalk dovrebbe essere preoccupato di usare

Quindi nel mio attuale sistema, uso Heroku per la messa in scena e il fagiolo magico per la produzione!

È stata una percentuale significativa del nostro business la migrazione di persone da Heroku ad AWS. Ci sono vantaggi per entrambi, ma dopo un po ‘è un po’ complicato per Heroku … una volta che hai bisogno di un certo livello di complessità non è più facile da mantenere con i limiti di Heroku.

Detto questo, ci sono sempre più opzioni per avere la semplicità di Heroku e la flessibilità di AWS essendo su AWS con ottimi framework / strumenti.

La cosa divertente è che Heroku usa effettivamente AWS sul backend. Elimina tutto il sovraccarico e fa la gestione dell’architettura su EC2 per te. (Ho avuto questa conoscenza da un ingegnere senior in una grande azienda durante un’intervista)

Amazon Web Services (AWS) offre numerosi servizi, da IaaS a PaaS, con una durata assicurata del 99,9999,9999% e disponibilità di dati e infrastruttura. AWS offre l’automazione dell’infrastruttura insieme a numerosi strumenti per gli sviluppatori per la pipeline del processo di distribuzione delle applicazioni.

D’altra parte, Heroku è solo PaaS che offre servizi per gestire la tua piattaforma sul loro cloud. AWS non è da nessuna parte se si tratta di infrastrutture o sicurezza.

Bene! L’osservatore Heroku è famoso negli sviluppatori in erba e appena nati mentre AWS ha una personalità sviluppatrice avanzata. DigitalOcean è anche un giocatore importante in questo campo. Cloudways ha reso molto semplice la creazione di Lamp Stack con un clic su DigitalOcean e AWS. Avere tutti gli aggiornamenti di servizi e pacchetti in un clic è molto meglio che fare tutto manualmente.

Puoi controllare completamente qui: https://www.cloudways.com/blog/host-php-on-aws-cloud/

Sometimes, I wonder why people compare AWS to Heroku. AWS is an IAAS( infrastructure as a service) it clearly speaks how robust and calculative the system is. Heroku, on the other hand, is just a SAAS, it is basically just one fraction of AWS services. So why struggle with setting up AWS when you can ship your first product to the prime using Heroku.

Heroku is free, simple and easy to deploy almost all types of stacks to the web. Heroku is specifically built to bypass all the hassles of shipping your application to a live server in less than no time.

Nevertheless, you may want to deploy your application using any of the tutorials from both parties and compare

AWS DOCS and Heroku Docs

Well Heroku uses AWS in background, it all depends on the type of solution you need. If you are a core linux and devops guy you are not worried about creating vm from scratch like selecting ami choosing palcement options etc, you can go with AWS. If you want to do things on surface level without having those nettigrities you can go with heroku.

Even though both AWS and Heroku are cloud platforms, they are different as AWS is IaaS and Heroku is PaaS

I ve read some answers about HEROKU and AWS being so different (the first is Platform as Service and the second is Infra as Service. To put the comparison into perspective, amazon does offer a PaaS solution its named AWS Elastic Beanstalk. For comparison about those , please check the below URL https://dzone.com/articles/heroku-or-amazon-web-services-which-is-best-for-your-startup

well.. its not all that rosy..

first of all: AWS is not rocket science, and if you know your way around deploying “things” at the end of the day its better to use AWS, and cheaper .. instead of any other PaaS which tend to be always more expensive in exchange of doing “things” for you … IMHO AWS is lot better and you have lot more control overall,

especially now when there is rightScale , bitnami, etc … and all those pre made EC2 images for so many different software stacks.