Presentation of the Mainflulux team held In Portland at Embedded Linux Conference & OpenIoT Summit North America March 14 2018. IoT middleware platforms have become necessary building blocks of every complex vertical IoT solution. Traditionally, the platforms have been built to run in the cloud; wide availability and rich capabilities have driven the first wave of IoT adoption. As the scale and complexity of IoT projects have grown, however, the need to provide solutions that move to process to the network edge has also grown. Down-scaling cloud capabilities is complex in part because of the more modest capabilities of edge computing in typical deployment models. As a result, there are few open solutions that address this need. We introduce Mainflux (https://github.com/Mainflux/mainflux) - a IoT Platform for cloud and edge that can simultaneously scale-out to hundreds of nodes in the cloud but can also scale down to a modest RaspberryPi computer without changing a single line of code. This scalability is achieved thanks to careful architecture, the effectiveness of the Go programming language, and technology choices used in the implementation. We will discuss the platform, its use and application, and our work to bring core concepts from it to various open source projects including EdgeX. Repository for Mainflux open source and royalty-free IoT platform published under Apache-2.0 license, free download https://github.com/mainflux/mainflux Mainflux company official website: https://www.mainflux.com/

1. Unified IoT Platform
Drasko Draskovic, Mainflux
Janko isidorovic, Mainflux

2. Over 10 years of industry experience in
semiconductor, telecom, system software,
embedded and electronics. MSc in Electrical
Engineering, Electronics, Telecommunication and
Control
OMAP processors for Texas Instruments, LTE SoC
with Sequans Communications, 5G connected
world with NOKIA
Connected everything (IoE) with Mainflux
Drasko
Draskovic
MSc. Electronics
Janko is the co-founder of Mainflux IoT open
source project. He is also chair of the Application
Work Group of Linux Foundation EdgeX project.
Janko has a 10+ years background in Project
Management, IT and Software integrations.
He holds MSc. In Telecommunications from
Belgrade University.
Janko
Isidorovic
MSc. Telecommunications

3. MAINFLUX
INTERNET OF THINGS PLATFORM
OPEN-SOURCE AND PATENT-FREE
DEPLOY ON-PREMISES OR IN THE CLOUD
Mainflux is highly secure, scalable, open-source IoT platform written in
Go and deployed in Docker.
It serves as software infrastructure and set of microservices for
development of the Internet of Things Solutions and deployment of
intelligent products.
https://www.mainflux.com/
https://github.com/mainflux

5. EdgeX Foundry
EdgeX Foundry™ is a vendor-neutral open source project building
a common open framework for IoT edge computing.
At the heart of the project is an interoperability framework hosted
within a full hardware- and OS-agnostic reference software
platform to enable an ecosystem of plug-and-play components
that unifies the marketplace and accelerates the deployment of IoT
solutions.
https://www.edgexfoundry.org/
https://github.com/edgexfoundry

6. Scalable Architecture for the
Internet of Things
An Introduction to Data-Driven Computing Platforms
http://www.oreilly.com/programming/free/scalable-architecture-for-the-internet-of-things.csp

7. Outline
1. IoT Platform
2. IoT Devices
3. IoT Edge
4. IoT On-premise
5. IoT Cloud
6. Unified IoT Architecture

8. IoT

9. What is Internet of Things
The Internet of Things is the network of
dedicated physical objects (things) that
contain embedded technology to sense
or interact with their internal state or
external environment.
The IoT comprises an ecosystem that
includes things, communications,
applications and data analysis.

10. Internet of Things > M2M
Connectivity and embedded technology
The cost of connectivity and embedded technology is
becoming less of a barrier to adoption.
Broadband communication, Wi-Fi, Near Field
Communication (NFC), Bluetooth and mobile networks are
becoming ubiquitous and able to support large volumes of
IoT connectivity at little incremental cost.
• Low Cost Sensors
• Long Range - Low Power Radio Networks

11. ARM - Trillion Connected Devices by 2035

12. “We completely restructured Intel to be a cloud
and Internet of Things company”
Raejeanne Skillern, vice president of
the Data Center Group and general
manager of the Cloud Service
Provider Business at Intel Corp.
March 2017.

13. IoT Platform

14. But IoT is still hard, because
electronics, firmware, RF, network
protocols, server architecture,
devops, security...

15. IoT Platform

16. IoT Landscape

17. IoT Platform Design - Bottom up approach
• Start with “users” - IoT platform users are devices
• Go to Edge
• Run on premise
• Push to Cloud

18. IoT Device/Client

19. IoT Landscape - Devices

20. Devices are Small - Sensors and Smart Dust

21. IoT Constrained Nodes
Name
Data Size
(e.g., RAM)
Code Size
(e.g., Flash)
Class 0, C0 << 10 KiB << 100 KiB
Class 1, C1 ~ 10 KiB ~ 100 KiB
Class 2, C2 ~ 50 KiB ~ 250 KiB
IETF RFC 7228: Terminology for Constrained-Node Networks
● MCU + RF front-end
● Bare-metal or small RTOS
● Constrained CPU clocking (low on kHz)
● Constrained flash and RAM
● Battery powered devices

22. Heavy networking stack just won't fit!

23. Should I use WS to connect devices?

24. HTTP then?

25. MQTT?

26. CoAP?

27. Devices are Big - Industry, Energy, Cloud

28. Devices are Big - Industry, Energy, Cloud
• Large amount of data
• High throughput
• Real-Time analytics
• Device actuation
Old and new protocols:
• OPC-UA
• MODBUS
• DBUS
• BACNET
• Zigbee
• Etc...

29. Devices are Disconnected

30. Devices are Disconnected
• Battery Powered
• Deployed in the field
• Network connectivity issues
• Devices need to reconnect

31. IoT Edge

32. IoT Landscape - Edge

33. Action Is On The Edge
“The edge of the IoT is where the action is. It includes a wide
array of sensors, actuators, and devices - those system
end-points that interact with and communicate real-time data
from smart products and services.”
Foundational Elements of an IoT Solution by Joe Biron and
Jonathan Follett (O’Reilly).

34. End of Cloud Computing
“Think about a
self-driving car, it’s
effectively a data center
on wheels.”
- Peter Levine, general
partner at Andreessen
Horowitz, “The End of Cloud
Computing”

35. Reasons For The Edge
• Low latency (immediate response)
• Perishable data (loses value after few seconds)
• Big amount of data (impossible and/or expensive to transfer)
• Network segmentation (organization)
• Private network installation
• Local security and firewalls

36. Cloud vs On Premise vs Edge
Edge
• Low memory footprint (RAM)
• Small size binaries
• Low Latency
• Hi Performance
• Deploy only microservices
you need for the project
On Premise / Cloud
• Scalability
• FT and HA
• Big Data

37. IoT Edge Gateways

38. IoT Edge Gateway Spec
Mainflux MFX-1
• NXP Quad 1GHz i.MX6 ARM A9
• 2GB RAM
• 8GB eMMC
• Industrial Temp. (-40° to 85° C)
• Includes WiFi/BT
• Size: 102mm x 69mm
Dell 5000
• Intel CPU E3825 1.33GHz
• 2GB RAM
• 32GB SSD
• Consumer Temp. (0°C to 50°C)
• WiFi
• Size: 229mm x 216mm

39. Go Comes Into The Play

40. Where and Why Go?
• Single code base runs everywhere - Intel, ARM, Windows,
Linux, MacOS
• Easy to code
• Small footprint
• Maintainable
• High performance

41. Go vs Java in EdgeX
Results clearly indicate Golang as more performant and efficient
as measured by number of factors above.
Release Metrics (Jim White, Senior Software Architect at Dell)

42. Mainflux RPi Example
drasko@Marx:~/go/src/github.com/mainflux/mainflux$ make -j 8 GOOS=linux GOARCH=arm GOARM=7
GOOS=linux GOARCH=arm GOARM=7 go build -ldflags "-s -w" -o build/mainflux-manager cmd/manager/main.go
…
drasko@Marx:~/go/src/github.com/mainflux/mainflux$ ls -lh build/
total 23M
-rwxr-xr-x 1 drasko drasko 4.0M Mar 14 17:29 mainflux-coap
-rwxr-xr-x 1 drasko drasko 4.7M Mar 14 17:29 mainflux-http
-rwxr-xr-x 1 drasko drasko 6.1M Mar 14 17:29 mainflux-manager
-rwxr-xr-x 1 drasko drasko 7.7M Mar 14 17:29 mainflux-normalizer
drasko@Marx:~/go/src/github.com/mainflux/mainflux$ file build/mainflux-manager
build/mainflux-manager: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped

43. Mainflux `FROM scratch` Dockerfile
FROM golang:1.9-alpine AS builder
ARG SVC_NAME
RUN apk update
&& apk add git
&& go get github.com/mainflux/mainflux
&& cd /go/src/github.com/mainflux/mainflux/cmd/$SVC_NAME
&& CGO_ENABLED=0 GOOS=linux go build -ldflags "-s" -a -installsuffix cgo -o /exe
FROM scratch
COPY --from=builder /exe /
ENTRYPOINT ["/exe"]

44. Mainflux Docker Images
drasko@Marx:~/go/src/github.com/mainflux/mainflux/docker$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
mainflux/http latest fa4368588610 2 days ago 5.94MB
mainflux/normalizer latest 7fe785bc947f 2 days ago 9.79MB
mainflux/manager latest eac8a24c1372 2 days ago 7.77MB
nginx 1.13-alpine 537527661905 2 weeks ago 17.9MB
postgres 10.2-alpine 400ef39e0dbf 3 weeks ago 39.5MB
mainflux/mqtt-adapter latest 5d0f098f76e9 8 weeks ago 123MB
nats 1.0.2 3e5d0988d123 6 months ago 5.7MB

45. IoT Platform - On Premise

46. IoT Landscape - On Premise Deployment

47. IoT Problems - On Premise
• Data from multiple Edge locations
• Company/Government Policy - No Cloud
• ERP Integration
• Enterprise Data Analytics
• Filter data and then push to cloud for advanced analytics
• Utilize existing hardware
• Hybrid solution - On premise and cloud

48. IoT Platform in the Cloud

49. IoT Problems - Cloud
• “Infinitely Scalable”
• High Latency
• Network connectivity can be lost
• Advanced Data Analytics
• Is Cloud also a “device” connected to the IoT Platform?

50. Unified Architecture

51. Why is Unified Architecture Important?
• Lower Entry Barrier
• Decrease Number of Technologies
Used
• Decrease Development Team Size
• Increase Security
• Simplify Code Maintenance
Bottom Line:
- Reduce Time To Market
- Lower TCO

52. IoT Problems - Diversity
• Hardware Scale - Constrained to Server to Cloud
• Hardware Architecture - Intel, ARM
• Network Topology - Mash, Star
• Network Connectivity - IP, no IP
• Wireless Networks - WiFi, LoRa, BLE, Zigbee, 6LoWPAN
• Security - Physical, Network, Application, Data Security
• IoT Protocols - MQTT, CoAP, OPC-UA, BACNET, MODBUS...

53. Mainflux

54. Use microservices, Luke

55. Mainflux Architecture
• Microservices
• Modular design
• Support for different
messaging databases
• Deploy Native or in
Container
• Stateless Containers easy
to scaleout

56. Mainflux - Messaging Subsystem
Messaging subsystem is composed of
following microservices:
• HTTP Server
• WS Server
• MQTT Broker
• CoAP Server
• NATS Broker
• Database Adapter and Storage
It’s role is to distribute messages
between various clients that can connect
via various protocols - i.e. it makes a
messaging bridge between them.

57. Mainflux - Reverse Proxy
• Load Balance - scaling, HA, Fault
Tolerance
• Reverse Proxy
• SSL termination - keep these certs at
one place. MQTT is pure TCP, and
CoAP is UDP

58. Mainflux - Manager
• Policy Based Auth
• Grouping devices by connection to
channels
• Channel corresponds to MQTT topic
• JWT and Certs for Devices
• JWT (short TTL)
• Bearer Token
• Uses SQL Database
• Evaluate support for OAuth 2.0
for Apps

59. Database Scalability
Database - SQL/NoSQL/NoDB
• PostgreSQL - device metadata
• Cassandra DB - device messaging
• MongoDB - device messaging
• InfluxDB - device messaging
• NoDB - Is Messaging Database Required?

60. Mainflux - Scalability
• Mainflux runs on Kubernetes
• Scaling is Easy - even across multiple datacenters
• Independently Scale each of the microservices depending on
the load
• Distributed Deployment

61. Kubernetes Deployment
• Easily Scale up/scale
down
• Easily add servers to the
system
• Scale each of the
microservices
independently

62. Mainflux - Scale Down
● Mainflux runs on RPi Class Hardware
● Native deployment on the Edge

65. `docker-compose up` and you got
your Mainflux system running!

66. Mainflux Project Timeline

67. Thank you!