Apcera Case Study: The selection of the Go language
+ apcera next generation cloud platform A Case Study: The Selection of Go at ApceraGo Conference JapanApril 13, 2013
Quick About Derek CollisonDesigned and Built CloudFoundry Founded March 2012Former Google, VMware, TIBCO San Francisco, CADistributed Systems Building Next Generation Cloud PlatformFounder of Apcera, Inc. Investors Kleiner Perkins@derekcollison Andreesen Horowitzderek@apcera.com True Ventures Data Collective @apcera www.apcera.com
CloudFoundryBuilt using RubyRuby the “Good” Great Language Easy Development Synchronous programming modelRuby the “Not so Good” Dependency Management Deployment Issues No builtin Eventing Model Lacks good support for Concurrency
EventMachineEventing in RubyAsynchronous IO, Timers, etc.EM + Fibers, CF process scalability model Fragile ComplexC++ code base, limited community supportComplex code baseCritical to process design patterns for CloudFoundryContributed to Dependency management issues
Apcera Choice CriteriaGood platform support (Linux, Windows, Mac, SmartOs)Good dependency model, preferred builtinGood support for Concurrency primitivesGood support for Large Scale Distributed SystemsCustomer neutral Not Java Not .Net
GoGood Designed by amazing team: Rob Pike, Ken Thompson, Robert Griesemer Synchronous programming model Concurrency is a ﬁrst class citizen Static executables - No dependencies (Except ARCH) Google Goodies - Builtin Testing, Docs, Benchmarks, Flags, etc. Good platform supportNot so Good New Language New Standard Libraries Immature GC and Scheduler Google starting to kill oﬀ projects, would Go be on that list?
Go DeeperGo Routines and Channels Well thought out concurrency primitives, based on variant of CSP. Can take advantage of Multi-Core (GOMAXPROCS)Statically Typed, compiled language Inference Interfaces - Again well thought out design Compiles fastEasy to learn - Don’t need a large talent poolDecent Standard Library - IO, FS, Network, HTTP, JsonGC, but Go has real STACKS!
Why I Would Choose Go?Stacks This is a big deal Relieves pressure from the GC Gives back power to the developer I spent 3+ months designing this in C in the 90s Go also allows interior pointers in structs to also relieve pressureStatically linked executables Deployment is “scp binary <target>”Easy to learn Scale teams with Java, C++, Ruby or Python experience Small Standard library, also easy to pick up in a week or so
Go Stacks?Why should you really care?Relieves pressure on GC Performance Stability - GC pausesMove from GC to stack easily, no GC hitYet, can auto-promote What do you mean?
Not all RosesImport model lacks support for versioning import “github.com/apcera/nats” - Which version do you get? We test for version constraints in pkg that importsCrypto is not production ready Proclaimed by a Go developer We built our own high performance mappings to OpenSSLStatic executables break when linking Being Fixed in 1.1 I believeString <-> Byte causes copiesGarbage Collector and Scheduler still young.
Not all Roses - Cont’dLogging library We wrote our own - Designed by former Twitter Ops team memberSQL Lack of error promotion and error handling Designed our own Enterprise grade ORM + driversHTTP Server I think everyone has written their own by nowMaps are slow Being ﬁxed in 1.1 I believe We wrote our own high performance ones for Go NATS server
Go SummaryGreat Systems language from GoogleConcurrency is ﬁrst class citizenTesting, Docs, Benchmarks are builtinStandard library is fairly complete and good enoughEasy to Learn - Go to www.golang.orgStatic ExecutablesStacks - You will thank me later.And Most Important Great velocity as Go moves from 1.0 -> 1.1 and beyond