The folk wisdom has always been that when running stateful applications inside containers, the only viable choice is to externalize the state so that the containers themselves are stateless or nearly so. Keeping large amounts of state inside containers is possible, but it’s considered a problem because stateful containers generally can’t preserve that state across restarts. In practice, this complicates the management of large-scale Kubernetes-based infrastructure because these high-performance storage systems require separate management. In terms of overall system management, it would be ideal if we could run a software-defined storage system directly in containers managed by Kubernetes, but that has been hampered by lack of direct device access and difficult questions about what happens to the state on container restarts. Ted Dunning describes recent developments that make it possible for Kubernetes to manage both compute and storage tiers in the same cluster. Container restarts can be handled gracefully without loss of data or a requirement to rebuild storage structures and access to storage from compute containers is extremely fast. In some environments, it’s even possible to implement elastic storage frameworks that can fold data onto just a few containers during quiescent periods or explode it in just a few seconds across a large number of machines when higher speed access is required. The benefits of systems like this extend beyond management simplicity, because applications can be more Agile precisely because the storage layer is more stable and can be uniformly accessed from any container host. Even better, it makes it a snap to configure and deploy a full-scale compute and storage infrastructure.

1. © 2017 MapR Technologies 1
Progress for big data in
Kubernetes

2. © 2017 MapR Technologies 2
kubernetes is coming!

3. © 2017 MapR Technologies 3
why?

4. © 2017 MapR Technologies 4
Source: Shippable.com http://blog.shippable.com/why-the-adoption-of-kubernetes-will-explode-in-2018
kubernetes = major community support

5. © 2017 MapR Technologies 5
every cloud supports kubernetes
https://www.sinax.be/en/aws/
https://www.westconcomstor.com/za/en/vendors/wc-vendors/microsoft-azure-EN-UK.html
https://www.g2crowd.com/products/google-kubernetes-engine-gke/details

6. © 2017 MapR Technologies 6
massive customer adoption rate

7. © 2017 MapR Technologies 7

8. © 2017 MapR Technologies 8
what is kubernetes?

9. © 2017 MapR Technologies 9
kubernetes (n.) - greek word for pilot or
helm

10. © 2017 MapR Technologies 10
kubernetes started life as a
successor to google’s borg
project...
https://cloud.google.com/security/encryption-in-transit/

11. © 2017 MapR Technologies 11
kubernetes is an ecosystem...
Source: Redmonk - http://redmonk.com/sogrady/2017/09/22/cloud-native-license-choices/

12. © 2017 MapR Technologies 12
container and resource orchestration engine...

13. © 2017 MapR Technologies 13
Source: Shippable.com http://blog.shippable.com/why-the-adoption-of-kubernetes-will-explode-in-2018
kubernetes won the container orchestration war...

14. © 2017 MapR Technologies 14
what is kubernetes?

15. © 2017 MapR Technologies 15
it runs containers

16. © 2017 MapR Technologies 16
what is a container?

17. © 2017 MapR Technologies 17
not a vm

18. © 2017 MapR Technologies 18
hardware
vm vs container
os
hypervisor
vm
os
libs
app
vm
os
libs
app
hardware
os
container
libs
app
container
libs
app
container
libs
app

19. © 2017 MapR Technologies 19
pets vs cattle
https://fwallpapers.com/view/cat-jeans
http://www.clipartpanda.com/clipart_images/free-clip-art-1083418

20. © 2017 MapR Technologies 20
pets vs cattle
- long lived
- name them
- care for them
- ephemeral
- brand them with #’s
- well..vets are expensive

21. © 2017 MapR Technologies 21

22. © 2017 MapR Technologies 22
isolation
cgroups
● cpu
● memory
● network
● etc.
namespaces
● pids
● mnts
● etc.
Chroot (filesystem)

23. © 2017 MapR Technologies 23
File File Read-only Layer
container images

24. © 2017 MapR Technologies 24
File File
File
Read-only Layer
Read-only Layer
container images

25. © 2017 MapR Technologies 25
File File
File
Read-only Layer
Read-only Layer
Writable Layer
container images

26. © 2017 MapR Technologies 26
File File File Container Image
chroot
container = image + isolation
cgroups
● cpu
● memory
● network
● etc.
namespaces
● pids
● mnts
● etc.

27. © 2017 MapR Technologies 27
containers have a problem

28. © 2017 MapR Technologies 28
you can never get away from
pets unless:
- you handle the problem of
container state
- you need an environment to
support cattle
MapR and kubernetes are the
solution

29. © 2017 MapR Technologies 29
Things docker can’t (or won’t) do...
• solve port mapping hell
• monitor running containers
• handle dead containers
• move containers so utilization improves
• autoscale container instances to handle load

30. © 2017 MapR Technologies 30
Magical View of Kubernetes

31. © 2017 MapR Technologies 31
App 1
Kubernetes
Magical View of Kubernetes
Kubernetes starts application
containers “somewhere”

32. © 2017 MapR Technologies 32
Magical View of Kubernetes
App 1 App 3
Kubernetes
Later containers may be started
elsewhere due to “affinities”

33. © 2017 MapR Technologies 33
Magical View of Kubernetes
App 1 App 2 App 3
Kubernetes
Kubernetes provides super fast
naming via DNS so containers
can find each other

34. © 2017 MapR Technologies 34
Note that you don’t think about
which machine at all

35. © 2017 MapR Technologies 35
You don’t think about which
machine at all
No more names from The Hobbit
Just cattle

36. © 2017 MapR Technologies 36
The Impact of Kubernetes
• Software engineering can be viewed as freezing bits
• Initially, everything is possible, nothing is actual
• We freeze the source
Then the binary
Then the package
Then the environment
Ultimately the system

37. © 2017 MapR Technologies 37

38. © 2017 MapR Technologies 38

39. © 2017 MapR Technologies 39

40. © 2017 MapR Technologies 40
git cc/ld
java/jar
Build
docker build
resources
config libraries
Package
helm package
Construct

41. © 2017 MapR Technologies 41
git cc/ld
java/jar
Build
docker build
resources
config libraries
Package
helm package
Construct
helm install/scale
Load balancer
Deploy

42. © 2017 MapR Technologies 42
This is glorious

43. © 2017 MapR Technologies 43
but we still have a problem

44. © 2017 MapR Technologies 44
state

45. © 2017 MapR Technologies 45
Not Done Yet
Load balancer

46. © 2017 MapR Technologies 46
Not Done Yet
Load balancer
Here’s the problem

47. © 2017 MapR Technologies 47
Not Really Ready at All
• State in containers messes
things up
• Restarts lose the state
• Replicating state makes
services complex
• Application developers just
aren’t systems developers
• State life-cycle doesn’t
match app life-cycle
Load balancer
Here’s the problem

48. © 2017 MapR Technologies 48
What is a Service Anyway?
Load balancer
RPC in

49. © 2017 MapR Technologies 49
But … Not Entirely
• Synchronous RPC-based services only serve one need
• In a synchronous service it’s common to do some, defer some
• But deferring work is hard in a synchronous world … we have
to give up the return call in some sense
• This is the germ of streaming architecture

50. © 2017 MapR Technologies 50
Deferred
What is a Service Anyway?
Load balancer
RPC in

51. © 2017 MapR Technologies 51
Isolation is The Defining Characteristic
• If I can hide details of who and where, I have a service
• If I can hide details of deployment, I have a micro-service
• If I can hide details of when, I have a streaming micro-service

52. © 2017 MapR Technologies 52
Temporal and Geo Isolation
Producer Consumer isn’t even running

53. © 2017 MapR Technologies 53
Temporal and Geo Isolation
Producer Consumer

54. © 2017 MapR Technologies 54
Producer
Consumer
Temporal and Geo Isolation
Consumer could be an ocean away

55. © 2017 MapR Technologies 55
We Need Multiple Forms of Persistence
• Files are important
– Config files, image files, archival data data
– Legacy applications like machine learning, web
• Tables are important
– Critical to have random update for some applications
– Should scale transparently without dedicated cluster
• Streams are important
– Should be co-equal form of persistence

56. © 2017 MapR Technologies 56
App 1 App 2 App 3

57. © 2017 MapR Technologies 57
App 1 App 2 App 3
stream
LogFile

58. © 2017 MapR Technologies 58
App 1 App 2 App 3
stream
LogFile

59. © 2017 MapR Technologies 59
App 1 App 2 App 3

60. © 2017 MapR Technologies 60
What Does This Data Platform Need to Have?
• Global namespace across entire Kubernetes cluster
– Between clusters as well if possible
• All three forms of primitive persistence
– Files, streams, tables
• Inherently scalable
– Performance, cardinality, locality
• Uniform access and control
– Path names for all objects, identical permission scheme

61. © 2017 MapR Technologies 61
What Does This Data Platform Need to Have?
• Global namespace across entire Kubernetes cluster
– Between clusters as well if possible
• All three forms of primitive persistence
– Files, streams, tables
• Inherently scalable
– Performance, cardinality, locality
• Uniform access and control
– Path names for all objects, identical permission scheme
• Oh…. got that already. Just need to wire it up to Kubernetes

62. © 2017 MapR Technologies 62

63. © 2017 MapR Technologies 63

64. © 2017 MapR Technologies 64
kubelet
docker
pod
Normally pods interact
directly with node resources

65. © 2017 MapR Technologies 65
kubelet
docker
pod
plugin We can install a volume
plugin (recently introduced)

66. © 2017 MapR Technologies 66
mapr-
fs
kubelet
docker
pod
plugin
fuse
This allows uniform access
to files, tables and streams

67. © 2017 MapR Technologies 67
Where does that take us?

68. © 2017 MapR Technologies 68
Consequences
• Installation of plugin is K8S level operation
– No per-node attention required
• Use of plugin is overlay operation
– No change needed for an container
– Any Helm chart can use the plugin for conventional file access
• Can share storage/compute or isolate or scale independently

69. © 2017 MapR Technologies 69
More Consequences
• State is no longer a dirty word for Kubernetes
• HPC can run on K8S
• Boring things can run on K8S without storage appliances
• Previously crazy ideas can now be valuable
• Complexity is largely not visible

70. © 2017 MapR Technologies 70
Cloud as-is: No unified data access or security concepts
Public Cloud
Application
✓
API
API Connector
Single cloud vendor strategy:
• Vendor lock in
• No failover in case of global outage
• Limited Edge capabilities
AWS Services:
• Kinesis & Elastic MapReduce
• Redshift & DynamoDB
• S3 & Glacier

71. © 2017 MapR Technologies 71
Cloud as-is: No unified data access or security concepts
Public Cloud
Application
✓
API
API Connector
AWS Services:
• Kinesis & Elastic MapReduce
• Redshift & DynamoDB
• S3 & Glacier
API
Azure Services:
• HD Insight
• SQL Server & CosmosDB
• Blob & DataLakeStore
Multi cloud strategy:
• Complex data movement between clouds
• On any other cloud:
• Different API‘s: application breaks
• Different Security concept

72. © 2017 MapR Technologies 72
Cloud as-is: No unified data access or security concepts
Edge Private Cloud
On Premise
Public Cloud Public Cloud Public Cloud
API
Application
✓
API API API API
API Connector
Multi cloud strategy:
• Complex data movement between clouds
• On any other cloud:
• Different API‘s, application breaks
• Different Security concept

73. © 2017 MapR Technologies 73
Open APIs
How a “Media Company” is using MapR
Application
• Unified Security Model
• Data access decoupled from physical
storage location. Globally.
• No lock-in to proprietary APIs
• Full openness
• Data made portable
API Connector
✓
GLOBAL DATA MANAGEMENT
Edge Private Cloud
On Premise
Public Cloud Public Cloud Public Cloud
Uniform computing
environment everywhere

74. © 2017 MapR Technologies 74
Open APIs
How “Manufacturing Company” is using MapR
Application
• Unified Security Model
• Data access decoupled from physical
storage location. Globally.
• No lock-in to proprietary APIs
• Full openness
• Data made portable
API Connector
✓
GLOBAL DATA MANAGEMENT
Edge Private Cloud
On Premise
Public Cloud Public Cloud Public Cloud
Platform level
data replication

75. © 2017 MapR Technologies 75
Tier 1 Bank #1 Creating a Global Filesystem
/mapr/edge1
/mapr/edge2
/mapr/edge3
/mapr/newyork
/mapr/amsterdam
/mapr/azure /mapr/gcp
/mapr/aws-eu-west
NFS POSIX HDFSREST
HOT
WARM
COLD
/mapr
Kafka JSON HBASE SQL S3
Application
✓
Global access
to local data

76. © 2017 MapR Technologies 76
Tier 1 Bank #2: Creating an “Ubernetes” Platform with MapR
Application
GLOBAL DATA MANAGEMENT
Edge Private Cloud
On Premise
Public Cloud Public Cloud Public Cloud
PodPod Pod Image Classification using
Tensorflow in a Docker container
Classic ETL
Scheduling & Scaling
MapR Kubernetes Volume Driver
Single pane of glass to
control jobs anywhere

77. © 2017 MapR Technologies 77
Additional Resources
O’Reilly report by Ted Dunning & Ellen Friedman © September 2017
Read free courtesy of MapR:
https://mapr.com/ebook/machine-learning-logistics/
O’Reilly book by Ted Dunning & Ellen Friedman
© March 2016
Read free courtesy of MapR:
https://mapr.com/streaming-architecture-using-
apache-kafka-mapr-streams/
Ted Dunning & Ellen Friedman
Model Management in theReal World
MachineLearning
Logistics

78. © 2017 MapR Technologies 78
Additional Resources
O’Reilly book by Ted Dunning & Ellen Friedman
© June 2014
Read free courtesy of MapR:
https://mapr.com/practical-machine-learning-new-
look-anomaly-detection/
O’Reilly book by Ellen Friedman & Ted Dunning
© February 2014
Read free courtesy of MapR:
https://mapr.com/practical-machine-learning/

79. © 2017 MapR Technologies 79
Additional Resources
by Ellen Friedman 8 Aug 2017 on MapR blog:
https://mapr.com/blog/tensorflow-mxnet-caffe-h2o-which-ml-best/
by Ted Dunning 13 Sept 2017 in
InfoWorld:
https://www.infoworld.com/article/3223
688/machine-learning/machine-
learning-skills-for-software-
engineers.html

80. © 2017 MapR Technologies 80
New Book!
We will be signing this book at the MapR booth
later today.
Detailed schedule at the booth.

81. © 2017 MapR Technologies 81
Please support women in tech – help build
girls’ dreams of what they can accomplish
© Ellen Friedman 2015#womenintech #datawomen

82. © 2017 MapR Technologies 82
Q&A
@mapr
tdunning@mapr.com
ENGAGE WITH US
@ Ted_Dunning