The document proposes atomizing student data and applications into Docker containers to create a hybrid cloud campus environment. Key points include: - Using multiple containers per student instead of individual VMs for better resource utilization and mobility across campus infrastructure. - Student web applications and data can remain unchanged and be accessed via container IDs instead of direct hardware. - Docker provides benefits like layered builds to simplify deployments across heterogeneous hardware like PCs and Raspberry Pis. - Performance tests show Docker containers have comparable or better performance than VMs, though Raspberry Pis have limitations due to their hardware.

1. Marat Zhanikeev
maratishe@gmail.com
maratishe.github.io
and Put Them on Docker Containers?
Tokyo Univ. of Science
We Atomize Student Data and Apps
ICM Cloud Academy (ICACON) @ Tokyo
PDF → bit.do/180524
#cloudification #VMs #containers
#campus #university #offload #fogclouds
#IoT #raspberrypi #docker
What if

2. 2 Ways to Deal with Network Congestion
To 3G/LTE
Virtual
Wireless
User
Internal
Engine
To 3G/LTE
Resource
Virtualization
1. use multiconnect to pool and
virtualize group connectivity as in
the figure 05
2. as in this paper, offload network
activity
05 myself ”Virtual Wireless User: A Practical Design for Parallel MultiConnect Using WiFi Direct in Group Communication” 10th MobiQuitous (2013)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 2/15
2/15

3. Traditional vs Cloudified Campus
• since VM-per-student is not feasible,
multiple-containers-per-student is the base unit
• containers can easily migrate across hardware within the campus (assuming
virtualized hardware)
• can be viewed as a kind of hybrid cloud
Access
Digital
campus
Traditional University
Students
Professors
Access
from home
Local
access
Cloudified University
Hybrid
Cloud
Access
from home
Virtual
machine
Containers
Physical machine
Container on PM
Unmanaged
hardware
Local
access
Virtual
classroom
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 3/15
3/15

4. Data and Apps on Containers
• huge pro: no need to change anything within the webapp (even keep the id-based
authentication)
• a small con: students now have to lookup their individual webapp containers
Traditional webapps
Data
(files, etc.)
SQL
Database
Web
app
User
(student,
lecturer, etc)
Web
Files
SQL DB
Web
Portal
Where is my
container?
(User ID)
Hybrid
Cloud
Virtual user
(web + data + SQL + …
containers)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 4/15
4/15

5. Implementation (Docker)
• hardware should be virtualized – Xen and such – for better management in
heterogeneous environments
• RPi is special – no way to run VMs, so only container level is possible
• otherwise, Docker is the best tool on the market today
◦ recent innovation of layered builds drastically simplifies cloning and reduces deploy time
Raspberry Pi Xen PM
Linux Xen Virtualizer
Docker
Docker
App
Docker
App … Linux VM …
Docker
Docker
App …
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 5/15
5/15

6. Webapp performance (docker vs...)
1 2 5 10 20 50 100 200 500 1000 2000
0
2000
4000
6000
8000
10000
12000
14000
Averagedownloadtime(ms)
Linux VMWindows VMLinux BoxDocker container on RPi
1 2 5 10 20 50 100 200 500 1000 2000
0
100
200
300
400
500
600
700
800
Averagedownloadtime(ms)
Downloaded data size (kbytes)
• up to 2Mbyte replies to webapp
requests
• Docker on RPi stands out (in a bad way) –
is it Docker or is it RPi?
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 6/15
6/15

7. Webapp performance (closer look)
• obviously, bad performance is due to RPi, not Docker
RPi noDocker (direct webapp)
Docker on virtual CentOS
RPi Docker on LAN
1 2 5 10 20 50 100 200 500 1000 2000
0
2000
4000
6000
8000
10000
12000
14000
Averagedownloadtime(ms)
Downloaded data size (kbytes)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 7/15
7/15

8. Deployment performance
• deploy using layered build – that is, having the majority of dependencies present
locally
• RPi does not just take longer, but the deploy time is much more unpredictable
• otherwise, even RPi can accommodate dozens of containers (freezes sometimes, though)
1 3 5 10 20 30 50
2
6
10
14
18
22
Taskcompletiontime(s)
Adding containers
Removing containers
Size of container population
1 3 5 10
1
3
5
7
9
11
Taskcompletiontime(s)
Adding containers
Removing containers
Size of container population
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 8/15
8/15

9. Docker Volumes (are just paths)
• data migration is trivial – just
rsync it ...
◦ between master and slave
copies
◦ between locations
• binary diffs 08 can help
further increase efficiency
08 myself ”DiffHub: An Efficient Cloud Sync Technology based on Binary Diffs” IPSJ JIP, vol.23, no.5 (2015)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 9/15
9/15

10. Future : Campus as a Fog Cloud
• push vs pull deploys, orchestration, and local resource discovery 01
• fox boxes without internet connection in the campus 07
WiFi
Wireless users
WiFi AP
Physical Device
Cloud Platform
VM
VM
Con.Con.Con.
Storage
Sensors
…
Beacon
WiFi AP
WiFi Client
P2P WiFi
Box s
Services
A Fog Box
VM VM VM …
Pull
Deploy
Device
Provider
3rd Party
Cloud
Fog
Local Services
Local
wireless
users
P2P WiFi
P2P WiFi-only
networking
01 myself ”A Cloud Visitation Platform to Facilitate Cloud Federation and Fog Computing” IEEE Computer (2015)
07 myself ”Theory and Practice for Fog Infrastructure based on Standalone Cloudified IoT Boxes” IEEE TRON Symposium (2017)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 10/15
10/15

11. That’s all, thank you ...
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 11/15
11/15

12. Total Cloudification
WiFi
Scale/sizeofcloudifieditems
Timeline
Now
(2016)
Probably
should not
cloudify
Should
definitely
cloudify
Data
Centers
Racks IoV > VC
Desktop
Notebook
APs,
Beacons
Smartphone
Sensor
IoT
Delegated
networking
Network
core Network
edge
07 myself ”Theory and Practice for Fog Infrastructure based on Standalone Cloudified IoT Boxes” IEEE TRON Symposium (2017)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 12/15
12/15

13. Fog Box with Local Resource Discovery
• storage is the first obvious choice for local resource 02
• but sensors, connectivity, etc. are also valid resources
• LHAP : Local Hardware Awareness Platform 01 is also the obvious answer to the
heterogeneity problem
Physical Device
LHAP
VM
VM
Con.Con.Con.
HUB
WiFi
Wireless users
Wired
users
Wireless
AP
Storage
Sensors
…
WiFi
Wireless users
WiFi AP
Physical Device
Cloud Platform
VM
VM
Con.Con.Con.
Storage
Sensors
…
Beacon
WiFi AP
WiFi Client
P2P WiFi
Box s
02 myself ”Fog Caching and a Trace-Based Analysis of its Offload Effect” IJITSA, vol.10(2) (2016)
01 myself ”A Cloud Visitation Platform to Facilitate Cloud Federation and Fog Computing” IEEE Computer (2015)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 13/15
13/15

14. Cloud Boxes : Push vs Pull Deploy
• pull is best for closed, tightly controlled systems with high security (set-top
boxes?)
• push is necessary for large-scale cloud and fog federations
Cloud Visitation Platform
App App App …
Pull-Based
Installation
(of Apps)
End
User
Device
Provider3rd Party
Service
Local
services
One
Cloud
Cloud Visitation Platform
App App App …
Cloud/device
Owner
3rd Party
Service Federated
Clouds
Local
services
Federated
Cloud
Manager
01 myself ”A Cloud Visitation Platform to Facilitate Cloud Federation and Fog Computing” IEEE Computer (2015)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 14/15
14/15

15. Local Hardware Awareness Platform
Local
hardware
VirtualMachine
Cloud
Platform
(Xen)
App
App
App
…
Multitenant
environment
Physical Machine (PM)
Tools
API
Layer
Control
Layer
Local
Hardware
Awareness
Platform
(LHAP)
…
VirtualMachine
App
Tools
…
VirtualMachine
App
VirtualMachine
App
App
App
…
Global network
(to Internet)
In-box
network
Conventional Platform
…
MiniOS
App
SSD
Operating
System VirtualMachine
App
App
App
…
Multitenancy
impossible
Physical Machine (PM)
Cloud
Platform
(Xen)
Operating
System
Global network
(to Internet)
HDD
Local
Network
Global network
(to Internet)
Physical Machine (PM)
Cloud
Platform
(Xen)
Operating
System
DtL:
Direct to Local
Local
hardware
SSD
HDD
Mini Cache
LHAP (proposed)
M.Zhanikeev – maratishe@gmail.com What if We Atomize Student Data and Apps and Put Them on Docker Containers? – bit.do/180524 15/15
15/15