Go and Docker are hot topics these days! I borrow ideas from a 19th century Italian engineer / philosopher to explain why.
Plus! A link to Go + Docker working together to make development + deployment easy-peasy.
2) Iron.io is platform for micro services, and we’ve been developing with Go + Docker in production for a while. We love it!
3) LXC, Jails, and Zones have been around for years. Why now?
Java, C++, and C# have been around for years. Why now?
4) How hot of a topic are containers?
Oracle Container Cloud +
Announced within hours of each other. (Oct 27th vs 28th)
6) Italian Economist + Engineer + Philosopher.
8) A poker game is on the frontier (can’t win money without taking from someone else).
An idea is probably on the Frontier if it's highly optimized, but comparing it to other solutions involves phrases like: catch-22, zero-sum game, “a sword that cuts both ways”, etc.
11) Image courtesy of https://github.com/golang-samples/gopher-vector
12) Optimize for hardware, or optimize for the developer. If a solution is Pareto efficient, you're likely trading some dev friendliness for better HW utilization (or vice versa).
13) Optimize JUST for hardware and you're writing Assembly.
14) Go too far in the direction of devs and you get PHP. Even big shops who once embraced it (FB) have switched their tune to "Woah, we've got to be more hardware friendly."
15) Most solutions aim to be somewhere in-between.
16) Go + Docker optimize for a lot of the same things!
Pretty good for HW.
GREAT for Devs.
17) At Iron.io we love Docker + Go. We've even built a handy workflow for cleanly getting dependencies into your Go Docker image.
The Easiest Way to
Develop with Go
“Pizza makes me think that anything is possible.”
Who am I?
Why this Talk?
Containers are hot (why?)
Go is hot (why?)
Let’s combine them. Hot-hot-heat! (why?!)
Vilfredo Pareto (1848–1923)
A state of allocation of resources in which it is
impossible to make any one individual better off
without making at least one individual worse off.
The set of all choices that are