Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Apcera Case Study: The selection of the Go language

25,315 views

Published on

This is from a presentation at GoCon Japan on April 13th, 2013.

Published in: Technology

Apcera Case Study: The selection of the Go language

  1. 1. + apcera next generation cloud platform A Case Study: The Selection of Go at ApceraGo Conference JapanApril 13, 2013
  2. 2. 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
  3. 3. How did we get here?
  4. 4. 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
  5. 5. 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
  6. 6. I still <3 Ruby
  7. 7. Choices for Apcera?
  8. 8. 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
  9. 9. Go vs Node.js
  10. 10. Node.jsGood V8 runtime from Google Evented system by design Javascript based All programmers will know Javascript.Not so Good Runtime Dependency Based on Javascript Function scoping Callback Spaghetti Dependency via external NPM (NPM is good)
  11. 11. GoGood Designed by amazing team: Rob Pike, Ken Thompson, Robert Griesemer Synchronous programming model Concurrency is a first 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 off projects, would Go be on that list?
  12. 12. Team selected Go in 15 minutes
  13. 13. Never once questioned decision
  14. 14. 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!
  15. 15. 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
  16. 16. 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?
  17. 17. My First Go Program
  18. 18. Not all Roses, there are issues
  19. 19. 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.
  20. 20. 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 fixed in 1.1 I believe We wrote our own high performance ones for Go NATS server
  21. 21. There are more.. BUT..
  22. 22. Go was right choice for Apcera
  23. 23. More will make same decision!
  24. 24. Go SummaryGreat Systems language from GoogleConcurrency is first 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
  25. 25. Thank You!ありがとう
  26. 26. Questions?
  27. 27. apceranext generation cloud platformwww.apcera.cominfo@apcera.com

×