구글 앱 엔진(Google App Engine 이하 GAE)이 런칭했다. 총 6편의 캠프파이어 원 동영상을 보고 샘플 애플리케이션을 만들어보면서 적잖이 놀랐다. 이거 물건이다.
<프리젠테이션 동영상>
Campfire One: Introducing Google App (pt. 1)
Campfire One: Introducing Google App (pt. 2)
Campfire One: Introducing Google App (pt. 3)
Campfire One: Introducing Google App (pt. 4)
Campfire One: Introducing Google App (pt. 5)
Campfire One: Introducing Google App (pt. 6)
<코드 시연 동영상>
Developing and deploying an application on Google App Engine
아마존 웹 서비스(Amazon Web Service 이하 AWS)의 존재가 그 동안 구글의 심기를 건드려왔을 것이다. 스타트업 애플리케이션 호스팅 시장을 아마존이 키워가고 있는데 구글이 손놓고 있다는 것이 좀 의아했었다. 경쟁 서비스를 준비하고 있을 거라 많은 사람들이 예측해왔지만 GAE는 그 예상보다 훨씬 얍삽한 형태를 하고 있다.
커널 가상화를 통해 OS 자체에 root 계정으로 접근할 수 있는 AWS와 달리 GAE는 사용자 계정 기반인 데다가 개발자가 OS 환경에 직접 접근할 수 없고 애플리케이션 배포에 특화된 제한된 환경 내에서 제한된 커멘트만 사용할 수 있다. 웹 어드민 외에는 콘솔도 제공되지 않는 것 같다. 이 부분은 전형적인 웹 호스팅을 닮았다.
파이썬 런타임만 제공되고 있고 관계형 데이터베이스도 사용할 수 없으며 스토리지도 단순한 파일시스템이 아니라 GFS(Google File System)를 사용한다. GAE 환경 내의 다른 파일에 접근할 수 없고(프레임워크 외에) 내가 직접 업로드하거나 애플리케이션을 통해 업로드된 파일에만 접근할 수 있다.
데이터베이스를 사용할 수 없는 대신 Bigtable이라 하는 Datastore를 사용한다. 아마존이 Simple DB라는 별도의 서비스로 런칭한 데이터 저장소 개념을 GAE는 내장하고 있을 뿐만 아니라 그것을 강제하고 있다.
Bigtable은 GQL이라는 쿼리 랭귀지를 사용하며 SQL과 문법이 거의 유사하지만 몇 가지 차이점이 있다. join 등의 구문을 제공하지 않고 데이터 타입을 새로 정의할 수 있다. Bigtable은 개발자가 머신 레벨까지 생각할 필요도 없고 Scalability가 이미 고려된 Computing/Datastore Cloud 위에서 애플리케이션만 작성하면 된다.
멀티 쓰레딩이나 퍼포먼스에 신경쓸 필요가 없으며, 자기네가 다 해준다고 강조한다. 테이블이나 스키마를 생성할 필요가 없고 애플리케이션의 모델 클래스에서 정의된 어트리뷰트 명세에 맞춰 데이터를 Bigtable에 저장하고 탐색한다.
레일스를 빗대자면, database.yml이나 migration 파일들이 필요 없어지는 것이다. 대신 schema.rb에 들어있던 명세들이 모델 클래스로 옮겨갈 것이다. 이런 생각들을 하다보니 문득 아마존의 Simple DB에 구미가 당겼다. 내 상상과 실제가 같은지 다른지 한 번 적용해봐야겠다.
GAE의 환경이 일반적인 OS위에 랭귀지와 라이브러리가 설치된 형태가 아니라 배포환경, 랭귀지, 프레임워크, 어드민 콘솔, 버전관리 등이 하나의 패키지로 통합된 모습을 보여주기 때문에 랭귀지 런타임을 추가하거나 지원하는 프레임워크를 추가하는 것이 간단한 문제가 아닌 듯 하다.
예를 들면 현재 파이썬을 지원한다고 해서 파이썬 기반의 프레임워크를 마음대로 설치해서 사용할 수 있는 것이 아니고 Django 0.96 버전을 사용하거나 GAE에가 자체적으로 제공하는 파이썬 프레임워크인 webapp을 사용해야 한다. 파이썬 2.5 표준 라이브러리를 제공하지만 OS 레벨이나 네트워크, 파일시스템에 대한 호출 함수는 제약이 주어진다고 공지하고 있다.
루비나 PHP가 지원된다고 해도 모든 GAE 환경이 새로 작성되어야 할 것 같다. 내장 서버와 버전관리, 어드민 등을 담고 있는 SDK부터도 루비로 재작성되어야 한다. 레일스가 GAE에 올라갈 수 있을지도 조금 걱정스럽다. DB를 안 쓰니 ActiveRecord 코드를 새로 쓰거나 Bigtable용 어답터를 지원하거나 다른 프레임워크로 대체되어야 한다.
webapp을 보니 루비의 Camping과 닮았다. 어줍잖은 예측을 해보자면, GAE의 차기 지원 랭귀지는 루비, 지원 프레임워크는 Camping이나 Camping을 참고로 만든 webapp for ruby가 아닐까.
배포하고자 하는 애플리케이션에 추가 라이브러리가 필요할 경우 분명 문제가 될텐데(GAE 환경에 뭔가를 새로 설치하는 것이 불가능해보인다. 업로드는 가능하지만) 내가 알기론 파이썬은 라이브러리가 하나의 py 파일로 배포되는 경향이 있기 때문에 이런 제약을 극복할 수 있다. 애플리케이션 폴더에 라이브러리 py파일을 넣어두고 배포하면 해당 라이브러리를 사용할 수 있기 때문이다.
만약 차후에 GAE가 루비 런타임과 레일스 프레임워크도 지원하게 된다 해도 GEM페키지는 사용하기 어려울 듯 하고 vender/plugin에 담아 한꺼번에 배포하는 방법밖에 없을 것이다. ImageMagick 등의 C기반 라이브러리 설치가 필요할 땐 어떻게 해야 할까. 몇 가지 주요 라이브러리를 기본적으로 설치해줄 것 같긴 하지만, 분명 필요한 라이브러리를 자유롭게 설치할 수 없다는 점은 제약요소다. 이런 경우는 AWS가 더 좋은 선택이 될 것이다. 아래 코드는 webapp을 사용한 예제 애플리케이션이다.
파이썬은 지난 달 애자일 컨설팅의 교육과정을 통해 페어 프로그래밍을 해본 적도 있고, 워낙 루비 코드와 닮았기 때문에 코드를 보거나 작성하는 데 어려움은 없었다. webapp코드를 MVC 관점에서 관찰해보자면, 라우팅과 모델, 컨트롤러가 한 파일에 들어있다. 원하면 뷰도 컨트롤러 안에 넣을 수 있다. 파이썬은 개행문자를 포함한 문자열을 변수에 담거나 인자로 넘길때 세 개의 큰 따옴표를 자주 쓴다. """이 안에 뷰를 표현할 html 테그를 넣는 것이다""".
라우팅은 webapp.WSGIApplication이 담당하고, webapp.RequestHandler를 인자로 받는 class가 라우팅된 요청을 처리하는 액션(레일스의 용어로)이다. post와 get 메서드를 정의하면 해당 http 메서드 종류에 따라 실행을 해준다. Database가 아니라 Datastore를 사용하기 때문에 스키마 정의 대신 모델 클래스에서의 어트리뷰트 정의만 있다. ORM과 비슷한 느낌으로 사용하면 될 듯 하다.
이 구문은 사실 GQL로 작성되어야 하는 부분인데 파이썬 메서드로 매핑이 되었다. 관계형 데이터베이스를 쓴다면 ORM이라는 용어가 적합하지만 오브젝트가 둥둥 떠다니는 데이터 저장소의 쿼리를 매핑하는 이런 메서드를 뭐라고 불러야 할까. 위의 코드는 아래의 코드의 동일한 동작을 한다.
webapp은 루비의 Camping처럼 경량 프레임워크이므로 한 파일 안에 담는 것이 탐색이 빠르다. 애플리케이션이 복잡해지면 webapp은 좋은 선택이 아닌 것 같다. python을 사용해본 김에 Django를 설치해서 프로젝트를 만들어보았는데, 레일스와 유사할 거라는 기대와는 달리 프로젝트-애플리케이션으로 분리된 구조가 조금 낯설다. Django는 나중에 봐야겠다. 레일스의 erb처럼 webapp도 템플릿 엔진이 있다. 실행할 코드를 {% %}에, 치환할 코드를 {{ }}에 담는다.
구글이 얼마전에 인수한 Jaiku를 GAE 위에 올려놓은 모습을 시연했고 곧 프로덕션 환경에도 적용한다고 했다. Builtwith에 검색해보니 Jaiku는 PHP인데 GAE에 어떻게 올렸는지 궁금하다. 혹시 파이썬 다음은 PHP? 또 웹 어드민을 보여주었는데 로드 모니터링 그래프와 로그 데이터, 그리고 Datastore의 데이터 목록을 볼 수 있다. 고작 admin일 뿐인데도 무려 Ajax를 써서 사용성을 높였다.
애플리케이션 개발이 끝나면 커멘드 한 줄로 배포할 수 있다. 현재는 SDK를 이용해 로컬에서 개발만 해볼 수 있고(대기자 상태) 배포는 좀 기다려야 해볼 수 있을 것 같다. 배포하는 순간순간 코드 히스토리가 저장이 되어서 배포 자체가 버전관리 commit의 역할을 하는 것 같다. 웹 어드민을 통해 코드를 롤백하는 모습을 시연했다. 협업을 고려했는지는 더 살펴봐야겠다.
부가적이지만 강력할 수 있는 몇 가지 지원을 보자면, 내 애플리케이션에 구글 계정으로 로그인할 수 있도록 webapp상에서 지원을 하고 있고, sending mail도 프레임워크에 내장되어 있다. Google Apps와 연동하면 도메인이나 계정관리도 용이할 것 같다.
500MB storge, 10GB Bandwidth in&out/day. 5 million PV/1month까진 공짜고 Capacity를 늘릴 때 비용을 지불하게 만들 계획이다. 대용량 업/다운로드 지원이 추가되고 다른 랭귀지 런타임이 추가되고 오프라인 프로세싱(구글 기어스와 연동된다는 이야기일듯) 지원도 추가된다고 한다. 시작하기엔 더없이 매력적인 조건이다. AWS의 EC2가 $0.10 per GB - data transfer in / $0.18 per GB - data transfer out 이고 S3가 $0.15 per GB - Month of storage used 이니 비교해볼 수 있다.
GAE는 '애플리케이션이나 잘 만들라'고 말한다. 머신 뿐만 아니라 스케일과 로드 벨런싱, 멀티 쓰레딩, 사용자 계정이나 메일 시스템, 배포, 버전관리, 쿼리 최적화, 모니터링 어드민까지 다 해줄테니 애플리케이션이나 잘 만들라고 말한다. 기존에는 애플리케이션을 잘 만들어도 쿼리를 최적화해야했고 시스템 엔지니어링이라 불리는 서버 관리를 해야 했는데 이제 하지 말라고 한다.
개발 효율성이 증대되고 고용 비용이 감소하면 비즈니스 기회가 증가할 것이다. 그런데 반대로 생각해보면, 고용해야 했던 인력들이 이제는 필요 없어지는 것이고 고용 안정성은 떨어질 수 있다고 볼 수 있다. 경험과 노하우를 가진 인력이 필요했던 분야가 패키지화된 외부 솔루션으로 대체되는 상황은 비용 감소와 기회 증대, 고용 감소를 동시에 야기한다.
GAE나 AWS 뿐만 아니라 오픈소스나 프레임워크 등 이 바닥에서 일어나는 많은 일들이 이런 방향을 향하고 있는 것 같다. 개발자는 자신의 포지션을 골수 엔지니어에서 비즈니스 엔지니어로 전환시켜야 하지 않을까. 같은 직급, 같은 개발일을 하더라도 스스로의 역할이 비즈니스에 가까울수록 피고용자 보다는 고용자에 가까워지고, 고용 안정성보다는 기회 증대가 중요해지니 위의 흐름과 같은 방향을 향하게 되지 않을까.
데이터 베이스를 천덕꾸러기 취급하는 AWS와 GAE를 보자면, Database의 시대가 가고 Datastore의 시대가 도래하고 있구나 싶다. 저렴하고 간단한 Deployment와 Scalability를 동시에 고려해야 하는 스타트업에게 AWS와 GAE는 매력적인 선택이다. Customization에 강한 대신 계정관리와 설정, 배포가 복잡한 AWS, 제약이 많은 대신 모든 것이 심플한 GAE, 그리고 두 서비스가 강조하는 Scalability.
그리고 한 가지 아이러니. 'Campfire' One에서 보여준 애플리케이션 중 하나는 37signals의 'Campfire'을 모방한 것이었다. GAE app gallery 페이지에 비난 덧글이 좀 보인다. 상용화할 생각 없이 시연을 위해 개발한 듯 하지만 이런 반응을 예측할 수 있었을텐데.
update: likejazz님의 포스트에 좋은 분석글이 링크되어 있다. 전반부는 일반적인 이야기고 후반부의 'It's not all good'부터 읽어볼 만 하다. GAE의 가장 큰 맹점은 애플리케이션이 구글 플랫폼에 발이 묶인다는 점인데 그걸 잘 짚고 있다.
<프리젠테이션 동영상>
Campfire One: Introducing Google App (pt. 1)
Campfire One: Introducing Google App (pt. 2)
Campfire One: Introducing Google App (pt. 3)
Campfire One: Introducing Google App (pt. 4)
Campfire One: Introducing Google App (pt. 5)
Campfire One: Introducing Google App (pt. 6)
<코드 시연 동영상>
Developing and deploying an application on Google App Engine
아마존 웹 서비스(Amazon Web Service 이하 AWS)의 존재가 그 동안 구글의 심기를 건드려왔을 것이다. 스타트업 애플리케이션 호스팅 시장을 아마존이 키워가고 있는데 구글이 손놓고 있다는 것이 좀 의아했었다. 경쟁 서비스를 준비하고 있을 거라 많은 사람들이 예측해왔지만 GAE는 그 예상보다 훨씬 얍삽한 형태를 하고 있다.
커널 가상화를 통해 OS 자체에 root 계정으로 접근할 수 있는 AWS와 달리 GAE는 사용자 계정 기반인 데다가 개발자가 OS 환경에 직접 접근할 수 없고 애플리케이션 배포에 특화된 제한된 환경 내에서 제한된 커멘트만 사용할 수 있다. 웹 어드민 외에는 콘솔도 제공되지 않는 것 같다. 이 부분은 전형적인 웹 호스팅을 닮았다.
파이썬 런타임만 제공되고 있고 관계형 데이터베이스도 사용할 수 없으며 스토리지도 단순한 파일시스템이 아니라 GFS(Google File System)를 사용한다. GAE 환경 내의 다른 파일에 접근할 수 없고(프레임워크 외에) 내가 직접 업로드하거나 애플리케이션을 통해 업로드된 파일에만 접근할 수 있다.
데이터베이스를 사용할 수 없는 대신 Bigtable이라 하는 Datastore를 사용한다. 아마존이 Simple DB라는 별도의 서비스로 런칭한 데이터 저장소 개념을 GAE는 내장하고 있을 뿐만 아니라 그것을 강제하고 있다.
Bigtable은 GQL이라는 쿼리 랭귀지를 사용하며 SQL과 문법이 거의 유사하지만 몇 가지 차이점이 있다. join 등의 구문을 제공하지 않고 데이터 타입을 새로 정의할 수 있다. Bigtable은 개발자가 머신 레벨까지 생각할 필요도 없고 Scalability가 이미 고려된 Computing/Datastore Cloud 위에서 애플리케이션만 작성하면 된다.
멀티 쓰레딩이나 퍼포먼스에 신경쓸 필요가 없으며, 자기네가 다 해준다고 강조한다. 테이블이나 스키마를 생성할 필요가 없고 애플리케이션의 모델 클래스에서 정의된 어트리뷰트 명세에 맞춰 데이터를 Bigtable에 저장하고 탐색한다.
레일스를 빗대자면, database.yml이나 migration 파일들이 필요 없어지는 것이다. 대신 schema.rb에 들어있던 명세들이 모델 클래스로 옮겨갈 것이다. 이런 생각들을 하다보니 문득 아마존의 Simple DB에 구미가 당겼다. 내 상상과 실제가 같은지 다른지 한 번 적용해봐야겠다.
GAE의 환경이 일반적인 OS위에 랭귀지와 라이브러리가 설치된 형태가 아니라 배포환경, 랭귀지, 프레임워크, 어드민 콘솔, 버전관리 등이 하나의 패키지로 통합된 모습을 보여주기 때문에 랭귀지 런타임을 추가하거나 지원하는 프레임워크를 추가하는 것이 간단한 문제가 아닌 듯 하다.
예를 들면 현재 파이썬을 지원한다고 해서 파이썬 기반의 프레임워크를 마음대로 설치해서 사용할 수 있는 것이 아니고 Django 0.96 버전을 사용하거나 GAE에가 자체적으로 제공하는 파이썬 프레임워크인 webapp을 사용해야 한다. 파이썬 2.5 표준 라이브러리를 제공하지만 OS 레벨이나 네트워크, 파일시스템에 대한 호출 함수는 제약이 주어진다고 공지하고 있다.
루비나 PHP가 지원된다고 해도 모든 GAE 환경이 새로 작성되어야 할 것 같다. 내장 서버와 버전관리, 어드민 등을 담고 있는 SDK부터도 루비로 재작성되어야 한다. 레일스가 GAE에 올라갈 수 있을지도 조금 걱정스럽다. DB를 안 쓰니 ActiveRecord 코드를 새로 쓰거나 Bigtable용 어답터를 지원하거나 다른 프레임워크로 대체되어야 한다.
webapp을 보니 루비의 Camping과 닮았다. 어줍잖은 예측을 해보자면, GAE의 차기 지원 랭귀지는 루비, 지원 프레임워크는 Camping이나 Camping을 참고로 만든 webapp for ruby가 아닐까.
배포하고자 하는 애플리케이션에 추가 라이브러리가 필요할 경우 분명 문제가 될텐데(GAE 환경에 뭔가를 새로 설치하는 것이 불가능해보인다. 업로드는 가능하지만) 내가 알기론 파이썬은 라이브러리가 하나의 py 파일로 배포되는 경향이 있기 때문에 이런 제약을 극복할 수 있다. 애플리케이션 폴더에 라이브러리 py파일을 넣어두고 배포하면 해당 라이브러리를 사용할 수 있기 때문이다.
만약 차후에 GAE가 루비 런타임과 레일스 프레임워크도 지원하게 된다 해도 GEM페키지는 사용하기 어려울 듯 하고 vender/plugin에 담아 한꺼번에 배포하는 방법밖에 없을 것이다. ImageMagick 등의 C기반 라이브러리 설치가 필요할 땐 어떻게 해야 할까. 몇 가지 주요 라이브러리를 기본적으로 설치해줄 것 같긴 하지만, 분명 필요한 라이브러리를 자유롭게 설치할 수 없다는 점은 제약요소다. 이런 경우는 AWS가 더 좋은 선택이 될 것이다. 아래 코드는 webapp을 사용한 예제 애플리케이션이다.
import wsgiref.handlers
import os
from google.appengine.ext.webapp import template
from google.appengine.ext import webapp
from google.appengine.ext import db
class Greeting(db.Model):
author = db.UserProperty()
content = db.StringProperty(multiline=True)
date = db.DateTimeProperty(auto_now_add=True)
class MainPage(webapp.RequestHandler):
def get(self):
greetings = Greeting.all().order('-date')
if users.get_current_user():
url = users.create_logout_url(self.request.uri)
url_linktext = 'Logout'
else:
url = users.create_login_url(self.request.uri)
url_linktext = 'Login'
template_values = {
'greetings': greetings,
'url': url,
'url_linktext': url_linktext,
}
path = os.path.join(os.path.dirname(__file__), 'index.html')
self.response.out.write(template.render(path, template_values))
class Guestbook(webapp.RequestHandler):
def post(self):
greeting = Greeting()
if users.get_current_user():
greeting.author = users.get_current_user()
greeting.content = self.request.get('content')
greeting.put()
self.redirect('/')
def main():
application = webapp.WSGIApplication(
[('/', MainPage),
('/sign', Guestbook)],
debug=True)
wsgiref.handlers.CGIHandler().run(application)
if __name__ == "__main__":
main()
파이썬은 지난 달 애자일 컨설팅의 교육과정을 통해 페어 프로그래밍을 해본 적도 있고, 워낙 루비 코드와 닮았기 때문에 코드를 보거나 작성하는 데 어려움은 없었다. webapp코드를 MVC 관점에서 관찰해보자면, 라우팅과 모델, 컨트롤러가 한 파일에 들어있다. 원하면 뷰도 컨트롤러 안에 넣을 수 있다. 파이썬은 개행문자를 포함한 문자열을 변수에 담거나 인자로 넘길때 세 개의 큰 따옴표를 자주 쓴다. """이 안에 뷰를 표현할 html 테그를 넣는 것이다""".
라우팅은 webapp.WSGIApplication이 담당하고, webapp.RequestHandler를 인자로 받는 class가 라우팅된 요청을 처리하는 액션(레일스의 용어로)이다. post와 get 메서드를 정의하면 해당 http 메서드 종류에 따라 실행을 해준다. Database가 아니라 Datastore를 사용하기 때문에 스키마 정의 대신 모델 클래스에서의 어트리뷰트 정의만 있다. ORM과 비슷한 느낌으로 사용하면 될 듯 하다.
greetings = Greeting.all().order('-date')
이 구문은 사실 GQL로 작성되어야 하는 부분인데 파이썬 메서드로 매핑이 되었다. 관계형 데이터베이스를 쓴다면 ORM이라는 용어가 적합하지만 오브젝트가 둥둥 떠다니는 데이터 저장소의 쿼리를 매핑하는 이런 메서드를 뭐라고 불러야 할까. 위의 코드는 아래의 코드의 동일한 동작을 한다.
greetings = db.GqlQuery("SELECT * FROM Greeting ORDER BY date DESC")
webapp은 루비의 Camping처럼 경량 프레임워크이므로 한 파일 안에 담는 것이 탐색이 빠르다. 애플리케이션이 복잡해지면 webapp은 좋은 선택이 아닌 것 같다. python을 사용해본 김에 Django를 설치해서 프로젝트를 만들어보았는데, 레일스와 유사할 거라는 기대와는 달리 프로젝트-애플리케이션으로 분리된 구조가 조금 낯설다. Django는 나중에 봐야겠다. 레일스의 erb처럼 webapp도 템플릿 엔진이 있다. 실행할 코드를 {% %}에, 치환할 코드를 {{ }}에 담는다.
<html>
<body>
{% for greeting in greetings %}
{% if greeting.author %}
<b>{{ greeting.author.nickname }}</b> wrote:
{% else %}
An anonymous person wrote:
{% endif %}
<blockquote>{{ greeting.content|escape }}</blockquote>
{% endfor %}
<form action="/sign" method="post">
<div><textarea name="content" rows="3" cols="60">
</textarea></div>
<div><input type="submit" value="Sign Guestbook"></div>
</form>
<a href="{{ url }}">{{ url_linktext }}</a>
</body>
</html>
구글이 얼마전에 인수한 Jaiku를 GAE 위에 올려놓은 모습을 시연했고 곧 프로덕션 환경에도 적용한다고 했다. Builtwith에 검색해보니 Jaiku는 PHP인데 GAE에 어떻게 올렸는지 궁금하다. 혹시 파이썬 다음은 PHP? 또 웹 어드민을 보여주었는데 로드 모니터링 그래프와 로그 데이터, 그리고 Datastore의 데이터 목록을 볼 수 있다. 고작 admin일 뿐인데도 무려 Ajax를 써서 사용성을 높였다.
애플리케이션 개발이 끝나면 커멘드 한 줄로 배포할 수 있다. 현재는 SDK를 이용해 로컬에서 개발만 해볼 수 있고(대기자 상태) 배포는 좀 기다려야 해볼 수 있을 것 같다. 배포하는 순간순간 코드 히스토리가 저장이 되어서 배포 자체가 버전관리 commit의 역할을 하는 것 같다. 웹 어드민을 통해 코드를 롤백하는 모습을 시연했다. 협업을 고려했는지는 더 살펴봐야겠다.
부가적이지만 강력할 수 있는 몇 가지 지원을 보자면, 내 애플리케이션에 구글 계정으로 로그인할 수 있도록 webapp상에서 지원을 하고 있고, sending mail도 프레임워크에 내장되어 있다. Google Apps와 연동하면 도메인이나 계정관리도 용이할 것 같다.
500MB storge, 10GB Bandwidth in&out/day. 5 million PV/1month까진 공짜고 Capacity를 늘릴 때 비용을 지불하게 만들 계획이다. 대용량 업/다운로드 지원이 추가되고 다른 랭귀지 런타임이 추가되고 오프라인 프로세싱(구글 기어스와 연동된다는 이야기일듯) 지원도 추가된다고 한다. 시작하기엔 더없이 매력적인 조건이다. AWS의 EC2가 $0.10 per GB - data transfer in / $0.18 per GB - data transfer out 이고 S3가 $0.15 per GB - Month of storage used 이니 비교해볼 수 있다.
GAE는 '애플리케이션이나 잘 만들라'고 말한다. 머신 뿐만 아니라 스케일과 로드 벨런싱, 멀티 쓰레딩, 사용자 계정이나 메일 시스템, 배포, 버전관리, 쿼리 최적화, 모니터링 어드민까지 다 해줄테니 애플리케이션이나 잘 만들라고 말한다. 기존에는 애플리케이션을 잘 만들어도 쿼리를 최적화해야했고 시스템 엔지니어링이라 불리는 서버 관리를 해야 했는데 이제 하지 말라고 한다.
개발 효율성이 증대되고 고용 비용이 감소하면 비즈니스 기회가 증가할 것이다. 그런데 반대로 생각해보면, 고용해야 했던 인력들이 이제는 필요 없어지는 것이고 고용 안정성은 떨어질 수 있다고 볼 수 있다. 경험과 노하우를 가진 인력이 필요했던 분야가 패키지화된 외부 솔루션으로 대체되는 상황은 비용 감소와 기회 증대, 고용 감소를 동시에 야기한다.
GAE나 AWS 뿐만 아니라 오픈소스나 프레임워크 등 이 바닥에서 일어나는 많은 일들이 이런 방향을 향하고 있는 것 같다. 개발자는 자신의 포지션을 골수 엔지니어에서 비즈니스 엔지니어로 전환시켜야 하지 않을까. 같은 직급, 같은 개발일을 하더라도 스스로의 역할이 비즈니스에 가까울수록 피고용자 보다는 고용자에 가까워지고, 고용 안정성보다는 기회 증대가 중요해지니 위의 흐름과 같은 방향을 향하게 되지 않을까.
데이터 베이스를 천덕꾸러기 취급하는 AWS와 GAE를 보자면, Database의 시대가 가고 Datastore의 시대가 도래하고 있구나 싶다. 저렴하고 간단한 Deployment와 Scalability를 동시에 고려해야 하는 스타트업에게 AWS와 GAE는 매력적인 선택이다. Customization에 강한 대신 계정관리와 설정, 배포가 복잡한 AWS, 제약이 많은 대신 모든 것이 심플한 GAE, 그리고 두 서비스가 강조하는 Scalability.
그리고 한 가지 아이러니. 'Campfire' One에서 보여준 애플리케이션 중 하나는 37signals의 'Campfire'을 모방한 것이었다. GAE app gallery 페이지에 비난 덧글이 좀 보인다. 상용화할 생각 없이 시연을 위해 개발한 듯 하지만 이런 반응을 예측할 수 있었을텐데.
update: likejazz님의 포스트에 좋은 분석글이 링크되어 있다. 전반부는 일반적인 이야기고 후반부의 'It's not all good'부터 읽어볼 만 하다. GAE의 가장 큰 맹점은 애플리케이션이 구글 플랫폼에 발이 묶인다는 점인데 그걸 잘 짚고 있다.
TRACKBACK :: http://flyingmate.net/trackback/45
-
Subject: Google App Engine
Tracked from 반복.. 삭제요즘 바빠서 인터넷과 RSS 정보 수집에 소흘하다 보니, 이런 물건이 출현한 사실도 이제 알았다. 컨셉은 기존의 아마존 웹 서비스와 유사하나, 제약을 좀 두면서 한층 사용 편의성을 높인 것으로 보인다. 구글이 주장하는 바는, 확장성 있는 웹 서비스를 런칭하는데 필요한 모든 귀찮고 지저분한 작업들은 자기들이 해결 할테니, Google App Engi
2008/04/09 22:16 -
Subject: 구글 웹 어플리케이션 플랫폼: App Engine
Tracked from likejazz.COM 삭제오픈API를 다루겠다고 선언하자마자 구글에서 엄청난 플랫폼을 내놓았다. Google App Engine이 그것인데 쉽게 말해 구글에서 1)데이타베이스를 포함한 플랫폼을 제공하고 2)호스팅을 해줄테니 개발자는 다른 것에 신경쓰지 말고 서비스 개발에만 집중할 수 있도록 한 것이다. 웹 호스팅이 단순히 호스팅 공간을 제공했던 것과 달리 App Engine은 구글의 플랫폼까지 제공하는 통합 개발 환경이란 점에서 보다 진일보한 형태라 할 수 있다. Go..
2008/04/10 13:48 -
Subject: Google App Engine이 공개된 이후 분위기...
Tracked from PHP와 Web 2.0 삭제공개 당일에 국내에 이상할만큼 조용하다가 슬슬 블로그에도 소감이 올라오고 있습니다.Google App Engine(이하 GAE)가 사용하는 기술은 Bigtable, GFS, Django, python, YAML 등입니다.여기서 YAML하면 역시 Ruby on rails이지요 GAE도 code.google.com 의 일환이기에 개발 이슈들이 공개되어있습니다.Please add ruby support http://code.google.com/p/goo...
2008/04/10 18:38 -
Subject: Google App Engine으로 “안녕하세요, 여러분” 출력하기
Tracked from 한날의 낙서 삭제1. 들어가며 며칠 전에 구글에서 Google App Engine이라는 플랫폼을 공개했다. 소식을 접하자 마자 계정 신청을 했는데 오늘 계정이 활성화 됐다는 전자우편이 왔다. Google App Engine에 대해 보다 자...
2008/04/11 18:09
댓글을 달아 주세요