App engine beats pony.key


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • My extremely biased take on why App Engine is more suitable for a variety of needs than django is currently.
  • I have programmed Django for ages somewhere after launch in 2005. Before that I was using CherryPy (more on that later). This is going to be my extremely biased talk.
  • Recently I have been doing some stuff in Google App Engine and I’m quite enamoured by it. It was mostly unusable on first launch but it too has come a long way in short time.
  • different strokes for different folks
  • Fun if you want to write another blog (!) or other content heavy editorial site.
    Or huge complex websites that compose multiple apps.

    Coming from a newspaper background, this is rather duh!
  • Scalability is not the same thing as performance. It means that as your application gets bigger, it does not degenerate (like Twitter does).
    And for complex small, data heavy sites.

    App Engine has some distinct characteristics which are cool (and some which aren’t).
  • You can, I’m not sure why you would. Without most of the features that make django worthwhile this seems like a pretty silly proposition.

    While app engine itself is perfectly usable for a variety of applications.
  • Experience trumps programming, programming trumps configuration.

    We want to program, not configure. If we wanted to configure stuff, we would program Java.

  • traditional relational databases suck
    if you don’t agree, you probably have not been using them enough
  • high performance and loose integrity (sides of the same coin)

    django non-rel ORM exists also seems like a silly idea,
    I haven’t looked into the current django-couchdb and other libraries yet, but it would be nice if these were ready for mainline use.
  • best approach to data migration: don’t
    ‘expando Models rule’

    Never having to migrate another database table again is a Good Thing.
  • Free hosting
    Standardized project layout (a Good Idea)
    Makes it 100x more likely that I’ll build a throwaway webservice on GAE than I will with django.

    django-fabric: looks too complex, lots of configuration

  • Yeah, most of this stuff is not very hard to setup in one way or other. But having this stuff built-in matters. Programmers that don’t understand that simple fact, ruin it for the rest.

    It removes the necessity to think about it. You can just use the API.
  • free account will work for your toy website (which are super easy to get started)
    as soon as it gets serious you can just convert $ into scale, you never have to hire (or become!) a sysop to configure EC2 instances yourself

    also you don’t need to backup because it’s a gridded setup, it will generally never go down (except when it does), at least it won’t go down for the more mundane of reasons

  • no JOINs
    no aggregates
    adding redundant data or by grouping data (remember, we don’t have JOINs)
    for instance cannot query SELECT DISTINCT city FROM entries
    so either walk through all your records (bad idea!)
    or make a new table called Cities and only put city stuff in there
  • A bad idea if it happens, but because everything in App Engine is in the request/response paradigm, this can be difficult if you want to do some complicated stuff that is hard to decompose/incrementalize. But webservers aren’t really the place (yet!) for that kinda stuff.
  • A Good Thing (you can use any templating language you want), but we’re stuck on the old 0.96 version (which is frankly silly given the number of updates App Engine gets).
  • Would be nice to have.

  • It feels very oldschool if you remember CherryPy (that’s what I used before Django came out).

    Not that hard and pretty easy to write a website in.
  • can’t really remove www.
    Domain linking in Google Applications is a fucking ghetto (even for domains you completely control).
    It’s doable but it’s very much harder than it should be.
  • It could be way prettier and nicer to use than it is. Common workflows could also be made easier.
  • This is pretty nice from an ops point of view.
  • Google is branding App Engine as an Enterprise product. All good software engineers know that the Enterprise is where programming goes to die.
    This may yield:
    - better availability (SLAs and that kinda crap)
    - more conservatism in development
    - a bigger focus on Java because of paying customers
    Which is a mixed bag.
  • Any system that removes configuration options and let’s you focus on the programming part (on getting work done) is a good system.

  • App engine beats pony.key

    1. 1. My App Engine has more horsepower than your Pony @alper
    2. 2. Different strengths
    3. 3. Django is good for content heavy
    4. 4. App Engine is made for scalability and realtime
    5. 5. Django on App Engine
    6. 6. Programming ≠ Configuration
    7. 7. The Good
    8. 8. Database
    9. 9. noSQL
    10. 10. no migrations
    11. 11. update
    12. 12. More batteries included
    13. 13. • Memcache • Receiving (!) e-mail • XMPP • Task Queues + Cron
    14. 14. Scalability + Availability
    15. 15. The Bad
    16. 16. No serious queries
    17. 17. denormalize
    18. 18. Deadline exceeded
    19. 19. Django templates
    20. 20. django.forms
    21. 21. The Ugly
    22. 22. Retro class MainPage(webapp.RequestHandler):     def get(self):         self.response.headers['Content-Type'] = 'text/plain'         self.response.out.write('Hello, webapp World!') application = webapp.WSGIApplication(                                      [('/', MainPage)],                                      debug=True) def main():     run_wsgi_app(application)
    23. 23. Domain linking
    24. 24. Admin interface
    25. 25. Enterprise
    26. 26. Programming ≠ Configuration
    27. 27. Best practices
    28. 28. • Work within the bounds • Use indexes • Use memcache • Create JSON endpoints • Compose complexity at the client side