This document is mostly drived from Martin Flower

1. Microservice Architecture
By
Rudra prasad Tripathy
29th April

2. Contemporary technologies
lSOA/ESB
lEAI
lLayers/tiered/component architecture

4. Gartner pattern

5. Principles
lComponentization via Services
lOrganized around Business Capabilities
lProducts not Projects
lSmart endpoints and dumb pipes
lDecentralized Governance
lDecentralized Data Management
lInfrastructure Automation
lDesign for failure
lEvolutionary Design

6. Use case
Desktop
Mobile
REST
Controller
Spring core
Business process
workflow RDBMS
Search
service
1 2
3 4
5
6
7
N
G
N
I
X

7. Use case
lThe use case doesn't have spring integration, but using spring
controller.
lSpring controller can access JPA service in case of Http service
operation without core.
lWorkflow services also can be accessed directly.
lSpring security can be integrated to make it API Gateway.

8. Contemporary technologies
lSOA/ESB
lEAI
lLayers/tiered/component architecture

9. Componentization via Services
•component is a unit of software that is independently replaceable and upgradeable.
•One main reason for using services as components (rather than libraries) is that
services are independently deployable
•A service may consist of multiple processes that will always be developed and
deployed together, such as an application process and a database that's only used by
that service.

10. Organized around Business Capabilities
•Conway's Law
•Cross team dependency
•Smaller services make it easy for small teams working on this without much
dependency on other teams. The boundry is easy to define

11. Products not Projects
Microservice proponents tend to avoid PROJECT model.
•The product mentality, ties in with the linkage to business capabilities
•Smaller granularity of services can make it easier to create the personal relationships
between service developers and their users.

12. Smart endpoints and dumb pipes
•Avoiding approaches that stress putting significant smarts into the
communication mechanism itself.
•Applications built from microservices aim to be as decoupled and as cohesive
as possible.
•Messaging over a lightweight message bus.

13. Decentralized Governance
•One of the consequences of centralized governance is the tendency to standardize on
single technology platforms.
•Teams building microservices prefer a different approach to standards too.
•Perhaps the apogee of decentralised governance is the build it / run it ethos
popularised by Amazon.
•Patterns like Tolerant Reader and Consumer-Driven Contracts
•Centralized governance can be achived through API GATEWAY.

14. Decentralized Data
Management
•At the most abstract level, it means that the
conceptual model of the world will differ
between systems.
•As well as decentralizing decisions about
conceptual models, microservices also
decentralize data storage decisions.
•Choosing to manage inconsistencies in this way
is a new challenge for many development
teams,

15. Infrastructure Automation
•Many of the products or systems being build with microservices are being
built by teams with extensive experience of Continuous Delivery and it's
precursor, Continuous Integration.
•Managing microservices in production.
•Promotion of working software 'up' the pipeline means we automate
deployment to each new environment.

16. Design for failure
•A consequence of using services as components, is that applications need to
be designed so that they can tolerate the failure of services.
•ince services can fail at any time, it's important to be able to detect the
failures quickly and, if possible
•Synthetic monitoring.
•Unified monitoring

17. Evolutionary Design
•Agile pattern
•Evolving architecture

18. Tools and techniques
lApache camel
lJboss fuse
lWSO2

19. Technology changes support
•Maturity in DevOp
 API management tool
 Maturity in REST approach.
 Asynchronous capability

20. Reference
•Martin flower.