Tại sao mọi người sử dụng Heroku khi AWS có mặt? Điều gì phân biệt Heroku với AWS? [đóng cửa]

Tôi là một lập trình viên RoR mới bắt đầu, người dự định triển khai ứng dụng của mình bằng Heroku. Tin từ những người bạn cố vấn khác của tôi nói rằng Heroku thực sự dễ sử dụng, tốt. Vấn đề duy nhất là tôi vẫn không biết Heroku làm gì ...

Tôi đã xem trang web của họ và tóm lại, Heroku làm gì để giúp nhân rộng nhưng ... tại sao điều đó lại quan trọng? Heroku giúp với:

1. Tốc độ - Nghiên cứu của tôi ngụ ý rằng việc triển khai AWS trên Bờ Đông Hoa Kỳ sẽ nhanh nhất nếu tôi nhắm mục tiêu đến đối tượng ở Hoa Kỳ / Châu Á.

2. Bảo mật - Chúng an toàn đến mức nào?

3. Thu nhỏ - Làm thế nào để nó thực sự hoạt động?

4. Hiệu quả chi phí - Có một cái gì đó giống như một dyno giúp dễ dàng mở rộng quy mô.

5. Làm thế nào để họ chống lại đối thủ cạnh tranh của họ? Ví dụ, Engine Yard và bluebox ?

Vui lòng sử dụng thuật ngữ tiếng Anh của cư sĩ để giải thích ... Tôi là một lập trình viên mới bắt đầu.

AWS / Heroku đều miễn phí cho các dự án sở thích nhỏ (để bắt đầu).

Nếu bạn muốn bắt đầu một ứng dụng ngay lập tức mà không cần nhiều tùy chỉnh về kiến ​​trúc, hãy chọn Heroku .

Nếu bạn muốn tập trung vào kiến ​​trúc và để có thể sử dụng các máy chủ web khác nhau, hãy chọn AWS . AWS tốn nhiều thời gian hơn dựa trên dịch vụ / sản phẩm bạn chọn, nhưng có thể xứng đáng. AWS cũng đi kèm với nhiều dịch vụ và sản phẩm plugin.

Heroku

• Nền tảng là một Dịch vụ (PAAS)
• Tài liệu tốt
• Có các công cụ và kiến ​​trúc tích hợp.
• Kiểm soát hạn chế về kiến ​​trúc trong khi thiết kế ứng dụng.
• Triển khai được chăm sóc (tự động thông qua GitHub hoặc thủ công thông qua các lệnh git hoặc CLI).
• Không tốn thời gian.

AWS

• Cơ sở hạ tầng như một dịch vụ (IAAS)
• Đa năng - có nhiều sản phẩm như EC2, LAMBDA, EMR, v.v.
• Có thể sử dụng một cá thể chuyên dụng để kiểm soát nhiều hơn về kiến ​​trúc, chẳng hạn như chọn HĐH, phiên bản phần mềm, v.v. Có nhiều hơn một lớp phụ trợ.
• Bean Beanalk là một tính năng tương tự như PAAS của Heroku.
• Có thể sử dụng triển khai tự động, hoặc cuộn của riêng bạn.

Đầu tiên, AWS và Heroku là những thứ khác nhau. AWS cung cấp Cơ sở hạ tầng dưới dạng Dịch vụ ( IaaS ) trong khi Heroku cung cấp Nền tảng là Dịch vụ ( PaaS ).

Có gì khác biệt? Rất gần đúng, IaaS cung cấp cho bạn các thành phần bạn cần để xây dựng mọi thứ trên nó; PaaS cung cấp cho bạn một môi trường nơi bạn chỉ cần đẩy mã và một số cấu hình cơ bản và nhận một ứng dụng đang chạy. IaaS có thể cung cấp cho bạn nhiều sức mạnh và sự linh hoạt hơn, với chi phí phải xây dựng và duy trì bản thân nhiều hơn.

Để mã của bạn chạy trên AWS và trông giống như triển khai Heroku, bạn sẽ muốn một số phiên bản EC2 - bạn sẽ muốn một lớp cân bằng tải / bộ đệm được cài đặt trên chúng (ví dụ Varnish ), bạn sẽ muốn các phiên bản chạy một cái gì đó như Hành khách và nginx để phục vụ mã của bạn, bạn sẽ muốn triển khai và định cấu hình phiên bản cơ sở dữ liệu được nhóm của một cái gì đó như PostgreQuery . Bạn sẽ muốn có một hệ thống triển khai với thứ gì đó như Capistrano và một cái gì đó thực hiện tổng hợp nhật ký.

Đó không phải là một lượng công việc không đáng kể để thiết lập và duy trì. Với Heroku, nỗ lực cần có để đạt đến giai đoạn đó có thể là một vài dòng mã ứng dụng và a git push.

Vì vậy, bạn đến nay và bạn muốn mở rộng quy mô. Tuyệt quá. Bạn đang sử dụng Puppet để triển khai EC2, phải không? Vì vậy, bây giờ bạn định cấu hình các tệp Capistrano của mình để quay lên / xuống các trường hợp cần thiết; bạn định lại cấu hình Puppet của mình để Varnish biết về các trường hợp nhân viên web và sẽ tự động gộp giữa chúng. Hoặc bạn heroku scale web:+5.

Hy vọng rằng cung cấp cho bạn một ý tưởng về sự so sánh giữa hai. Bây giờ để giải quyết các điểm cụ thể của bạn:

Tốc độ

Hiện tại Heroku chỉ chạy trên các phiên bản AWS trong us-eastvà eu-west. Đối với bạn, điều này nghe có vẻ như những gì bạn muốn. Đối với những người khác, nó có khả năng được xem xét nhiều hơn.

Bảo vệ

Tôi đã thấy rất nhiều máy chủ sản xuất được bảo trì nội bộ bị chậm trễ trong các bản cập nhật bảo mật, hoặc nói chung là kém kết hợp với nhau. Với Heroku, bạn có người khác quản lý những thứ đó, đó là một phước lành hoặc một lời nguyền tùy thuộc vào cách bạn nhìn vào nó!

Khi bạn triển khai, bạn đang chuyển mã của mình một cách hiệu quả cho Heroku. Đây có thể là một vấn đề cho bạn. Bài viết của họ về Dyno Isolation mô tả chi tiết các công nghệ phân lập của họ (có vẻ như nhiều dynos được chạy trên các cá thể EC2 riêng lẻ). Một số đồng nghiệp đã bày tỏ vấn đề với các công nghệ này và sức mạnh của sự cô lập của họ; Tôi không ở vị trí đủ kiến ​​thức / kinh nghiệm để thực sự bình luận, nhưng việc triển khai Heroku hiện tại của tôi cho rằng "đủ tốt". Nó có thể là một vấn đề cho bạn, tôi không biết.

Thu nhỏ

Tôi đã chạm vào cách người ta có thể thực hiện điều này trong so sánh IaaS vs PaaS của tôi ở trên. Khoảng, ứng dụng của bạn có một Procfile, trong đó có các dòng của biểu mẫu dyno_type: command_to_run, ví dụ: (được viết từ http://devcenter.heroku.com/articles/ Process-model ):

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

Điều này, với một:

heroku scale web:2 worker:10

sẽ dẫn đến việc bạn có 2 webdynos và 10 workerdynos đang chạy. Đẹp, đơn giản, dễ dàng. Lưu ý rằng đó weblà một loại dyno đặc biệt, có quyền truy cập vào thế giới bên ngoài và đứng sau bộ ghép kênh lưu lượng truy cập web đẹp của họ (có thể là một loại kết hợp Varnish / nginx) sẽ định tuyến lưu lượng phù hợp. Nhân viên của bạn có thể tương tác với một hàng đợi tin nhắn để định tuyến tương tự, từ đó họ sẽ nhận được vị trí thông qua một URL trong môi trường.

Hiệu quả chi phí

Rất nhiều người có rất nhiều ý kiến ​​khác nhau về điều này. Hiện tại, nó là 0,05 đô la / giờ cho một giờ dyno, so với 0,025 đô la / giờ đối với phiên bản vi mô AWS hoặc 0,09 đô la / giờ đối với phiên bản nhỏ AWS.

Tài liệu dyno của Heroku nói rằng bạn có khoảng 512 MB RAM, vì vậy có lẽ không quá vô lý khi xem xét một dyno giống như một ví dụ vi mô EC2. Có đáng giá gấp đôi giá? Bao nhiêu bạn coi trọng thời gian của bạn? Lượng thời gian và công sức cần thiết để xây dựng dựa trên ưu đãi của IaaS để đạt được tiêu chuẩn này chắc chắn không hề rẻ. Tôi thực sự không thể trả lời câu hỏi này cho bạn, nhưng đừng đánh giá thấp 'chi phí ẩn' của việc thiết lập và bảo trì.

(Một chút sang một bên, nhưng nếu tôi kết nối với một dyno từ đây ( heroku run bash), một cái nhìn cursory cho thấy 4 lõi /proc/cpuinfovà 36GB RAM - điều này khiến tôi tin rằng tôi đang ở trong "Trường hợp lớn gấp đôi bộ nhớ lớn " . Tài liệu về Heroku dyno nói rằng mỗi dyno nhận được 512 MB RAM, vì vậy tôi có khả năng chia sẻ với tối đa 71 dynos khác. (Tôi không có đủ dữ liệu về sự đồng nhất của các phiên bản AWS của Heroku, vì vậy khả năng của bạn có thể thay đổi))

Làm thế nào để họ chống lại đối thủ cạnh tranh của họ?

Điều này, tôi sợ rằng tôi thực sự không thể giúp bạn với. Đối thủ cạnh tranh duy nhất tôi từng xem là Google App Engine - tại thời điểm tôi đang tìm cách triển khai các ứng dụng Java và số lượng hạn chế đối với các khung và công nghệ có thể sử dụng là vô cùng khó chịu. Đây không chỉ là "chỉ là một thứ Java" - số lượng hạn chế chung và những cân nhắc cần thiết ( gợi ý Câu hỏi thường gặp ở một số) có vẻ không thuận tiện. Ngược lại, triển khai lên Heroku là một giấc mơ.

Phần kết luận

Tôi hy vọng điều này trả lời câu hỏi của bạn (vui lòng bình luận nếu có khoảng trống / các lĩnh vực khác mà bạn muốn giải quyết). Tôi cảm thấy tôi nên cung cấp vị trí cá nhân của tôi. Tôi yêu Heroku vì "triển khai nhanh". Khi tôi bắt đầu một ứng dụng và tôi muốn một số lưu trữ giá rẻ (tầng miễn phí Heroku là tuyệt vời - về cơ bản nếu bạn chỉ cần một web dyno và 5 MB PostgreQuery, thì miễn phí để lưu trữ một ứng dụng), Heroku là vị trí tiếp theo của tôi . Đối với "Triển khai sản xuất nghiêm túc" với một số khách hàng trả tiền, với thỏa thuận cấp độ dịch vụ, dành thời gian dành riêng cho ops, et cetera, tôi hoàn toàn không thể tự mình giảm bớt sự kiểm soát đó cho Heroku, và sau đó là AWS hoặc máy chủ của chúng tôi đã được nền tảng lưu trữ của sự lựa chọn.

Cuối cùng, đó là về những gì làm việc tốt nhất cho bạn. Bạn nói rằng bạn là "lập trình viên mới bắt đầu" - có thể việc sử dụng Heroku sẽ cho phép bạn tập trung vào việc viết Ruby và không phải mất thời gian để xây dựng tất cả các cơ sở hạ tầng khác xung quanh mã của bạn. Tôi chắc chắn sẽ thử.

Lưu ý, AWS thực sự có cung cấp PaaS, Elastic Beanstalk , hỗ trợ Ruby, Node.js, PHP, Python, .NET và Java. Tôi nghĩ nói chung hầu hết mọi người, khi họ nhìn thấy "AWS", nhảy sang những thứ như EC2 và S3 và EBS, đó chắc chắn là những sản phẩm của IaaS

Như Kristian Glass đã nói, không có so sánh giữa IaaS ( AWS ) và PaaS ( Heroku , EngineYard ).

PaaS về cơ bản giúp các nhà phát triển tăng tốc độ phát triển ứng dụng, từ đó tiết kiệm tiền và quan trọng nhất là đổi mới ứng dụng và kinh doanh của họ thay vì thiết lập cấu hình và quản lý những thứ như máy chủ và cơ sở dữ liệu. Các tính năng khác mua để sử dụng PaaS là ​​quy trình triển khai ứng dụng như nhanh nhẹn, Tính sẵn sàng cao, Giám sát, Quy mô / Descale, nhu cầu chuyên môn hạn chế, triển khai dễ dàng và giảm chi phí và thời gian phát triển.

Nhưng vẫn còn một điều tối kỵ đối với PaaS dẫn đến rào cản cho việc áp dụng PaaS:

• Ít kiểm soát máy chủ và cơ sở dữ liệu
• Chi phí sẽ rất cao nếu không được quản lý đúng cách
• Sớm và mơ hồ trong thời đại ngày nay

Ngoài ra, bạn nên có đủ bộ kỹ năng để thay đổi bạn IaaS:

• Mua lại phần cứng
• Hệ điều hành
• Phần mềm máy chủ
• Môi trường tập lệnh phía máy chủ
• máy chủ web
• Hệ thống quản lý cơ sở dữ liệu (Mysql, Redis, v.v.)
• Cấu hình máy chủ sản xuất
• Công cụ để thử nghiệm và triển khai
• Ứng dụng giám sát
• Tính sẵn sàng cao
• Tải định tuyến / định tuyến http
• Chính sách sao lưu dịch vụ
• Hợp tác nhóm
• Tái sản xuất

Nếu bạn có doanh nghiệp quy mô nhỏ, PaaS sẽ là lựa chọn tốt nhất cho bạn:

• Làm bao nhiêu trả bấy nhiêu
• Chi phí khởi đầu thấp
• Để lại hệ thống ống nước cho chuyên gia
• PaaS xử lý tự động mở rộng / khử cặn, Cân bằng tải, khắc phục thảm họa
• PaaS quản lý tất cả các yêu cầu bảo mật
• PaaS quản lý độ tin cậy, tính sẵn sàng cao
• Paas quản lý nhiều tiện ích bên thứ ba cho bạn

Nó sẽ là sự lựa chọn hoàn toàn cá nhân dựa trên yêu cầu. Bạn có thể có thông tin chi tiết về Ứng dụng PPT Hosting Rails của tôi .

Có rất nhiều cách khác nhau để xem xét quyết định này từ các mục tiêu phát triển, CNTT và kinh doanh, vì vậy đừng cảm thấy tồi tệ nếu nó có vẻ quá sức. Nhưng cũng - không lật đổ khả năng mở rộng.

Hãy suy nghĩ về yêu cầu của bạn .

Tôi đã thiết kế các trang web đã phục vụ hơn 8 triệu lượt mỗi ngày và cung cấp terabyte video mỗi tuần được xây dựng trên cơ sở hạ tầng bắt đầu từ 250 nghìn đô la phần cứng vốn bởi một nhân viên lao động CNTT MM khổng lồ.

Nhưng tôi cũng có các trang web nhỏ hơn được thiết kế để tạo ra $ 10- $ 20k mỗi năm, không có yêu cầu lưu lượng truy cập, db hoặc xử lý rất cao và tôi đã loại bỏ những tài khoản lưu trữ chung $ 10 / tháng mà không ảnh hưởng.

Trong tương lai, việc triển khai sẽ trông giống Heroku hơn AWS, chỉ vì tiến bộ. Không có giá trị nào trong việc chuyển đổi cơ sở hạ tầng CNTT của các cơ sở hạ tầng internet không thể tự động hóa ngày càng tăng và không có gì liên quan đến giá trị của sản phẩm hoặc dịch vụ bạn đang cung cấp.

Ngoài ra, hãy ghi nhớ với một trang web thương mại - khả năng mở rộng là điều chúng ta thường gọi là "vấn đề tốt phải có" - mặc dù các vấn đề về khả năng mở rộng với các trang web như Facebook và Twitter rất cao, nhưng chúng không ảnh hưởng tiêu cực đến thành công của họ - tin tức thậm chí có thể đã đóng góp cho nhiều người đăng ký hơn (tất cả báo chí là báo chí tốt).

Nếu bạn có một dịch vụ tạo ra 100 nghìn đô la mỗi ngày và gặp sự cố mở rộng, tôi rất vui lòng gỡ bỏ nó cho bạn bất kể ngôn ngữ, db, nền tảng hoặc cơ sở hạ tầng nào bạn đang chạy!

Khả năng mở rộng là một vấn đề triển khai có thể sửa chữa - không có khách hàng là một vấn đề tồn tại.

Thực tế bạn có thể sử dụng cả hai - bạn có thể phát triển một ứng dụng với máy chủ amazon ec2. Sau đó đẩy nó (với git) miễn phí trong một thời gian (sử dụng cấp miễn phí heroku để phục vụ công chúng) và kiểm tra nó như vậy. Nó rất hiệu quả so với việc thuê một máy chủ, nhưng bạn sẽ phải nói chuyện với một api heroku hạn chế hơn, đó là điều bạn nên suy nghĩ. Nguồn: phương pháp này đã được áp dụng cho một trong các lớp học trực tuyến của tôi "Kỹ thuật khởi nghiệp từ Coursera / Stanford của Balaji S. Srinivasan và Vijay S. Pande

Chà, mọi người thường hỏi câu hỏi này: Heroku hoặc AWS khi bắt đầu triển khai thứ gì đó.

Thử nghiệm sử dụng cả Heroku & AWS của tôi, đây là đánh giá và so sánh nhanh của tôi:

Heroku

• Một lệnh để triển khai bất cứ loại dự án nào của bạn: Ruby on Rails, Nodejs
• Vì vậy, nhiều cú nhấp chuột để tích hợp plugin & bên thứ ba: Thật dễ dàng để bắt đầu với một cái gì đó.
• Không có tự động mở rộng quy mô; điều đó có nghĩa là bạn cần phải tăng / giảm thủ công
• Chi phí đắt đỏ, đặc biệt, khi hệ thống cần nhiều tài nguyên hơn
• Ví dụ miễn phí có sẵn
• Ví dụ miễn phí đi ngủ nếu nó không hoạt động.
• Trung tâm dữ liệu: chỉ US & EU
• CÓ THỂ đi sâu vào / truy cập vào cấp độ máy bằng cách sử dụng Heroku run bash(Cảm ơn, MJafar Mash cho lời khuyên) nhưng đó là loại hạn chế! Bạn không có quyền truy cập đầy đủ!
• Không cần biết quá nhiều về DevOps

AWS - EC2

• Điều này giống như một máy có hệ điều hành cấu hình sẵn (hoặc không), vì vậy bạn cần cài đặt phần mềm, thư viện để làm cho trang web / dịch vụ của bạn trực tuyến.
• Plugin & Library cần được tích hợp thủ công hoặc tập lệnh tự động hóa (tập lệnh công khai & được viết bởi bạn)
• Tự động mở rộng và cân bằng tải là các dịch vụ được hỗ trợ, chỉ cần tìm hiểu cách định cấu hình và tích hợp vào hệ thống của bạn
• Chi phí khá rẻ, tùy thuộc vào dịch vụ và số giờ bạn sử dụng.
• Có vài giờ miễn phí cho các phiên bản T2.micro, nhưng thông thường, bạn sẽ trả vài đô la mỗi tháng (nếu vẫn sử dụng T2.micro)
• Ví dụ miễn phí của bạn sẽ không đi ngủ, sẵn sàng 24/7 (vì bạn có thể trả tiền cho nó :))
• Trung tâm dữ liệu: trên toàn thế giới. Chọn khu vực phù hợp nhất với bạn.
• Lặn vào cấp độ máy. Vì vậy, bạn có thể thưởng thức nó
• Một số kiến ​​thức về DevOps, nhưng không sao, Stackoverflow rất hữu ích ở đó!

AWS Elastic Beanstalk thay thế Heroku, nhưng rẻ hơn

• Bean Beanalk được công bố là bản beta công khai từ năm 2010; nó giúp chúng ta dễ dàng hơn để làm việc với việc triển khai. Để biết chi tiết xin vui lòng vào đây

• Beanstalk là miễn phí, chi phí bạn sẽ trả sẽ dành cho các dịch vụ bạn sử dụng & số giờ sử dụng.

• Tôi sử dụng Elastic Beanstalk trong một thời gian dài, và tôi nghĩ rằng nó có thể là sự thay thế của Heroku và rẻ hơn!

Tóm lược

• Heroku: Dễ dàng bắt đầu, ví dụ MIỄN PHÍ , nhưng đắt tiền sau
• AWS: Không dễ, giờ miễn phí, loại rẻ hơn , Beanstalk nên được sử dụng

Vì vậy, trong hệ thống hiện tại của tôi, tôi sử dụng Heroku để dàn dựng và Beanstalk cho sản xuất!

Các câu trả lời hiện có chính xác rộng rãi:

• Heroku rất dễ sử dụng và triển khai, có thể dễ dàng cấu hình để tự động triển khai kho lưu trữ (ví dụ: GitHub), có rất nhiều tiện ích bổ sung của bên thứ ba và tính phí nhiều hơn cho mỗi phiên bản.

• AWS có phạm vi rộng hơn các dịch vụ bên thứ nhất có giá cạnh tranh bao gồm DNS, cân bằng tải, lưu trữ tệp giá rẻ và có các tính năng doanh nghiệp như có thể xác định các chính sách bảo mật.

Đối với tl; dr bỏ qua đến cuối bài này.

AWS ElasticBeanstalk là một nỗ lực để cung cấp một nền tảng triển khai tự động và dễ dàng giống như Heroku. Vì nó sử dụng các thể hiện EC2 (mà nó tạo ra tự động), các máy chủ EB có thể làm mọi thứ mà mọi thể hiện EC2 khác có thể làm và nó rẻ để chạy.

Triển khai với EB rất chậm; việc triển khai một bản cập nhật có thể mất từ ​​10 đến 15 phút cho mỗi máy chủ và việc triển khai đến một cụm lớn hơn có thể chiếm phần tốt nhất trong một giờ - so với chỉ vài giây để triển khai một bản cập nhật trên Heroku. Việc triển khai trên EB cũng không được xử lý đặc biệt liền mạch, điều này có thể áp đặt các ràng buộc đối với thiết kế ứng dụng.

Bạn có thể sử dụng tất cả các dịch vụ mà ElasticBeanstalk sử dụng đằng sau hậu trường để xây dựng hệ thống bespoke của riêng bạn (với CodeDeploy, Bộ cân bằng tải đàn hồi, Nhóm tự động mở rộng - và CodeCommit, CodeBuild và CodePipeline nếu bạn muốn sử dụng tất cả) Vài tuần thiết lập nó lần đầu tiên vì nó khá phức tạp và hơi phức tạp hơn là chỉ cấu hình mọi thứ trong EC2.

AWS Lightsail cung cấp tùy chọn lưu trữ có giá cạnh tranh, nhưng không giúp triển khai hoặc nhân rộng - nó thực sự chỉ là một trình bao bọc cho sản phẩm EC2 của họ (nhưng chi phí cao hơn nhiều). Nó cho phép bạn tự động chạy một tập lệnh bash khi thiết lập ban đầu, đây là một thao tác tốt nhưng thật tuyệt vời so với chi phí chỉ thiết lập một phiên bản EC2 (bạn cũng có thể lập trình).

Một số suy nghĩ về việc so sánh (để thử và trả lời các câu hỏi, mặc dù theo cách vòng vo):

1. Đừng đánh giá thấp quản trị hệ thống làm việc là bao nhiêu, bao gồm giữ mọi thứ bạn đã cài đặt cập nhật với các bản vá bảo mật (và các bản cập nhật hệ điều hành không thường xuyên).

2. Đừng đánh giá thấp mức độ lợi ích của việc triển khai tự động, tự động mở rộng và cung cấp và cấu hình SSL.

   Tự động triển khai khi bạn cập nhật kho Git của mình dễ dàng với Heroku. Nó gần như ngay lập tức, duyên dáng vì vậy không có sự cố ngừng hoạt động cho người dùng cuối và chỉ có thể được thiết lập để cập nhật nếu các bài kiểm tra / Tích hợp liên tục vượt qua để bạn không phá vỡ trang web của mình nếu bạn triển khai mã bị hỏng.

   Bạn cũng có thể sử dụng ElasticBeanstalk để triển khai tự động, nhưng hãy sẵn sàng dành một tuần để thiết lập lần đầu tiên - bạn có thể phải thay đổi cách bạn triển khai và xây dựng tài sản (như CSS và JS) để làm việc với cách mà ElasticBeanstalk xử lý việc triển khai hoặc xây dựng logic vào ứng dụng của bạn để xử lý việc triển khai.

   Lưu ý trong việc ước tính chi phí để triển khai liền mạch mà không bị ngừng hoạt động trên EB, bạn cần chạy nhiều phiên bản - EB tung ra các bản cập nhật cho từng máy chủ để dịch vụ của bạn không bị suy giảm - khi Heroku tạo ra một dyno mới cho bạn và chỉ không dùng nữa dịch vụ cũ cho đến khi tất cả các yêu cầu đến nó được xử lý xong (sau đó nó sẽ xóa nó).

   Thật thú vị, chi phí lưu trữ để chạy nhiều máy chủ với EB có thể rẻ hơn một phiên bản Heroku duy nhất, đặc biệt là khi bạn bao gồm chi phí của các tiện ích bổ sung.

Một số vấn đề khác không được hỏi cụ thể, nhưng được nêu ra bởi các câu trả lời khác:

1. Sử dụng một nhà cung cấp khác nhau cho sản xuất và phát triển là một ý tưởng tồi.

   Tôi đang co rúm rằng mọi người đang đề nghị điều này. Mặc dù mã lý tưởng chỉ chạy tốt trên mọi nền tảng hợp lý để có thể mang theo càng tốt, các phiên bản phần mềm trên mỗi máy chủ sẽ khác nhau rất nhiều và chỉ vì mã chạy theo giai đoạn không có nghĩa là nó sẽ chạy trong sản xuất (ví dụ: Node.js / Các phiên bản Ruby / Python / PHP / Perl có thể khác nhau về cách làm cho mã không tương thích, thường theo những cách im lặng có thể không bị bắt ngay cả khi bạn có phạm vi kiểm tra tốt).

   Một ý tưởng tốt là tận dụng thứ gì đó như Heroku để tạo mẫu, các dự án nhỏ hơn và microsites - để bạn có thể xây dựng và triển khai mọi thứ một cách nhanh chóng mà không cần đầu tư nhiều thời gian vào cấu hình và bảo trì.

   Hãy chắc chắn tính đến chi phí chạy cả hai trường hợp sản xuất và tiền sản xuất khi đưa ra quyết định đó, không quên chi phí sao chép toàn bộ môi trường (bao gồm các dịch vụ của bên thứ ba như lưu trữ / bổ sung dữ liệu, cài đặt và định cấu hình SSL, v.v.) .

2. Nếu sử dụng AWS, hãy cảnh giác với các phiên bản được cấu hình sẵn AWS từ các nhà cung cấp như Bitnami - chúng là một cơn ác mộng bảo mật. Họ có thể phơi bày rất nhiều ứng dụng dễ bị tổn thương khét tiếng theo mặc định mà không đề cập đến nó trong phần mô tả.

   Thay vào đó, hãy xem xét chỉ sử dụng phân phối chính được hỗ trợ tốt, chẳng hạn như Ubuntu hoặc Debian (hoặc CentOS nếu bạn cần hỗ trợ RPM).

   Lưu ý: Ưu đãi của Amazon có phân phối riêng của họ được gọi là Amazon Linux, sử dụng RPM, nhưng đó là phần mềm EC2 cụ thể và ít được hỗ trợ bởi bên thứ ba / phần mềm nguồn mở.

3. Bạn có thể cũng thiết lập một thể EC2 trên AWS (hoặc Lightsail) và cấu hình với một cái gì đó giống như Flynn hoặc dokku vào nó - mà sau đó bạn có thể triển khai nhiều trang web một cách dễ dàng, có thể là đáng giá nếu bạn duy trì rất nhiều dịch vụ hoặc muốn trở thành có thể quay những điều mới một cách dễ dàng. Tuy nhiên, việc thiết lập nó không tự động như việc sử dụng Heroku và cuối cùng bạn có thể dành nhiều thời gian để cấu hình và duy trì nó (đến mức tôi thấy việc triển khai bằng cách sử dụng cụm Amazon và Docker Swarm dễ dàng hơn so với thiết lập chúng; YMMV).

Tôi đã sử dụng các phiên bản AWS EC (một mình và theo cụm), Elastic Beanstalk và Lightsail và Heroku cùng một lúc tùy thuộc vào nhu cầu của dự án mà tôi đang làm việc.

Tôi ghét dành thời gian cấu hình các dịch vụ nhưng hóa đơn Heroku của tôi sẽ là hàng ngàn mỗi năm nếu tôi sử dụng nó cho mọi thứ và AWS tính ra một phần chi phí.

tl; dr

Nếu tiền không bao giờ là vấn đề tôi sẽ sử dụng Heroku cho hầu hết mọi thứ vì nó là một công cụ tiết kiệm thời gian khổng lồ - nhưng tôi vẫn muốn sử dụng AWS cho các dự án phức tạp hơn, nơi tôi cần sự linh hoạt và các dịch vụ tiên tiến hơn mà Heroku không cung cấp.

Kịch bản lý tưởng đối với tôi sẽ là nếu ElasticBeanstalk chỉ hoạt động giống Heroku hơn - tức là với cấu hình dễ dàng hơn và nhanh hơn và cơ chế triển khai tốt hơn.

Một ví dụ về dịch vụ gần như hiện tại .sh , thực sự sử dụng AWS đằng sau hậu trường, nhưng giúp triển khai và phân cụm dễ dàng như trên Heroku (với SSL tự động, DNS, triển khai duyên dáng, thiết lập cụm siêu dễ dàng và sự quản lý).

Tôi đã sử dụng nó khá nhiều cho cả triển khai ứng dụng Node.js và Docker, cảnh báo chính là các trường hợp được chia sẻ (một cái gì đó được phản ánh trong chi phí thấp hơn của chúng) và hiện không có tùy chọn để mua các phiên bản chuyên dụng. Tuy nhiên, công cụ triển khai nguồn mở 'bây giờ' của họ cũng có thể được sử dụng để triển khai cho các phiên bản dành riêng trên AWS cũng như Google Cloud và Azure.

Đó là một tỷ lệ đáng kể trong việc kinh doanh của chúng tôi di chuyển người từ Heroku sang AWS. Có những lợi thế cho cả hai, nhưng sau một thời gian, Heroku sẽ trở nên lộn xộn ... một khi bạn cần một mức độ phức tạp nhất định không còn dễ dàng duy trì với những hạn chế của Heroku.

Điều đó nói rằng, ngày càng có nhiều lựa chọn để có được sự dễ dàng của Heroku và tính linh hoạt của AWS bằng cách có mặt trên AWS với các khung / công cụ tuyệt vời.

Điều thú vị là Heroku thực sự sử dụng AWS trên phần phụ trợ. Nó lấy đi tất cả chi phí và quản lý kiến ​​trúc trên EC2 cho bạn. (Có kiến ​​thức từ một kỹ sư cao cấp tại một Công ty lớn trong một cuộc phỏng vấn)

Tốt! Tôi quan sát Heroku nổi tiếng trong các nhà phát triển vừa chớm nở và mới ra đời trong khi AWS có nhân cách nhà phát triển tiên tiến. DigitalOcean cũng là một người chơi chính trong lĩnh vực này. Cloudways đã giúp việc tạo ngăn xếp đèn trở nên dễ dàng hơn rất nhiều khi nhấp vào DigitalOcean và AWS. Có tất cả các dịch vụ và gói cập nhật trong một nhấp chuột tốt hơn nhiều so với thực hiện tất cả mọi thứ bằng tay.

Bạn có thể kiểm tra hoàn toàn tại đây: https://www.cloudways.com/blog/host-php-on-aws-cloud/

Vâng Heroku sử dụng AWS trong nền, tất cả phụ thuộc vào loại giải pháp bạn cần. Nếu bạn là một linux linux và devops guys, bạn không lo lắng về việc tạo vm từ đầu như chọn ami chọn các tùy chọn palced, v.v., bạn có thể đi với AWS. Nếu bạn muốn làm mọi thứ ở cấp độ bề mặt mà không cần những điều đó, bạn có thể đi với heroku.

Amazon Web Services (AWS) cung cấp rất nhiều dịch vụ từ IaaS đến PaaS với độ bền 99.9999999% và tính sẵn có của dữ liệu và cơ sở hạ tầng. AWS cung cấp tự động hóa cơ sở hạ tầng cùng với một số công cụ để các nhà phát triển thực hiện quy trình triển khai ứng dụng của họ.

Mặt khác, Heroku chỉ là PaaS cung cấp dịch vụ để quản lý nền tảng của bạn trên đám mây của họ. Không nơi nào đứng với AWS cho dù đó là cơ sở hạ tầng hay bảo mật.

Đôi khi, tôi tự hỏi tại sao mọi người so sánh AWS với Heroku. AWS là một IAAS (cơ sở hạ tầng như một dịch vụ), nó nói rõ hệ thống mạnh mẽ và tính toán như thế nào. Heroku, mặt khác, chỉ là một SAAS, về cơ bản nó chỉ là một phần của các dịch vụ AWS. Vậy tại sao phải vật lộn với việc thiết lập AWS khi bạn có thể gửi sản phẩm đầu tiên của mình đến thủ tướng bằng Heroku.

Heroku là miễn phí, đơn giản và dễ dàng để triển khai hầu hết các loại ngăn xếp lên web. Heroku được xây dựng đặc biệt để vượt qua mọi rắc rối khi chuyển ứng dụng của bạn đến một máy chủ trực tiếp trong thời gian ngắn hơn.

Tuy nhiên, bạn có thể muốn triển khai ứng dụng của mình bằng bất kỳ hướng dẫn nào từ cả hai bên và so sánh

AWS DOCS và Heroku Docs

Mặc dù cả AWS và Heroku đều là nền tảng đám mây, chúng khác nhau vì AWS là IaaS và Heroku là PaaS

Heroku giống như tập hợp con của AWS. Nó chỉ là nền tảng như một dịch vụ, trong khi AWS có thể được triển khai như mọi thứ và ở mọi cấp độ.

Việc thực hiện phụ thuộc vào những gì yêu cầu kinh doanh. Nếu nó phù hợp với một trong hai, sử dụng cho phù hợp.