The document discusses the differences between monolithic and microservices architectures, highlighting the advantages and disadvantages of each. Microservices offer benefits like technology heterogeneity, resilience, and easier scaling, while monolithic systems can be simpler to develop and deploy but face challenges in scaling and continuous deployment. The document also outlines principles of microservices, integration methods, deployment strategies, and tools for monitoring and managing services effectively.

1. MICRO SERVICES
Anki

2. MONOLITHIC ARCHITECTURE
• Monolithic application either a layered or hexagonal architecture and consists of
different types of components
– Document Components
– Business Logic
– Database Access Logic
– Application Integration Logic
These are different logical components corresponding to different functional areas of
application

3. WEB APPLICATION ARCHITECTURE
To
Tomcat
war
UI
Accounting
Inventory
Shipping
Browser Apache DB

4. ADVANTAGES
• Simple to
– Develop
– Test
– Deploy
– Scale
© 2016 Company XY. All rights reserved. For internal use only

5. DISADVANTAGES
• Overloaded IDE
• Overloaded web container
• Continuous deployment is difficult
• Obstacle to scaling development
• Requires a long-term commitment to a technology stack

6. MONOLITHIC ARCHITECTURE

7. MONOLITHIC ARCHITECTURE
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
-- Melvyn Conway, 1967
UI Specialists
Middleware Specialists
Database Specialists

8. MICRO SERVICES ARCHITECTURE
• Micro services architecture is a new way of designing software applications as a
suite of individually deployable services.

9. KEY BENEFITS
• Technology Heterogeneity
• Resilience
• Scaling
• Ease of Deployment
• Composability
• Optimizing for Replicability
• Organizational Alignment

10. MICRO SERVICES ARCHITECTURE

11. DIFFERENCE BETWEEN SOA AND MICRO SERVICES
• None ( Answer from the people who read the OASIS SOA Reference Model )
• Microservice is SOA today
• Microservice approach has emerged from the real-world user, taking our better
understanding of system and architecture to do SOA well.

12. WHAT MAKES A GOOD SERVICE?
• Loose Coupling
– A change in one service should not require change in other services
• High Cohesion
– Related behaviour sit together and unrelated behaviour else where
– If you want to change a behaviour you can change in single place & release that
service alone for delivering that change

13. HOW TO INTEGRATE SERVICE?
• Database
• Synchronous versus Asynchronous
• Service orchestration versus Choreography
• Remote Procedure calls
• REST
• Asynchronous Event-Based collaboration

14. PRINCIPLES OF MICRO SERVICES
• Modelled around business concepts
• Adapt culture of automation
• Hide internal implementation details
• Decentralize all the things
• Deploy independently
• Isolate failure
• Highly Observable

15. SPLITTING MONOLITHIC APPLICATION
• When we split monolithic application into micro services, the biggest issue lies in
changing the communication pattern i.e. in memory method calls to RPC leads
to chatty communications which does not perform well

16. IDENTIFY SEAMS
• What is seam ?
– A portion of the code can be treated on isolation, worked on without impacting the rest
of the code base

17. THINK MONOLITHIC AS MARBLE
© 2016 Company XY. All rights reserved. For internal use only

18. DATABASE AS A METHOD OF INTEGRATING SERVICES
Catalog
Repository
warehouse
Repository
Finance
Repository
Recommen
dation
Repository

19. DEPLOYMENT
© 2016 Company XY. All rights reserved. For internal use only

20. DEPLOYMENT
• Multiple Services for Host
• Application Containers
• Single Service for Host

21. DEPLOYMENT
VMWare, Aws will reduce the overhead of host management using virtualization.

22. MONITORING
What needs to be monitored ?
- CPU
- Memory
- Response Time

23. LOGSTATSH & KIBANA
Service
System
Log
Logstatsh
Application
Log Kibana
Host
Host Host Host
© 2016 Company XY. All rights reserved. For internal use only

24. SEMATIC MONITORING
• Synthetic Transaction
© 2016 Company XY. All rights reserved. For internal use only

25. CORRELATION IDS
• Correlation ids help to track call chains across multiple services
Web Frontend
Registration
Service
Payment
Gateway
Postal System Email System
Register Customer
ID : abc
ID : abc ID : abc
ID : abc

26. FAILURE IS EVERYWHERE
• Autoscaling of system capable of reacting to the increased load or failure of
individual nodes might be fantastic
• The following is the requirements before think about scaling
– Response time
– Availability
– Durability of Data

27. FAILURE IS EVERYWHERE
• In Micro service architecture we can consider a much more nauncend situation
• In e-commerce website for example cart service is down, but still we could show
the web page with listing.

28. ARCHITECTURAL SAFETY MEASURES
• When some thing goes wrong, that should not cause ripple-effects.
• System that just act slow are much harder to deal with than systems that just fail
fast.
• Implementing right timeouts
• Implementing bulkheads, separating different connection pools.
• Implementing a circuit breaker to avoid sending calls to an unhealthy system

29. ANTIFRAGILE ORGANIZATION
• Benefit from failure and disaster
• Embracing and inciting failure through software, building systems that can
handle it.
– Choas Monkey
– Choas Gorilla
– Latency Monkey

30. TOOLS
• Schema Spy (http://schemaspy.sourceforge.net/)
• Structure 101 (http://structure101.com/)
• https://www.nagios.org/
• http://newrelic.com/
• https://twitter.github.io/zipkin/

31. © 2016 Company XY. All rights reserved. For internal use only