Frage Warum verwenden Menschen Heroku, wenn AWS vorhanden ist? Was unterscheidet Heroku von AWS?


Ich bin ein Anfänger RoR-Programmierer, der plant, meine App mit Heroku zu implementieren. Das Wort meiner anderen Berater-Freunde sagt, dass Heroku wirklich einfach ist, gut zu benutzen. Das einzige Problem ist, dass ich immer noch keine Ahnung habe, was Heroku macht ...

Ich habe sie angeschaut Webseite Kurz gesagt, was Heroku tut, hilft beim Skalieren, aber ... warum ist das überhaupt von Bedeutung? Wie hilft Heroku bei:

  1. Geschwindigkeit - Meine Untersuchungen haben ergeben, dass der Einsatz von AWS an der US-Ostküste am schnellsten vonstatten gehen würde, wenn ich ein Publikum aus den USA / Asien anspreche.

  2. Sicherheit - Wie sicher sind sie?

  3. Skalierung - Wie funktioniert es eigentlich?

  4. Kosteneffizienz - Es gibt so etwas wie einen Prüfstand, der das Skalieren erleichtert.

  5. Wie gehen sie gegen ihre Konkurrenten vor? Beispielsweise, Maschinenhof und blaue Box?

Bitte benutzen Sie englische Begriffe um zu erklären ... Ich bin ein Anfänger Programmierer.


971
2018-03-21 10:00


Ursprung


Antworten:


AWS / Heroku sind beide frei für kleine Hobby-Projekte (am Anfang).

Wenn Sie sofort eine App ohne viel Anpassung der Architektur starten möchten, wählen Sie Heroku.

Wenn Sie sich auf die Architektur konzentrieren und verschiedene Webserver verwenden möchten, wählen Sie AWS. AWS ist zeitaufwendiger, je nachdem, welchen Service / welches Produkt Sie wählen, aber es kann sich lohnen. AWS enthält auch viele Plugin-Dienste und -Produkte.


Heroku

  • Plattform als Service (PAAS)
  • Gute Dokumentation
  • Hat eingebaute Werkzeuge und Architektur.
  • Begrenzte Kontrolle über die Architektur beim Entwerfen der App
  • Für die Bereitstellung ist gesorgt (nur über Git-Befehle).
  • Nicht zeitaufwendig.

AWS

  • Infrastruktur als Dienstleistung (IAAS)
  • Vielseitig - hat viele Produkte wie EC2, LAMBDA, EMR, etc.
  • Kann eine dedizierte Instanz für mehr Kontrolle über die Architektur verwenden, z. B. Auswahl des Betriebssystems, der Softwareversion usw. Es gibt mehr als eine Backend-Ebene.
  • Elastic Beanstalk ist eine Funktion, die der PAAS von Heroku ähnelt.
  • Kann die automatisierte Bereitstellung verwenden oder eigene Aufgaben ausführen.

133
2017-10-05 08:46



Das Wichtigste zuerst: AWS und Heroku sind verschiedene Dinge. AWS bietet Infrastructure as a Service (IaaS) während Heroku eine Plattform als Dienstleistung anbietet (PaaS).

Was ist der Unterschied? Ganz ungefähr, IaaS gibt Ihnen Komponenten, die Sie brauchen, um Dinge darauf zu bauen; PaaS bietet Ihnen eine Umgebung, in der Sie einfach Code und einige grundlegende Konfigurationen eingeben und eine laufende Anwendung erhalten. IaaS kann Ihnen mehr Power und Flexibilität geben, auf Kosten von selbst mehr aufbauen und unterhalten.

Um Ihren Code auf AWS laufen zu lassen und ein bisschen wie eine Heroku-Bereitstellung aussehen zu lassen, benötigen Sie einige EC2-Instanzen. Auf diesen sollte ein Load-Balancer / Caching-Layer installiert sein (z. Lack), wollen Sie, dass Instanzen so etwas ausführen Passagier und nginx Um Ihren Code bereitzustellen, sollten Sie eine Clustered-Database-Instanz von etwa bereitstellen und konfigurieren PostgreSQL. Sie werden ein Bereitstellungssystem mit etwas wie Capistranound etwas, das Log-Aggregation durchführt.

Das ist keine unbedeutende Menge an Arbeit, die man aufbauen und pflegen muss. Bei Heroku ist der Aufwand, um zu dieser Art von Stufe zu kommen, vielleicht ein paar Zeilen Anwendungscode und a git push.

Du bist also so weit, und du willst größer werden. Groß. Du benutzt Marionette für deine EC2-Bereitstellung, oder? Jetzt konfigurieren Sie Ihre Capistrano-Dateien, um Instanzen nach Bedarf hoch / runter zu drehen; Sie passen Ihre Puppet-Konfiguration an, so dass Varnish Web-Worker-Instanzen kennt und automatisch zwischen ihnen zusammenfasst. Oder du heroku scale web:+5.

Hoffentlich gibt Ihnen das einen Eindruck vom Vergleich zwischen den beiden. Jetzt um Ihre spezifischen Punkte anzusprechen:

Geschwindigkeit

Derzeit läuft Heroku nur auf AWS-Instanzen in us-east und eu-west. Für dich hört sich das nach allem an, was du willst. Für andere ist es möglicherweise mehr eine Überlegung.

Sicherheit

Ich habe viele intern unterhaltene Produktionsserver gesehen, die bei Sicherheitsupdates weit hinterherhinken oder nur schlecht zusammengestellt sind. Mit Heroku haben Sie jemand anderen, der so etwas handhabt, was entweder ein Segen oder ein Fluch ist, je nachdem, wie Sie es sehen!

Bei der Bereitstellung übergeben Sie Ihren Code effektiv an Heroku. Dies könnte ein Problem für Sie sein. Ihr Artikel über Dyno-Isolierung beschreibt ihre Isolationstechnologien (es scheint, als würden mehrere Prüfpunkte auf einzelnen EC2-Instanzen ausgeführt). Mehrere Kollegen haben sich mit diesen Technologien und der Stärke ihrer Isolierung auseinandergesetzt. Ich bin leider nicht in der Lage genügend Wissen / Erfahrung zu haben, um wirklich etwas zu kommentieren, aber meine aktuellen Heroku-Einsätze halten das für "gut genug". Es kann ein Problem für dich sein, ich weiß es nicht.

Skalierung

Ich habe berührt, wie man dies in meinem obigen IaaS vs PaaS-Vergleich umsetzen könnte. In etwa hat Ihre Anwendung eine Procfile, die Linien der Form hat dyno_type: command_to_runso zum Beispiel (von http://devcenter.heroku.com/articles/process-model):

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

Dies mit:

heroku scale web:2 worker:10

wird dazu führen, dass du 2 hast web Dynos und 10 worker Dynos laufen. Nett, einfach, einfach. Beachten Sie, dass web ist ein spezieller Dyno-Typ, der Zugriff auf die Außenwelt hat und hinter seinem netten Web-Traffic-Multiplexer (wahrscheinlich eine Art von Varnish / Nginx-Kombination) steht, der den Verkehr entsprechend routet. Ihre Mitarbeiter interagieren wahrscheinlich mit einer Nachrichtenwarteschlange für ein ähnliches Routing, über das sie den Standort über eine URL in der Umgebung abrufen.

Kosteneffizienz

Viele Leute haben unterschiedliche Meinungen dazu. Gegenwärtig beträgt es 0,05 USD pro Stunde für eine Prüfstunde, verglichen mit 0,025 USD pro Stunde für eine AWS-Mikroinstanz oder 0,09 USD pro Stunde für eine kleine AWS-Instanz.

Herokus Dyno-Dokumentation sagt man hat ungefähr 512MB RAM, also ist es wahrscheinlich nicht auch unangemessen, einen Prüfstand als ein bisschen wie eine EC2-Mikroinstanz zu betrachten. Ist es den doppelten Preis wert? Wie viel schätzen Sie Ihre Zeit? Die Menge an Zeit und Aufwand, die erforderlich ist, um auf einem IaaS-Angebot aufzubauen, um dieses Niveau zu erreichen, ist definitiv nicht billig. Ich kann diese Frage nicht wirklich für Sie beantworten, aber unterschätzen Sie nicht die "versteckten Kosten" von Setup und Wartung.

(Ein bisschen daneben, aber wenn ich mich von hier aus mit einem Dyno verbinde (heroku run bash), ein kursorischer Blick zeigt 4 Kerne in /proc/cpuinfo und 36 GB RAM - das lässt mich glauben, dass ich auf einem bin "Doppel-Extra-Instanz mit hohem Speicherbedarf". Der Heroku Dyno-Dokumentation sagt jeder Dyno erhält 512 MB RAM, so dass ich potenziell mit bis zu 71 anderen Dynos teilen. (Ich habe nicht genügend Daten über die Homogenität der AWS-Instanzen von Heroku, daher kann Ihre Laufleistung variieren))

Wie gehen sie gegen ihre Konkurrenten vor?

Ich kann Ihnen leider nicht wirklich helfen. Der einzige Konkurrent, den ich je gesehen habe, war Google App Engine - Zu der Zeit, als ich nach Java-Anwendungen suchen wollte, und die Anzahl der Beschränkungen für verwendbare Frameworks und Technologien war unglaublich abschreckend. Dies ist mehr als "nur ein Java-Ding" - die Menge an allgemeinen Einschränkungen und notwendigen Überlegungen (die FAQ Hinweise auf mehrere) schien weniger als bequem. Im Gegensatz dazu war der Einsatz bei Heroku ein Traum.

Fazit

Ich hoffe, dass dies Ihre Fragen beantwortet (bitte kommentieren Sie, wenn es Lücken / andere Bereiche gibt, die Sie angesprochen haben möchten). Ich fühle, dass ich meine persönliche Position anbieten sollte. Ich liebe Heroku für "schnelle Bereitstellungen". Wenn ich eine Anwendung starte, und ich möchte ein billiges Hosting (die kostenlose Heroku-Stufe ist großartig - im Wesentlichen, wenn Sie nur einen Web-Dyno und 5 MB PostgreSQL benötigen, ist es kostenlos, eine Anwendung zu hosten), ist Heroku meine Go-to-Position . Für "Serious Production Deployment" mit mehreren zahlenden Kunden, mit einem Service-Level-Agreement, mit dedizierter Zeit für Ops und so weiter, kann ich mich nicht dazu entschließen, so viel Kontrolle auf Heroku zu übertragen, und dann entweder AWS oder Unsere eigenen Server waren die bevorzugte Hosting-Plattform.

Letztendlich geht es darum, was am besten für dich funktioniert. Du sagst, du bist "ein Anfänger-Programmierer" - es könnte nur sein, dass du mit Heroku dich darauf konzentrierst, Ruby zu schreiben, und keine Zeit damit verbringen musst, die ganze andere Infrastruktur um deinen Code aufzubauen. Ich würde es definitiv versuchen.


Beachten Sie, dass AWS tatsächlich ein PaaS-Angebot hat, Elastische Bohnenstange, die Ruby, Node.js, PHP, Python, .NET und Java unterstützt. Ich denke, dass die meisten Leute, wenn sie "AWS" sehen, zu Dingen wie EC2 und S3 und EBS springen, die definitiv IaaS-Angebote sind


1953
2018-03-21 10:57



Wie Kristian Glass Said sagte, gibt es keinen Vergleich zwischen IaaS (AWS) und PaaS (Heroku, Motoryard).

PaaS hilft Entwicklern im Grunde, die Entwicklung von Apps zu beschleunigen, wodurch sie Geld sparen und vor allem ihre Anwendungen und ihr Geschäft erneuern können, anstatt Konfigurationen einzurichten und Dinge wie Server und Datenbanken zu verwalten. Andere Funktionen, die PaaS verwenden, sind der Anwendungsimplementierungsprozess wie Agilität, hohe Verfügbarkeit, Überwachung, Skalierung / Entkalkung, begrenzter Bedarf an Fachwissen, einfache Bereitstellung sowie reduzierte Kosten und Entwicklungszeit.

Aber es gibt immer noch eine dunkle Seite von PaaS, die eine Barriere für die PaaS-Adoption darstellt:

  • Weniger Kontrolle über Server und Datenbanken
  • Die Kosten sind sehr hoch, wenn sie nicht ordnungsgemäß geregelt werden
  • Frühzeitig und zweifelhaft in der heutigen Zeit

Abgesehen von oben sollten Sie genug Fähigkeiten haben, um IaaS zu managen:

  • Hardware-Erwerb
  • Betriebssystem
  • Serversoftware
  • Serverseitige Scripting-Umgebung
  • Webserver
  • Datenbankverwaltungssystem (Mysql, Redis usw.)
  • Konfigurieren Sie den Produktionsserver
  • Tool zum Testen und Bereitstellen
  • Überwachungs-App
  • Hohe Verfügbarkeit
  • Load-Blancing / HTTP-Routing
  • Service-Backup-Richtlinien
  • Gruppenarbeit
  • Produktion neu aufbauen

Wenn Sie kleine Unternehmen haben, ist PaaS die beste Option für Sie:

  • Zahlen Sie wenn sie hinausgehen
  • Niedrige Startkosten
  • Überlassen Sie die Installation dem Fachmann
  • PaaS übernimmt die automatische Skalierung / Entzunderung, Load Balancing, Disaster Recovery
  • PaaS verwaltet alle Sicherheitsanforderungen
  • PaaS verwaltet Zuverlässigkeit, hohe Verfügbarkeit
  • Paas verwaltet viele Add-ons von Drittanbietern für Sie

Es wird völlig individuelle Wahl basierend auf der Anforderung sein. Sie können Details zu meinem PPT haben Hosting von Schienen Apps.


57
2018-02-04 07:52



Es gibt viele verschiedene Möglichkeiten, diese Entscheidung aus der Sicht der Entwicklung, der IT und der Geschäftsziele zu betrachten, also fühlen Sie sich nicht schlecht, wenn es überwältigend erscheint. Aber auch - Skalierbarkeit nicht überdenken.

Denk an dein Anforderungen.

Ich habe Websites entwickelt, die über 8 Millionen Uniques pro Tag bedient haben und terabytes Video pro Woche geliefert haben, das auf Infrastrukturen aufgebaut wurde, die bei $ 250.000 in Hardware von einem riesigen $ MM-IT-Personal begannen.

Aber ich hatte auch kleinere Websites, die entwickelt wurden, um $ 10- $ 20k pro Jahr zu generieren, hatte keine sehr hohen Datenverkehr, db oder Verarbeitungsanforderungen, und ich lief diese von einem 10 $ / mo generischen Hosting-Konto ohne Kompromisse.

In Zukunft wird die Bereitstellung mehr nach Heroku als nach AWS aussehen, nur wegen des Fortschritts. Es gibt keinen Wert im IT-Bereich - das Drehen skalierender Internet-Infrastrukturen, der nicht zunehmend automatisierbar ist und nichts mit dem Wert des Produkts oder der Dienstleistung, die Sie anbieten, zu tun hat.

Denken Sie auch an eine kommerzielle Website - Skalierbarkeit ist das, was wir oft als "gutes Problem" bezeichnen - obwohl Skalierbarkeitsprobleme mit Websites wie Facebook und Twitter sehr wichtig waren, hatten sie keinen negativen Einfluss auf ihren Erfolg - die Nachrichten könnte sogar haben beigetragen zu mehr Anmeldungen (alle drücken ist gut drücken).

Wenn Sie einen Dienst haben, der 100k + Unikate pro Tag generiert und Probleme mit der Skalierung hat, dann nehme ich Ihnen gerne die Dienste weg, egal welche Sprache, Datenbank, Plattform oder Infrastruktur Sie betreiben!

Skalierbarkeit ist ein reparierbares Implementierungsproblem - keine Kunden zu haben ist ein existenzielles Problem.


30
2018-02-16 17:31



Eigentlich kannst du beides nutzen - du kannst eine App mit Amazon-Servern ec2 entwickeln. Dann schiebe es (mit git) für eine Weile kostenlos zu Heroku (benutze Heroku free tier, um es der Öffentlichkeit zu servieren) und teste es so. Es ist sehr kosteneffektiv im Vergleich zu einem Server zu mieten, aber Sie müssen mit einer restriktiveren Heroku API sprechen, worüber Sie nachdenken sollten. Quelle: Diese Methode wurde für einen meiner Online-Kurse "Startup Engineering aus Coursera / Stanford von Balaji S. Srinivasan und Vijay S. Pande übernommen

Added a scheme so my explanation will be easier to understand


30
2018-02-17 11:30



Die vorhandenen Antworten stimmen weitgehend überein:

  • Heroku ist sehr einfach zu verwenden und zu implementieren, kann leicht für die automatische Bereitstellung eines Repository (zB GitHub) konfiguriert werden, hat viele Add-Ons von Drittanbietern und berechnet mehr pro Instanz.

  • AWS bietet eine breitere Palette von First-Party-Diensten zu wettbewerbsfähigen Preisen, einschließlich DNS, Load-Balancing, günstigen Dateispeicher und verfügt über Enterprise-Funktionen wie die Möglichkeit, Sicherheitsrichtlinien zu definieren.

Für die tl; dr Springe zum Ende dieses Posts.

AWS ElasticBeanstalk ist ein Versuch, eine Heroku-ähnliche Autoscaling- und einfache Bereitstellungsplattform bereitzustellen. Da es EC2-Instanzen verwendet (die es automatisch erstellt), können EB-Server alles tun, was auch immer eine andere EC2-Instanz tun kann, und es ist kostengünstig zu betreiben.

Deployment mit EB ist sehr langsam; Das Bereitstellen eines Updates kann 10-15 Minuten pro Server dauern, und die Bereitstellung in einem größeren Cluster kann den größten Teil einer Stunde beanspruchen - im Vergleich zu nur wenigen Sekunden, um ein Update auf Heroku bereitzustellen. Bereitstellungen auf EB werden ebenfalls nicht besonders nahtlos gehandhabt, was zu Einschränkungen beim Anwendungsdesign führen kann.

Sie können alle Dienste nutzen, die ElasticBeanstalk im Hintergrund verwendet, um Ihr eigenes maßgeschneidertes System zu erstellen (mit CodeDeploy, Elastic Load Balancer, Auto Scaling Groups - und CodeCommit, CodeBuild und CodePipeline, wenn Sie All-in gehen möchten) ein paar Wochen, die es das erste Mal einrichten, da es ziemlich kompliziert und etwas trickreich ist, als nur Dinge in EC2 zu konfigurieren.

AWS Lightsail bietet eine kostengünstige Hosting-Option, hilft aber nicht bei der Bereitstellung oder Skalierung - es ist nur ein Wrapper für das EC2-Angebot (kostet aber viel mehr). Es lässt Sie automatisch ein Bash-Skript bei der Erstinstallation ausführen, was eine nette Sache ist, aber es ist teuer im Vergleich zu den Kosten für das Einrichten einer EC2-Instanz (was Sie auch programmatisch tun können).

Einige Gedanken zum Vergleich (um die Fragen zu beantworten und zu beantworten, wenn auch auf Umwegen):

  1. Unterschätzen Sie nicht, wie viel Arbeitssystemadministration ist, einschließlich der Tatsache, dass Sie alles, was Sie installiert haben, mit Sicherheitspatches (und gelegentlichen Betriebssystemupdates) auf dem neuesten Stand halten.

  2. Unterschätzen Sie nicht, wie vorteilhaft eine automatische Bereitstellung, automatische Skalierung und SSL-Bereitstellung und -Konfiguration ist.

    Die automatische Bereitstellung beim Aktualisieren Ihres Git-Repositorys ist mit Heroku mühelos möglich. Es ist nahezu sofort und elegant, sodass Endbenutzer keine Ausfälle haben und nur dann eine Aktualisierung durchführen können, wenn die Tests / Continuous Integration erfolgreich verlaufen. Sie brechen also Ihre Site nicht, wenn Sie defekten Code implementieren.

    Sie können ElasticBeanstalk auch für die automatische Bereitstellung verwenden. Seien Sie jedoch darauf vorbereitet, eine Woche beim ersten Mal einzurichten. Möglicherweise müssen Sie die Bereitstellung und Erstellung von Assets (wie CSS und JS) ändern, um mit der Verarbeitung von Bereitstellungen oder dem Erstellen von Logik umzugehen in Ihre App, um Bereitstellungen zu verwalten.

    Seien Sie sich bewusst, dass für eine nahtlose Bereitstellung ohne Ausfall auf EB mehrere Instanzen ausgeführt werden müssen - EB führt Updates für jeden Server einzeln aus, so dass Ihr Service nicht beeinträchtigt wird - während Heroku einen neuen Prüfstand für Sie spinnt und nur noch veraltet der alte Dienst, bis alle Anforderungen an ihn erledigt sind (dann wird er gelöscht).

    Interessanterweise können die Hosting-Kosten für die Ausführung mehrerer Server mit EB günstiger sein als für eine einzelne Heroku-Instanz, insbesondere wenn Sie die Kosten für Add-Ons berücksichtigen.

Einige andere Fragen, die nicht speziell gestellt, aber von anderen Antworten aufgeworfen werden:

  1. Die Verwendung eines anderen Anbieters für Produktion und Entwicklung ist eine schlechte Idee.

    Ich erzürnte, dass die Leute dies vorschlagen. Idealerweise sollte Code auf jeder vernünftigen Plattform gut laufen, so dass er so portabel wie möglich ist. Versionen von Software auf jedem Host werden jedoch stark variieren und nur weil Code im Staging ausgeführt wird, heißt das nicht, dass er in der Produktion läuft (zB Major Node.js / Ruby / Python / PHP / Perl-Versionen können sich auf verschiedene Arten unterscheiden, die Code inkompatibel machen, oft auf stille Art und Weise, die selbst bei einer anständigen Testabdeckung nicht aufgefangen werden können.

    Eine gute Idee ist es, etwas wie Heroku für das Prototyping, kleinere Projekte und Microsites zu nutzen - so können Sie Dinge schnell erstellen und bereitstellen, ohne viel Zeit in Konfiguration und Wartung investieren zu müssen.

    Berücksichtigen Sie bei dieser Entscheidung unbedingt die Kosten für die Ausführung von Produktions- und Vorproduktionsinstanzen. Vergessen Sie dabei nicht die Kosten für die Replikation der gesamten Umgebung (einschließlich Drittanbieter-Services wie Datenspeicher / Add-ons, Installation und Konfiguration von SSL usw.). .

  2. Wenn Sie AWS verwenden, achten Sie auf vorkonfigurierte AWS-Instanzen von Anbietern wie Bitnami - sie sind ein Sicherheitsalarm. Sie können viele notorisch verwundbare Anwendungen standardmäßig aussetzen, ohne sie in der Beschreibung zu erwähnen.

    Betrachten Sie stattdessen nur eine gut unterstützte Mainstream-Distribution wie Ubuntu oder Debian (oder CentOS, wenn Sie RPM-Unterstützung benötigen).

    Hinweis: Das Amazon-Angebot hat eine eigene Distribution namens Amazon Linux, die RPM verwendet, aber es ist EC2-spezifisch und wird von Drittanbietern / Open-Source-Software weniger gut unterstützt.

  3. Sie könnten auch eine EC2-Instanz auf AWS (oder Lightsail) einrichten und mit etwas Ähnlichem konfigurieren flynn oder Dokku Darauf können Sie dann problemlos mehrere Sites bereitstellen, was sich lohnen kann, wenn Sie viele Services pflegen oder neue Dinge einfach auf den Markt bringen möchten. Die Einrichtung ist jedoch nicht so automatisch wie die Verwendung von Heroku und Sie können viel Zeit damit verbringen, sie zu konfigurieren und zu warten (bis zu dem Punkt, an dem ich die Bereitstellung mit Amazon Clustering und Docker Swarm als einfacher empfinde; YMMV).

Ich habe AWS EC-Instanzen (allein und in Clustern), Elastic Beanstalk und Lightsail und Heroku gleichzeitig verwendet, je nach den Anforderungen des Projekts, an dem ich gerade arbeite.

Ich hasse es, Zeit mit der Konfiguration von Diensten zu verbringen, aber meine Heroku-Rechnung würde Tausende pro Jahr betragen, wenn ich sie für alles verwenden würde und AWS einen Bruchteil der Kosten berechnet.

tl; dr

Wenn Geld nie ein Problem wäre, würde ich Heroku für fast alles verwenden, da es ein enormer Zeitaufwand ist - aber ich würde immer noch AWS für kompliziertere Projekte verwenden wollen, in denen ich die Flexibilität und erweiterte Dienste benötige, die Heroku nicht bietet.

Das ideale Szenario für mich wäre, wenn ElasticBeanstalk einfach mehr wie Heroku funktioniert - d. H. Mit einfacherer Konfiguration und schneller und einem besseren Bereitstellungsmechanismus.

Ein Beispiel für einen Dienst, der fast das ist jetzt.sh, die AWS tatsächlich hinter den Kulissen nutzt, aber die Bereitstellung und das Clustering so einfach macht wie auf Heroku (mit automatischem SSL, DNS, eleganten Bereitstellungen, super-einfacher Cluster-Einrichtung und -Management).

Ich habe es sowohl für die Node.js-App als auch für Docker-Image-Bereitstellungen ziemlich oft verwendet. Der größte Nachteil besteht darin, dass die Instanzen geteilt werden (was sich in niedrigeren Kosten niederschlägt) und derzeit keine Option zum Kauf dedizierter Instanzen. Ihr Open-Source-Bereitstellungstool "jetzt" kann jedoch auch für die Bereitstellung auf dedizierten Instanzen in AWS sowie Google Cloud und Azure verwendet werden.


22
2018-01-12 07:49



Nun, die Leute stellen diese Frage normalerweise: Heroku oder AWS, wenn sie mit der Bereitstellung beginnen.

Mein Experiment, sowohl Heroku als auch AWS zu verwenden, hier ist meine schnelle Überprüfung und Vergleich:

Heroku

  • Ein Befehl, um alle Projekttypen zu implementieren: Ruby on Rails, Nodejs
  • So viele 1-Klick Plugins und Drittanbieter integrieren: Es ist super einfach mit etwas zu beginnen.
  • Keine automatische Skalierung Das bedeutet, dass Sie manuell nach oben / unten skalieren müssen
  • Kosten sind teuer, insbesondere wenn das System mehr Ressourcen benötigt
  • Freie Instanz verfügbar
  • Die freie Instanz geht in den Ruhezustand, wenn sie inaktiv ist.
  • Rechenzentrum: nur USA und EU
  • KANN mit Hilfe von in / auf die Maschinenebene tauchen Heroku run bash (Danke, MJafar Mash für den Rat) aber es ist irgendwie begrenzt! Sie haben keinen vollen Zugriff!
  • Sie müssen nicht zu viel über DevOps wissen

AWS - EC2

  • Dies ist wie bei einer Maschine mit vorkonfiguriertem Betriebssystem (oder nicht), Sie müssen also Software, Bibliothek installieren, damit Ihre Website / Ihr Dienst online geht.
  • Plugin und Bibliothek müssen manuell eingebunden werden, oder Automatisierungsskript (öffentliches Skript & von Ihnen geschrieben)
  • Auto-Skalierung und Load-Balancer sind die unterstützten Dienste. Lernen Sie einfach, wie Sie Ihr System konfigurieren und in Ihr System integrieren
  • Die Kosten sind ziemlich günstig, abhängig von den Diensten und der Anzahl der Stunden, die Sie nutzen
  • Es gibt mehrere freie Stunden für T2.micro Instanzen, aber normalerweise zahlen Sie jeden Monat ein paar Dollar (wenn Sie T2.micro verwenden)
  • Ihre freie Instanz wird nicht schlafen gehen und ist rund um die Uhr verfügbar (weil Sie dafür bezahlen können :))
  • Rechenzentrum: auf der ganzen Welt. Wählen Sie die Region aus, die am besten zu Ihnen passt.
  • Tauchen Sie in die Maschinenebene ein. So können Sie es genießen
  • Etwas Wissen über DevOps, aber es ist okay, Stackoverflow ist da hilfreich!

AWS Elastische Bohnenstange eine Alternative von Heroku, aber billiger

  • Elastic Beanstalk wurde ab 2010 als öffentliche Beta angekündigt; Es erleichtert uns die Arbeit mit der Bereitstellung. Für Details gehen Sie bitte Hier

  • Bohnenstange ist kostenlos, die Kosten, die Sie zahlen, werden für die von Ihnen genutzten Dienstleistungen und die Anzahl der Stunden der Nutzung sein.

  • Ich benutze Elastic Beanstalk für eine lange Zeit, und ich denke, es kann der Ersatz von Heroku und billiger sein!

Zusammenfassung

  • Heroku: Einfach am Anfang, FREI Beispiel, aber teuer später
  • AWS: Nicht einfach, freie Stunden verfügbar, irgendwie billiger, Bohnenstange sollte besorgt sein zu verwenden

In meinem derzeitigen System verwende ich Heroku für die Inszenierung und Beanstalk für die Produktion!


20
2018-05-23 10:36