6. 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
7. 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
8. Device communication from across the
globe
Has Huge Impact
on the service
Service should be
exposed always to
one region
9. Service Monitoring and Monitoring
Apps
• Service Monitoring should never be an after-
thought
• Service Monitoring solutions should be developed in
parallel
10. Simulation
• Simulation service to
simulate hundreds and
thousands of devices
should also be developed
in parallel along with the
monitoring apps
11. 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
17. 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
18. 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
20. 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
21. 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
22. 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
26. Orchestration
Downside of this approach
• Customer service
can become too
much of a central
governing authority
• Extremely brittle
• Higher cost of
change
28. 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
29. 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
34. 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
37. 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
38. NoSQL
• It is cluster friendly
• Non-relational
• Schema-less
39. NoSQL - Implicit schema
• Build relationship out of
the implicit schema
40. 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
42. 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
43. Fault Tolerance
• FaultTolerance is a Requirement, Not a Feature
• Network timeouts and retries
• Using Semaphores to control resource usage
• Circuit breakers
44. 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
45. 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
49. 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>
50. 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
51. 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