Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sting Like a Bee -- Introducing the Swarm Architecture #71

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions tim_lossen-sting_bee/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
# Sting Like a Bee
## Introducing the Swarm Architecture

It has become fashionable to bash "large, monolithic rails apps" as
evil and obsolete. So you run out and tear your lovely program up
into pieces and make it all distributed .... wait, now you have *five*
problems!

In this talk, I am going to debunk this myth, and argue that monolithic
apps work and scale extremely well -- you just have to be smart and get
the overall architecture right. I will present the "Swarm" pattern and
explain how using unreliable protocols like UDP and *embracing* single
points of failure (instead of trying to eliminate them) can paradoxically
improve both resilience and scalability.

At Wooga, we have been searching for the "perfect" backend stack
since three years. The swarm architecture, which will go into production
this autumn, is the latest evolutionary step on this journey.



## Tim Lossen

Tim really enjoys talking about himself in the third person. Not.
He lives in Berlin with his girlfriend and two charming little daughters.
Tim is deeply in love with Ruby and co-organized Euruko 2011.
Tim works as backend engineer at social gaming startup [Wooga](http://wooga.com).
At night he likes to go down to the basement and hack on secret hardware
projects like Superglobe or [Evercube](http://evercu.be).

![Profile picture](http://tim.lossen.de/tim.png)

- [My website](http://tim.lossen.de)
- [My twitter](https://twitter.com/#!/tlossen)
- [Past talk slides](http://www.slideshare.net/tim.lossen.de)
- [More talk slides](http://speakerdeck.com/u/tlossen)
- [Past talk video](http://vimeo.com/12610120)
- [Speaking history](http://lanyrd.com/profile/tlossen/sessions/)

Binary file added tim_lossen-sting_bee/profile_picture_1994.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
24 changes: 24 additions & 0 deletions tim_lossen-sting_bee/proposal.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
The Tenth Fleet
---------------

It has become fashionable to bash "Large, Monolithic Rails Apps" as
evil and obsolete. So you run out and tear your lovely program up
into pieces. Wait, now you have *five* problems!

In this talk, I am going to debunk the above myth, and argue that
monolithic apps work (and especially scale) extremely well -- you
just have to be smart and get the overall architecture right. I will
present the "Fleet" pattern and explain how embracing (instead of
trying to eliminate) single points of failure can paradoxically
*improve* resilience and scalability.

The Fleet architecture has evolved at





"Tenth Fleet has operational control over Navy information, computer,
cryptologic, and space forces."

http://en.wikipedia.org/wiki/United_States_Tenth_Fleet