Building Microservices O'Reilly Book Lessons Learned
Suggested Readings
- Lightbend Akka things that could go wrong microservices https://www.lightbend.com/blog/how-akka-works-at-least-once-message-delivery
Building Microservices
Logging
- Aggregation ID
Design
- Bounded Context
- Architecture principles
- Orchestration vs Choreography
- Sync vs Asynchronous
- Semantic Versioning
- BFFs design pattern. Backend for frontend
- If you canβt decouple the data from two different service, ie both stock service and warehouse service requires to know the product object the you can expose product data through an api rather than sharing the database.
Data Pump Patterns
- Cron Jobs - Periodic
- Materialized View
- Event Driven
- Backup Pattern
Deployment
- Pipeline: build or services concurrently and run e2e at the end when all are done
Security:
- DON'T write your own crypto (encryption)
Anti-Patterns
- Shared librarires
- Modules
- Common libraries
Laws
Software Engineering Laws
Conway's Law - The system
Moore's Law - number of memory doubles every 2 years
Brooke's Law - you cannot build 1 baby with 9 women in 1 month
Pastel's Law
- Defining a standard and principles in practice !principles.png
Standards
- Monitoring Choices are nagios graphite kibana scraper. Just make it standard
- Interfaces should be standard
- Architecture safety. Each service should have contingency and not one should hold everything together. 2xx 4xx 5xx codes should be used correctly
- Create a template skeleton for ideal microservice to be followed. A good example are dropwizard karyn hystrix.
Key concepts:
Orchestration vs choreography
Protocols:
- rpc is fast and simulates local calls but is quite rigid with regards to change and requires client to change on stub changes
- Rest hateoas
- Json vs xml. Json limits hypermedia control ie http links. Extracting just part of the payload could be complex in json vs xpath
- Websocket has nothing to do with web but just opens a tcp protocol
Migration
- Semantic versioning
- Exposing two end points. Gradual change Aggregate api calls under one gateway
- API gateway to orchestrate backend call
- Hateoas
Reporting DB ways
- Read Replica of DB
- Scheduled Data pump - same as materialised view
- Event Backup - replay all the events
Synthetic monitoring
- We can create a fake event every 10 minutes or so and report if it does not get processed down the line in say 500ms
Testing
- Run all test up to integration testing and run end to end with all running at the same time
Authentication considerations
User auth
- SAML or openId
Service to service authβ
- HTTPS basic header auth. Http is susceptible to man in thr middle
- Use saml as well
- Bearer Token - static token generated by server
- Access Token - usually it is retrieved by using bearer token together with client id to get a expiring access token
- 2 way SSL - complex to renew and debug
- API keys (public/private key pair and key chains)
- username password
- JWT
- HMAC - Hash messaging code, you has the payload and key and server verifies it. Challenge is how to share it. Check how amazon s3 uses it
- API keys - like google maps where there is a key associated to each user group
generate an image of cat surfing