The document discusses microservices as a modern software architecture that allows for the independent deployment of small, decoupled services, facilitating modular application development. It contrasts microservices with monolithic architectures, highlighting benefits like simplicity, scalability, and technology diversity, while noting challenges such as increased complexity and communication overhead. The text advises a pragmatic approach, suggesting the consideration of monolithic designs first for smaller projects before transitioning to microservices.

1. MICROSERVICES
WHAT, WHY & DONT'S
key concepts for evaluation
effect
free!

2. …WHAT’STHAT MICROSERVICESTHING?

3. –Torsten Winterberg, Oracle ACE Director
“Microservices are the kind of SOA we have
been talking about for the last decade”.

4. – Eberhard Wolff, adesso AG head of the technology advisory board
“Microservices must be independently
deployable, whereas SOA services are often
implemented in deployment monoliths”.

5. PSSSST! TELL NO ONE
(SOA failed)

6. ARE MICROSERVICES BETTER?
• Greater simplicity
• The "micro" difference
• Cloud infrastructure
• New container technology
• Faster, more reliable networks
• Less politics

7. THE (SOMETIMES EVIL) MONOLITH

8. ✓simple to develop
✓IDEs & development tools support
✓easy to test
✓simple to deploy
✓works well for relatively small apps

9. - growth overloads everything
- difficult to adopt new technologies
- often stuck with the starting choices
- doesn’t scale to long-lived-application

10. IN COMPUTING, MICROSERVICES IS
SOFTWARE ARCHITECTURE STYLE IN
WHICH COMPLEX APPLICATIONS ARE
COMPOSED OF SMALL, INDEPENDENT
PROCESSES COMMUNICATING WITH
EACH OTHER USING LANGUAGE-
AGNOSTIC APIS.
THESE SERVICES ARE SMALL, HIGHLY
DECOUPLED AND FOCUS ON DOING A
SMALLTASK, FACILITATING A MODULAR
APPROACHTO SYSTEM-BUILDING

12. DATASTORE

13. DEPLOYMENT

14. • suite of small services
• running in its own process
• communicating with lightweight mechanisms
• built around business capabilities
• independently automated deployable
• minimum of centralized management
• technology agnostic
MICROSERVICES

16. ✓each microservice is relatively small
✓easier for a developer to understand
✓easier to scale development
✓improve fault isolation
✓develop and deploy independently
✓no long-term commitment to a tech-stack
✓allow a fine-grained performance tuning or scaling

17. - additional complexity of a distributed system
- tools/IDEs are monolithic applications oriented
- testing is more difficult
- must implement the inter-service communication
- increase memory consumption

18. WHO HAS USEDTHEM?

19. IS A GOOD CHOICE FOR
THE SYSTEMYOU'RE
WORKING ON?

20. • Strong Module Boundaries
• Independent Deployment
• Technology Diversity
• Distribution
• Eventual Consistency
• OperationalComplexity
COSTSBENEFITS

21. YAGNI
do a monolith first

22. MARTIN FOWLER
“you shouldn't start
a new project with
microservices, even if
you're sure your
application will be
big enough to make
it worthwhile”

23. PRODUCTIVITY vs COMPLEXITY

24. • ensuring the team has the skills needed
• taking a pragmatic approach
• adapting to teams and customers capabilities
TAKEWAYS

26. Thank you.
@realfuzzy
Michele Franzin

27. CREDITS
slides 7,15 - http://www.infoq.com/articles/microservices-intro
slides 11,12,13,21,23 - http://martinfowler.com/bliki/
slide 5 - http://apsblog.burtongroup.com/
http://martinfowler.com/bliki/microservices.html
http://www.infoq.com/articles/microservices-intro
https://en.wikipedia.org/wiki/Microservices
http://martinfowler.com/microservices/
RESOURCES