Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building microservices


Published on

Tips and tricks of building microservices for highly scalable applications. Presentatio talks about core architectural concerns to take care while planning to build microservices.
Used for the talk at Delhi tech meetup March2017.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Building microservices

  1. 1. Building Microservices Delhi Tech Meetup - 22/3/2017 {Prashant Parashar} (Presentation slides used for the talk on “building micro-services”. Slides alone not a comprehensive material on the topic.)
  2. 2. Why, when ?
  3. 3. Two Pizza Teams N(N-1)/2 is the number of conversation connections within a team.
  4. 4. Should I move to MicroServices? What’s your traffic? What’s your team size? How complex is the system?
  5. 5. Why? Scale Platform Scale Team scale
  6. 6. Why? Reuse Reusability Replaceability Focused Evolution
  7. 7. “Don’t build microservices in a 5-people-startup!”
  8. 8. Hows & whats of building
  9. 9. Independent systems vs micro-services vs Heterogeneous Interfaces Federated Standards Homogeneous Interfaces Common Standards Common design Language
  10. 10. Identification Clear separation of concerns, Isolation Not just CRUD Self-sufficient Management vision
  11. 11. Common design language Interfaces, API language Protocols Security Commons libraries Other cross-cutting concerns Clear architectural guidelines - Be pragmatic than ideal
  12. 12. Architectural Concerns - Security Simplistic - manage at firewall Intermediate - inter-service tokens Advanced: Identity service, encryption etc [Avoid till you can]
  13. 13. Architectural Concerns - Protocols Create common libs for protocol standards [HTTP, Headers, Marshaling protocols], connection pooling, failure handling, logging etc JSON, XML, Protobuf, all? Provision for protocol/serialization versions! Always.
  14. 14. Architectural Concerns - Context Manage context across sync and async calls! Context should contain: ❏ Unique source request Id ❏ User/actor id ❏ Caller service id ❏ Specific server instances ❏ Security/authorization info, if applicable
  15. 15. Service Mess...Mesh
  16. 16. Tip: Define upstream/downstream levels Cross-cutting (even log, security etc) User
  17. 17. Aggregation Do it closer to the user UI Layers should have their own aggregation layer Some duplication is okay
  18. 18. Develop/Deploy/Test/Debug
  19. 19. Testability Automated tests is essential Service level tests important End-to-End tests? Auto deploy with automated tests
  20. 20. Debugging Be verbose Track call chain. Carry as much context as you can.
  21. 21. Runtime Performance Prepare for performance degradation of others Use circuit breakers. Timeouts won’t help. Isolation of problem is important. Design such. Design for failure. Have product flag/alternative setup Idempotent APIs help Sync vs Async services - design for best & worst case
  22. 22. one-size fits all
  23. 23. Thanks! der