Grinding the java monolith
1 like1,316 views
This document discusses various premises and realities regarding software architecture patterns. It addresses premises and failures around decomposing monolithic systems into microservices, using domain objects as APIs, and other architectural approaches. Key points made include that implicit coupling through shared databases can persist, services may end up larger than desired, and domain objects can leak implementation details.
Grinding the java monolith
- 3. This Photo by Unknown Author is licensed under CC BY-NC
- 4. This Photo by Unknown Author is licensed under CC BY-SA
- 6. This Photo by Unknown Author is licensed under CC BY-SA
- 8. Users Orders Suppliers Finance
- 9. Users Orders Suppliers Finance
- 10. Users Orders Suppliers Finance
- 12. Context A large system that requires decomposition. Mix of high-level and low-level concerns Several operations are at the same level of abstraction Layers POSA 1 Solution Therefore, structure your system into an appropriate number of layers and place them on top of each other.— Buschmann, et. al., Pattern Oriented Software Architecture, Vol 1. Each layer should have a narrow, well-specified interface. It should be possible to substitute a different implementation of the layer without change to higher layers in the stack. • Forces • Late changes should have limited ripple effect • Interfaces should be stable, may be standardized • Parts should be interchangeable • Other systems may reuse lower layers • Responsibilities should be grouped for comprehension and maintainability • Further decomposition is needed for team structure and design. Example: TCP stack Failed example: Ruby on Rails Question: What makes a better or worse implementation of layers? Layer 1 1.1 1.2 1.3 Layer 2 2.1 2.2 Layer 3 3.1 3.2 3.3 <<uses>>
- 15. ▪No limits to effect of bad code ▪Common-mode failures in shared code ▪Latent semantic coupling
- 16. ▪Poor monitoring ▪Poor retry / timeout handling ▪Disruptive deployments
- 17. ▪ My experience: 2 out of 3 such projects will not succeed. ▪ The killers: ▪ Impatience ▪ Unrealistic expectations ▪ Hubris
- 19. ▪ Premise ▪ Refactor to create interfaces between subdomains, then turn those into HTTP interfaces ▪ Failure modes: 1. It takes too long. Executive impatience will defeat the plan. 2. Ongoing feature work introduces new dependencies faster than they are removed.
- 20. ▪ Tempting to make your key domain objects into services. ▪ Makes deployments more disruptive ▪ Creates common dependency from many features to the entity services.
- 21. ▪ Premise ▪ Keep developer utilization high by drawing them from a pool for the duration of a project. ▪ When the project is done, throw the developers back into the pool. ▪ Failure modes: 1. Project-orientation favors deadlines over code health & architecture initiatives. 2. Developers doing the hard work of refactoring should be able to enjoy the fruit of their efforts. ▪ Instead: 1. Use product teams
- 22. ▪ Premise: ▪ We know the domain, let’s design new services that leave the past behind. ▪ Reality: ▪ We make the same mistakes over and over. ▪ “Second system effect” ▪ Designers’ optimism not supported by any past evidence ▪ Instead: ▪ Design in context. ▪ Accept the scars of the past.
- 23. ▪ Premise: ▪ Create an intercepting proxy that can divert some kinds of traffic to one new service at a time. ▪ Reality: ▪ Sometimes works ▪ However, you will not like the service design. ▪ Services must be designed expediently and in the context of the current system’s interaction ▪ That’s OK, they can be replaced easier after the first effort.
- 24. ▪ Premise: ▪ The current system works. ▪ Devs know what’s needed in their own areas ▪ But are afraid of the far-distant effects of their changes ▪ Response: ▪ Break into “product” teams ▪ Give each one a copy of the code ▪ Let them delete anything they don’t need. ▪ Reality: ▪ Coupling via the DB lasts a long time ▪ Services will be larger than desired
- 25. ▪ Premise ▪ Microservices are never “done” ▪ Keep the pressure on simplifying design ▪ Reality ▪ Devs are often uncomfortable with ambiguity ▪ Deleting services & code that were just barely deployed feels “wrong”
- 26. ▪ Premise ▪ Objects with long lifespans that serve multiple uses are hard to change ▪ Therefore, find major boundaries in the business process ▪ Make the “before” and “after” portions into separate services ▪ Reality ▪ Addresses consistency better than entity services ▪ Supports converging business processes ▪ Not as easy to support divergence
- 27. ▪ Premise ▪ Domain objects make good representations to transfer in APIs ▪ An API can be expressed as REST on domain objects. ▪ Reality ▪ Makes it very difficult to handle multiple versions of APIs ▪ Leaks implementation detail & internals of the service ▪ Instead ▪ Treat request data as data ▪ At most, map into object that represent the interface itself
- 29. ▪ Premise ▪ Hexagonal architecture expresses the domain independently of integration & persistence tech ▪ Reality ▪ Improved testability ▪ Smaller domain ▪ Better support for monitoring, metrics, and ALM