From servers and containers, to services and things. Building an Internet of Things of the clouds and infrastructure we're building today. Maps the future of configuration management and systems artifact management.

1. Things will Change
Eric Windisch
UCSM’14
June 19th

2. Visionary
• Built wearable computer in 2000
• Began building and selling PaaS-like
solutions in 2002
• Began selling VM-based VPS in 2006;
• Began architecting “cloud” IaaS in 2007
at historic price-points ($5/mo VMs!)
• OpenStack contributor since Q1 2011
• Joined Docker in January 2014
@ewindisch

3. Configuration
management

4. Containers

6. Microservices

7. “The Operating System is Dead”

8. “Two years ago, I said to a
colleague: The kernel is dying.
Now I fear the distribution is dying.”

10. “Containers technology finally
leverages the things the kernel
does well.”

11. “There is, of course, the matter of
orchestrated per-tenant VM
clusters which run clouds of
containers — such as Google does.”

13. “Its close alignment to the Internet
of Things is the disruptive element
of the microservices movement”

14. Things

15. “It’s no surprise that embedded
network programming is usually
bad, if most developers are
working, not only with 80’s
hardware, but with developer
libraries of a similar vintage — as
far as networking is concerned.”

16. The Cloud

17. Shoud
Things
Change?

18. “There is no such thing as
stateless.”

19. “However, we can not prevent
state from changing. We cannot kill
the Chaos Monkey.”

20. “It is naive to think we can simply
throw away VMs or containers —
we want to preserve their state
for archival and analysis.”

22. “The biggest problem with blind
a d h e r e n c e t o i m m u t a b l e
infrastructure & 12-factor… is
ignorance of the importance of
the implicit state of a system
which should not be deemed
disposable.”

23. Things
will Change

25. “We cannot control change, we
can only effect it and manage it.”

26. Microservices
will Change

27. “APIs and sensors, both, are
inputs.”

28. Containers
will Change

30. “We need to manage containers
like we manage Things. Products
that do not do this are not good
long-term solutions for managing
containers.”

31. Distributed
SYSTEMS

32. C
A P

34. “Because we cannot kill the Chaos
Monkey, we need to know how to
collect its droppings.
1 2 - f a c t o r a n d i m m u t a b l e
infrastructure fail to acknowledge
this.”

35. “We need to manage change, not
prevent it”

36. Puppet?
Chef?
Ansible?
Salt?

37. “They are not designed for
microservices. They are not
designed for Things. They are
designed for creating change, not
for capturing it.”

38. “My fear is less that they’ll fail to
evolve, but that they’ll lose their
identities in the process..”

39. “One could… use Chef as a cloud
orchestration solution — in fact,
this was the initial scheduling for
the Deis project.”

40. “The new pattern will be to
configure Things through their own
APIs, rather than through custom
agents.”

41. “This [new fashion of configuration
management] will work on all
Things, all devices, and across
Operating Systems — even
Windows.”

42. “ We c a n n o l o n g e r a b i d e
configuration management tools
that use specialized agents.”

43. The future of
management services

44. “Application-specific discovery and
inventory mechanisms won’t go
away, no more than Gopher has.”

45. “Just as Hypertext provided an
implicit graph, linking and building
relationships between websites —
our next generation of web
technologies will offer an explicit
graph to provide discovery and
inventory.”

46. Changing Things

47. “The worst thing I have to say
about Heat is that OpenStack as a
whole tends to be overly insular,
m a k i n g t h e a d h o c u s e o f
components such as Heat, an
uncommon exercise. Still, Heat
supports standalone installation.”

49. “In some ways, Chef might already
offer many of the right things for
the next generation, if only at a
relatively local, non-global scale.”

50. Now you have 2
TRILLION
Problems

51. ”What we need today are hyper-
connected Things”

53. “MQTT solves important problems
related to accessing sensor data,
but not all the problems of
accessing and controlling things.”

54. Things at REST…

55. “The primary issue with REST is
that it’s not a protocol. It is at best
a guideline. That’s not strict
enough for building a hyper-
connected web.”

56. “Protocols such as MQTT provide
value as a buffer to support
idempotency for REST access to
Things, but this works better for
retrieving data, rather than
creating or updating it.”

57. Things as Services

58. Proto-types

59. “MQTT itself is a protocol, not a
document-type… but if it doesn’t
do all the things we need, we
either need a different protocol, or
multiple.”

60. “Every time you create a new
standard to solve a problem, you
have two problems.”

62. Upgrade the
Internet

63. “We want to do more. We want
devices to connect. We want
those devices to know not just who
to speak to, but how to speak to
others.”

64. “Google could be
super seded by
t h e S e m a n t i c
Web”
— Tim Berners-Lee

65. “Recognizing that what we want is
a Semantic Web, gives us context
for researching and understanding
the efforts that have come
before.”

66. Semantic Web

67. “The RDF and OWL efforts have
been nearly complete failures.”

68. “The Semantic Web should not just
express the context of things, but
provide discoverability.”

69. Now… time for
something different.

70. “libswarm builds libchan, which
builds on top of existing protocols
such as SPDY and HTTP2, or
WebSockets.”

71. “This new Internet, or web, needs
to be about all Things, not all
Devices. Where all services are
Things and all Things are services.”

72. “We need new services and
c onfigurati on management
solutions that work across devices,
clouds, and containers.”

73. “We need to bet on free, open,
and semantic hyper-connected
protocols — whatever those
protocols may be.”

74. “Today, we are changing our
servers, but tomorrow — We want
to change the world.”

75. Thank you.