AWS가있을 때 사람들이 왜 Heroku를 사용합니까? Heroku와 AWS의 차이점은 무엇입니까? [닫은]

저는 Heroku를 사용하여 앱을 배포 할 계획 인 초보자 RoR 프로그래머입니다. 다른 조언자 친구의 말에 따르면 Heroku는 사용하기가 정말 쉽고 쉽습니다. 유일한 문제는 여전히 Heroku가 무엇을하는지 전혀 모른다는 것입니다 ...

나는 그들의 웹 사이트 와 간단히 말해서, Heroku 가하는 일은 스케일링에 도움이되지만 ... 왜 중요한가? Heroku는 어떻게 도움이됩니까?

1. 속도-필자의 연구에 따르면 미국 / 아시아 기반 고객을 대상으로하는 경우 미국 동부 해안에 AWS를 배포하는 것이 가장 빠를 것입니다.

2. 보안-얼마나 안전합니까?

3. 스케일링-실제로 어떻게 작동합니까?

4. 비용 효율성-확장하기 쉬운 dyno와 같은 것이 있습니다.

5. 그들은 어떻게 경쟁사에 대항합니까? 예를 들어 Engine Yard 및 bluebox ?

설명하기 위해 평신도 영어 용어를 사용하십시오 ... 저는 초보자 프로그래머입니다.

AWS / Heroku 는 소규모 취미 프로젝트 (시작부터)에 대해 모두 무료입니다.

아키텍처를 많이 사용자 정의하지 않고 바로 앱을 시작하려면 Heroku 를 선택하십시오 .

아키텍처에 집중하고 다른 웹 서버를 사용하려면 AWS 를 선택하십시오 . AWS는 선택한 서비스 / 제품에 따라 시간이 많이 걸리지 만 그만한 가치가 있습니다. AWS는 많은 플러그인 서비스 및 제품과 함께 제공됩니다.

헤 로쿠

• PAAS (Platform as a Service)
• 좋은 문서
• 내장 도구 및 아키텍처가 있습니다.
• 앱을 디자인하는 동안 아키텍처를 제한적으로 제어합니다.
• 배포가 처리됩니다 (GitHub를 통한 자동 또는 git 명령 또는 CLI를 통한 수동).
• 시간이 걸리지 않습니다.

AWS

• IAS (Infrastructure as a Service)
• 다용도-EC2, LAMBDA, EMR 등과 같은 많은 제품이 있습니다.
• OS, 소프트웨어 버전 등을 선택하는 등 아키텍처를보다 효과적으로 제어하기 위해 전용 인스턴스를 사용할 수 있습니다. 둘 이상의 백엔드 계층이 있습니다.
• Elastic Beanstalk는 Heroku의 PAAS와 유사한 기능입니다.
• 자동 배포를 사용하거나 직접 배포 할 수 있습니다.

우선, AWS와 Heroku는 다릅니다. AWS는 IaaS (Infrastructure as a Service )를 제공하는 반면 Heroku는 PaaS ( Platform as a Service )를 제공합니다.

차이점이 뭐야? 대략적으로 IaaS는 그 위에 물건을 만드는 데 필요한 구성 요소를 제공합니다. PaaS는 코드 및 일부 기본 구성을 푸시하고 실행중인 애플리케이션을 얻는 환경을 제공합니다. IaaS는 더 많은 것을 구축하고 유지해야하는 비용으로 더 많은 기능과 유연성을 제공 할 수 있습니다.

코드를 AWS에서 실행하고 Heroku 배포와 비슷하게 보이려면 EC2 인스턴스가 필요합니다.로드 밸런서 / 캐싱 레이어가 설치되어 있어야합니다 (예 : Varnish ). 승객 과 nginx 는 코드를 제공하기 위해 PostgreSQL 과 같은 클러스터 된 데이터베이스 인스턴스를 배포하고 구성하려고합니다 . Capistrano 와 같은 로그 시스템과 배포 시스템이 필요합니다 .

그것은 설정하고 유지해야 할 일이 그리 중요하지 않습니다. Heroku를 사용하면 이러한 단계에 도달하기위한 노력은 몇 줄의 응용 프로그램 코드와입니다 git push.

그래서 당신은 지금까지 있고, 당신은 확장하고 싶습니다. 큰. EC2 배포에 Puppet 을 사용하고 있습니까? 이제 Capistrano 파일을 구성하여 필요에 따라 인스턴스를 스핀 업 / 다운 할 수 있습니다. Varnish가 웹 작업자 인스턴스를 인식하고 자동으로 풀링되도록 Puppet 구성을 다시 지그하십시오. 또는 당신 heroku scale web:+5.

바라건대 그것은 둘 사이의 비교에 대한 아이디어를 제공합니다. 이제 특정 요점을 해결하십시오.

속도

현재 Heroku는 us-east및의 AWS 인스턴스에서만 실행됩니다 eu-west. 당신을 위해, 이것은 당신이 어쨌든 원하는 것 같습니다. 다른 사람들에게는 잠재적으로 더 많은 고려 사항입니다.

보안

보안 업데이트에 뒤쳐져 있거나 일반적으로 제대로 구성되지 않은 많은 내부 유지 관리 프로덕션 서버를 보았습니다. Heroku를 사용하면 다른 것을 관리하는 사람이 있습니다. 이것은 어떻게 보느냐에 따라 축복이거나 저주입니다!

배포 할 때 코드를 Heroku로 바로 넘겨줍니다. 이것은 당신에게 문제가 될 수 있습니다. Dyno Isolation에 대한 기사에서는 격리 기술에 대해 자세히 설명합니다 (여러 개의 dyno가 개별 EC2 인스턴스에서 실행되는 것처럼 보입니다). 몇몇 동료들은 이러한 기술과 격리의 강도에 관한 문제를 표명했습니다. 나는 실제로 언급하기에 충분한 지식 / 경험의 위치에 있지 않지만, 현재의 Heroku 배포는 "충분히 좋다"고 생각합니다. 잘 모르겠습니다.

스케일링

위의 IaaS와 PaaS 비교에서 이것을 구현하는 방법에 대해 설명했습니다. 대략 응용 프로그램 Procfile의 양식은 다음과 같습니다 dyno_type: command_to_run(예 : http://devcenter.heroku.com/articles/process-model 참조 ).

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

이것은 다음과 같습니다.

heroku scale web:2 worker:10

2 개의 webdynos와 10 개의 workerdynos가 실행됩니다. 좋고 간단하고 쉽습니다. 참고 web외부 세계에 액세스 할 수있는 특별한 다이노 유형이며, 자신의 좋은 웹 트래픽 멀티플렉서 뒤에 (니스 / nginx를 조합의 아마 일종) 따라 그 의지 경로 트래픽입니다. 작업자는 비슷한 라우팅을 위해 메시지 대기열과 상호 작용하여 환경의 URL을 통해 위치를 가져옵니다.

비용 효율성

많은 사람들이 이것에 대해 많은 다른 의견을 가지고 있습니다. 현재 AWS 마이크로 인스턴스의 경우 $ 0.025 / hr 또는 AWS 소형 인스턴스의 경우 $ 0.09 / hr와 비교하여 dyno 시간의 경우 시간당 $ 0.05입니다.

Heroku가의 다이노 설명서 는 아마 그래서 당신은, RAM 512MB의에 대해이 말한다 너무 EC2 마이크로 인스턴스 같은 비트 같은 다이노을 고려하는 것이 불합리한. 가격의 두 배가 가치가 있습니까? 시간을 얼마나 소중하게 생각하십니까? 이 표준에 도달하기 위해 IaaS 솔루션을 기반으로 구축하는 데 필요한 시간과 노력은 확실히 저렴하지 않습니다. 이 질문에 실제로 답할 수는 없지만 설정 및 유지 관리의 '숨겨진 비용'을 과소 평가하지는 않습니다.

(여기서 제쳐두고 있지만 (here heroku run bash) 에서 dyno에 연결 하면 커서 모양으로 4 코어 /proc/cpuinfo와 36GB RAM이 표시됩니다. 이렇게하면 "High-Memory Double Extra Large Instance" 에 있다고 믿게됩니다 " . Heroku dyno 문서에 따르면 각 dyno는 512MB의 RAM을 수신하므로 최대 71 개의 다른 dyno와 공유 할 수 있습니다. (Heroku의 AWS 인스턴스의 동질성에 대한 데이터가 충분하지 않으므로 마일리지가 다를 수 있습니다.)

그들은 어떻게 경쟁사에 대항합니까?

정말 도와 드릴 수 없습니다. 필자가 실제로 살펴본 유일한 경쟁자는 Google App Engine 이었습니다. Java 응용 프로그램을 배포하려고 할 때 사용 가능한 프레임 워크 및 기술에 대한 제한 이 엄청나게 퍼졌습니다. 이것은 "단지 Java 일"이상입니다. 일반적인 제한 및 필요한 고려 사항 ( 몇 가지 FAQ 힌트)은 편리하지 않은 것 같습니다. 반대로 Heroku에 배포하는 것은 꿈이었습니다.

결론

이것이 귀하의 질문에 답변되기를 바랍니다 (갭이 있거나 다른 영역이 있으면 의견을 말하십시오). 나는 내 개인적인 입장을 제시해야한다고 느낍니다. "빠른 배포"로 Heroku를 좋아합니다. 응용 프로그램을 시작할 때 저렴한 호스팅을 원할 때 (Heroku 프리 티어가 훌륭합니다. 기본적으로 하나의 웹 dyno와 5MB의 PostgreSQL 만 있으면 응용 프로그램을 호스팅하는 것이 무료입니다) Heroku는 제 위치입니다 . 서비스 수준 계약이 있고 운영에 시간을 할애 할 수있는 시간이있는 여러 유료 고객이있는 "심각한 프로덕션 배포"의 경우, 많은 제어권을 Heroku로 오프로드 할 수 없습니다. 자체 서버는 선택한 호스팅 플랫폼이었습니다.

궁극적으로 가장 적합한 것이 무엇인지에 관한 것입니다. 당신은 "초보 프로그래머"라고 말합니다-Heroku를 사용하면 Ruby 작성에 집중할 수 있고 코드 주변의 다른 모든 인프라를 얻는 데 시간을 들일 필요가 없습니다. 확실히 시도해 볼 것입니다.

AWS에는 실제로 Ruby, Node.js, PHP, Python, .NET 및 Java를 지원 하는 PaaS 오퍼링 인 Elastic Beanstalk가 있습니다. 나는 일반적으로 대부분의 사람들이 "AWS"를 볼 때 EC2 및 S3 및 EBS와 같은 것으로 뛰어들 것입니다.

Kristian Glass Said는 IaaS ( AWS )와 PaaS ( Heroku , EngineYard )를 비교하지 않았습니다 .

PaaS는 기본적으로 개발자가 앱 개발 속도를 높이도록 지원하므로 구성을 설정하고 서버 및 데이터베이스와 같은 것을 관리하는 대신 비용을 절감하고 애플리케이션과 비즈니스를 혁신하는 것이 가장 중요합니다. PaaS를 사용하기 위해 구매하는 다른 기능으로는 민첩성, 고 가용성, 모니터링, 스케일 / 디 스케일, 전문 지식의 제한 필요성, 쉬운 배포 및 비용 및 개발 시간 단축과 같은 애플리케이션 배포 프로세스가 있습니다.

그러나 여전히 PaaS 채택에 장애가되는 PaaS에는 어두운면이 있습니다.

• 서버 및 데이터베이스에 대한 통제력 감소
• 제대로 관리되지 않으면 비용이 매우 높아질 것입니다
• 현재 날짜와 나이에 조숙하고 모호한

위와 별도로 IaaS를 관리 할 수있는 충분한 기술이 있어야합니다.

• 하드웨어 획득
• 운영 체제
• 서버 소프트웨어
• 서버 측 스크립팅 환경
• 웹 서버
• 데이터베이스 관리 시스템 (Mysql, Redis 등)
• 프로덕션 서버 구성
• 테스트 및 배포 도구
• 모니터링 앱
• 고 가용성
• 로드 블랜딩 / HTTP 라우팅
• 서비스 백업 정책
• 팀 협업
• 생산 재 구축

소규모 사업을하는 경우 PaaS가 가장 적합합니다.

• 당신이가는대로 지불
• 낮은 시작 비용
• 배관을 전문가에게 맡기십시오
• PaaS는 자동 스케일링 / 디 스케일링,로드 밸런싱, 재난 복구를 처리합니다
• PaaS는 모든 보안 요구 사항을 관리합니다
• PaaS는 안정성, 고 가용성을 관리합니다
• Paas는 많은 타사 애드온을 관리합니다

요구 사항에 따라 완전히 개인이 선택합니다. 내 PPT Hosting Rails Apps 에 대한 세부 정보를 가질 수 있습니다 .

실제로 두 가지를 모두 사용할 수 있습니다. Amazon EC2 서버로 앱을 개발할 수 있습니다. 그런 다음 (git과 함께) heroku에 한동안 무료로 푸시하고 (heroku free tier를 사용하여 대중에게 제공하십시오) 그렇게 테스트하십시오. 서버를 임대하는 것보다 비용면에서 효과적이지만 더 제한적인 heroku api와 이야기해야합니다. 출처 :이 방법은 온라인 수업 중 하나 인 Balaji S. Srinivasan과 Vijay S. Pande의 Coursera / Stanford의 스타트 업 엔지니어링에 채택되었습니다.

개발, IT 및 비즈니스 목표에서이 결정을 보는 데는 여러 가지 방법이 있으므로 압도적으로 느껴지더라도 나쁘지 않습니다. 또한 확장 성을 지나치게 생각하지 마십시오.

요구 사항 에 대해 생각하십시오 .

나는 하루에 8M 이상의 고유 한 서비스를 제공하는 웹 사이트를 설계했으며, 일주일에 테라 바이트 규모의 비디오를 대규모 MM IT 인력 직원이 운영하는 자본 하드웨어에서 2 억 5 천만 달러 규모의 인프라를 기반으로 구축했습니다.

하지만 매년 10 ~ 20 만 달러를 생성하도록 설계된 더 작은 웹 사이트를 보유하고 있으며 트래픽, DB 또는 처리 요구 사항이 많지 않았으며 10 달러 / 월 일반 호스팅 계정에서 타협없이 웹 사이트를 운영했습니다.

앞으로는 진전으로 인해 배포가 AWS보다 Heroku처럼 보일 것입니다. 점점 더 자동화 할 수없는 인터넷 인프라 확장의 IT 노브 터닝에는 전혀 가치가 없으며 제공하는 제품이나 서비스의 가치와 관련이 없습니다.

또한 상용 웹 사이트를 염두에 두십시오-확장 성은 우리가 종종 '좋은 문제'라고 부릅니다. Facebook 및 Twitter와 같은 사이트의 확장 성 문제는 매우 유명하지만 성공에 부정적인 영향을 미치지 않습니다-뉴스 더 많은 가입에 기여 했을 수도 있습니다 (모든 프레스는 좋은 프레스입니다).

하루에 100k + 고유 항목을 생성하고 확장 문제가있는 서비스가있는 경우, 사용중인 언어, db, 플랫폼 또는 인프라에 관계없이 서비스를 제공하게되어 기쁩니다!

확장 성은 해결 가능한 구현 문제입니다. 고객이없는 것은 존재하는 문제입니다.

글쎄, 사람들은 일반적으로 무언가 배포를 시작할 때 Heroku 또는 AWS와 같은 질문을합니다.

Heroku와 AWS를 모두 사용한 실험은 다음과 같습니다.

헤 로쿠

• 프로젝트 유형에 관계없이 하나의 명령 : Ruby on Rails, Nodejs
• 플러그인과 타사를 통합하기 위해 많은 원 클릭 : 무언가로 시작하는 것은 매우 쉽습니다.
• 자동 확장이 없습니다. 즉, 수동으로 확장 / 축소해야합니다.
• 특히 시스템에 더 많은 리소스가 필요한 경우 비용이 비싸다
• 사용 가능한 무료 인스턴스
• 비어있는 인스턴스는 비활성 상태 인 경우 절전 상태가됩니다.
• 데이터 센터 : 미국 및 EU 만
• Heroku run bash(고마워, MJafar Mash를 사용하여) 머신 레벨에 액세스하거나 머신 레벨에 액세스 할 수는 있지만 제한적입니다! 전체 액세스 권한이 없습니다!
• DevOps에 대해 너무 많이 알 필요가 없습니다

AWS-EC2

• 이것은 사전 구성 OS가 있거나없는 시스템과 같으므로 웹 사이트 / 서비스가 온라인 상태가되도록 소프트웨어, 라이브러리를 설치해야합니다.
• 플러그인 및 라이브러리를 수동으로 통합하거나 자동화 스크립트 (공용 스크립트 및 사용자 작성)
• 자동 확장 및로드 밸런서는 지원되는 서비스입니다. 시스템 구성 및 통합 방법을 배우십시오.
• 비용은 매우 저렴하며 사용하는 서비스 및 시간에 따라 다릅니다.
• T2.micro 인스턴스에는 몇 시간의 무료 시간이 있지만 일반적으로 매월 몇 달러를 지불합니다 (T2.micro를 계속 사용하는 경우)
• 무료 인스턴스는 24 시간 연중 무휴로 잠들지 않습니다 (비용을 지불 할 수 있기 때문에).
• 데이터 센터 : 전 세계. 귀하에게 가장 적합한 지역을 선택하십시오.
• 기계 수준으로 다이빙하십시오. 그래서 당신은 그것을 즐길 수 있습니다
• DevOps에 대한 지식이 있지만 괜찮습니다. 스택 오버플로가 도움이됩니다!

AWS Elastic Beanstalk 는 Heroku의 대안이지만 저렴합니다.

• Elastic Beanstalk는 2010 년부터 공개 베타 버전으로 발표되었습니다. 배포 작업을보다 쉽게 ​​수행 할 수 있습니다. 자세한 내용은 여기 를 참조 하십시오

• Beanstalk는 무료이며, 지불하는 비용은 사용하는 서비스 및 사용 시간에 대한 비용입니다.

• 나는 Elastic Beanstalk를 오랫동안 사용하고 있으며 Heroku를 대체하고 저렴하게 사용할 수 있다고 생각합니다!

요약

• Heroku : 처음에는 쉽고 무료 인스턴스이지만 나중에는 비쌉니다.
• AWS : 쉽지 않고, 무료로 제공되는 시간, 더 저렴하고 , Beanstalk는 사용을 염려해야합니다.

따라서 현재 시스템에서는 준비를 위해 Heroku를 사용하고 생산을 위해 Beanstalk를 사용합니다!

기존 답변은 크게 정확합니다.

• Heroku는 사용 및 배포가 매우 쉽고 저장소 (예 : GitHub) 자동 배포를 위해 쉽게 구성 할 수 있으며 많은 타사 애드온이 있으며 인스턴스 당 요금이 더 많이 듭니다.

• AWS는 DNS,로드 밸런싱, 저렴한 파일 스토리지를 포함하여보다 경쟁력있는 가격의 퍼스트 파티 서비스를 제공하며 보안 정책을 정의 할 수있는 것과 같은 엔터프라이즈 기능을 갖추고 있습니다.

를 들어 TL; DR 이 게시물의 끝으로 건너 뜁니다.

AWS ElasticBeanstalk는 Heroku와 같은 자동 확장 및 쉬운 배포 플랫폼을 제공하려는 시도입니다. EC2 인스턴스 (자동 생성)를 사용하므로 EB 서버는 다른 EC2 인스턴스가 수행 할 수있는 모든 작업을 수행 할 수 있으며 운영 비용이 저렴합니다.

EB를 사용한 배포는 매우 느립니다. 업데이트 배포는 서버 당 10-15 분이 소요될 수 있으며 더 큰 클러스터에 배포하는 경우 Heroku에 업데이트를 배포하는 데 몇 초 밖에 걸리지 않습니다. EB에서의 배포는 특히 완벽하게 처리되지 않으므로 응용 프로그램 디자인에 제약이 발생할 수 있습니다.

ElasticBeanstalk가 배후에서 사용하는 모든 서비스를 사용하여 자체 맞춤형 시스템을 구축 할 수 있습니다 (CodeDeploy, Elastic Load Balancer, Auto Scaling Groups 및 CodeCommit, CodeBuild 및 CodePipeline 사용). 몇 주 만에 EC2에서 구성하는 것보다 상당히 복잡하고 약간 까다로워 처음으로 설정했습니다.

AWS Lightsail은 경쟁력있는 가격의 호스팅 옵션을 제공하지만 배포 또는 확장에 도움이되지 않습니다. 실제로 EC2 오퍼링을위한 래퍼 일뿐입니다. 초기 설정에서 bash 스크립트를 자동으로 실행할 수 있습니다.이 방법은 훌륭하지만 EC2 인스턴스를 설정하는 비용 (프로그래밍 방식으로 수행 할 수 있음)과 비교할 때 비쌉니다.

비교에 대한 몇 가지 생각 (로터리 방식이지만 질문을 시도하고 대답하기 위해) :

1. 보안 패치 (및 간혹 OS 업데이트)로 설치 한 모든 것을 유지하는 것을 포함하여 작업 시스템 관리의 양을 과소 평가하지 마십시오.

2. 자동 배포, 자동 확장 및 SSL 프로비저닝 및 구성의 이점을 과소 평가하지 마십시오.

   Heroku를 사용하면 Git 리포지토리를 업데이트 할 때 자동 배포가 쉬워집니다. 거의 즉각적이고 우아하므로 최종 사용자에게 중단이 없으며 테스트 / 연속 통합이 통과하는 경우에만 업데이트하도록 설정하여 깨진 코드를 배포해도 사이트가 중단되지 않도록 할 수 있습니다.

   자동 배포에 ElasticBeanstalk를 사용할 수도 있지만 처음으로 1 주일을 소비 할 준비가되어 있습니다. ElasticBeanstalk가 배포를 처리하거나 논리를 빌드하는 방식으로 작업하기 위해 자산 (CSS 및 JS 등)을 배포 및 빌드하는 방법을 변경해야 할 수도 있습니다 배포를 처리하기 위해 앱에.

   EB에서 중단없이 원활하게 배포하려면 여러 인스턴스를 실행해야하는 비용을 예상하십시오. EB는 각 서버에 개별적으로 업데이트를 롤아웃하여 서비스가 저하되지 않도록합니다.-Heroku가 새로운 dyno를 제공하고 더 이상 사용하지 않는 경우 모든 요청이 처리 될 때까지 오래된 서비스가 삭제됩니다.

   흥미롭게도 EB를 사용하여 여러 서버를 실행하는 호스팅 비용은 단일 애드온 비용보다 저렴할 수 있습니다. 특히 애드온 비용을 포함 시키면 더욱 그렇습니다.

구체적으로 묻지 않았지만 다른 답변으로 제기 된 다른 문제 :

1. 생산 및 개발을 위해 다른 공급자를 사용하는 것은 좋지 않습니다.

   나는 사람들이 이것을 제안하고 있다고 울고 있습니다. 이상적인 플랫폼은 가능한 한 모든 플랫폼에서 정상적으로 실행되어야하지만 가능한 한 이식성이 뛰어나지 만 각 호스트의 소프트웨어 버전은 매우 다양하며 준비 단계에서 코드를 실행한다고해서 프로덕션에서 실행되는 것은 아닙니다 (예 : 주요 Node.js / Ruby / Python / PHP / Perl 버전은 코드가 호환되지 않는 방식이 다를 수 있습니다.

   좋은 아이디어는 Heroku와 같은 것을 프로토 타이핑, 소규모 프로젝트 및 마이크로 사이트에 활용하는 것이므로 구성 및 유지 관리에 많은 시간을 투자하지 않고도 물건을 신속하게 구축하고 배포 할 수 있습니다.

   결정을 내릴 때 프로덕션 및 사전 프로덕션 인스턴스를 모두 실행하는 비용을 고려하여 전체 환경 (데이터 저장소 / 추가 기능, SSL 설치 및 구성 등의 타사 서비스 포함)을 복제하는 비용을 잊지 마십시오. .

2. AWS를 사용하는 경우 Bitnami와 같은 공급 업체의 AWS 사전 구성된 인스턴스에주의하십시오. 보안 악몽입니다. 그들은 설명에서 언급하지 않고 기본적으로 악명 높은 취약한 응용 프로그램을 많이 노출시킬 수 있습니다.

   대신 우분투 또는 데비안 (또는 RPM 지원이 필요한 경우 CentOS)과 같이 잘 지원되는 주류 배포판을 사용하십시오.

   참고 : Amazon 오퍼에는 RPM을 사용하는 Amazon Linux라는 자체 배포판이 있지만 EC2에 따라 다르며 타사 / 오픈 소스 소프트웨어에서 덜 지원합니다.

3. 또한 AWS (또는 Lightsail)에서 EC2 인스턴스를 설정하고 flynn 또는 dokku 와 같은 방식으로 구성 할 수 있습니다.이 사이트에서 여러 사이트를 쉽게 배포 할 수 있습니다. 서비스를 많이 유지하거나 원하는 경우 유용 할 수 있습니다 새로운 것을 쉽게 돌릴 수 있습니다. 그러나 설정하는 것은 Heroku를 사용하는 것만 큼 자동적이지 않으며 구성 및 유지 관리에 많은 시간을 소비 할 수 있습니다 (Amazon clustering 및 Docker Swarm을 사용하여 배포하는 것이 설정하는 것보다 쉽습니다). YMMV).

작업중인 프로젝트의 요구에 따라 AWS EC 인스턴스 (단독 및 클러스터), Elastic Beanstalk 및 Lightsail 및 Heroku를 동시에 사용했습니다.

서비스 구성에 시간을 소비하는 것이 싫지만 모든 용도로 사용하고 AWS가 적은 비용을 지불하면 Heroku 요금은 연간 수천 달러가됩니다.

tl; dr

돈이 결코 문제가되지 않았다면 Heroku는 거의 모든 시간을 절약 할 수 있기 때문에 거의 모든 것을 위해 Heroku를 사용하고 있지만 Heroku가 제공하지 않는 유연성과 고급 서비스가 필요한 복잡한 프로젝트에는 AWS를 계속 사용하고 싶습니다.

가장 이상적인 시나리오는 ElasticBeanstalk가 Heroku와 비슷하게 작동하는 경우, 즉 구성이 쉽고 빠르며 배포 메커니즘이 더 나은 경우입니다.

거의 비슷한 서비스의 예 는 now.sh 이며 실제로는 무대 뒤에서 실제로 AWS를 사용하지만 Heroku와 마찬가지로 배포 및 클러스터링을 쉽게 만듭니다 (자동 SSL, DNS, 우아한 배포, 매우 쉬운 클러스터 설정 및 조치).

Node.js 앱과 Docker 이미지 배포 모두에 꽤 많이 사용했습니다. 주목할 점은 인스턴스가 공유되고 (저비용에 반영된) 현재 전용 인스턴스를 구입할 수있는 옵션이 없다는 것입니다. 그러나 오픈 소스 배포 도구 '지금'을 사용하여 AWS 및 Google Cloud 및 Azure의 전용 인스턴스에 배포 할 수도 있습니다.

Heroku에서 AWS로 사람들을 마이그레이션하는 사업의 상당 부분을 차지했습니다. 두 가지 모두 장점이 있지만 잠시 후에 Heroku에 혼란스러워집니다 .Heroku의 한계로 더 이상 쉽게 유지할 수없는 특정 수준의 복잡성이 필요하면.

즉, 훌륭한 프레임 워크 / 도구를 사용하여 AWS를 사용함으로써 Heroku를 용이하게하고 AWS의 유연성을 제공하는 옵션이 점점 더 많아지고 있습니다.

재미있는 점은 Heroku가 실제로 백엔드에서 AWS를 사용한다는 것입니다. 모든 오버 헤드를 없애고 EC2에서 아키텍처 관리를 수행합니다. (인터뷰 중 대기업 수석 엔지니어의 지식을 얻었다)

잘! 필자는 Heroku가 신진 개발자 및 신생 개발자로 유명하지만 AWS는 개발자 페르소나를 발전 시켰습니다. DigitalOcean도이 분야의 주요 업체입니다. Cloudways는 DigitalOcean과 AWS를 클릭하면 Lamp 스택을 훨씬 쉽게 만들 수 있습니다. 한 번의 클릭으로 모든 서비스 및 패키지 업데이트를 수행하는 것이 모든 작업을 수동으로 수행하는 것보다 훨씬 낫습니다.

https://www.cloudways.com/blog/host-php-on-aws-cloud/ 에서 완전히 확인할 수 있습니다.

물론 Heroku는 백그라운드에서 AWS를 사용하며 필요한 솔루션 유형에 따라 다릅니다. 핵심 Linux 및 devops 사용자라면 palcement 옵션 등을 선택하는 것과 같은 vm을 처음부터 걱정하지 않아도 AWS와 함께 갈 수 있습니다. 그 순 결함을 가지지 않고 표면에서 일을하고 싶다면 헤 로쿠와 함께 갈 수 있습니다.

AWS (Amazon Web Services)는 99.9999999 %의 내구성과 데이터 및 인프라의 가용성을 보장하여 IaaS에서 PaaS에 이르는 다양한 서비스를 제공합니다. AWS는 개발자가 애플리케이션 배포 프로세스를 파이프 라인 할 수있는 여러 도구와 함께 인프라 자동화를 제공합니다.

반면에 Heroku는 클라우드에서 플랫폼을 관리하는 서비스를 제공하는 PaaS입니다. 인프라 또는 보안 여부에 관계없이 AWS와 관련이 없습니다.

때때로 사람들이 왜 AWS를 Heroku와 비교하는지 궁금합니다. AWS는 IAAS (서비스로서의 인프라)로서 시스템이 얼마나 강력하고 계산적인지를 명확하게 말해줍니다. 반면 Heroku는 SAAS 일 뿐이며 기본적으로 AWS 서비스의 일부일뿐입니다. 따라서 Heroku를 사용하여 첫 번째 제품을 주요 제품으로 배송 할 수있을 때 AWS를 설정하는 데 어려움을 겪는 이유는 무엇입니까?

Heroku는 무료이며 간단하며 거의 모든 유형의 스택을 웹에 쉽게 배포 할 수 있습니다. Heroku는 응용 프로그램을 라이브 서버로 신속하게 배송하는 모든 번거 로움을 우회하도록 특별히 설계되었습니다.

그럼에도 불구하고 두 당사자의 자습서를 사용하여 응용 프로그램을 배포하고 비교할 수 있습니다.

AWS DOCS 및 Heroku 문서

AWS와 Heroku는 모두 클라우드 플랫폼이지만 AWS는 IaaS이고 Heroku는 PaaS이므로 다릅니다.

Heroku는 AWS의 하위 집합과 같습니다. AWS는 서비스 수준의 플랫폼 일뿐 아니라 모든 수준에서 AWS로 구현할 수 있습니다.

구현은 비즈니스 요구 사항에 따라 다릅니다. 어느 쪽이든 들어가면 그에 따라 사용하십시오.