The document discusses the promises and myths of new distributed computing platforms like Docker and Weave. It identifies 8 myths of how these new platforms position themselves, such as the idea that applications can be independent of the operating system or that platforms are better at designing apps than developers. The reality is that by "turning back the clock 30 years" to older distributed computing approaches, many of the skills and tools developers already use can apply when building apps on new platforms like Docker and Weave.

1. 7+1 myths of the New OS
Alexis Richardson, Weave

2. Weave Network “SDN for hipsters”

3. The main points
1. In minutes, Weave solves Docker multi host problem
1. Inconceivably easy to use. And: dynamic, multi-cloud,
multi-hop, easy to wire up to rest of world...
1. Application developers don’t have to be experts in
networking or distributed systems, the SDN does it for
you...

4. Use cases and examples
http://weaveblog.com/
https://github.com/zettio/weave

5. The interesting part..
Weave Network is 100% decentralised
Standard APIs - IP, DNS, DHCP…
“Enables, then gets out of your way” -- supports a much
wider set of use cases...

6. Can we solve more
problems this way?

8. 1994
SUN Microsystems invents a lingua franca for
the new world of distributed computing
→ JAVA
Promises portable web based applications by
providing a runtime container. Is designed
by distributed computing people...

9. 7+1 myths of distributed computing
“Fallacies” - according to SUN Microsystems when Java was born
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous. (added by Gosling, 1997)

10. Where did Java go to?
Java turned into J2EE - tried to hide
complexity in a ‘platform’
→ the app server disaster
One size fits all “platforms” supporting
alleged enterprise requirements like
transactions
Let’s NOT DO THIS AGAIN

12. Ubiquitous and cheap
physical compute infra

13. Are we in post-fallacy world?
1. A homogeneous cloud with zero administrators?
2. Unbounded, cheap bandwidth albeit not zero cost?
3. Decouple applications from physical topology?

14. No we are NOT
1. A homogeneous cloud with zero administrators?
2. Unbounded, cheap bandwidth albeit not zero cost?
3. Decouple applications from physical topology?
// TODO: get latency to zero and system
integrity to 100% (CAP/Zooko)

15. DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER

16. DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER DOCKER

17. DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER
DOCKER DOCKER DOCKER

18. A profound change just occurred
Docker delivers a new alignment between dev
and ops: a container is what you ship, when
you ship an application
Google - 2B containers / week
If we are all like Google → 10T / year?

19. The new Docker
Scalable distributed application platform,
or, if you like: the New OS.
read.about.it@
http://weaveblog.com/2014/11/13/life-and-docker-
networking/

20. The new Weave
OK, so people want a New OS...
Let’s learn from Java & the Fallacies & the J2EE mistake.
1. Update the fallacies to “7+1 myths of the New OS”.
2. This is partly for fun :-)
3. But it is also to motivate future work!

21. MYTH 1
The application lifecycle is independent of the OS

22. But the reality is...
Dev and Ops align on a single build, the container
Neil Ellis:
“After Docker many of us are starting to look at things in
a different way. Our apps are now the same as machines
thanks to Docker. This means our applications can act like
they once did, as the sole piece of software running on a
machine.”
This leads to using containers for microservices, and in
the future, to microkernels & short lived microcontainers

23. MYTH 2
Distributed systems, and hence new apps, need a panoply of
unfamiliar tools and skills

24. But the reality is...
Because containers align app with machine lifecycle, we
can take advantage of decades of best practice
Neil again: “... this has the interesting side effect of
making older and low level technologies directly relevant
to application development and operations.
Forget your UDDI, you can go back to using DNS (optionally
with SRV records) instead. Forget application servers,
just load balance your containers.
It is as if we have turned back the clock 30 years, in a
good way.”

25. MYTH 3
Apps must be fundamentally rewritten and all operational
tooling replaced

26. But the reality is...
Because “we have turned back the clock 30 years, in a good
way”, every single API and tool can *already work*
We can envisage a composable runtime system, like Unix,
but for the era of containers and cloud scale apps
This can consist of a set of critical micro-services, like
networks (IP), service discovery (DNS), naming (DHCP).. in
which every service is completely obvious and intuitive
This makes it much easier to migrate and refactor apps.

27. MYTH 4
Platforms are better at designing your app than you are

28. But the reality is...
Mostly, you already know how to write apps and manage them
In a Unix like world of composable micro services that
have obvious APIs, you can choose what to build and you
already have the skills to do it
Opinionated platforms are extremely useful when aligned
with special cases (eg mobile) but can never be general
purpose. E.g not every app is a 12-factor web app.
A general purpose system must be unopinionated: it must
first enable, and then get out of your way.

29. MYTH 5
You really need an all-inclusive system

30. But the reality is...
You want adaptability & to plug in your own services
If you have to “learn” a platform before building an
application, you MAY be doing the wrong thing
All inclusive platforms tend to get in the way of choice
and application design. Enterprises also *require*
pluggability within the model and not as a ‘bolt on’.
Examples of good models: Amazon’s IaaS+services model; and
Netflix OSS which should be called “Netflix OS” ;-)

31. MYTH 6
Dev/Test and Production need different tooling

32. But the reality is...
Good tools scale from dev/test to prod
The ideal system should ‘scale from laptop to cloud’ with
a single set of APIs and tooling.
You need a system that is scale and location invariant, in
order to be truly portable. You need dynamic topologies
eg. using a Weave Network :-)
Note to Docker - can haz downloads <800MB plz

33. MYTH 7
Co-ordination is a platform concern, and not an
application level concern

34. But the reality is...
The internet is completely decentralised and your systems
should be too
Example: Consensus. YAGNI a lot of the time.
When you do need it, you want the semantics exposed up to
the app and not buried inside the platform (Java app
servers made this mistake with transactions)

35. MYTH N+1
Docker will solve all known problems of computing

36. Recap: New myths for New OS
7+1 new myths
1. The application lifecycle is independent of the OS
2. Distributed systems require a panoply of new skills and tools.
3. Apps must be fundamentally rewritten, and tooling replaced.
4. Platforms are better at designing your app than you are.
5. You really need an all inclusive system.
6. Dev/test and production need different tooling.
7. Coordination is a platform concern not an app level concern.
8. Docker will solve all known problems of computing

37. The new Weave: help with the faff
Download Docker and Weave and build an app in the way that
you already know how to do, but: using containers.
Weave will NOT get in your way: apps do not need
fundamental rewrites and ops teams do not need to retool.
Like Unix, a runtime system that is obvious, unopinionated
and composable. But: for 2014 concerns.
Mix in your own (micro)services and orchestration to taste!

38. Many challenges, here are a few
Logging without tears
Decentralised access control
Distributed LB and proxying