May 2016: App Engine, Stateful Messaging

calendar May 30, 2016 · 3 min read · appengine messaging  ·
Share on: linkedin copy

Please RSVP at Meetup or Google+.

We get started at 6:30 pm.

Sponsors

Food provided by Bellstone Engineering.

Venue provided by Startup Edmonton.

Talks

Google App Engine

Chris Olsen shared his experience using Google App Engine to ship a Go service under a hard deadline. He framed App Engine as outsourcing DevOps — no servers to set up or maintain, no deployment scripts, monitoring, SSL, backups, or scaling to worry about — which let him focus on the application. He walked through configuration with app.yaml (and its companions cron.yaml, dispatch.yaml, dos.yaml, queue.yaml, and index.yaml), a minimal httprouter handler, and deploying with goapp deploy. On the data side he covered App Engine's Datastore — a NoSQL store whose relationships are expressed in code via keys rather than in the models — plus gotchas like adding the datastore key to JSON payloads manually and avoiding unnecessary indexes because they add write cost. He also touched on pricing (queries and email cost money, Memcache is free), black-box testing with aetest and appengine.NewContext, and his conclusion that App Engine's quirks are a worthwhile trade-off.

Key points:

  • App Engine removes much of the DevOps burden (servers, SSL, scaling, backups).
  • app.yaml plus optional config files define runtime, handlers, cron, queues, and indexes.
  • Deploy with goapp deploy; handlers can use any router.
  • Datastore is NoSQL; relationships live in code via keys, not in the models.
  • Include the datastore key manually in JSON and don't over-index (writes cost).
  • Memcache is free; Datastore queries and email are billed.
  • aetest and appengine.NewContext support black-box endpoint tests.

slides

Stateful Messaging

Gerrit Renker talked about stateful messaging and the "Scalability Protocols" behind libraries like nanomsg and go-mangos. He framed the problem as reliability above the transport layer — the familiar "send and pray" pattern and TCP's head-of-line blocking — and traced the lineage from AMQP and ØMQ through to nanomsg and its Go binding. ØMQ treats sockets as stateful (a BSD socket plus a finite state machine) with built-in patterns like request/reply, publish/subscribe, and push/pull, but its REQ/REP state machine is only one bit deep and can hang on certain disconnects. nanomsg, by the same author, addresses this with more explicit state machines, pluggable transports (TLS, websockets), and IETF-style protocol specifications: REQREP, PAIR, PUBSUB, PIPELINE, BUS, and SURVEY. The talk showed how requests are routed through channel and message IDs, how BUS broadcasts to all peers, and how SURVEY collects time-windowed votes, before demonstrating go-mangos, which brings these protocols to Go with TLS and inproc, tcp, tls+tcp, and websocket transports.

Key points:

  • Messaging reliability is a problem above the transport layer.
  • ØMQ introduced stateful sockets and reusable messaging patterns.
  • REQ/REP is simple but fragile — it can hang on disconnects.
  • nanomsg adds explicit state machines and pluggable transports.
  • Scalability Protocols: REQREP, PAIR, PUBSUB, PIPELINE, BUS, SURVEY.
  • go-mangos brings them to Go with TLS and multiple transports.

slides, demo code

Events