describing and comparing different protocols when it come to deploying apis on edge computing devices. 5 different categories are analyzed and 7 protocols are examined

1. Version 1.0
APIs at the
Edge
APIs in the wild or how do APIs behave when left at the edge? Will they survive the
adversities out there?
Luca Ferrari
EMEA Edge Solution
Architect @ Red Hat
1

2. Version 1.0
Agenda
Edge definition
Edge challenges
Application pattern solutions
Protocol alternatives
Comparison
Energy analysis on PI [WIP]
Silver bullet
2

3. What and why
edge?
3

4. Definition
Edge computing is a distributed application
architecture that places computational resources
(eg, CPU and storage) close to the source of the
data.
By doing so, it offers the advantages of low
latency, high performance, and security for a wide
range of applications. 4

5. Why?
“ Around 10% of enterprise-generated data is created and processed outside
a traditional centralized data center or cloud. By 2025, Gartner predicts this
figure will reach 75%”
5

6. In everyday life …
➔ 5g connected ambulance to stream video and
sensor data from the ambulance directly to the
hospital
➔ Intelligent analysis at the edge of the patient
condition by leveraging patient models
➔ Allow for remote diagnostics through streaming of
advanced tools feed
6
Connected ambulance

7. Edge challenges
7

8. Challenges
1
Unreliable
connection
2
Unreliable
power source
3
Data sync not
always possible
4
Reduced
computing
resources
5
Legacy
protocols
6
Secure by
design
requirement
7
Low latency
requirement
8
High volume
of data
8

9. Problem
BrianzAcque self-service Case dell’acqua water kiosks dispense high-quality
still and sparkling water, purchased using a rechargeable payment card. To
present relevant, real-time information to consumers at each Case dell’acqua
location, BrianzAcque needed to integrate live data from its aqueducts and
water purification plants such as pH, calcium, chromium, nickel, mercury, and
manganese levels—and create a central management system. Additionally,
kiosks must be able to read citizens’ payment cards to identify users and
process purchases.
Solution
The technology in the kiosks is based on the Arduino interactive electronic
platform. Container platform is distributed outside of the datacenter to adapt
to IoT needs, which provides portability across deployments and devices.
1. Achieved real-time delivery of water quality data
2. Improved operational efficiency and costs
3. Established robust security to meet industry regulations
Field example
9

10. Field example
10
Problem
Manage 1 billion ConnectedDrive requests per week
Stay competitive in the autonomous vehicle market & transform from a “car
maker” to “mobility provider”
Offer customers new connected services
Invest in autonomous driving by using data
Solution
High-performance AI Platform for autonomous driving to analyze massive
amounts of global test fleet data in the cloud
Cloud-native platform lets developers focus on building apps
ConnectedDrive backend runs on Container Platform
1. 12 million connected cars
2. 1 billion request per week

11. Patterns
11

12. Pattern solutions
Typical policies or patterns applied at the REST level to solve edge challenges:
1. Persist measurements locally when disconnected
2. Filter and aggregate to reduce bandwidth usage
3. Cache query results and authentication on Edge side
4. Automatic device registration
5. …
12

13. Talking to edge
13

14. Stack
14
REST
COAP
MQTT
Thrift
Websockets
AMQP
gRPC

15. HTTP
HTTP/2
HTTP/2 improvements:
❏ Binary encoding (vs plain text)
❏ Request response multiplexing (vs multiple TCP
connections)
❏ Stream prioritization
❏ TLS by default
❏ Server Push
❏ Header compression
15
http://www.http2demo.io/

16. HTTP
HTTP/3 [proposal]
HTTP/3 major difference:
❏ HTTP/3 uses QUIC, a multiplexed transport
protocol built on UDP
16
https://cloudflare-quic.com/

17. REST
01
No official standard
Defining features:
● Client server model
● Stateless
● Cacheable
● Uniform interface
● Transparent layering
17

18. REST
01
No official standard
Defining features:
● Client server model
● Stateless
● Cacheable
● Uniform interface
● Transparent layering
18

19. REST
01
Used everywhere, mobile applications included
Easiest way to try:
https://learning.postman.com/docs/developer/ech
o-api/
Typical output format:
JSON but can transfer binary
19

20. COAP
02
CoAP is a lightweight M2M protocol from the IETF CoRE
(Constrained RESTful Environments) Working Group.
Constrained Application Protocol (CoAP):
❏ Runs on UDP (optional DTLS)
❏ Very similar to HTTP (support many of the request/response
codes)
❏ Possible multicast
❏ Low protocol overhead (binary protocol)
20

21. COAP
02
Used mainly for IoT and M2M communications, found
in WSN. Not widely used as it is relatively young
Easiest way to try:
https://coap.me/
21

22. gRPC
03
gRPC is a cross-platform open source high
performance Remote Procedure Call (RPC) framework.
gRPC was initially created by Google.
gRPC Remote Procedure Call:
❏ Uses HTTP/2 protocol
❏ Uses Protocol Buffers to describe the interfaces
❏ Strict message specification (less doubt about
implementation)
22

23. gRPC
03
Typically used in connecting services in a microservices
oriented architecture, or connecting mobile device
clients to backend services.
Try out with:
https://blog.postman.com/testing-grpc-apis-with-
postman/
23

24. MQTT
04
MQTT is a M2M communication protocols, introduced
in 1999.
MQTT client publishes messages to an MQTT broker,
which are subscribed by other clients or may be
retained for the future subscription. Clients can
subscribe to multiple topics and receives every
message published to the each topic.
Message Queuing Telemetry Transport Protocol:
❏ it is a publish/subscribe messaging
❏ it is a binary protocol
❏ It offers 3 levels of QoS
24

25. MQTT
04
Typically used in IoT enterprise and home solutions
Easiest way to try:
http://www.hivemq.com/demos/websocket-client/
25

26. AMQP
05
AMQP is a lightweight M2M protocol, designed
for reliability, security, provisioning and interoperability.
Latest spec version is 1.0
Advanced Message Queuing Protocol:
❏ supports both request/response and publish/subscribe
❏ Binary protocol
❏ exchanges messages in various ways: directly, in fanout
form, by topic, or based on headers
26

27. AMQP
05
Java environment, enterprise messaging, but also
sometimes IoT scenarios
Easiest way to try:
http://tryrabbitmq.com/
27

28. Thrift
06
Thrift is an Interface Definition Language and binary communication
protocol developed at Facebook for "scalable cross-language services
development". Open Source Apache project.
Apache Thrift:
❏ Similar to gRPC and inherently similar advantages
❏ Binary format
❏ It can use TCP and HTTP
28

29. Thrift
06
29
Still used widely at Facebook and in general for all
those use cases where gRPC is used

30. Websockets
07
WebSocket provides full-duplex communication
channels over a single TCP connection. It is using
HTTP as underlying protocol, with HTTP Upgrade
message.
WebSockets:
❏ Provides full duplex communication
❏ Allow for stream of messages
❏ Enabled by default on most browsers
30

31. Websockets
07
31
Relevant in IoT scenarios for these main reasons:
❏ allow to encapsulate protocols such as MQTT
without the need for middleware
❏ It is a real time protocol
❏ It uses a pub/sub framework based on HTTP
Typically used when real time feeds are needed:
video/chats, real time location, real time updates
Easiest way to try:
https://www.piesocket.com/websocket-tester

32. Showdown
32

33. Metrics
1. Information efficiency (protocol overhead)
2. Support for prioritization and traffic control
3. Security measures and standards
4. Performance (latency & TPS) [WIP]
5. Developer experience & adoption
33

34. Protocol overhead
34
❏ Assumption of a very simple message to
simulate Edge scenario (1KB)
❏ Will be using default or typical header size
for all protocols
❏ Since grpc runs on HTTP/2 further
optimizations might be achieved
Lower is better

35. Security
35
❏ REST and HTTP offer almost any form of variation in terms of AuthN and AuthZ and
communication encryption
❏ MQTT supports secure communication over TLS and supports AuthZ as well (port 8883
typically)
❏ AMQP supports secure communication over TLS and supports AuthZ too (port 5671)
❏ Websockets can use secure communication over port 443 HTTPS
❏ Grpc implements secure communication by default based on HTTP/2 with multiple AuthN
methods
❏ Coap adopts Datagram TLS over UDP for secure communication

36. Traffic control
36
❏ REST offers no flow control, but HTTP/2 introduces flow control functionality
❏ gRPC can take advantage of the above features
❏ Flow control is possible with AMQP (in Apache ArtemisMQ both Consumer and
Producer flow control measures are available), QoS is supported as well
❏ Flow control is available with the latest version of MQTT (v5), 3 level of QoS are
supported
❏ No flow control with Thrift, Coap or Websockets

37. Performance
37
Higher is better Lower is better

38. DX & adoption
❏ Interest is growing for MQTT at the edge
❏ grpc interest mostly related to cyberattacks
❏ Amqp mostly related and associated to java world
❏ Websockets mostly associated with javascript
❏ Both grpc and thrift have support across all major
programming languages
❏ Both mqtt and amqp require a broker making DX harder
38
Subjective scoring

39. Give me the
answer!
39

40. Sorry no silver bullet here, just a clickbait
Given the current environment and
volatility around Iot and Edge markets
no predictions can be made, but …
40

41. Sorry no silver bullet here, just a clickbait
Seems like MQTT is winning over in the
IoT and Edge space.
If otherwise you prefer request /
response model your answer might be
gRPC
41

42. Few words from
my co-host …
42

43. Quick intro
43

44. Links
44

45. Links
45

46. Thank you &
to our collaborator
Honeypot.io
46