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

The 7 Deadly Sins of Microservices

The 7 Deadly Sins of Microservices

MuCon 2014

Tareq Abedrabbo

November 27, 2014
Tweet

More Decks by Tareq Abedrabbo

Other Decks in Technology

Transcript

  1. About me CTO at OpenCredo Author, developer, open-source committer, with

    a long term interest in service-based architecture
  2. Microservices Design Principles Tools Decoupling Separation of concerns Encapsulation Engineering

    Practices Spring Boot RabbitMQ Hystrix Automation Scalability Fault-tolerance Continuous Delivery Testing Dropwizard Config Management
  3. Questions to ask: - What languages do I need to

    support? - What libraries? - How dynamic and flexible does my implementation need to be?
  4. Always start by designing the contract of your service (CDD,

    it is like TDD but for microservices!)
  5. Do I need: - Simple request/response paradigm? - Message persistence?

    - Reliability? - Asynchronous notification?
  6. Designing a shared domain model is common in a monolithic

    architecture (it is even a best practice!)
  7. Things domain models are used for: - drive business logic

    - map business entities to the database - manage input & output
  8. The shared domain model fallacy: we are in full control

    of the context and the boundaries of the application
  9. Internal application services: - often have the wrong granularity -

    can have interdependencies - or a dependency on a shared domain
  10. Macro things to think about: - updating, deploying and scaling

    services independently - functional, performance and regression testing - system-wide behaviour, including failure scenarios
  11. In microservices world, developers need to have good understanding of:

    - Messaging - Scalability, fault-tolerance and resilience - Integration and remoting And potentially learn a few new technologies and tools
  12. –Melvin Conway “organisations which design systems […] are constrained to

    produce designs which are copies of the communication structures of these organisations.”
  13. Collaboration on a microservices project between: - devs and ops

    - techies and business - and across teams
  14. Hopefully, we can now begin to have pragmatic answers to

    questions such as: - How do I design a (micro)service? - How big or small should a service be? - Should a microservices be reusable?