The document discusses microservices, which is an approach to developing software applications as suites of independently deployable services. Key points include: - A microservice is a discrete unit of functionality that can be accessed remotely and operated independently. Microservices have specific outcomes, are self-contained, act as black boxes, and may use other underlying services. - Microservices divide applications into small, independent components with their own databases. This allows each service to be developed, deployed, and scaled independently. - The microservices approach has advantages like improved modularity, flexibility, and fault tolerance but also has drawbacks like increased complexity in testing and coordination across services. - Major challenges in implementing microservices include partitioning

1. MICROSERVICES
1
RAJESH KUMAR

2. WHAT IS A SERVICE?
 A service is a discrete unit of functionality that can be accessed
remotely and acted upon independently
 A service has four properties
 It represents a business activity with a specified outcome.
 It is self-contained.
 It is a black box for its consumers.
 It may consist of other underlying services
2

3. WHAT IS SOA?
 A service-oriented architecture is a style of computer software
where services are provided to the other components by
application components, through a communication protocol over a
network.
 The basic fundamental principles of service oriented architecture is
independent of vendors, products and technologies.
 e.g. SOAP, REST, Messaging, WCF
3

4. WHAT ARE MICROSERVICES?
 Microservices are an implementation approach for SOA?
 Some may not agree
 An application is developed as a suite of small services.
 Services are independently build and deployed component
 Each service has its own database
 May use synchronous or asynchronous calls
4

5. CHARACTERISTICS
 Built around business capabilities
 Independently developed from each other
 Independently deployed
 Scaled independently
 A dedicated team works for each service during lifecycle
5

6. TRADITIONAL TEAMS
6
Actually it is just Rohan


7. MSA TEAMS (CROSS FUNCTIONAL)
7

8. ADVANTAGES
8
 Each microservice is relatively small
 Easier for a developer to understand
 Easy to refactor, debug and test
 Speeds up build and deployment
 Each service can be deployed independently of other services
 Easier to deploy new versions of services frequently
 Can be scaled independently

9. ADVANTAGES
9
 Improved fault tolerance
 The other services will continue to handle requests.
 One component of a monolithic architecture can bring down entire system.
 Eliminates any long-term commitment to a technology stack
 Every service can have its own tech stack suited for its functionality
 Learning curve

10. DRAWBACKS
10
 Adds complexity to the system
 Implement the inter-service communication mechanism
 Distributed transactions
 Lots of network calls?
 A usual method call becomes an across the network service call
 Testing is more difficult

11. DRAWBACKS
11
 Increased resource uses
 Separate environments, CI/CD mechanisms
 Increased memory consumption e.g. separate JVM for each service
 Use cases that spawn across multiple services require very careful
co-ordination between teams
 Biggest hurdle is to to find how to partition the system into
microservices

12. CHALLENGES
12
 Database partitioning
 Application partitioning
 Inter-service communication

13. DATABASE PARTITIONING
13
 Generally the most difficult part
 Joins, sorting and referential integrity
 Handle in the application code
 Create steps in transactions that can be played out
 Event driven
 Eventual consistency

14. EVENTUAL CONSISTENCY
14
 How to design eventually consistent business logic
 Atomically update DB and publish event
 Distributed transactions?
 Slow, Deadlock prone
 Database triggers?
 DB specific, error prone

15. EVENTUAL CONSISTENCY CONTD
15
 eBay solution
 Update DB, create event
 Consume event
 Mark event as consumed
 Error prone, does not work in race conditions
 What is the solution?

16. EVENTUAL CONSISTENCY CONTD
16
 Present is a fold over history
 Do not update database
 Just publish events
 Events update DB
 Maintain ordering of events
 Replay events to arrive at a state
 Complicates the design, duplicate events will be tricky

17. DATABASE PARTITIONING CONTD
17
 Create master-slave strategy
 Synching databases
 Polyglot persistence
 Most NoSql databases have no acid properties, joins or transactions

18. APPLICATION PARTITIONING
18
 Partition along use cases
 Several new services to handle calls from other services
 Application logging is tricky
 Central or local, inter service calls log tailing is difficult
 Deployment strategy

19. APPLICATION PARTITIONING
19
 Code dependencies needs to be managed
 Better not to have dependent modules
 Handle global configuration data
 Zookeeper?

20. INTER-SERVICE COMMUNICATION
20
 Technology
 REST
 Messaging
 Performance
 Unreliable communication
 Failover, slow response, circuit breakers etc

21. PITFALLS
21
 Testing each service is easy
 Testing the whole system is not, who owns integration?
 Technology Pluralism
 Should not lead to technology explosion, no one can understand the whole
system
 Independent deployment hastens release cycle
 Watch out for dependencies between services
 Release, monitoring and versioning must be standardized

22. PITFALLS CONTD
22
 Refactoring a service is easy
 Its another beast to refactor across services
 Development is MSA oriented
 But CI/CD pipeline is not
 Teams are still built around technology and not services

23. KNOWN USERS
23
 Amazon
 Netflix
 eBay

24. QUESTIONS?
24

25. FOOD FOR THOUGHT
ARE MICROSERVICES FOR EVERYONE?