Dlaczego ludzie używają Heroku, gdy AWS jest obecny? Co odróżnia Heroku od AWS? [Zamknięte]

1101

Jestem początkującym programistą RoR, który planuje wdrożyć moją aplikację za pomocą Heroku. Wiadomość od moich innych doradców mówi, że Heroku jest naprawdę łatwy, dobry w użyciu. Jedynym problemem jest to, że wciąż nie mam pojęcia, co robi Heroku ...

Spojrzałem na ich stronę internetową i w skrócie: Heroku pomaga w skalowaniu, ale ... dlaczego to w ogóle ma znaczenie? W jaki sposób Heroku pomaga w:

  1. Szybkość - moje badania sugerowały, że wdrożenie AWS na wschodnim wybrzeżu USA byłoby najszybsze, jeśli kieruję reklamy do odbiorców z USA / Azji.

  2. Bezpieczeństwo - jak bezpieczne są?

  3. Skalowanie - jak to naprawdę działa?

  4. Efektywność kosztowa - istnieje coś takiego jak hamownia, która ułatwia skalowanie.

  5. Jak radzą sobie w porównaniu z konkurencją? Na przykład Engine Yard i bluebox ?

Aby wyjaśnić, proszę użyć laickich angielskich terminów ... Jestem początkującym programistą.

Bryan
źródło
267
Właściwie korzystam z niego z powodu bezpłatnego planu;).
wesele
56
Powinieneś był zapytać, jaka jest różnica między elastyczną łodygą fasoli Heroku i AWS. W przeciwnym razie otrzymasz zwykłe odpowiedzi „PaaS vs IaaS”, a nie to, czego prawdopodobnie szukasz.
Jus12
38
rozwijaj się na heroku, skaluj na heroku, wprowadzaj innowacje na heroku ... wtedy gdy pomysł stanie się hitem biznesowym, następnie przenieś się na aws ... na przykład, kiedy zatrudniasz.
Muhammad Umer
10
Migracja może być trudna, jeśli korzystasz z kilku usług i musisz przetransportować, skonfigurować, przetestować wszystko ... To na pewno będzie kosztować
Paolo
37
Jedną z moich ulubionych rzeczy w Heroku jest automatyczne wdrażanie z Github, więc mogę mieć productiongałąź na moim repozytorium. Za każdym razem, gdy nowe zatwierdzenie jest wypychane do tego repozytorium, Heroku automatycznie chwyta je, buduje i wdraża. Nie muszę się w ogóle martwić o nic po stronie serwera!
Razi Shaban

Odpowiedzi:

245

AWS / Heroku są bezpłatne dla małych projektów hobbystycznych (na początek).

Jeśli chcesz od razu uruchomić aplikację, bez większego dostosowywania architektury, wybierz Heroku .

Jeśli chcesz skupić się na architekturze i móc korzystać z różnych serwerów WWW, wybierz AWS . AWS jest bardziej czasochłonne w zależności od wybranej usługi / produktu, ale może być tego warte. AWS oferuje również wiele usług i produktów wtyczek.


Heroku

  • Platform as a Service (PAAS)
  • Dobra dokumentacja
  • Ma wbudowane narzędzia i architekturę.
  • Ograniczona kontrola architektury podczas projektowania aplikacji.
  • Zajmuje się wdrażaniem (automatycznie przez GitHub lub ręcznie za pomocą poleceń git lub CLI).
  • Nie czasochłonne.

AWS

  • Infrastruktura jako usługa (IAAS)
  • Wszechstronny - posiada wiele produktów, takich jak EC2, LAMBDA, EMR itp.
  • Można użyć wystąpienia dedykowanego w celu uzyskania większej kontroli nad architekturą, na przykład wyboru systemu operacyjnego, wersji oprogramowania itp. Istnieje więcej niż jedna warstwa zaplecza.
  • Elastic Beanstalk to funkcja podobna do PAAS Heroku.
  • Może korzystać z automatycznego wdrażania lub utworzyć własne.
SuperNova
źródło
7
ElasticBeanstalk jest znacznie bardziej opłacalny niż Heroku, ponieważ nie ma znaczników dla usługi poza serwerami, z których korzystasz. Można również użyć ElasticBeanstalk z AWS darmo tier aws.amazon.com/elasticbeanstalk/pricing
zags
25
@Zags „opłacalne” to kwestia opinii. Jeśli mogę stworzyć i wdrożyć aplikację Heroku w mniej niż minutę, a konfiguracja Beanstalk zajmuje potencjalnie wiele godzin - nie jest to opłacalne, biorąc pod uwagę, że kilka godzin czasu programisty niszczy wszelkie „oszczędności”, które można uzyskać z Beanstalk. To naprawdę zależy od priorytetów - czy funkcje wysyłkowe są ważniejsze, czy też ważniejsza jest konfiguracja i utrzymanie infrastruktury?
Brian Drogi
5
@BrianDear łatwość konfiguracji zależy od Twojej znajomości różnych systemów. Nawet jeśli ElasticBeanstalk zajmuje więcej czasu, biorąc pod uwagę jednakową znajomość, AWS zazwyczaj kosztuje 60% kosztu Heroku (porównaj wydajność Heruku-m do AWS m4.xlarge). Z rachunkiem za serwer wynoszącym zaledwie 100 USD miesięcznie, 40% oszczędności pozwoli odzyskać koszt „kilku godzin inżynierii” w ciągu roku. Im wyższy rachunek za serwer, tym silniejszy argument za AWS.
Zags,
4
Wdrożenie na Beanstalk zajmuje ~ 5 minut. Wybierz platformę -> Prześlij zip -> Raduj się. Chcesz wdrożyć, pchając do opanowania? Poświęć kolejne 5 minut na skonfigurowanie CodePipeline. Oba te przepływy pracy można wykonać przy użyciu tylko konsoli GUI, jeśli CLI jest dla ciebie zastraszający.
Anthony Manning-Franklin
1
Niestety dokumentacja nie jest wymieniona w AWS. AWS ma jedną z najlepszych dokumentacji dowolnej technologii / platformy. Użyłem go jeszcze przed opublikowaniem tej odpowiedzi, około 2013 r.
lupchiazoem
2055

Po pierwsze, AWS i Heroku to różne rzeczy. AWS oferuje infrastrukturę jako usługę ( IaaS ), podczas gdy Heroku oferuje platformę jako usługę ( PaaS ).

Co za różnica? W przybliżeniu IaaS zapewnia komponenty potrzebne do zbudowania czegoś na nim; PaaS zapewnia środowisko, w którym po prostu wypychasz kod oraz podstawową konfigurację i dostajesz działającą aplikację. IaaS może dać ci więcej mocy i elastyczności, kosztem konieczności samodzielnego budowania i utrzymywania.

Aby twój kod działał w AWS i wyglądał trochę jak wdrożenie Heroku, będziesz potrzebować niektórych instancji EC2 - będziesz chciał zainstalować na nich moduł równoważenia obciążenia / buforowania (np. Varnish ), będziesz chciał instancji uruchamiających coś w rodzaju Passenger i nginx do obsługi kodu, będziesz chciał wdrożyć i skonfigurować klastrową instancję bazy danych czegoś takiego jak PostgreSQL . Będziesz potrzebował systemu wdrażania z czymś takim jak Capistrano i czymś gromadzącym logi.

To nie jest niewielka ilość pracy do skonfigurowania i utrzymania. W Heroku wysiłek, aby przejść do tego rodzaju etapu, to może kilka linii kodu aplikacji i git push.

Więc jesteś tak daleko i chcesz zwiększyć skalę. Świetny. Używasz Puppet do wdrożenia EC2, prawda? Tak więc teraz konfigurujesz pliki Capistrano, aby odpowiednio zwiększać / zmniejszać instancje; ponownie konfigurujesz konfigurację Puppet, aby Varnish wiedział o instancjach web-workera i automatycznie gromadził między nimi pule. Albo ty heroku scale web:+5.

Mam nadzieję, że daje to wyobrażenie o porównaniu obu. Teraz, aby zająć się swoimi konkretnymi punktami:

Prędkość

Obecnie Heroku działa tylko na instancjach AWS w us-easti eu-west. Dla ciebie to i tak brzmi jak chcesz. Dla innych jest to potencjalnie więcej uwagi.

Bezpieczeństwo

Widziałem wiele wewnętrznie utrzymywanych serwerów produkcyjnych, które są daleko w tyle w przypadku aktualizacji zabezpieczeń lub po prostu ogólnie źle połączone. Dzięki Heroku masz kogoś innego zarządzającego tego rodzaju rzeczami, które są albo błogosławieństwem, albo przekleństwem, w zależności od tego, jak na to patrzysz!

Podczas wdrażania skutecznie przekazujesz swój kod bezpośrednio Heroku. To może być dla ciebie problem. W artykule na temat izolacji dyno wyszczególniono ich technologie izolacji (wygląda na to, że na poszczególnych instancjach EC2 działa wiele dyn). Kilku kolegów wyraziło problemy z tymi technologiami i siłą ich izolacji; Niestety nie mam wystarczającej wiedzy / doświadczenia, aby naprawdę komentować, ale moje obecne wdrożenia Heroku uważają to za „wystarczająco dobre”. To może być dla ciebie problem, nie wiem.

skalowanie

Dotknąłem powyższego sposobu, w jaki można to zaimplementować w moim porównaniu IaaS vs PaaS. W przybliżeniu twoja aplikacja ma linię Procfile, która ma wiersze formularza dyno_type: command_to_run, więc na przykład (cribbed from http://devcenter.heroku.com/articles/process-model ):

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

To z:

heroku scale web:2 worker:10

spowoduje, że uruchomisz 2 webdynos i 10 workerdynos. Miło, prosto, łatwo. Zauważ, że webjest to specjalny typ hamowni, który ma dostęp do świata zewnętrznego, i stoi za ładnym multiplekserem ruchu sieciowego (prawdopodobnie jakąś kombinacją Varnish / nginx), który odpowiednio kieruje ruchem. Twoi pracownicy prawdopodobnie wchodzą w interakcję z kolejką komunikatów dla podobnego routingu, z której uzyskają lokalizację za pośrednictwem adresu URL w środowisku.

Efektywność kosztowa

Wiele osób ma na ten temat wiele różnych opinii. Obecnie jest to 0,05 USD / godz. Za godzinę dynamiki, w porównaniu do 0,025 USD / godz. W przypadku mikro instancji AWS lub 0,09 USD / godz. W przypadku małej instancji AWS.

Heroku za dokumentację dyno mówi trzeba około 512 MB pamięci RAM, więc to chyba nie zbyt nierozsądne rozważyć dyno jak trochę jak instancji EC2 mikro. Czy warto podwoić cenę? Ile cenisz swój czas? Ilość czasu i wysiłku potrzebnego do zbudowania oferty IaaS w celu dostosowania jej do tego standardu zdecydowanie nie jest tania. Naprawdę nie mogę odpowiedzieć na to pytanie, ale nie lekceważ „ukrytych kosztów” konfiguracji i konserwacji.

(Trochę na bok, ale jeśli podłączę się tutaj do hamowni ( heroku run bash), pobieżny wygląd pokazuje 4 rdzenie /proc/cpuinfoi 36 GB pamięci RAM - to prowadzi mnie do przekonania, że ​​jestem w „Bardzo dużej instancji podwójnie dużej pamięci” " . Dokumentacja dyno Heroku mówi, że każda hamownia otrzymuje 512 MB pamięci RAM, więc potencjalnie udostępniam maksymalnie 71 innym dynom. (Nie mam wystarczających danych na temat homogeniczności instancji AWS Heroku, więc twój przebieg może się różnić))

Jak radzą sobie w porównaniu z konkurencją?

Obawiam się, że nie mogę ci pomóc. Jedynym konkurentem, na jakiego naprawdę patrzyłem, był Google App Engine - w tamtym czasie chciałem wdrożyć aplikacje Java, a ilość ograniczeń dotyczących użytecznych platform i technologii była niesamowicie odrażająca. To coś więcej niż „tylko Java” - ilość ogólnych ograniczeń i niezbędnych uwag ( kilka wskazówek FAQ ) wydawała się mniej niż wygodna. Natomiast wdrożenie w Heroku było snem.

Wniosek

Mam nadzieję, że to odpowiada na twoje pytania (proszę o komentarz, jeśli są luki / inne obszary, które chciałbyś rozwiązać). Czuję, że powinienem zaoferować swoje osobiste stanowisko. Uwielbiam Heroku za „szybkie wdrażanie”. Kiedy uruchamiam aplikację i chcę taniego hostingu (darmowa warstwa Heroku jest niesamowita - w zasadzie, jeśli potrzebujesz tylko jednej dynamiki internetowej i 5 MB PostgreSQL, możesz bezpłatnie hostować aplikację), Heroku jest moją pozycją do przejścia . W przypadku „Serious Production Deployment” z kilkoma płatnymi klientami, z umową dotyczącą poziomu usług, ze specjalnym czasem na wydatki na operacje, itd., Nie mogę się zmusić do przeniesienia tak dużej kontroli na Heroku, a potem AWS lub nasze własne serwery były wybraną platformą hostingową.

Ostatecznie chodzi o to, co działa najlepiej dla Ciebie. Mówisz, że jesteś „początkującym programistą” - być może po prostu używanie Heroku pozwoli ci skoncentrować się na pisaniu w języku Ruby i nie będziesz musiał spędzać czasu na budowaniu całej infrastruktury wokół kodu. Zdecydowanie spróbuję.


Uwaga: AWS ma w rzeczywistości ofertę PaaS, Elastic Beanstalk , która obsługuje Ruby, Node.js, PHP, Python, .NET i Java. Myślę, że generalnie większość ludzi, widząc „AWS”, przeskakuje do takich rzeczy jak EC2, S3 i EBS, które są zdecydowanie ofertami IaaS

Kristian Glass
źródło
33
Pamiętaj, że teraz elastyczna łodyga fasoli w pełni obsługuje aplikacje ruby ​​za pasażerem.
przepisany
4
Heroku obsługuje teraz także serwery w UE, nie tylko w regionie USA.
Thomas Welton
7
Biorąc pod uwagę AWS BeanStalk, czy cała dyskusja na temat tego, jak Heroku jest rozwiązaniem PaaS, podczas gdy AWS jest „tylko” ofertą IaaS, jest nieważna?
Gmu
6
@KristianGlass Byłoby wspaniale, gdybyśmy mogli uzyskać zaktualizowaną odpowiedź, która naprawdę patrzy na dwie oferty PaaS (Beanstalk i Heroku)
Alex Chumbley
3
Cieszę się, że przydało się to ludziom :) @Gmu W momencie udzielania odpowiedzi EB był wystarczająco ograniczony, aby założenie, że „AWS” oznacza „EC2”, wydawało się całkiem rozsądne, ale jak sugeruje Alex, przyjrzę się teraz odpowiedzi znacznie się poprawił.
Kristian Glass
68

Jak powiedział Kristian Glass, nie ma porównania między IaaS ( AWS ) i PaaS ( Heroku , EngineYard ).

PaaS zasadniczo pomaga programistom przyspieszyć tworzenie aplikacji, oszczędzając w ten sposób pieniądze i, co najważniejsze, wprowadzając innowacje do aplikacji i firm, zamiast konfigurować konfiguracje i zarządzać takimi rzeczami, jak serwery i bazy danych. Inne funkcje zakupu PaaS to proces wdrażania aplikacji, taki jak zwinność, wysoka dostępność, monitorowanie, skalowanie / odkamienianie, ograniczone zapotrzebowanie na wiedzę specjalistyczną, łatwe wdrożenie oraz obniżony koszt i czas programowania.

Ale nadal istnieje ciemna strona PaaS, która prowadzi barierę dla przyjęcia PaaS:

  • Mniej kontroli nad serwerem i bazami danych
  • Koszty będą bardzo wysokie, jeśli nie będą właściwie regulowane
  • Przedwczesne i wątpliwe w obecnym dniu i wieku

Oprócz powyższego powinieneś mieć wystarczającą liczbę umiejętności, aby poradzić sobie z IaaS:

  • Nabycie sprzętu
  • System operacyjny
  • Oprogramowanie serwera
  • Środowisko skryptów po stronie serwera
  • serwer internetowy
  • System zarządzania bazą danych (Mysql, Redis itp.)
  • Skonfiguruj serwer produkcyjny
  • Narzędzie do testowania i wdrażania
  • Aplikacja do monitorowania
  • Duża dostępność
  • Ładowanie Blending / HTTP Routing
  • Zasady tworzenia kopii zapasowych usług
  • Praca drużynowa
  • Odbuduj produkcję

Jeśli prowadzisz małą firmę, PaaS będzie dla Ciebie najlepszą opcją:

  • Pay as you Go
  • Niski koszt uruchomienia
  • Pozostaw instalację wodno-kanalizacyjną ekspertowi
  • PaaS obsługuje automatyczne skalowanie / odkamienianie, równoważenie obciążenia, odzyskiwanie po awarii
  • PaaS zarządza wszystkimi wymogami bezpieczeństwa
  • PaaS zarządza niezawodnością, wysoką dostępnością
  • Paas zarządza wieloma dodatkami stron trzecich

Będzie to całkowicie indywidualny wybór na podstawie wymagań. Możesz mieć szczegółowe informacje na temat moich aplikacji PPT Hosting Rails .

Pravin Mishra
źródło
3
Widzę EngineYard i Heroku, i oczywiście ElasticBeanstalk ... wszystkie działają na AWS pod spodem. W rzeczywistości, czy są jakieś główne PaaS, które NIE działają na aws pod spodem? Jakieś pomysły? Na zdrowie
Fattie
5
Joe, wiem, że jest późno, ale aby odpowiedzieć na twoje pytanie, IBM Bluemix działa na SoftLayer.
Antonio Cangiano,
PaaS zarządza wszystkimi wymogami bezpieczeństwa Być może zabezpieczenie serwera, ale bardzo mylące (szczególnie w świecie, w którym programiści domyślają się, że ich system jest domyślnie bezpieczny). Z pewnością nie ochroni cię przed XSS, CSRF i prawdopodobnie nie ustawi dla ciebie żadnych ważnych nagłówków HTTP. Już widzę to teraz: Thank you for your concerns. We assure you that we take security very seriously and run or systems on secure servers. There is no need to worry about [insert security issue here] as all that is handled by.... -1, ale odwróciłbym to, jeśli był odpowiednio edytowany.
Nateowami,
4
Coraz częściej pojawia się kategoria rozwiązań PaaS (DIY PaaS), które działają na Twojej infrastrukturze, rozwiązując niektóre problemy związane z elastycznością / kontrolą PaaS. Kilka przykładów: openshift , cloudfoundry , Hasura . Uwaga: Pracuję w Hasura.
iamnat
35

Właściwie możesz używać obu - możesz opracować aplikację na serwerach Amazon Amazon ec2. Następnie popchnij go (za pomocą git) do heroku za darmo na jakiś czas (użyj darmowego poziomu heroku, aby podać go publicznie) i przetestuj w ten sposób. Wynajęcie serwera jest bardzo opłacalne, ale będziesz musiał porozmawiać z bardziej restrykcyjnym interfejsem heroku, o czym powinieneś pomyśleć. Źródło: ta metoda została przyjęta dla jednej z moich klas internetowych „Inżynieria uruchamiania z Coursera / Stanford” przez Balaji S. Srinivasan i Vijay S. Pande

Dodano schemat, aby moje wyjaśnienie było łatwiejsze do zrozumienia

sivi
źródło
15
Jaka jest korzyść z używania mikroinstancji jako maszyny programistycznej zamiast korzystania z komputera lokalnego? Nie widzę dodatkowej korzyści z dodania AWS w tym konkretnym przypadku. Dzięki!
Mateo
5
prawdopodobnie dlatego, że w środowisku akademickim sprawi, że instrukcje konfigurowania środowiska programistycznego będą bardziej spójne i nie będą musieli martwić się o to, aby działało w systemie Windows
Jeff Dickey
2
Taka architektura pomaga uniknąć wielu niezgodności systemu operacyjnego Windows / Linux. Naucz się także systemu operacyjnego Linux bez konieczności instalowania go na komputerze lokalnym. Jeśli masz komputer Mac, jest to mniejszy problem, ale wiele osób korzysta z systemu Windows.
sivi
13
To się nazywa maszyna wirtualna, wciąż nie widzę sensu w tym.
Abe Petrillo
2
Posiadanie osobnej platformy do inscenizacji i produkcji to bardzo okropny pomysł; główne wersje oprogramowania będą się różnić w niekompatybilny sposób. Powinieneś być w stanie uruchomić kod lokalnie w celu programowania, nawet jeśli natywny system operacyjny różni się od produkcyjnego systemu operacyjnego (w najgorszym przypadku z czymś takim jak VMware lub włóczęga lub z emulatorem, jeśli budujesz na platformę osadzoną; ale natywnie jest ogólnie łatwiejsza do pracy z). Tylko zdalne wdrażanie kodu w chmurze jest straszną przeszkodą w szybkim rozwoju aplikacji, co sprawia, że ​​testowanie i debugowanie jest niepotrzebnie czasochłonne.
Iain Collins
34

Istnieje wiele różnych sposobów patrzenia na tę decyzję od celów programistycznych, informatycznych i biznesowych, więc nie przejmuj się, jeśli wydaje się przytłaczająca. Ale także - nie przemyśl skalowalności.

Pomyśl o swoich wymaganiach .

Zaprojektowałem strony internetowe, które obsługiwały ponad 8 milionów unikatów dziennie i co tydzień dostarczały terabajty wideo zbudowane na infrastrukturze od 250 tys.

Ale miałem też mniejsze strony internetowe, które zostały zaprojektowane do generowania 10–20 tys. USD rocznie, nie wymagały bardzo dużego ruchu, db ani wymagań dotyczących przetwarzania, i bez kompromisu uruchomiłem ogólne konto hostingowe o wartości 10 USD / mc.

W przyszłości wdrożenie będzie wyglądać bardziej jak Heroku niż AWS, tylko z powodu postępu. Przekręcanie pokrętłami IT skalowania infrastruktur internetowych ma zerową wartość, co nie jest coraz bardziej zautomatyzowane i żadna z nich nie ma nic wspólnego z wartością oferowanego produktu lub usługi.

Pamiętaj też o komercyjnej witrynie - skalowalność często nazywamy „dobrym problemem” - chociaż problemy ze skalowalnością w witrynach takich jak Facebook i Twitter były bardzo głośne, nie miały negatywnego wpływu na ich sukces - wiadomości mógł nawet przyczynić się do większej liczby rejestracji (cała prasa to dobra prasa).

Jeśli masz usługę, która generuje ponad 100 000 unikatów dziennie i masz problemy ze skalowaniem, chętnie wezmę ją za Ciebie bez względu na język, db, platformę lub infrastrukturę, na której pracujesz!

Skalowalność jest możliwym do naprawienia problemem implementacyjnym - brak klientów to problem egzystencjalny.

BricoleurDev
źródło
28

Cóż, ludzie zwykle zadają to pytanie: Heroku lub AWS, kiedy zaczynają coś wdrażać.

Mój eksperyment z użyciem obu Heroku i AWS, oto moja szybka recenzja i porównanie:

Heroku

  • Jedno polecenie, aby wdrożyć niezależnie od typu projektu: Ruby on Rails, Nodejs
  • Tak wiele 1-kliknięcia, aby zintegrować wtyczki i strony trzecie: bardzo łatwo zacząć od czegoś.
  • Nie używaj automatycznego skalowania; oznacza to, że musisz ręcznie skalować w górę / w dół
  • Koszt jest drogi, szczególnie gdy system potrzebuje więcej zasobów
  • Bezpłatna instancja dostępna
  • Darmowa instancja przechodzi w tryb uśpienia, jeśli jest nieaktywna.
  • Centrum danych: tylko USA i UE
  • MOŻNA zanurzyć się w poziomie / uzyskać dostęp do poziomu maszyny za pomocą Heroku run bash(Dzięki, MJafar Mash za radę), ale jest to trochę ograniczone! Nie masz pełnego dostępu!
  • Nie musisz wiedzieć zbyt dużo o DevOps

AWS - EC2

  • To tak jak maszyna z systemem operacyjnym przed konfiguracją (lub nie), więc musisz zainstalować oprogramowanie, bibliotekę, aby twoja strona internetowa / usługa przełączyły się w tryb online.
  • Wtyczka i biblioteka muszą być zintegrowane ręcznie lub skrypt automatyzacji (skrypt publiczny i napisany przez ciebie)
  • Automatyczne skalowanie i moduł równoważenia obciążenia to obsługiwane usługi. Dowiedz się, jak skonfigurować i zintegrować system
  • Koszt jest dość tani, zależy od tego, z jakich usług i liczby godzin korzystasz
  • Istnieje kilka bezpłatnych godzin dla instancji T2.micro, ale zwykle płacisz kilka dolarów co miesiąc (jeśli nadal używasz T2.micro)
  • Twoja darmowa instancja nie pójdzie spać, dostępna 24/7 (bo możesz za nią zapłacić :))
  • Centrum danych: na całym świecie. Wybierz region, który najbardziej Ci odpowiada.
  • Zanurz się na poziomie maszyny. Możesz się tym cieszyć
  • Trochę wiedzy na temat DevOps, ale jest w porządku, Stackoverflow jest tam pomocny!

AWS Elastyczna fasola stanowi alternatywę dla Heroku, ale jest tańsza

  • Elastic Beanstalk został ogłoszony jako publiczna beta od 2010 roku; pomaga nam łatwiej pracować z wdrożeniem. Aby uzyskać szczegółowe informacje, proszę przejść tutaj

  • Beanstalk jest bezpłatny, koszt, który zapłacisz, będzie związany z usługami, z których korzystasz i liczbą godzin użytkowania.

  • Używam Elastic Beanstalk od dłuższego czasu i myślę, że może to być zastąpienie Heroku i tańsze!

Podsumowanie

  • Heroku: łatwe na początku, BEZPŁATNA instancja, ale później droga
  • AWS: Niełatwe, dostępne wolne godziny, trochę tańsze , Beanstalk powinien być zaniepokojony w użyciu

Więc w moim obecnym systemie używam Heroku do inscenizacji i Beanstalk do produkcji!

Hieu Pham
źródło
3
Podoba mi się sposób, w jaki odpowiadasz na pytanie. Próbowałem Heroku i AWS. Zgadzam się z tobą, aby zalecić:Use Heroku for staging, and Beanstalk for production!
Chetabahana
1
heroku run bashi masz dostęp do swojej hamowni
Mohammad Jafar Mashhadi
Czy możesz podać jakieś oszacowanie cen? Będę musiał opublikować Java Web App na Tomcat (Spring Framework, angularJS itp.), pomyślmy o 1000 użytkowników miesięcznie, z których każdy używa aplikacji przez 5 minut. Jaka jest szacunkowa cena? (jak bardzo niskie zużycie, ale dostępność przez cały miesiąc)
brzytwa
1
@razor, jeśli używasz mikro instancji t2 (dobre dla preprodukcji lub małego projektu), cena jest tak niska, że ​​wynosi około 5 $ do 10 $ miesięcznie, jak moja pamięć w poprzednim projekcie. Szczegóły tutaj aws.amazon.com/ec2/pricing
Hieu Pham
a Heroku będzie znacznie droższe? (2 razy?) Z podobnym użyciem? znam strony z cenami, ale ciężko jest obliczyć / wyobrazić sobie, ile mocy procesora zajmie taka prosta aplikacja lub jakie będzie zużycie DB po miesiącach (DB będzie dość grzeczny)
razor
27

Istniejące odpowiedzi są zasadniczo dokładne:

  • Heroku jest bardzo łatwy w użyciu i wdrażaniu, może być łatwo skonfigurowany do automatycznego wdrażania repozytorium (np. GitHub), ma wiele dodatków innych firm i pobiera więcej opłat za instancję.

  • AWS oferuje szerszy zakres konkurencyjnych cenowo usług własnych, w tym DNS, równoważenie obciążenia, tanie przechowywanie plików oraz funkcje korporacyjne, takie jak możliwość definiowania zasad bezpieczeństwa.

Dla tl; dr przejdź do końca tego postu.

AWS ElasticBeanstalk to próba zapewnienia podobnej do Heroku autokalibracji i łatwej platformy do wdrażania. Ponieważ korzysta z instancji EC2 (które tworzy automatycznie), serwery EB mogą zrobić wszystko, co może zrobić każda inna instancja EC2, a jej uruchomienie jest tanie.

Wdrożenie za pomocą EB przebiega bardzo wolno; wdrożenie aktualizacji może potrwać 10–15 minut na serwer, a wdrożenie w większym klastrze może zająć najlepszą część godziny - w porównaniu do zaledwie kilku sekund na wdrożenie aktualizacji w Heroku. Wdrożenia na EB również nie są obsługiwane wyjątkowo płynnie, co może nakładać ograniczenia na projektowanie aplikacji.

Możesz użyć wszystkich usług, z których korzysta ElasticBeanstalk, aby zbudować własny system na zamówienie (z CodeDeploy, Elastic Load Balancer, Auto Scaling Groups - i CodeCommit, CodeBuild i CodePipeline, jeśli chcesz wejść wszystko), ale na pewno możesz wydać dobry kilka tygodni konfigurowanie go po raz pierwszy, ponieważ jest dość skomplikowane i nieco bardziej skomplikowane niż tylko konfiguracja w EC2.

AWS Lightsail oferuje opcję hostingu po konkurencyjnych cenach, ale nie pomaga we wdrożeniu ani skalowaniu - to naprawdę tylko opakowanie dla ich oferty EC2 (ale kosztuje znacznie więcej). Pozwala na automatyczne uruchomienie skryptu bash przy początkowej konfiguracji, co jest miłym akcentem, ale jest drogie w porównaniu z kosztem samej konfiguracji instancji EC2 (co można również zrobić programowo).

Kilka przemyśleń na temat porównywania (aby spróbować odpowiedzieć na pytania, choć w sposób okrężny):

  1. Nie lekceważ, ile kosztuje administracja systemem pracy, w tym aktualizowanie wszystkiego, co zainstalowałeś, z poprawkami bezpieczeństwa (i okazjonalnymi aktualizacjami systemu operacyjnego).

  2. Nie należy lekceważyć korzyści wynikających z automatycznego wdrażania, automatycznego skalowania oraz udostępniania i konfiguracji SSL.

    Automatyczne wdrażanie po aktualizacji repozytorium Git jest łatwe dzięki Heroku. Jest prawie natychmiastowy, bezproblemowy, więc nie ma żadnych przestojów dla użytkowników końcowych i można go ustawić na aktualizację tylko wtedy, gdy testy / Ciągła integracja przejdzie, aby nie uszkodzić witryny, jeśli wdrożysz uszkodzony kod.

    Możesz także użyć ElasticBeanstalk do automatycznego wdrażania, ale bądź przygotowany na spędzenie tygodnia przy pierwszej konfiguracji - być może będziesz musiał zmienić sposób wdrażania i budowania zasobów (takich jak CSS i JS), aby pracować z tym, jak ElasticBeanstalk obsługuje wdrożenia lub logikę kompilacji w Twojej aplikacji do obsługi wdrożeń.

    Szacując koszty, musisz wiedzieć, że w celu bezproblemowego wdrożenia bez przestoju na EB musisz uruchomić wiele instancji - EB wdraża aktualizacje dla każdego serwera indywidualnie, aby Twoja usługa nie uległa pogorszeniu - gdy Heroku uruchamia dla ciebie nową dynamikę i po prostu przestaje działać stara usługa do momentu przetworzenia wszystkich żądań do niej (następnie zostanie usunięta).

    Co ciekawe, koszt hostingu wielu serwerów z EB może być tańszy niż pojedyncza instancja Heroku, zwłaszcza po uwzględnieniu kosztów dodatków.

Niektóre inne kwestie, o które nie pytano konkretnie, ale poruszono je w innych odpowiedziach:

  1. Użycie innego dostawcy do produkcji i rozwoju to zły pomysł.

    Kulę się, że ludzie to sugerują. Podczas gdy idealnie kod powinien działać poprawnie na każdej rozsądnej platformie, aby był jak najbardziej przenośny, wersje oprogramowania na każdym hoście będą się znacznie różnić, a sam fakt, że kod działa w fazie przejściowej, nie oznacza, że ​​będzie działał w środowisku produkcyjnym (np. Główny Node.js / Wersje Ruby / Python / PHP / Perl mogą się różnić w sposób, który powoduje niezgodność kodu, często w cichy sposób, który może nie zostać złapany, nawet jeśli masz przyzwoity zasięg testu).

    Dobrym pomysłem jest wykorzystanie czegoś takiego jak Heroku do prototypowania, mniejszych projektów i mikrostron - abyś mógł szybko budować i wdrażać rzeczy bez inwestowania dużej ilości czasu w konfigurację i konserwację.

    Podejmując decyzję, pamiętaj o uwzględnieniu kosztów uruchamiania instancji produkcyjnych i przedprodukcyjnych, nie zapominając o kosztach replikacji całego środowiska (w tym usług stron trzecich, takich jak magazyny danych / dodatki, instalacja i konfiguracja SSL itp.) .

  2. Jeśli używasz AWS, uważaj na wstępnie skonfigurowane wystąpienia AWS od dostawców takich jak Bitnami - są koszmarem bezpieczeństwa. Domyślnie mogą ujawniać wiele aplikacji, które są szczególnie narażone na atak, nie wspominając o tym w opisie.

    Rozważ zamiast tego skorzystanie z dobrze obsługiwanej dystrybucji głównego nurtu, takiej jak Ubuntu lub Debian (lub CentOS, jeśli potrzebujesz wsparcia RPM).

    Uwaga: oferta Amazon ma własną dystrybucję o nazwie Amazon Linux, która wykorzystuje RPM, ale jest specyficzna dla EC2 i gorzej obsługiwana przez oprogramowanie innych firm / oprogramowanie open source.

  3. Można też skonfigurować instancji EC2 na AWS (lub Lightsail) i skonfiguruj z czymś Flynn lub Dokku na nim - na który można następnie wdrożyć wiele witryn łatwo, co może być warto jeśli utrzymują wiele usług lub chcą być w stanie łatwo odkryć nowe rzeczy. Jednak skonfigurowanie go nie jest tak automagiczne jak samo używanie Heroku i możesz w końcu poświęcić dużo czasu na konfigurowanie i utrzymanie go (do tego stopnia, że ​​wdrażanie za pomocą klastrowania Amazon i Docker Swarm jest łatwiejsze niż konfigurowanie; YMMV).

Korzystałem z instancji AWS EC (samodzielnie i w klastrach), Elastic Beanstalk oraz Lightsail i Heroku jednocześnie, w zależności od potrzeb projektu, nad którym pracuję.

Nienawidzę spędzać czasu na konfigurowaniu usług, ale mój rachunek Heroku wynosiłby tysiące rocznie, gdybym używał go do wszystkiego, a AWS oblicza ułamek kosztów.

tl; dr

Jeśli pieniądze nigdy nie były problemem, używałbym Heroku do prawie wszystkiego, ponieważ to ogromna oszczędność czasu - ale nadal chciałbym używać AWS do bardziej skomplikowanych projektów, w których potrzebuję elastyczności i bardziej zaawansowanych usług, których Heroku nie oferuje.

Idealny scenariusz byłby dla mnie, gdyby ElasticBeanstalk działał bardziej jak Heroku - tj. Z łatwiejszą konfiguracją, szybszym i lepszym mechanizmem wdrażania.

Przykładem usługi, która jest prawie taka, jest teraz.sh , która faktycznie używa AWS za kulisami, ale sprawia, że ​​wdrażanie i klastrowanie jest tak proste, jak na Heroku (z automatycznym SSL, DNS, wdzięcznymi wdrożeniami, superłatwą konfiguracją klastra i zarządzanie).

Użyłem go dość często zarówno dla aplikacji Node.js, jak i wdrożeń obrazów Docker, głównym zastrzeżeniem jest to, że instancje są współużytkowane (co znajduje odzwierciedlenie w ich niższym koszcie) i obecnie nie ma możliwości zakupu dedykowanych instancji. Jednak ich narzędzie do wdrażania typu open source „teraz” może być również użyte do wdrożenia w dedykowanych instancjach w AWS, a także Google Cloud i Azure.

Iain Collins
źródło
8

To znaczny procent naszej firmy migrującej z Heroku do AWS. Oba mają zalety, ale na Heroku robi się chaotycznie po pewnym czasie ... kiedy potrzebujesz określonego poziomu złożoności, który nie jest już łatwy do utrzymania przy ograniczeniach Heroku.

To powiedziawszy, jest coraz więcej opcji, aby mieć łatwość Heroku i elastyczność AWS, będąc w AWS z doskonałymi ramami / narzędziami.

Kendall Miller
źródło
Czy możesz podać jakieś oszacowanie cen? Będę musiał opublikować Java Web App na Tomcat (Spring Framework, angularJS itp.), pomyślmy o 1000 użytkowników miesięcznie, z których każdy używa aplikacji przez 5 minut. Jaka jest szacunkowa cena? (jak bardzo niskie zużycie, ale dostępność przez cały miesiąc)
brzytwa
3

Zabawne jest to, że Heroku faktycznie używa AWS na backendie. To eliminuje koszty ogólne i zarządza architekturą w EC2. (Zdobył tę wiedzę od starszego inżyniera w dużej firmie podczas wywiadu)

Saurav Prakash
źródło
1

Dobrze! Obserwuję, że Heroku słynie z rozwijających się i nowonarodzonych programistów, podczas gdy AWS ma zaawansowaną osobowość programistów. DigitalOcean jest również ważnym graczem na tym terenie. Cloudways znacznie ułatwiło tworzenie stosu lamp jednym kliknięciem na DigitalOcean i AWS. Posiadanie wszystkich aktualizacji usług i pakietów jednym kliknięciem jest znacznie lepsze niż robienie wszystkiego ręcznie.

Możesz sprawdzić całkowicie tutaj: https://www.cloudways.com/blog/host-php-on-aws-cloud/

Shahroze Nawaz
źródło
1

Cóż, Heroku używa AWS w tle, wszystko zależy od rodzaju potrzebnego rozwiązania. Jeśli jesteś podstawowym Linuksem i jesteś facetem od devos, nie martwisz się tworzeniem vm od zera, np. Wybieraniem ami, wybieraniem opcji palcement itp., Możesz skorzystać z AWS. Jeśli chcesz robić rzeczy na powierzchni, nie mając tych netigrigities, możesz przejść do Heroku.

prasoon
źródło
0

Amazon Web Services (AWS) oferuje wiele usług od IaaS do PaaS, zapewniając 99,9999999% trwałość oraz dostępność danych i infrastruktury. AWS oferuje automatyzację infrastruktury wraz z kilkoma narzędziami dla programistów w celu usprawnienia procesu wdrażania aplikacji.

Z drugiej strony Heroku to po prostu PaaS, który oferuje usługi zarządzania Twoją platformą w chmurze. AWS nie ma znaczenia, czy jest to infrastruktura, czy bezpieczeństwo.

Prash
źródło
6
Potrzebne jest cytowanie: „AWS nie ma znaczenia, czy jest to infrastruktura, czy bezpieczeństwo”.
pdoherty926,
0

Czasami zastanawiam się, dlaczego ludzie porównują AWS do Heroku. AWS to IAAS (infrastruktura jako usługa), która wyraźnie mówi o tym, jak solidny i kalkulacyjny jest system. Z drugiej strony Heroku to tylko SAAS, to w zasadzie tylko jedna część usług AWS. Po co więc męczyć się z konfiguracją AWS, skoro możesz wysłać swój pierwszy produkt na pierwsze miejsce za pomocą Heroku.

Heroku jest darmowe, proste i łatwe do wdrożenia prawie wszystkich rodzajów stosów w sieci. Heroku został specjalnie zaprojektowany, aby ominąć wszystkie problemy związane z wysyłaniem aplikacji na serwer na żywo w krótkim czasie.

Niemniej jednak możesz wdrożyć aplikację przy użyciu dowolnego z samouczków obu stron i porównać

AWS DOCS i Heroku Docs

Sammy Joseph
źródło
0

Chociaż zarówno AWS, jak i Heroku są platformami chmurowymi, różnią się, ponieważ AWS to IaaS, a Heroku to PaaS

Gopinath J.
źródło
2
To nie jest poprawne. AWS oferuje zarówno IAAS, jak i PAAS.
Glenn Bech,
0

Heroku jest jak podzbiór AWS. Jest to tylko platforma jako usługa, podczas gdy AWS może być wdrożony jako wszystko i na dowolnym poziomie.

Wdrożenie zależy od wymagań biznesowych. Jeśli pasuje, użyj odpowiednio.

Krunal Barot
źródło