- DDD
- Microservices
- Events
- CQRS
- Distributed Messaging
Microservices are an expensive option.
Simplicity and pressure to deliver causes increasing complication over time.
- One monolithic database
- ASP.NET Web App
- Didn't scale
- No domain ownership
- Long and difficult deployments
- Working with code was difficult
- Initially started by using Pub/Sub model
- Component publishes a messages, another receives message
- Identify bounded contexts (e.g. payment, address validation)
- Define interfaces between components in the monolith
- Abstract away the database
- Use just route to the database
- Gradually the application became asynchronous
- Initially struggled with race conditions
- Business became frustrated with race hazards
- Testing became difficult
- Race conditions developed under load
- Sequential problems developed
- Deployments became difficult
- Different deployment methods emerged for different services
- Features that span multiple context caused ownership issues
- User stories needed to be continuously translated into DDD/services
- Implemented strict code reviews to manage issues
- People felt unempowered and undermined by other service developers
- Decided to validate through greater testing
- More problems developed with more services
- Decomposing a problem pushed the complexity to the interactions
- Difficult to visualise the flow
- Difficult for new developers to understand the big picture
- Used logging to track the path through the services (eg. splunk, logstash)
- Thought it was just a refactoring exercise
- Didn't involve the business
- Concerns emerged over data duplication
- Important to accept that a distributed system will have inconsistencies
- Monitoring is more valuable than acceptance testing
- Business metrics from monitoring gives real-time stats
- Can measure the immediate impact of changing/introducing a microservice
- Metrics from monitoring give you freedom
- Rewriting a microservice is possible - safety net
- Can measure how microservice changes impact the overall service
- Microservices should be defined as one unit of business functionality
- Rule of thumb: Can I rewrite it in 3-4 days?
- Docker containers can encapsulate a microservice
- Services should reside on their own server (isolated, distributed)
- Cloud technologies best suited
- However, increasing number of instances increases network traffic
- How long did the migration take you?
- 24 months.
- Could have been shorter with greater business involvement
- Biggest pain point?
- Definition of where business boundaries are
- Would have been cleaner in a single rearchitecting exercise
- What kind of testing do you perform?
- Still have acceptance and smoke testing
- Rely on monitoring
- How do you orchestrate your microservices?
- Service bus and messaging
- Can you deploy different versions of your microservices?
- Specify version of service to use in message
- Where there cultural issues? Did you have to fight Conway's Law?
- Able to organise around services and end-to-end
- Developers became fully responsible for microservice
- Extended to on-call support
https://skillsmatter.com/skillscasts/6256-monoliths-to-microservices-a-journey