Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Micro services: what are and when not to use

SeeSaw
October 24, 2015

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.

SeeSaw

October 24, 2015
Tweet

More Decks by SeeSaw

Other Decks in Programming

Transcript

  1. – Torsten Winterberg, Oracle ACE Director “Microservices are the kind

    of SOA we have been talking about for the last decade”.
  2. – Eberhard Wolff, adesso AG head of the technology advisory

    board “Microservices must be independently deployable, whereas SOA services are often implemented in deployment monoliths”.
  3. ARE MICROSERVICES BETTER? • Greater simplicity • The "micro" difference

    • Cloud infrastructure • New container technology • Faster, more reliable networks • Less politics
  4. ✓simple to develop ✓IDEs & development tools support ✓easy to

    test ✓simple to deploy ✓works well for relatively small apps
  5. - growth overloads everything - difficult to adopt new technologies

    - often stuck with the starting choices - doesn’t scale to long-lived-application
  6. 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
  7. • 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
  8. ✓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
  9. - 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
  10. • Strong Module Boundaries • Independent Deployment • Technology Diversity

    • Distribution • Eventual Consistency • OperationalComplexity COSTS BENEFITS
  11. 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”
  12. • ensuring the team has the skills needed • taking

    a pragmatic approach • adapting to teams and customers capabilities TAKEWAYS
  13. 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