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.
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
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
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
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.
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)
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?
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
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
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
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
63. CLOUD APPLICATION DELIVERY MODELS
▸ IaaS (Infrastructure as a Service) - Host
▸ PaaS (Platform as a Service) - Build
▸ SaaS (Software as a Service) - Consume
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.
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
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
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