Google App Engine의 장단점

Google App Engine의 장단점

---

[2009 년 8 월 21 일 업데이트 된 목록]

Google App Engine에서 애플리케이션을 빌드 할 때의 모든 장점 및 단점 목록을 작성하도록 도와주세요.

장점 :

1. 서버 또는 서버 공간을 구매할 필요가 없습니다 (유지 관리 없음).
2. 스케일링 문제를 더 쉽게 해결합니다.
3. 소비 된 리소스의 일정 수준까지 확보합니다.

단점 :

1. Google App Engine에 잠겨 있습니까?
2. 개발자는 App Engine의 파일 시스템에 대한 읽기 전용 액세스 권한이 있습니다.
3. App Engine은 HTTP 요청에서 호출 된 코드 만 실행할 수 있습니다 (예약 된 백그라운드 작업 제외).
4. 사용자는 임의의 Python 모듈을 업로드 할 수 있지만 순수한 Python 모듈 인 경우에만 가능합니다. C 및 Pyrex 모듈은 지원되지 않습니다.
5. App Engine은 항목에서 반환되는 최대 행을 Datastore 호출 당 1000 행으로 제한합니다. ( 업데이트 -이제 App Engine에서 더 큰 쿼리에 액세스하기위한 커서 지원)
6. Java 응용 프로그램은 JRE Standard Edition 클래스의 하위 집합 (JRE Class White List) 만 사용할 수 있습니다.
7. Java 애플리케이션은 새 스레드를 작성할 수 없습니다.

알려진 문제 !! : http://code.google.com/p/googleappengine/issues/list

엄격한 한계

개발자 당 앱-
요청 당 10 회-앱당 30 초
파일-3,000
HTTP 응답 크기
-10MB 데이터 저장소 항목 크기-1MB
애플리케이션 코드 크기 -150MB
업데이트 Blob 저장소에서 이제 최대 50MB의 파일을 저장할 수 있습니다.

찬반 양론?
App Engine의 인프라는 애플리케이션을 구축하는 데 따르는 많은 시스템 관리 및 개발 과제를 제거하여 수백만 히트까지 확장 할 수 있습니다. Google은 필요에 따라 클러스터에 코드 배포, 모니터링, 장애 조치, 애플리케이션 인스턴스 시작을 처리합니다.

다른 서비스를 통해 사용자는 거의 모든 * NIX 호환 소프트웨어를 설치하고 구성 할 수 있지만 App Engine에서는 개발자가 Python 또는 자바를 프로그래밍 언어로 사용하고 제한된 API 집합을 사용해야합니다. 현재 API를 사용하면 BigTable 비 관계형 데이터베이스에서 데이터를 저장하고 검색 할 수 있습니다. HTTP 요청 만들기 이메일 보내기; 이미지 조작; 및 캐싱. 대부분의 기존 웹 애플리케이션은 관계형 데이터베이스가 필요하기 때문에 수정없이 App Engine에서 실행할 수 없습니다.

---

장점 :

• 확장 가능
• 쉽고 저렴합니다 (단기적으로).
• 신생 기업 / 개인을위한 좋은 옵션.
• 데이터를 저장하고 검색하는 앱에 적합합니다.

단점 :

• CPU 집약적 인 계산에는 적합하지 않습니다. 느리고 비싸다.
• 확장 성은 앱이 Google 규모에서 작동하는 경우 그다지 중요하지 않습니다. 그러면 자체 서버에서 실행하기에 충분한 돈을 벌 수 있습니다.
• 여기저기서 많은 제한이 있습니다. 결과적으로 심층 데이터 분석이 어렵습니다. GAE를 사용하여 소셜 그래프를 생성 할 수 없습니다.

나는 그것이 심각한 사업을 의미하지 않고 장기적으로 비싸다고 말할 것입니다.

---

(큰 새로운) PRO : GAE는 이제 MySQL을 지원합니다 : https://developers.google.com/cloud-sql/

---

장점 :

• 통합 로그를위한 내장 UI

• 작업 대기열을위한 내장 웹 인터페이스

• 기본 개체 목록의 기본 제공 인덱스.

단점 :

• 로그를 매우 빠르게 느슨하게

• 매우 비싸다

• 매우 비싸다

• 매우 비싸다

• 해킹 불가. 확장하는 방식으로 코딩해야하기 때문에 확장됩니다.

• 더 긴 개발주기. 때로는 무언가를 함께 해킹하고 5 시간 후에 버려야 할 때가 있습니다. appengine을 사용하면 적절한 코드를 작성하고 확장 할 수 있도록 많은 항목을 작성해야합니다. "find. | grep .avi | xargs ffmpeg -compress ...."만 수행 할 수 없습니다. :)

• APNS (iPhone)에 푸시 알림을 보내는 것과 같은 가장 간단한 작업을 수행하는 데 시간을 낭비하게됩니다. 앞으로 안드로이드 만 지원하고 싶다면 괜찮습니다.

• 데이터베이스 정리가 끔찍합니다. 주로 매우 느리기 때문에 데이터베이스의 행을 수정하는 것은 엄청난 고통이지만 시간 제약 내에서 적절하게 반복하려면 많은 코드가 필요합니다.

• "파일 시스템"에서 작업하기 위해 Lucene을 이식하는 것은 고통 스러웠습니다.

• Slow for what you pay.

• Even MORE expensive if your app has spikes of traffic. My app has those spikes if a user that has many followers makes an action and we have to push notifications to his followers. Because of that I have to keep 10 inactive servers always on ($$$$$) to handle spikes.

Appengine isn't too bad due to the fact that I have the option to burn $$$$ instead of being concerned about scalability and fixing bottlenecks to reduce server usage. Sometimes it worth it.

My advice to people starting new products is to go with hetzner.de which is where I host my other products servers. It's cheap and extremely hackable. I have one server at hetzner that is handling 3x more traffic than the product that I have on appengine. The difference in price is $100 a month versions $2700 a month!

I have system admin experience, so the bottom line is that I would never choose appengine over having my own ROOT server. Don't be that bored software engineer wanting to experiment new things instead of building great products!

---

Pro: Unlimited scalabity to your application and scales with demand.

---

Con: Not available in some countries (Argentina).

Edit

Available worldwide, but only through Google Groups for App Engine.

---

When assessing pros and cons, I think it is important to clarify the market for which one is representing. Developers looking for a cost-effective solution to help them with the steep part of their planned hockey-stick growth curve will weigh heavily the cons already listed. For a small business owner, however, GAE is a God-send. These folks most often are looking to "the cloud" as a means to more effectively run their business (i.e. sell physical product and services). For the SMB, GAE the pros already listed can be much more valuable compared to the hockey-stick seeking dev, whilst the cons weight in at a fraction of the devs' measure. I don't see the GAE team doing anything related to SMB positioning, so I guess answers like this are me just pulling on Superman's cape, and spitting into the wind. Really GAE should be absolutely ruling the SMB space now. If not (I have no insights re: user base), then its is a greatly lamentable failure.

---

I believe , GAE is yet to mature in terms of providing the basic features for serious business such as Datastore with complex primary key, java.awt.* support, these are just a few I'm naming.

Other than the free space and to build some "Hobby" websites, I strongly feel GAE is NOT the place java guys should looking into.

I'm having applications built on the JSP/Servlets and MySQL, thinking about migrating to GAE, but I find I will be spending more "value time" on the migration than just buying a space from some java hosting provider such as EATJ, etc (Sorry not marketing, just an experience).

Another big issue I've got is migration of my existing mySQL data into GAE, bulkupload is really pathetic and has no client support.

No support for Local Db to Server DB upload.

Once the GAE is ready with "all the Cons" mentioned by above, then I'll think we can look in to this migration.

---

You are force to own a cell phone line, and your country+carrier must be able to receive international SMSs.

(I hate cell phones, and my mom's or co-workers won't get the SMSs)

---

Con: No Other RDBMS or NoSQL databases are not possible ....

---

Con: All your base are belong to us

... On a serious note:

Con: You don't control the environment your application runs in. The same cons as with outsourcing any component. Fun for toys, not for business (yet) IMHO.

Various things like API for Google proprietary backends such as their database system and other 'lockdowns' and frameworks that mean your code is tied, in some loose sense to their system can create cost issues later if you want to migrate from GAE. Of course, you could abstract these.

I like GAE, AppJet and others. They are cool. But everything has its place. If you want freedom and the ability to control your language's modules, API, syntax/stdlib versions and whatnot ... don't relinquish control to a service provider.

The lack of standards for environments and specifications for what your app can expect worries me in the cloud arena.

common sense stuff really.

---

Con: Limited to Java and Python

참고URL : https://stackoverflow.com/questions/1306279/pros-cons-of-google-app-engine