Micro services: what are and when not to use

Talk about basic concepts behind micro services to better evaluate when introduce it in a project.

1. MICROSERVICES WHAT, WHY & DONT'S key concepts for evaluation effect free!
2. …WHAT’S THAT MICROSERVICES THING?
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 SMALL TASK, FACILITATING A MODULAR APPROACH TO 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 USED THEM?
19. IS A GOOD CHOICE FOR THE SYSTEM YOU'RE WORKING ON?
20. • Strong Module Boundaries • Independent Deployment • Technology Diversity • Distribution • Eventual Consistency • OperationalComplexity COSTS BENEFITS
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