Iot cloud service v2.0

IoT Cloud Platform
Transitioning from a monolith to micro services architecture
BY VINOD WILSON – ARCHITECT – CRESTRON ELECTRONICS

Agenda
Goals
• Enable Scalable
Business
• Support Entry into new
markets
• Support innovation in
existing markets
Enterprise Capability
• Multi-tenancy
• Enterprise Reference
Data
• Global customer issue
• Devices
communicating from
across the globe
• Monitoring
• FaultTolerance
• Simulation
• Deployment
Looking forward and
future Insights
• Monolithic to
Microservices
• Team Structural
Problems
• DevOPS
• Advantages of
Microservices
• Microservices logical
architecture
• Decentralized Data
Management
• CAPTheorem
• Polyglot Persistence
• FaultTolerance
• Automated Failure
Testing
• Web Application
Decomposition
• Metering & Billing
IOT Cloud Service
Platform
• CSP Block Diagram
• CSP Architecture
• DDD and Practice
• CSP Event Sourcing
• CSPWorkflow
• CSP POC
Execution Strategy
• AlignTeam and
organizational
structure
• Standardization,Team
choice, Development
Tools, Options, Cross-
team coordination
• Microservices Interface
specification
• Microservice internal
architecture and design
• Microservice Fault
Tolerant Design
specification
• Repository Design
• DevOPS First
• TDD
• UnitTests, Integration
Tests, UAT
• Microservices
Development

Goals
Device
Program
Ancillary
Device
Telemetry
File
Storage
Policies
Licenses Alerts
Change
Logs
API
Exposure
Email
SMS
Time to Market
Organization
Driving architecture
Architecture Driving
organization
Enable Scalable
Business
Support Entry
into new
markets
Support
innovation in
existing
markets

Cloud Service – Data - Multi-tenancy
Cloud
Service Multi-
tenancy

Reference Data & Master Data
Management

Enterprise Reference & Master Data
Dealers
Products
Identity Enterprise
web apps
Product
Lines
Enterprisereference&MasterData
Duplicated Azure AD
Enterprise Soft Division
IT Services Division
EnterpriseTools Division
IT Services Division

Enterprise Reference & Master Data
Enterprise Reference
Data & Master Data
Dealers
Products
Identity
Product
Lines
Enterprisereference&MasterData
Moved
Managed By Enterprise
Reference DataTeam
Pushed
A
z
u
r
e
S
e
r
vi
c
e
B
u
s
Enterprise
Web Apps
EnterpriseTools
Azure AD
Cloud Services

Device communication from across the
globe
Has Huge Impact
on the service
Service should be
exposed always to
one region

Service Monitoring and Monitoring
Apps
• Service Monitoring should never be an after-
thought
• Service Monitoring solutions should be developed in
parallel

Simulation
• Simulation service to
simulate hundreds and
thousands of devices
should also be developed
in parallel along with the
monitoring apps

Monolith Service Deployment
• Always involves deployment of the entire service
• For major schema changes the deployment might take long hours
• Deployment checklist is huge and only few people in the team might
know about it

Conway’s Law
1968
Any piece of software
reflects the organizational
structure that produced it

What is a Microservice?
Microservices are a loosely coupled Service-Oriented
Architecture (SOA) with bounded contexts

Complexity over time (Monolith vs
Microservices)
COMPLEXITY
TIME
Complexity Over Time

Microservices - Trends
Who are using microservices?

Conway’s Law in Action
Head Of IT
Head Of
Operations
Head Of
DBA’s
Head Of
Infrastructure
Head Of
Development
Head Of App
Dev
Head Of UI
Typical Enterprise Organization Structure
Infrastructure
DataStore
Application
User Interface
Resulting Software
An Enormous Monolith

Microservices Organization Structure
Product
Lead
Developer
Developer Developer
Sys Admin DBA
NoSQL
Admin
Javascript
Developer
Graphic
Artist
Infrastructure
DataStore
Application
API
Resulting Software
Infrastructure
DataStore
Application
API
Infrastructure
DataStore
Application
API
Infrastructure
DataStore
Application
API
Many small Microservices
Each team should treat other teams as external vendor
1. Clear Interfaces
2. Clear SLAs

Microservices logical architecture

Characteristics of different organization
types
Centralized Organizations
Focused onTechnology
Layers
• Product Monoliths
• Simple change requires
extensive coordination
across all of the layers
• Business logic is spread
everywhere because it’s
easier to bury it in the
layer you own
• No real ownership
Distributed Organizations
Focused on products
• Produce Microservices
• SmallTeams can make
any change they want to
an individual
microservice
• Architecture clean
because developers
have 100% control
• True ownership

Standardize where it makes sense
Teams do not have 100% freedomDevelopmentTooling
SourceControl
ConfigurationManagement
Data Format
Communication Protocol
Alerting
Monitoring
Custom Code
Programming Language
Messaging
Data Store
Infrastructure
Team Has Complete Choice
Offer a menu of 2-3 options
Standardize on One

Benefits of Microservices
• Easier to understand and develop
• Faster to build and deploy
• Reduced startup time
• Scales development: Develop, deploy and scale each service independently
• Improves fault isolation
• Eliminates long-time commitment to a technology stack
• Microservice => something that could be rewritten in two weeks
• Decentralized Governance

Service integration
OrchestrationVs Choreography

Example: process of creating new customer

Orchestration
Downside of this approach
• Customer service
can become too
much of a central
governing authority
• Extremely brittle
• Higher cost of
change

Event driven architecture and Eventual
Consistency
• Application has to handle eventually consistent data
• Application has to handle duplicate events
• How to generate events?
• Atomically publish an event since there could be failures

Event Sourcing
• An event-centric approach to designing domain models
• Request becomes a command that is sent to anAggregate
• Aggregates handle commands by generating events
• Apply events to an aggregate to update state
• Persist events NOT state
• Replay events to recreate the current state of an aggregate
• Event Store = database + message broker

DevOPS Principle
Cultural movement enabled by technology
Dev
Paid to add
new feature
OPS
Paid to keep
system stable,
fast and
available
DevOPS

Rules of distributed computing
CAP Theorm – pick any two
Theory
C
Consistency
A
Availability
Pick
Any
Two
P
Partition
Tolerance
• Consistency
• Each node shows the same
data all times
• Availability
• Each node is available for
writes at all times
• PartitionTolerance
• Able to handle network
outages
Practice
• PickA or P
• Partition tolerance is non-negotiable because we
have networks that can always fails
• Enterprise IT Systems
• Often CP
• Microservices Systems
• Often AP

Decomposition MicroserviceA
Microservice
B
Microservice A Microservice B

Impedence mismatch problem in RDBMS
• We want to show and store
in two different ways

SQL was designed to run in a single big
boxes
• It doesn’t work very well with large
clusters
• Too much of operations involved in
maintaining large clusters
• Many gave up designing large relational
clusters

NoSQL
• It is cluster friendly
• Non-relational
• Schema-less

NoSQL - Implicit schema
• Build relationship out of
the implicit schema

NoSQL - Advantages
• Aggregate oriented database
• Store Every aggregate as a single unit
• Aggregate storage is useful when it is stored in clusters
• Runs efficiently in clusters and way more straightforward

Scalability and Performance (NoSQL vs
RDBMS)

Polyglot persistence
• Polyglot persistence is all about choosing the right persistence option for
the task at hand
• Polyglot persistence is needed since the volume of data is exploding
• What options do we have?
• RDBMS
• Document Stores
• Key-Value pairs
• BLOB Storage
• Table Storage
• Graph DBs
• Message Queues

Fault Tolerance
• FaultTolerance is a Requirement, Not a Feature
• Network timeouts and retries
• Using Semaphores to control resource usage
• Circuit breakers

Automated Failure Testing
• Chaos Monkey
• A tool that randomly disables our production instances to make sure we can survive this
common type of failure without any customer impact
• Latency Monkey
• Induces artificial delays in our RESTful client-server communication layer to simulate
service degradation and measures if upstream services respond appropriately
• Conformity Monkey
• Finds instances that don’t adhere to best-practices and shuts them down
• Doctor Monkey
• Taps into health checks that run on each instance as well as monitors other external signs
of health (e.g. CPU load) to detect unhealthy instances.
• Once unhealthy instances are detected, they are removed from service and after giving
the service owners time to root-cause the problem, are eventually terminated.
• Janitor Monkey
• Ensures that our cloud environment is running free of clutter and waste. It searches for
unused resources and disposes of them.
• Chaos Gorilla
• is similar to Chaos Monkey, but simulates an outage of an entire Cloud availability zone

Emerging Technologies
• Service Fabric
• Distributed systems platform that makes it easy to package, deploy, and
manage scalable and reliable micro services
• VMs, Containers, and Processes
• Windows Server 2016 – Has container support

IoT Domain Modeling
• Difficult to conceive domain
modelling in IoT

Web Application Decomposition
(Partitioned Web Application)

No longer a single base URL
Browser Content Router
Products UI
Checkout UI
Order Management
UI
Account
Management UI
/products
/checkout
/Orders
/account
http://acme.com/<service>

Partitioned Web Application
Browser
Content
Router
Products UI
Checkout UI
Order Management
UI
Account
Management UI
/checkout
/Orders
/account
http://acme.com/<service>
API
Gateway
REST Client
Products Info Service
Recommendation
service
Review Service
Order Service
Service Registry
1. Single Entry Point
2. Protocol
Translation
3. Reduces chatty
network calls
Microservice
s Registers
when they
startup

Execution Strategy
• Identify one microservice for POC
• Write interface specification for the microservice (Swagger)
• Identify the core services needed for implementing one microservice
• Implement core services
• Develop one microservice and make it as reference implementation for other
teams
• Demo DevOPS
• Demo Fault isolation and Fault tolerance

Iot cloud service v2.0

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Iot cloud service v2.0

Similar to Iot cloud service v2.0 (20)

More from Vinod Wilson

More from Vinod Wilson (15)

Recently uploaded

Recently uploaded (20)

Iot cloud service v2.0