How to Design a Backend for IoT
0 likes109 views
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.
How to Design a Backend for IoT
- 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
- 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.
- 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
- 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