• The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. • To start explaining the microservice style it's useful to compare it to the monolithic style: a monolithic application built as a single unit (all our past projects and current ones are monolithic). • We cannot say there is a formal definition of the microservices architectural style, but we can attempt to describe what we see as common characteristics for architectures that fit the label. • Knowing when to use microservices, its benefits, and its costs are also important. • In the demo, it is shown how to build simple microservice applications using Spring. Source: http://martinfowler.com/microservices

1. Microservices

2. Monoliths vs Microservices

3. Common Characteristics
1. Componentization via Services
2. Organized around Business Capabilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary Design

4. 1. Componentization via Services
• a component is a unit of software that is
independently replaceable and upgradeable

5. 1. Componentization via Services
Component Types:
• libraries: components that are linked into a
program and called using in-memory function
calls
• services: out-of-process components who
communicate with a mechanism such as a
web service request, or remote procedure call

6. 2. Organized around Business Capabilities
• Conway’s Law: “Any organization that designs
a system (defined broadly) will produce a
design whose structure is a copy of the
organization's communication structure.”

7. 2. Organized around Business Capabilities

8. 2. Organized around Business Capabilities

9. 2. Organized around Business Capabilities
• How big is a
microservice?

10. 3. Products not Projects
• Project Model: the aim is to deliver some piece
of software which is then considered to be
completed
• Product Model: a team should own a product
over its full lifetime; "you build, you run it"

11. 4. Smart Endpoints and Dumb Pipes
• An ESB anti-pattern

12. 4. Smart Endpoints and Dumb Pipes
• “Be of the web, not behind the web”
- Ian Robinson
• Messaging over a lightweight message bus:
i.e. RabbitMQ, ZeroMQ

13. 5. Decentralized Governance
• centralized governance has the tendency to
standardize on single technology platforms
• use the right tool for the job; splitting the
monolith's components out into services we
have a choice when building each of them

14. 6. Decentralized Data Management
• Polygot Persistence : when storing data, it is
best to use multiple data storage technologies,
chosen based upon the way data is being
used by individual applications or components
of a single application

15. 6. Decentralized Data Management

16. 6. Decentralized Data Management

17. 7. Infrastructure Automation

18. 7. Infrastructure Automation

19. 8. Design for Failure

20. 8. Design for Failure
• applications need to be designed so that they
can tolerate the failure of services
• health monitoring
• centralized logging

21. 9. Evolutionary Design

22. When to use?

23. When to use?

24. Demo

25. References
• http://martinfowler.com/microservices/
• https://github.com/spring-cloud-
samples/fortune-teller
• https://github.com/netflix/eureka
• https://github.com/cloudfoundry