This document provides an overview of how to design a backend for the Internet of Things (IoT). It discusses key concepts like DevOps, microservices, and cloud computing. The presenter has experience working with IoT infrastructure and recommends a serverless architecture using AWS services like Lambda, API Gateway, and S3. Design principles like the 12 factor app methodology and avoiding monolithic applications are emphasized. Distributed systems challenges around areas like configuration, logging, and security are also addressed.

1. HOW TO DESIGN A BACKEND
FOR THE IOT
İBRAHİM GÜRSES

2. WHO AM I?
▸ Graduated From Bilkent University in 2011
▸ Vakıfbank, Gate Elektronik, T2 Yazılım, OpsGenie,
Hazelcast, Arçelik.
▸ Currently working on IoT infrastructure @Arçelik
▸ Co-Founder of Ankara Cloud Meetup

3. ANKARA CLOUD MEETUP

4. SERVERLESS COMPUTING WITH AWS
HTTPS://WWW.YOUTUBE.COM/WATCH?V=LEPQXTOWDJS

5. DEVOPS CULTURE AND PRACTICES
HTTPS://WWW.YOUTUBE.COM/WATCH?V=D3E0XJCRWCE

6. AGENDA
▸ IOT
▸ DevOps
▸ 12 Factor App
▸ Cloud
▸ Microservices
▸ Q&A & Demo

7. IOT

8. FROM MOORE’S LAW TO METCALFE’S LAW
Metcalfe's law states that the value of a telecommunications network
is proportional to the square of the number of connected users of the
system

9. WHAT IS IOT?
▸ The network of physical object that contain embedded
technology to communicate and interact with their internal
states or the external environment. (Gartner)
▸ The term is coined by Kevin Ashton in 1999 in
Procter&Gamble
▸ Also called M2M, Industrial Internet, Web of Things,
Internet of Everything, Industry 4.0

10. 3 PILARS OF IOT

11. GARTNER’S HYPE CYCLE 2016

12. FATHER OF JAVA AND IOT

13. FATHER OF JAVA AND IOT

14. A TYPICAL IOT DATA PROCESSING ARCHITECTURE
Source : Internet of Things: Principles and Paradigms, Elsevier Science, 2016

15. PROCESSING DATA FROM THE EDGE
▸ Collect
▸ Instrument apps
▸ Deliver events to analytics service
▸ Receive and store many live data streams
▸ Analyze
▸ Real-time and historical analysis of event streams
▸ Aggregations, pivots and patterns
▸ Consume
▸ Publish analytics in a consumable format
▸ Inform and influence
▸ Make better decisions

17. IOT TECH STACK

18. DEVOPS

19. DEVELOPMENT BEFORE DEVOPS
▸ DevOps is a new term that primarily
focuses on improved collaboration,
communication, and integration between
software developers and IT operations. It’s
an umbrella term that some describe as a
philosophy, cultural change, and paradigm
shift. Figure shows developer throwing
code "over the wall" Historically many
organisations have been vertically
structured with poor integration among
development, infrastructure, security and
support teams. Frequently the groups
report into different organisational
structures with different corporate goals
and philosophies.

20. FILLING THE GAPS

21. WHAT DEVOPS BRINGS
▸ Today, these old divisions are breaking down, with the IT and
developer roles merging and following a series of systematic
principles:
▸ Infrastructure as code
▸ Continuous deployment
▸ Automation
▸ Monitoring
▸ Security

22. INFRASTRUCTURE AS CODE
▸ Repeatability (Humans make mistakes)
▸ Agility (Roll forward or roll back easily)
▸ Auditing and Security (Paper trail and permissions)

23. AUTOMATION AND CONFIGURATION MANAGEMENT
▸ Provisioning (CloudFormation, OpsWorks, BeansTalk)
▸ Declarative (Loosely coupled to implementation)
▸ Configuration (Chef, Pupper, SaltStack, Ansible, DSC)

24. MONITORING AND SECURITY
▸ Processing all systems logs in real time.
▸ Logs should be considered as events
▸ Security can inject analysis tools to dev pipeline.
▸ Testing is not optional in devops.

25. DEVOPS
▸ Do not write code and toss it to ops and testing team
▸ Do not repeat task manually
▸ Rise of devops tools(Chef, Puppet, Ansible)
▸ Spend time developing business code instead of
infrastructure code (NoOps)

26. MOVING LEGACY APPS ON CLOUD
▸ Asset Hosting
▸ How do you deal with uploaded content? (images/
videos/music)?
▸ Session Management
▸ How do you deal with session data? Session replication
will be a necessity, sticky session is bad for scalability
and availability

27. MOVING LEGACY APPS ON CLOUD CONTD
▸ SQL
▸ What considerations are there SQL? (How to handle
stored procedures)
▸ NoSQL
▸ How can you take advantage modern trends of NoSQL?

28. MOVING LEGACY APPS ON CLOUD CONTD
▸ Caching
▸ How do you incorporate modern caching techniques?
▸ Async Processing
▸ How do you handle long running processes?

29. 12 FACTOR APP

30. 12FACTOR.NET

31. WHAT IS 12 FACTOR APP?
▸ It is a methodology for building SaaS application
▸ Tries to define systematic problems in app development
▸ Tries to define a set of conceptual solutions to those
problems

32. GENERAL PROPERTIES OF 12 FACTOR APP
▸ Uses declarative format for setup automation.(Easy
orientation for new joining devs)
▸ Has a clean contract with underlying operations system
(Increases portability)
▸ Is suitable for deployment on modern cloud systems
(CloudNative app, also no need for an army of ops guys to
deploy and maintain the app)

33. 12 FACTOR APP
▸ Code is version Controlled
▸ Always tracked in version control system
▸ 1:1 relationship between code base and app
▸ Many deploys of given app
▸ Codebase same across deploys version may differ

34. WHAT WE DO?

35. 12 FACTOR APP
▸ Dependencies are declared and Isolated
▸ Never assume system-wide packages
▸ Dependency declaration manifest
▸ Isolated so no dependency leak from system
▸ Helps new developers

36. WHAT WE DO?
We use maven. A new
developer can start working
by simply typing single
command `mvn clean install`
and all library dependencies
will be installed.

37. 12 FACTOR APP
▸ Configuration is Stored in the Environment
▸ Should store in env variables
▸ Should not be constants in code
▸ Ideally not in conf files
▸ Avoid grouping as environments

38. WHAT WE DO?
▸ All environment variable and configuration information is
stored over AWS and all applications including mobile
client and wifi-card gets their configuration information
from a single place.

39. 12 FACTOR APP
▸ Backing Services as Attached Resource
▸ Services consumed over the network
▸ No distinction between local or third party services
▸ Keep Dependencies de-coupled
▸ Attach and detach at will

40. WHAT WE DO?
▸ We use AWS services for both SQL
and NoSQL data storage
(RDS,DynamoDB)

41. 12 FACTOR APP
▸ Build and Run Stages are separated
▸ Impossible to change code at runtime
▸ Releases should have IDs
▸ Build may be complex, started by Devs
▸ Run is simple and completely unattended

42. WHAT WE DO?

43. 12 FACTOR APP
▸ Application Executed as Stateless Processes
▸ Share Nothing (Universal Scalability Law)
▸ Persisted data in stateful backing store
▸ Memory and File System is for cache only
▸ Avoid sticky Sessions

44. WHAT WE DO?
▸ We implemented stateless serverless architecture with
AWS API Gateway and Lambda.
▸ Each request to cloud is executed within a Lambda
function inside a isolated stateless container

45. 12 FACTOR APP
▸ Services Exported via Port Binding
▸ Self Contained
▸ Embedded servers
▸ Listen on specific port
▸ Very specific and idealistic

46. 12 FACTOR APP
▸ Application scaled out via process model
▸ Processes are first class citizens
▸ Work assigned to process type
▸ Applications have process that span servers
▸ Use OS process managers not deamons

47. 12 FACTOR APP
▸ Processes are disposable
▸ Can be started or stopped at any time
▸ Minimal start up time, graceful shutdown
▸ Worker processes return to work queue
▸ Robust against sudden death

48. 12 FACTOR APP
▸ Parity Between Application Environments
▸ Avoid time/personnel/tool gaps
▸ Design for continuous deployment
▸ Very important for backing services
▸ Containers and config mgmt. makes this easier.

49. 12 FACTOR APP
▸ Logs are stream of time-ordered events
▸ App is never concerned with storing log files
▸ Execution environment capture logs
▸ May be routed to file, watched, sent to external service

50. WHAT WE DO?
▸ We use AWS CloudWatch to monitor system logs.

51. 12 FACTOR APP
▸ Management Task Run as One-off Process
▸ Run in identical environment
▸ Separate out as scripts that are source controlled
▸ Don’t run from local terminal
▸ Don’t run directly against the database

52. ADDITIONAL DEVOPS DESIGN CONSIDERATIONS
▸ Rely on sync messaging
▸ Compose applications out of service
▸ Assess portability requirements
▸ Embrace the abstractions

53. DEVOPS ANTI-PATTERNS
▸ Relying on the local file system
▸ Building services that scale up
▸ Trying to change code server side
▸ Manually coordinating builds
▸ Hard-coding configuration
▸ Cramming everything into one app

54. DEVOPS CONCEPTS BEFORE FAILURE
▸ Chaos Monkey
▸ Blue/Green - Canary Deployment
▸ Dependency Injection
▸ Andon Cords
▸ The Cloud
▸ Embedded Teams

55. DEVOPS CONCEPTS AFTER FAILURE
▸ Blameless Postmortems
▸ Public Status Page
▸ Developers on Call
▸ Incident Command System

56. CAMS MODEL
▸ Culture
▸ Automation
▸ Measurement
▸ Sharing

57. KAIZEN’S GUIDES
▸ Good processes bring good results
▸ Go see for yourself (gemba)
▸ Speak with data, manage by facts
▸ Take action to contain and correct root causes
▸ Work as a team
▸ Kaizen is everybody’s business

58. SOFTWARE FACTORY

59. LEVELS OF MATURITY OF DEVOPS PROCESS

60. WHERE TO BEGIN?

61. CLOUD

63. CLOUD APPLICATION DELIVERY MODELS
▸ IaaS (Infrastructure as a Service) - Host
▸ PaaS (Platform as a Service) - Build
▸ SaaS (Software as a Service) - Consume

66. PETS VS CATTLE

67. AWS IOT

68. AWS IOT COMPONENTS
▸ Device Gateway
▸ Enables devices to securely and efficiently communicate with
AWS IoT.
▸ Message Broker
▸ Provides a secure mechanism for things and AWS IoT
applications to publish and receive messages from each
other. You can use either the MQTT protocol directly or MQTT
over WebSocket to publish and subscribe. You can use the
HTTP REST interface to publish.

69. AWS IOT COMPONENTS
▸ Rule Engine
▸ Provides message processing and integration with other AWS services.
You can use a SQL-based language to select data from message
payloads, process and send the data to other services, such as Amazon
S3, Amazon DynamoDB, and AWS Lambda. You can also use the
message broker to republish messages to other subscribers
▸ Security and Identity Service
▸ Provides shared responsibility for security in the AWS cloud. Your things
must keep their credentials safe in order to securely send data to the
message broker. The message broker and rules engine use AWS security
features to send data securely to devices or other AWS services.

70. AWS IOT COMPONENTS
▸ Thing registry
▸ Organizes the resources associated with each thing. You register your
things and associate up to three custom attributes with each thing. You
can also associate certificates and MQTT client IDs with each thing to
improve your ability to manage and troubleshoot your things.Security
and Identity Service.
▸ Thing Shadow Service
▸ Provides persistent representations of your things in the AWS cloud. You
can publish updated state information to a thing shadow, and your thing
can synchronize its state when it connects. Your things can also publish
their current state to a thing shadow for use by applications or devices.

71. SERVERLESS COMPUTING MODEL

72. AWS LAMBDA

73. AWS APIGATEWAY

74. MOBILE SAMPLE BACKEND SERVERLESS ARCITECTURE

75. WHAT WE DO?

76. AMAZON S3 HOSTED WEBSITE

77. WHAT WE DO?

78. MICROSERVICES

79. MICROSERVICE
▸ Is there a formal definition for microservice architecture ?
▸ No
▸ What is the Difference between monolithic and micro
service styles?
▸ Easy to maintain
▸ Deployment
▸ Scaling

83. DON’T !!!

84. ADVANTAGES
▸ Can use right tool for the job
▸ Can replace entire components easier
▸ Can scale specific components
▸ Super cloud friendly
▸ Will push you DevOps

85. CHALLENGES
▸ Distributed/versioned configuration
▸ Auto configurations and refresh on runtime
▸ New services can auto register at startup
▸ Service registration and discovery
▸ Centralised log management
▸ Collects and visualise log events from distributed processes
▸ Circuit Breaker (Bulk Heading)
▸ Prevent problems with chain of failures
▸ Security

86. DISTRIBUTED SYSTEMS

87. SUN’S FALLACIES OF DISTRIBUTED COMPUTING
▸ The network is reliable.
▸ Latency is zero.
▸ Bandwidth is infinite.
▸ The network is secure.
▸ Topology doesn't change.
▸ There is one administrator.
▸ Transport cost is zero.
▸ The network is homogeneous.

88. ANY ORGANIZATION THAT DESIGNS A
SYSTEM WILL PRODUCE A DESIGN WHOSE
STRUCTURE IS A COPY OF THE
ORGANIZATION’S COMMUNICATION
STRUCTURE.
Melvin Conway
CONWAY’S LAW

89. DEMO

90. QUESTIONS?

91. WE ARE HIRING