Ręczne wdrażanie w porównaniu z Amazon Elastic Beanstalk

Question

Jakie są korzyści, które uzyskujemy dzięki użyciu Elastic Beanstalk przez zwykłe tworzenie instancji EC2 i konfigurowanie serwera tomcat i wdrażanie itp. Dla typowej aplikacji sieciowej Java. Czy równoważenie obciążenia, monitorowanie i autoskalowanie to jedyne zalety?

Załóżmy, że dla mojej aplikacji internetowej, która korzysta z bazy danych, zainstalowałem bazę danych w samej instancji EC2. Kiedy ma miejsce automatyczne pobieranie, baza danych zostanie utworzona w nowo utworzonej instancji lub uzyska dostęp do bazy danych, którą utworzyłem w głównej instancji ... Jeśli utworzy ona tylko replikę, gdy nastąpi automatyczne skalowanie, w jaki sposób nastąpi synchronizacja danych między instancjami?

Answer 1

Wszystkie wymienione rzeczy, takie jak równoważenie obciążenia, monitorowanie i automatyczne skalowanie to zdecydowanie atuty.

Musisz jednak myśleć w ten sposób: w prawdziwym Platform as a Service (PAAS) celem jest oddzielenie aplikacji od platformy. Jako programista martwisz się tylko o swoją aplikację. Platforma jest "wynajęta" dla ciebie. Platformy "instancje" są automatycznie aktualizowane, administrowane, skalowane, zrównoważone itp. Po prostu wgrasz plik WAR i działa on (przynajmniej teoretycznie).

EC2 samo w sobie nie jest PAAS. Jest bardziej podobny do IAAS (Infrastructure as a Service). Nadal musisz zadbać o instancje serwera, instalować na nich oprogramowanie, aktualizować je itp.

Elastic Beanstalk to system PAAS. Tak więc są App Engine i Azure wśród wielu innych.

W prawdziwym systemie PAAS, DBMS jest oddzielnym komponentem z serwera (serwerów) aplikacji WWW. Powód jest oczywisty: DBMS nie może być zainstalowany na instancjach, które są używane dla serwera aplikacji, ponieważ, gdy instancje są tworzone i niszczone w oparciu o ruch, DBMS byłby stracony! Posiadanie DBMS i serwera aplikacji na tym samym komputerze/instancji i tak nie jest dobrym pomysłem.

W systemie PAAS DBMS jest osobną usługą. W przypadku Amazon byłoby to Amazon RDS. Podobnie jak w przypadku Elastic Beanstalk, gdzie nie musisz martwić się o serwer aplikacji, a po prostu przesłać plik WAR, z RDS, nie musisz martwić się o DBMS i po prostu wdrożyć swoje bazy danych.

Elastic Beanstalk i RDS działają bardzo dobrze razem, szczególnie gdy są rozmieszczone w tej samej strefie dostępności, gdzie opóźnienie byłoby bardzo niskie.

Wreszcie, użycie Elastic Beanstalk nie kosztuje nic więcej niż wdrożone zasoby (instancje EC2 i system równoważenia obciążenia). Jednak RDS nie jest tani i na pewno będzie droższy niż użycie pojedynczej instancji EC2 zarówno dla serwera aplikacji, jak i DBMS.

Answer 2

Elastic Beanstalk to coś więcej niż równoważenie obciążenia, monitorowanie i autoskalowanie.

1) Zarządza wersjami aplikacji poprzez przechowywanie i zarządzanie różnymi wersjami aplikacji, co pozwala na łatwe przełączanie się między różnymi wersjami aplikacji.

2) Posiada koncepcję "środowisk" dla każdej aplikacji, umożliwiając wdrażanie różnych wersji aplikacji w każdym środowisku. Jest to przydatne na przykład, jeśli chcesz skonfigurować oddzielne środowiska kontroli jakości i DEV i chcesz w łatwy sposób wdrożyć kompilację najpierw w DEV, a następnie wdrożyć tę samą wersję aplikacji w kontroli jakości, gdy zespół kontroli jakości jest gotowy do następnej kompilacji.

3) Dostarcza na zewnątrz ważnych ustawień konfiguracji kontenera (na przykład ustawień pamięci Tomcat) do konsoli Elastic Beanstalk i interfejsu API. Z tego powodu można łatwo zapisać ustawienia i skopiować je między środowiskami.

4) Przeglądaj pliki dziennika aplikacji za pomocą konsoli i automatycznie przesuwaj i archiwizuj pliki dziennika do S3. (Wprawdzie ta funkcja jest obecnie trochę słaba.)