ProgramingTip

AWS가있을 때 사람들이 Heroku를 사용하는 이유는 무엇입니까?

bestdevel 2020. 9. 27. 13:18
반응형

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


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

나는 결혼식 웹 사이트를 방문하는 것이 중요하고 간단히 말해서 Heroku가하는 일은 확장에 도움이 될까요? Heroku는 다음을 어떻게 지원합니까?

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

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

  3. 밀리 링-실제로 어떻게 작동합니까?

  4. 비용 효율성-쉽게 확장 할 수있는 다이노와 같은 것이 있습니다.

  5. 경쟁자들과 어떻게 경쟁합니까? 예 : Engine Yardbluebox ?

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


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

아키텍처를 많이 사용자 지정하지 않고 바로 앱을 시작하기 위해 Heroku 를 선택합니다 .

아키텍처에 집중하고 다른 웹 서버를 사용할 수 있도록 구매하기 위해 AWS 를 선택하십시오 . AWS는 선택한 서비스 / 제품에 따라 시간이 더 많이 걸리지 만 그만한 가치가 있습니다. AWS는 또한 많은 추가 서비스 및 제품과 함께 제공됩니다.


Heroku

  • 서비스로서의 플랫폼 (PAAS)
  • 좋은 문서
  • 기본 제공 도구 및 아키텍처가 있습니다.
  • 앱을 디자인하는 동안 아키텍처에 대한 제어.
  • 배포가 처리됩니다 (GitHub를 통해 자동으로 또는 git 명령 또는 CLI를 통해 수동으로).
  • 시간이 많이 걸리지.

AWS

  • IaaS (Infrastructure as a Service)
  • 다용도 -EC2, LAMBDA, EMR 등록 같은 많은 제품이 있습니다.
  • OS, 소프트웨어 버전 등을 선택하는 등 아키텍처에 대한 더 많은 제어를 위해 전용 인스턴스를 사용할 수 있습니다. 백엔드 계층이 두 개 이상 있습니다.
  • Elastic Beanstalk는 Heroku의 PAAS와 기능입니다.
  • 자동화 된 배포를 사용하거나 직접 롤링 할 수 있습니다.

우선, AWS와 Heroku는 서로 관련되어 있습니다. AWS는 Infrastructure as a Service ( IaaS )를 제공하는 반면 Heroku는 Platform as a Service ( PaaS )를 제공합니다.

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

코드를 AWS에서 실행하고 Heroku 배포처럼 보이게 비용 청구 일부 EC2 인스턴스가 필요합니다. 여기에로드 밸런서 / 캐싱 계층 (예 : Varnish )을 설치 하고 다음과 같은 인스턴스를 실행하는 것이 좋습니다. Passengernginx 에서 코드를 제공하는 PostgreSQL 과 같은 클러스터형 데이터베이스 인스턴스를 배포하고 구성해야 합니다 . Capistrano 와 같은 배포 시스템과 로그를 수행하는 시스템이 필요합니다 .

설정 및 유지 관리에 많은 작업이 필요하지 않습니다. Heroku를 사용하면 단계에 도달하는 데 필요한 노력은 애플리케이션 코드 몇 줄과 git push.

그래서 당신은 여기까지 왔고, 당신은 확장하고 싶습니다. 큰. EC2 배포에 Puppet사용하고 계십니까? 이제 필요에 따라 인스턴스를 오르간 업 / 다운하도록 Capistrano 파일을 구성합니다. Varnish가 웹 인스턴스를 인식하고 이들 사이에서 자동으로 풀링 가능한 꼭두각시 구성을 다시 지그합니다. 아니면 당신 heroku scale web:+5.

이 둘 사이의 비교에 대한 아이디어를 얻을 수 있기를 바랍니다. 이제 특정 요점을 해결 비용 :

속도

현재 Heroku는 us-easteu-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 개의 webdyno와 10 개의 workerdyno가 실행됩니다. 간단하고 간단합니다. 참고 web외부 세계에 액세스 할 수있는 특별한 다이노 유형이며 자신의 좋은 웹 트래픽 멀티플렉서 (니스 / nginx를 조합의 아마 일종) 따라 그 의지 경로 트래픽입니다. 여기서는 라우팅을 통해 메시지 메시지와 상호 작용할 수 있고 여기에서 환경의 URL을 통해 위치를 얻습니다.

비용 효율성

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

Heroku가의 다이노에 설명서 따르면 약 5백12메가바이트의 RAM이 있으므로 다이노를 EC2 인스턴스와 같은 micro-것으로 간주하는 것이 너무 비합리적이지 않습니다 . 가격의 두 배의 가치가 있습니까? 시간을 얼마나 소중하게 생각하십니까? 이 표준에 도달하기 위해 IaaS 오퍼링 위에 구축하는 데 필요한 시간과 노력은 성능 수준이 없습니다. 이 질문에 실제로 답할 수는 없지만 설정 및 유지 관리의 '숨겨진 비용'을 과소 평가하지 않습니다.

(약간 제쳐두고, 여기에서 다이노에 연결하면 ( heroku run bash), 피상적 모양으로 4 개의 코어 /proc/cpuinfo와 36기가바이트의 RAM이 표시됩니다. 이로 인해 "고용량 메모리 이중 초대형 인스턴스" 에 있다고 믿게됩니다. " . Heroku가 다이노 설명서에 따르면 각 다이노 는 512MB의 RAM을 수신하고 최대 71 개의 다른 dyno와 공유 할 수 있습니다. (Heroku의 AWS 인스턴스의 동질성에 대한 데이터가 충분하지 않고 마일리지가 다를 수 있습니다))

경쟁자들과 어떻게 경쟁합니까?

이건 정말 도와 드릴 수 없네요. 제가 실제로 본 유일한 경쟁자는 구글 앱 엔진 이었습니다 . 자바 애플리케이션을 배포하려고 사용 가능한 프레임 워크와 기술에 대한 제한 이 엄청나게 맞지 가능성 이 있습니다. 이것은 "단순한 Java 일"이상입니다. 일반적인 제한 사항과 필요한 사항 ( FAQ 힌트 여러 개)이 편리하지 않을 것입니다. Heroku에 배포하는 꿈 이었죠.

결론

이 정보가 귀하의 질문에 대한 답변이 되었기를 바랍니다 (간격이 있거나 해결하고자하는 다른 영역이 있으면 의견을 남겨주세요). 제 개인적인 입장을 제시해야한다고 생각합니다. 저는 "빠른 배포"를 위해 Heroku를 좋아합니다. 응용 프로그램을 시작할 때 저렴한 호스팅을 원할 때 (Heroku 프리 티어는 굉장합니다-본질적으로 웹 다이노 하나와 PostgreSQL 5MB 만 필요한 경우 응용 프로그램을 호스팅하는 것은 무료입니다) Heroku는 내 위치입니다. . 여러 유료 고객과 서비스 수준 계약을 맺고 운영에 전념하는 시간이있는 "심각한 프로덕션 배포"의 경우 Heroku와 AWS 또는 우리 자신의 서버는 최고의 호스팅 플랫폼이었습니다.

즉, 귀하에게 가장 많은 것이 무엇인지에 대한 것입니다. 당신이 "초보 프로그래머"라고 말하면 Heroku를 사용하면 Ruby 작성에 집중할 수 있고 주변의 다른 모든 인프라를 구축하는 데 시간을 할 필요가 없습니다. 나는 확실히 그것을 시도 할 것입니다.


AWS에는 실제로 Ruby, Node.js, PHP, Python, .NET 및 Java를 지원 하는 PaaS 제품인 Elastic Beanstalk가 있습니다. 일반적으로 대부분의 사람들은 "AWS"를 볼 때 확실히 IaaS 제품인 EC2, S3 및 EBS와 같은 것으로 이동합니다.


Kristian Glass가 말했듯이 IaaS ( AWS )와 PaaS ( Heroku , EngineYard ) 는 수 없습니다 .

PaaS는 기본적으로 개발자가 앱 개발 속도를 높이는 데 도움이되는 중요한 구성을 설정하고 서버 및 데이터베이스와 같은 항목을 관리하는 비용을 절감하고 가장 비용이 많이 드는 애플리케이션 및 비즈니스를 혁신하는 것입니다. PaaS를 사용하기 위해 구매하는 다른 기능은 민첩성, 고 가용성, 모니터링, 확장 / 제거, 전문 지식에 대한 배치, 손쉬운 배포, 비용 및 개발 시간 감소와 같은 애플리케이션 배포 프로세스입니다.

그러나 PaaS에 대한 장벽을 이끄는 PaaS에는 여전히 어두운면이 있습니다.

  • 서버 및 데이터베이스에 대한 제어 감소
  • 유 전적으로 관리되지 않는 비용이 매우 효율적입니다.
  • 현재 시대에 이르고 의심스러운

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

  • 하드웨어 금액
  • 운영 소모품
  • 서버 소프트웨어
  • 서버 측 스크립팅 환경
  • 웹 서버
  • 데이터베이스 관리 시스템 (Mysql, Redis 등)
  • 서버 서버 구성
  • 테스트 및 배포 용 도구
  • 모니터링 앱
  • 고 가용성
  • 블랭킹로드 / Http 라우팅
  • 서비스 백업 정책
  • 팀 협업
  • 생산 재건

소규모 비즈니스를 운영하는 경우 PaaS가 최상의 옵션입니다.

  • 당신이가는대로 지불
  • 낮은 시작 비용
  • 배관은 전문가에게 맡기십시오
  • PaaS는 Auto Scaling / Decaling,로드 밸런싱, 재해 복구를 처리합니다.
  • PaaS는 모든 보안 요구 사항을 관리합니다.
  • PaaS는 안정성, 고 가용성을 관리합니다.
  • Paas는 많은 추가 기능을 관리합니다.

요구 사항에 따라 개별적으로 선택됩니다. 내 PPT Hosting Rails Apps 에 대한 세부 정보를 얻을 수 있습니다 .


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

내 설명이 이해하기 쉽도록 구성표를 추가했습니다.


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

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

저는 하루에 8 백만 개 이상의 고유 항목을 서비스하고 막대한 $ MM IT 인력이 자본 하드웨어에서 $ 250,000부터 시작하는 인프라를 기반으로 구축 된 테라 바이트의 비디오를 제공하는 웹 사이트를 설계했습니다.

그러나 나는 또한 연간 $ 10- $ 20k를 생성하도록 설계된 더 작은 웹 사이트를 가지고 있었고, 트래픽, db 또는 처리 요구 사항이 매우 높지 않았으며,이를 손상없이 $ 10 / 월 일반 호스팅 계정에서 실행했습니다.

앞으로 배포는 진행 상황에서 AWS보다 Heroku와 비슷해 보일 것입니다. 점점 더 자동화되지 않는 확장 인터넷 인프라의 IT 조정에는 가치가 없으며 제공하는 제품 또는 서비스의 가치와 관련이 없습니다.

또한 상업용 웹 사이트를 염두에 두십시오. 확장 성은 우리가 종종 '좋은 문제'라고 부르는 것입니다. Facebook 및 Twitter와 같은 사이트의 확장 성 문제는 매우 중요했지만 성공에 부정적인 영향을 미치지 않았습니다. 더 많은 가입에 기여 했을 수도 있습니다 (모든 언론이 좋은 언론입니다).

하루에 10 만 개 이상의 고유 항목을 생성하고 확장 문제가있는 서비스가있는 경우 실행중인 언어, DB, 플랫폼 또는 인프라에 관계없이이 서비스를 제거하게되어 기쁩니다!

확장 성은 수정 가능한 구현 문제입니다. 고객이없는 것은 실존적인 문제입니다.


기존 답변은 광범위하게 정확합니다.

  • Heroku는 사용 및 배포가 매우 쉽고 저장소 (예 : GitHub)를 자동 배포하도록 쉽게 구성 할 수 있으며 많은 타사 추가 기능이 있으며 인스턴스 당 더 많은 비용이 청구됩니다.

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

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

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

EB를 사용한 배포는 매우 느립니다. 업데이트를 배포하는 데는 서버 당 10-15 분이 걸릴 수 있으며 더 큰 클러스터에 배포하는 데는 Heroku에 업데이트를 배포하는 데 몇 초 밖에 걸리지 않는 데 비해 1 시간이 가장 많이 소요될 수 있습니다. EB에 대한 배포는 특히 원활하게 처리되지 않으므로 애플리케이션 설계에 제약이있을 수 있습니다.

ElasticBeanstalk가 백그라운드에서 사용하는 모든 서비스를 사용하여 맞춤형 시스템을 구축 할 수 있지만 (CodeDeploy, Elastic Load Balancer, Auto Scaling 그룹 및 CodeCommit, CodeBuild 및 CodePipeline (모두 사용하려는 경우 CodePipeline 포함))을 사용할 수 있습니다. EC2에서 구성하는 것보다 상당히 복잡하고 약간 더 까다롭기 때문에 처음으로 설정하는 데 몇 주가 걸립니다.

AWS Lightsail은 경쟁력있는 가격의 호스팅 옵션을 제공하지만 배포 또는 확장에는 도움이되지 않습니다. 실제로 EC2 제품의 래퍼 일뿐입니다 (하지만 훨씬 더 많은 비용이 듭니다). 초기 설정시 bash 스크립트를 자동으로 실행할 수 있습니다. 이것은 좋은 터치이지만 EC2 인스턴스를 설정하는 비용 (프로그래밍 방식으로도 수행 할 수 있음)에 비해 비용이 많이 듭니다.

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

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

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

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

    자동 배포를 위해 ElasticBeanstalk를 사용할 수도 있지만 처음 설정하는 데 1 주일이 소요될 수 있습니다. ElasticBeanstalk가 배포를 처리하거나 로직을 빌드하는 방법을 사용하려면 CSS 및 JS와 같은 자산을 배포하고 빌드하는 방법을 변경해야 할 수도 있습니다. 배포를 처리 할 수 ​​있습니다.

    EB에서 중단없이 원활한 배포를 위해서는 여러 인스턴스를 실행해야합니다. EB는 서비스가 저하되지 않도록 각 서버에 개별적으로 업데이트를 롤아웃합니다. 이전 서비스에 대한 모든 요청이 처리 될 때까지 (그런 다음이를 삭제합니다).

    흥미롭게도 EB로 여러 서버를 실행하는 호스팅 비용은 특히 추가 기능 비용을 포함하면 단일 Heroku 인스턴스보다 저렴할 수 있습니다.

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

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

    나는 사람들이 이것을 제안하고 있다고 믿습니다. 이상적으로 코드는 합리적인 플랫폼에서 잘 실행되어 가능한 한 이식 가능해야하지만, 각 호스트의 소프트웨어 버전은 크게 다를 수 있으며 코드가 스테이징에서 실행된다고해서 프로덕션에서 실행된다는 의미는 아닙니다 (예 : 주요 Node.js / Ruby / Python / PHP / Perl 버전은 코드를 호환되지 않게 만드는 방식이 다를 수 있으며, 적절한 테스트 범위가 있어도 잡히지 않을 수있는 조용한 방식으로 종종 있습니다.

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

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

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

    대신 Ubuntu 또는 Debian (또는 RPM 지원이 필요한 경우 CentOS)과 같이 잘 지원되는 주류 배포판을 사용하는 것이 좋습니다.

    참고 : Amazon 제안에는 RPM을 사용하는 Amazon Linux라는 자체 배포판이 있지만 EC2에 한정되어 있으며 타사 / 오픈 소스 소프트웨어에서 잘 지원되지 않습니다.

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

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

나는 서비스를 구성하는 데 시간을 보내는 것이 싫지만 모든 것에 사용하고 AWS가 비용의 일부를 처리한다면 Heroku 청구서는 연간 수천 달러가 될 것입니다.

tl; dr

돈이 문제가되지 않았다면 거의 모든 작업에 Heroku를 사용하여 시간을 절약 할 수 있었지만 Heroku가 제공하지 않는 유연성과 고급 서비스가 필요한 더 복잡한 프로젝트에는 여전히 AWS를 사용하고 싶습니다.

저에게 이상적인 시나리오는 ElasticBeanstalk가 Heroku와 비슷하게 작동하는 것입니다. 즉, 더 쉬운 구성과 더 빠르고 더 나은 배포 메커니즘으로 작동합니다.

거의 이와 같은 서비스의 예 now.sh 입니다. 실제로는 백그라운드에서 AWS를 사용하지만 Heroku 에서처럼 쉽게 배포 및 클러스터링을 수행 할 수 있습니다 (자동 SSL, DNS, 단계적 배포, 매우 쉬운 클러스터 설정 및 조치).

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


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

Heroku와 AWS를 모두 사용한 실험은 다음과 같습니다. 빠른 검토 및 비교 :

Heroku

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

AWS-EC2

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

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

  • Elastic Beanstalk는 2010 년부터 공개 베타로 발표되었습니다. 배포 작업을 더 쉽게 수행 할 수 있습니다. 자세한 내용은 여기 로 이동 하세요

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

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

요약

  • Heroku : 처음에는 쉽고 무료 인스턴스이지만 나중에는 비쌉니다.
  • AWS : 쉽지 않음, 무료 사용 가능 시간, 다소 저렴함 , Beanstalk는 사용에 대해 걱정해야합니다.

그래서 현재의 시스템에서는 스테이징에 Heroku를 사용하고 프로덕션에 Beanstalk를 사용합니다!


Heroku에서 AWS로 사람들을 마이그레이션하는 것은 우리 비즈니스의 상당 부분이었습니다. 둘 다 장점이 있지만 잠시 후 Heroku에서 지저분 해집니다 ... 특정 수준의 복잡성이 필요하면 Heroku의 한계로 더 이상 유지하기가 쉽지 않습니다.

즉, 뛰어난 프레임 워크 / 도구를 갖춘 AWS에서 Heroku의 용이성과 AWS의 유연성을 얻을 수있는 옵션이 점점 더 많아지고 있습니다.


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


잘! 나는 관찰자 Heroku는 신생 개발자와 새로 태어난 개발자로 유명하고 AWS는 개발자 페르소나를 발전시켰다. DigitalOcean은 또한이 분야의 주요 업체입니다. Cloudways를 사용하면 DigitalOcean 및 AWS에서 클릭 한 번으로 램프 스택을 훨씬 쉽게 만들 수 있습니다. 클릭 한 번으로 모든 서비스 및 패키지 업데이트를하는 것이 모든 작업을 수동으로 수행하는 것보다 훨씬 낫습니다.

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


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

반면에 Heroku는 클라우드에서 플랫폼을 관리하는 서비스를 제공하는 PaaS 일뿐입니다. 인프라 든 보안이든 AWS와 함께 할 곳은 없습니다.


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

Heroku는 무료이며 간단하며 거의 모든 유형의 스택을 웹에 배포하기 쉽습니다. Heroku는 애플리케이션을 라이브 서버로 신속하게 배송하는 모든 번거 로움을 우회하도록 특별히 제작되었습니다.

그럼에도 불구하고 양측의 튜토리얼 중 하나를 사용하여 애플리케이션을 배포하고 비교할 수 있습니다.

AWS DOCSHeroku 문서


Heroku는 백그라운드에서 AWS를 사용하며 필요한 솔루션 유형에 따라 다릅니다. 핵심 Linux 및 devops 사람이라면 ami가 palcement 옵션을 선택하는 것과 같이 처음부터 VM을 만드는 것에 대해 걱정하지 않아도 AWS를 사용할 수 있습니다. 그 넷 티그 리티없이 표면 수준에서 일을하고 싶다면 heroku와 함께 갈 수 있습니다.


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


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

구현은 비즈니스 요구 사항에 따라 다릅니다. 둘 중 하나에 맞으면 그에 따라 사용하십시오.

참고 URL : https://stackoverflow.com/questions/9802259/why-do-people-use-heroku-when-aws-is-present-what-distinguishes-heroku-from-aws

반응형