Downloaded 27 times
More Related Content
Iot cloud service v2.0
- 1. IoT Cloud Platform Transitioningfrom a monolith to micro services architecture BY VINOD WILSON – ARCHITECT – CRESTRON ELECTRONICS
- 2. 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
- 3. Goals Device Program Ancillary Device Telemetry File Storage Policies Licenses Alerts Change Logs API Exposure Email SMS Time toMarket Organization Driving architecture Architecture Driving organization Enable Scalable Business Support Entry into new markets Support innovation in existing markets
- 4. Cloud Service –Data - Multi-tenancy Cloud Service Multi- tenancy
- 5. Reference Data &Master Data Management
- 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 fromacross the globe Has Huge Impact on the service Service should be exposed always to one region
- 9. Service Monitoring andMonitoring Apps • Service Monitoring should never be an after- thought • Service Monitoring solutions should be developed in parallel
- 10. Simulation • Simulation serviceto 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
- 12.
- 13. Conway’s Law 1968 Any pieceof software reflects the organizational structure that produced it
- 14. What is aMicroservice? Microservices are a loosely coupled Service-Oriented Architecture (SOA) with bounded contexts
- 15. Complexity over time(Monolith vs Microservices) COMPLEXITY TIME Complexity Over Time
- 16. Microservices - Trends Whoare using microservices?
- 17. Conway’s Law inAction 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 DeveloperDeveloper 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
- 19.
- 20. Characteristics of differentorganization 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 itmakes 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
- 23.
- 24.
- 25. Example: process ofcreating new customer
- 26. Orchestration Downside of thisapproach • Customer service can become too much of a central governing authority • Extremely brittle • Higher cost of change
- 27.
- 28. Event driven architectureand 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 • Anevent-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
- 30.
- 31.
- 32. DevOPS Principle Cultural movementenabled by technology Dev Paid to add new feature OPS Paid to keep system stable, fast and available DevOPS
- 33.
- 34. Rules of distributedcomputing 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
- 35.
- 36. Impedence mismatch problemin RDBMS • We want to show and store in two different ways
- 37. SQL was designedto 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 iscluster friendly • Non-relational • Schema-less
- 39. NoSQL - Implicitschema • 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
- 41. Scalability and Performance(NoSQL vs RDBMS)
- 42. Polyglot persistence • Polyglotpersistence 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 • FaultToleranceis 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 • ServiceFabric • 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
- 46. IoT Cloud ServicePlatform
- 47. IoT Domain Modeling •Difficult to conceive domain modelling in IoT
- 48. Web Application Decomposition (PartitionedWeb Application)
- 49. No longer asingle 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 ProductsUI 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 • Identifyone 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
- 52.