diff options
Diffstat (limited to 'content/heroku.article')
-rw-r--r-- | content/heroku.article | 74 |
1 files changed, 74 insertions, 0 deletions
diff --git a/content/heroku.article b/content/heroku.article new file mode 100644 index 0000000..2aa75c2 --- /dev/null +++ b/content/heroku.article @@ -0,0 +1,74 @@ +# Go at Heroku +21 Apr 2011 +Tags: guest +Summary: _This week’s blog post is written by_ [_Keith Rarick_](http://xph.us/) _and_ [_Blake Mizerany_](http://itsbonus.heroku.com/), _systems engineers at_ [Heroku](http://www.heroku.com/). _In their own words, they "eat, drink, and sleep distributed systems." Here they discuss their experiences using Go._ +OldURL: /go-at-heroku + +Keith Rarick + +Blake Mizerany + +## + +_This week’s blog post is written by_ [_Keith Rarick_](http://xph.us/) +_and_ [_Blake Mizerany_](http://itsbonus.heroku.com/), +_systems engineers at_ [Heroku](http://www.heroku.com/). +_In their own words, they "eat, drink, and sleep distributed systems." Here they discuss their experiences using Go._ + +A big problem that comes with building distributed systems is the coordination +of physical servers. +Each server needs to know various facts about the system as a whole. +This critical data includes locks, configuration data, +and so on, and it must be consistent and available even during data store failures, +so we need a data store with solid consistency guarantees. +Our solution to this problem is [Doozer](http://xph.us/2011/04/13/introducing-doozer.html), +a new, consistent, highly-available data store written in Go. + +At Doozer's core is [Paxos](http://en.wikipedia.org/wiki/Paxos_(computer_science)), +a family of protocols for solving consensus in an unreliable network of unreliable nodes. +While Paxos is essential to running a fault-tolerant system, +it is notorious for being difficult to implement. +Even example implementations that can be found online are complex and hard to follow, +despite being simplified for educational purposes. +Existing production systems have a reputation for being worse. + +Fortunately, Go's concurrency primitives made the task much easier. +Paxos is defined in terms of independent, +concurrent processes that communicate via passing messages. +In Doozer, these processes are implemented as goroutines, +and their communications as channel operations. +In the same way that garbage collectors improve upon malloc and free, +we found that [goroutines and channels](https://blog.golang.org/2010/07/share-memory-by-communicating.html) +improve upon the lock-based approach to concurrency. +These tools let us avoid complex bookkeeping and stay focused on the problem at hand. +We are still amazed at how few lines of code it took to achieve something +renowned for being difficult. + +The standard packages in Go were another big win for Doozer. +The Go team is very pragmatic about what goes into them. +For instance, a package we quickly found useful was [websocket](https://golang.org/pkg/websocket/). +Once we had a working data store, we needed an easy way to introspect it +and visualize activity. +Using the websocket package, Keith was able to add the web viewer on his +train ride home and without requiring external dependencies. +This is a real testament to how well Go mixes systems and application programming. + +One of our favorite productivity gains was provided by Go's source formatter: +[gofmt](https://golang.org/cmd/gofmt/). +We never argued over where to put a curly-brace, +tabs vs. spaces, or if we should align assignments. +We simply agreed that the buck stopped at the default output from gofmt. + +Deploying Doozer was satisfyingly simple. +Go builds statically linked binaries which means Doozer has no external dependencies; +it's a single file that can be copied to any machine and immediately launched +to join a cluster of running Doozers. + +Finally, Go's maniacal focus on simplicity and orthogonality aligns with +our view of software engineering. +Like the Go team, we are pragmatic about what features go into Doozer. +We sweat the details, preferring to change an existing feature instead of +introducing a new one. +In this sense, Go is a perfect match for Doozer. + +We already have future projects in mind for Go. Doozer is just the start of much bigger system. |