The document discusses the FogGuru project, which aims to train the next generation of European experts in fog computing. The 3-year project will provide in-depth technical training to 8 Early Stage Researchers across universities, companies and a living lab testbed in Valencia, Spain. The project addresses key challenges in fog computing like resource management, stream processing and application development through its research objectives and the ESR projects. The training combines technical skills, innovation mindsets, networking opportunities and soft skills to develop recognized specialists and entrepreneurs in fog computing.

1. TRAINING THE NEXT GENERATION OF EUROPEAN FOG COMPUTING EXPERTS
Fog Computing for Dummies
Fog Computing for Dummies
Boot Camp, 18-20 September 2018
Guillaume Pierre, University of Rennes 1

2. section
Why do we need fog
computing?
2

3. Since 2016: Mobile traffic > Fixed traffic
Now: IoT-generated traffic grows faster than Internet
backbone capacity
3
IoT
DEVICES

4. New types of mobile applications
 Interactive/immersive applications require ultra-low latencies
• E.g., augmented reality requires end-to-end delays under 20ms
• But user-to-cloud latencies ~20-30ms (wired) / ~100-150ms (4G)
 Throughput-oriented applications require local computations
• The source of data and destination of results are often co-located
• E.g., videosuveilance
• Fact: IoT-generated traffic grows faster than the Internet backbone
capacity
 Dependable applications must tolerate poor client-side network
connections
• Underground, in rural areas, etc.
4

5. 5

6. Who owns computing resources
located closest to
the mobile end users
and the IoT devices?
 Mobile network operators
 Smart cities
 Enterprises
 Citizens
 …
6

7. Fog computing = cloud + edge + end-user devices
as a single execution platform
7
Low latency
Localized traffic
• Less global traffic
• Better reliability
• Privacy (perhaps)…

8. Typical cloud platform: Typical fog platform:
Cloud ≠ Fog
 Few data centers
 Lots of resources per data center
 High-performance networks
 Cloud resource location is (mostly)
irrelevant
 Huge number of points-of-presence
 Few resources per PoP
 Commodity networks
 Fog resource location is extremely
important
5

9. section
Making fog servers really small
9

10. Our powerful server machines
10

11. Our powerful server machines
11

12. 12

13. SD cards were designed to store
photos, videos, etc.
The main limitation of our RPIs: the DISK
 Small number of large files
=> large physical blocks
 The RPI’s SD reader is
connected to the USB bus
=> not the fastest…
13

14. section
Toward proximity-aware fog
computing platforms
Or how to transform a cloud management
system into a fog management system…
14

15. The fog according to us
15

16. Kubernetes is a great platform…
16
 Container-based => lightweight, can run on a Rpi
 Pods and services => easy to deploy and (re-)scale applications
 Integrated autoscaling => ready for fluctuating workloads
 Designed around feedback control loops => simple and robust
 Large community of users and developers => can can find help
when needed 

17. … but it is not ready for the fog
17

18. … but it is not ready for the fog
18

19. … but it is not ready for the fog
19

20. … but it is not ready for the fog
20

21. … but it is not ready for the fog
21

22. How Kubernetes routes requests
 (not necessary in our use-cases): expose a public IP address to
external users
 Route traffic from any Kuberbetes node to one of the pods
• The central kube-proxy controller detects a change in the set of
pods
• It requests all cluster nodes to update their routes
• Routes are implemented using iptables
 By default requests are distributed equally between all pods
22

23. Making request redirection location-aware
 Let’s change kube-proxy:
• Detect a change in the set of pods
• Request each cluster node to update its routes to nearby pods
 Where should each node route its traffic?
• To the closest pod according to GPS coordinates
• To the closest pod according to Vivaldi coordinates
• Load-balance to the n closest pods
• …
 We need to deploy additional monitoring functionality
• Vivaldi…
23

24. section
The FogGuru project
24

25. Fog computing is still in its infancy
 No general-purpose reference platform available
• Mostly cloud systems which pretend to address fog concerns
• But with very little solutions to the specific challenges of fog computing
 FogGuru will investigate some of the most challenging management issues
in fog platforms: resource scheduling, migration, autonomous management,
anomaly detection, etc.
 No fog-specific middleware
 FogGuru will investigate how to adapt stream-processing middlewares to
fog environments
 No guidelines on how to develop a fog application
 FogGuru will develop blueprints for latency-sensitive and throughput-
intensive applications
 No highly-trained specialist in fog computing
 FogGuru will train 8 ESRs on various aspects of fog computing
25

26. FogGuru: train the next generation of European fog
computing experts
 Strong consortium:
• 2 universities, 2 high-tech SMEs, 2 partner organizations
 Ambitious training program:
• In-depth technical education in the respective ESR’s scientific fields
• Broad technical and soft-skills training in relevant domains
• State-of-the-art training in Innovation and Entrepreneurship
 Living lab experience in Valencia:
• Deploy FogGuru’s technologies in real urban settings
• Engage with external beta-testers to evaluate the technologies and
refine the technological innocation plans
 Every ESR will personally drive his/her full
research → innovation → end-user engagement process
• 40% time in academia, 40% in SMEs, 20% in the living lab
26

27. Consortium & domains of expertise
27

28. Research objectives
 RO1: to manage resources and applications in scalable fog
platforms
• Fog platforms are made of many tiny points-of-presence,
connected with commodity long-distance networks
• How should we adapt cloud computing technologies to this new
environment?
 RO2: To adapt stream-processing middleware systems for fog
applications
• Stream processing was designed for high-performance data
analytics in clusters/clouds
• How should we adapt it to fog environments?
 RO3: To develop blueprints for innovative applications
• How does one develop innovative fog computing applications?
28

29. ESR projects and mobility
29
# Empl
oyer
Enrol-
ment
Project title Research
objectives
Second-
ment #1
Second-
ment #2
ESR1
(Paulo)
UR1 UR1 Fog computing service roaming
techniques
RO1, RO3 UH LNV
ESR2
(Hamid)
UR1 UR1 Stream processing operator placement RO1, RO2 ELA LNV
ESR3
(Lilly)
ELA TUB Autonomous management optimizations
based on on-line anomaly detection
RO1 TUB LNV
ESR4
(Mulugeta)
ELA UR1 Automatic optimization of autonomous
management systems
RO1 UR1 LNV
ESR5
(Dimitrios)
TUB TUB Elasticity mechanisms for distributed
stream processing under QoS constraints
RO2 UH LNV
ESR6
(Felipe)
TUB TUB Robust data stream optimization under
variable traffic conditions
RO2 ELA LNV
ESR7
(Davaadorj)
UH UR1 Scalable data pipelines in fog
computing environments
RO2, RO3 UR1 LNV
ESR8
(Mozhdeh)
UH UR1 Fog computing-enabled IoT situation-
aware services
RO3 UR1 LNV

30. Training objectives
 TO1: to enable ESRs to become recognized specialists in their
respective technical domains
• Indispensable for scientific credibility and impact
 TO2: to make ESRs knowledgeable in a wide range of related
technical topics
• Ability to enter new areas and interact with specialists of other fields
 TO3: to make ESRs develop an entrepreneurial and business
innovation oriented mindset
• Detect business opportunities, conduct the innovation process,
maximize social impact
 TO4: to make ESRs master a wide range of transferable soft skills
• Useful skills regardless of career choices
30

31. Training events
31
# Training
objectives
Main training events Lead
institution
Project
month
Duration Open
event
1 TO3, TO4 Boot Camp UH M7 3 days
2 TO3 Opportunity recognition EITDR M7 1 week
3 TO1 Year 1 workshop: research methods UR1 M15 1 week ✓
4 TO1, TO4 Mid-thesis defenses TUB M24 2 days
5 TO3, TO4 Business modeling and development EITDR M24 3 weeks
6 TO2 Year 2 workshop: linking with other
disciplines
ELA M33 3 days ✓
7 TO3, TO4 Growth and harvest EITDR M33 2 weeks
8 TO1 PhD defenses UR1 M46 2 days ✓
45 days

32. The living lab
 Deploy a real fog in the city center of Valencia
 Experiment the technologies developed by FogGuru’s ESRs
 Engage with the local SME/startup eco-system:
• Recruit beta-testers for scientific evaluations
• Evaluate the usability and social acceptability of fog technologies
 Also a good platform for dissemination/exploitation
32

33. 33

34. 34

35. Work packages
35
WP # WP Title Lead
beneficiary
Start
month
End
month
WP1 Project governance UR1 M1 M48
WP2 Recruitment and training UH M1 M48
WP3 Living lab UR1 M22 M48
WP4 Application resource management ELA M7 M48
WP5 Stream processing in fog computing
environments
TUB M7 M48
WP6 Dissemination, communication and
innovation
UH M1 M48
WP7 Ethics requirements UR1 M1 M48
WP8 Open access UR1 M1 M48
(*)
(*): to be largely delegated to LNV

36. The FogGuru project has received funding from the European Union’s
Horizon 2020 research and innovation programme under the Marie
Skłodowska-Curie grant 765452.
TRAINING THE NEXT GENERATION
OF EUROPEAN FOG COMPUTING EXPERTS
www.fogguru.eu
Merci!