![Architectural Concerns - Security
Simplistic - manage at firewall
Intermediate - inter-service tokens
Advanced: Identity service, encryption etc [Avoid till
you can]](https://image.slidesharecdn.com/buildingmicroservices-prashantparashar-170323050901/85/Building-microservices-12-320.jpg)
![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.](https://image.slidesharecdn.com/buildingmicroservices-prashantparashar-170323050901/85/Building-microservices-13-320.jpg)
Building microservices
- 1. Building Microservices Delhi Tech Meetup - 22/3/2017 {Prashant Parashar} (Presentation slides used for the talk on “building micro-services”. ݺߣs alone not a comprehensive material on the topic.)
- 2. Why, when ?
- 3. Two Pizza Teams N(N-1)/2 is the number of conversation connections within a team.
- 4. Should I move to MicroServices? What’s your traffic? What’s your team size? How complex is the system?
- 5. Why? Scale Platform Scale Team scale
- 7. “Don’t build microservices in a 5-people-startup!”
- 8. Hows & whats of building
- 9. Independent systems vs micro-services vs Heterogeneous Interfaces Federated Standards Homogeneous Interfaces Common Standards Common design Language
- 10. Identification Clear separation of concerns, Isolation Not just CRUD Self-sufficient Management vision
- 11. Common design language Interfaces, API language Protocols Security Commons libraries Other cross-cutting concerns Clear architectural guidelines - Be pragmatic than ideal
- 12. Architectural Concerns - Security Simplistic - manage at firewall Intermediate - inter-service tokens Advanced: Identity service, encryption etc [Avoid till you can]
- 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. 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
- 16. Tip: Define upstream/downstream levels Cross-cutting (even log, security etc) User
- 17. Aggregation Do it closer to the user UI Layers should have their own aggregation layer Some duplication is okay
- 19. Testability Automated tests is essential Service level tests important End-to-End tests? Auto deploy with automated tests
- 20. Debugging Be verbose Track call chain. Carry as much context as you can.
- 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