Basic Information about the Micro Service Architecture

1. SERVICES -
ARCHITECTURE
Governance Team
10 Mar 17

2. • Traditional Approach
• Issues in Traditional
• Define MS
• Characteristics of
MSA
• Service Discovery
• Communication /
Integration in MS
– MSA

3. • Data Management in
MS
• Deployment Strategy
• Migration to MSA
• PROS & Cons of MSA
• Best Practices of MSA
• Demo
• QA
– MSA

4. Monolith – Architecture
• Monolithic means
composed all in one
piece. Monolithic
software is designed to
be self-contained.
• Components of the
program are
interconnected and
interdependent (tightly
coupled)

5. Monolith Characteristics
• Extensibility is bit difficult since the code base
is very huge
• Slow down the development and takes more
time to shipping the new features
• CD – Impossible Task
• Difficult to scale
• Application Reliability
• Long Term commitment in Technology Stack

6. Micro Service Architecture-MSA
• Small, and Focused on Doing One Thing Well
• Software applications as a suite of Independently
deployable, small, modular services in which each
service runs a unique process and communicates
through a well-defined, lightweight mechanism to
serve a business goal
• Large functionality or business capability is
decomposed into set of small services

7. MSA – Characteristics
• Componentization via Services
• Organized around Business
Capabilities
• Decentralized Governance
• Products not Projects
• Decentralized Data Management
• Infrastructure Automation
• Design for failure
• Evolutionary Design
(From Martin Fowler’s Link)

8. MSA – Interaction Style
• Services are interacted using
Inter process communication (IPV)
Mechanism.
IPC :
One to one /One to Many
Sync/Async

9. MSA – Interaction Style
IPC Style One to One One to Many
Sync Request /Response
Async Notification Publish /Subscribe
Request/Async Response Publish/Async Response

10. MSA – Interaction Style Sample

11. MSA – Service Discovery

12. MSA – Service Discovery
• Client Side Discovery Pattern
• Server Side Discovery Pattern

13. MSA – Client Side Service Discovery

14. MSA – Server Side Service Discovery

15. MSA – Data Management
• Challenge in MSA Data Management
– Since MSA handling the different DB with different
services the following challenges we are facing in the
Data management Context
• Transaction Management-2PC/Distributed Transaction
• Retrieve the Data from Multiple DB

16. Event Driven Architecture
• You can use the events to implements Business
transaction that span of Multiple Services
• Its not ACID Transaction instead its BASE Model
• Its guarantees such as eventually consistency

17. Event Driven Architecture-
• Steps to Perform the Transaction in EDA
– Update the Business entity and publish the event from
Service1
– Publish the events into Message Broker
– Service 2 consume the event , update the business entity
based on the event
– Service 2 publish another event in the Message Broker
– Service 1 consume the event and update the status in
their DB

18. Event Driven Architecture-Flow

19. Event Driven Architecture-Flow
Materialized View :
Read the data from Multiple DB
Data is always eventually consistent.

20. Atomicity in MSA
Achieving Atomicity in following ways
 Publishing event using local transaction
 Mining a Database Transaction log
 Event Sourcing
 DB Link/Trigger

21. Deployment Strategy
MSA Deployment Patterns:
Multiple Service Instance /Host Pattern
Service Instance /Host Pattern
Service Instance /VM
Service Instance/Container
Serverless Deployment Pattern

22. Migration Strategy
Following strategy for Monolith  MSA Migration
• Stop Digging code –
• No further extension in the Monolith instead create the separate
service for those new requirement
• Using glue code for internal integration between service and
monolith
• Separate the Frontend and Backend layer
• Separate the Presentation layer with Business /Data Layer
• Communication between those layers through IPC
• Extract the Module from Monolith
• Extract the key module from monolith and convert into service

23. MSA Design Pattern
Aggregator DP
Proxy DP
Shared Data DP
ASync Message DP
Chain DP
Branch DP

24. API Gateway

25. PROS -MSA
• Independent Deployment and Development
• Code and Team size not grow rapidly
• Define the services based on Business capability
• Reliability
• Easy to Scale
• No long-term commitment to technology stack

26. Cons -MSA
• Complexity in terms of
Architect/Testing/Deployment
• Increasing number of services will cause the
Memory /Resource/ Maintenance issue
• Communication between the services bit complex
• Duplication effort

27. Demo – Technology
• Java 8
• Spring Boot
• Spring Cloud
• Postgresql
• Cloud Foundry
• Eureka
• Maven

28. Demo
• Restful Service
• Restful with DB
• IPC Demo

29. QUESTIONS?

30. APPENDIX

31. Handling Partial Failure
• Network Timeout
• Limiting number of outstanding request- Throttling
• Circuit Broker Pattern
• Provide the Fallback –
– Perform fall back logic when a request fails. For example,
return cached data or a default value, such as an empty
set of recommendations

32. Message Channels
• Point 2 Point
– delivers a message to exactly one of the consumers that
are reading from the channel
– IPC – One –to – One
• Publish – Subscribe
– delivers each message to all of the attached consumers.
– IPC – One –to-Many

33. HATEOAS

34. MSA-Chassis
• Its framework, which handles cross-cutting
concerns like logging/Security/Health
check/Externalize the configuration file,Service
registration/service discovery and etc

35. Service Registry
• Key Part of Service Discovery
• Its DB containing the network location of
services instance
• Tools /API used to register the services in
Registry
• Ex:
– Etcd
– Consul
– Apache ZooKeeper

36. Service Registration
• Service instances must be registered with and
unregistered from the service registry
• Two ways
– Self Registration
– Third Party Tool Registration

37. ACID
• Atomicity –
– Changes are made atomically
• Consistency –
– The state of the database is always consistent
• Isolation –
– Even though transactions are executed
concurrently, it appears they are executed serially
• Durable –
– Once a transaction has committed, it is not undone

38. BASE

39. Polyglot Persistence
• MSA uses the mix of Database like No
SQL/RBDMS and etc to store/query the
different kind of data

40. A|B Testing

41. Single Responsibility Principle

42. Demo GitHub
– https://github.com/parameshnon