Monolithic Delivery
Download as PPTX, PDF0 likes127 views
This document discusses techniques for delivering software in smaller, more frequent units to reduce coupling and increase flexibility. It advocates dividing monolithic systems into independent services that can be developed and deployed separately. Specific techniques mentioned include having each service focus on a single task, making incremental improvements, refactoring code frequently, deploying changes quickly, and monitoring systems to identify problems early. Barriers to this approach like unnecessary branching and shared binaries are also addressed. References are provided for further reading on related topics like continuous delivery and emergent design.
Monolithic Delivery
- 1. { Monolithic Delivery ACCU Conference 2018 Chris Oldwood
- 3. 1. a large single upright block of stone, especially one shaped into or serving as a pillar or monument. - a very large and characterless building. - a large block of concrete sunk in water, e.g. in the building of a dock. 2. a large, impersonal political, corporate, or social structure regarded as indivisible and slow to change. Monolith (n) https://www.google.co.uk/search?q=define+monolith
- 7. Monitors upstream data feeds Decides when to process data feeds Manages compute grid Processes data feeds in parallel Dispatches work to grid Aggregate results in parallel “The Scheduler”
- 11. {Techniques for smaller deliveries Decoupling Delivery
- 12. Smaller Units of Change http://parkinsurance.co.uk/wp-content/uploads/2015/06/Josephine-Reitzel-2013-bike-messenger-worlds.jpg
- 13. Always Be Ready To Ship http://wiki.c2.com/?AlwaysBeReadyToShip “A principle (or consequence) of highly iterative software development methodologies is that after the first iteration, the product is always ‘ready to ship’. That is, the product does something useful and is in a releasable state.”
- 14. An example: sharing loyalty points: View shared balance Accrue shared value Spend shared value Join customers Split customers Partial Deliveries
- 15. Emergent Design
- 16. https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf “Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. ‘We have met the enemy, and he is us.’” -- Ralph Johnson
- 17. Console app v0.1 v1.0 DB Services Services Command line tools File- system Command line tools Scripts
- 18. Emergent Design is the continued borrowing and repaying of short term technical debt to allow practical experience to drive evolution.
- 19. Refactor All The Things “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away” -- Antoine de Saint-Exupery
- 22. {Friction inducing behaviours Barriers to Delivery
- 23. Identify the Real Waste https://twitter.com/raganwald/status/794527181225357312
- 28. {Filling in the gaps Q & A
Editor's Notes
- #2: I’m a freelance developer working with “enterprise grade” technology. This talk is about the misconception that monolithic architectures are inherently bad, the problem is not necessarily the system’s architecture but might be the method of delivery.
- #4: What is a “monolith” anyway?
- #5: Possibly the most common visual metaphor for a monolith – opaque, impenetrable, undiscoverable, etc.
- #6: True monolithic systems involved the delivery of a single piece of hardware and software, e.g. a mainframe or home computer.
- #7: What do we mean today by a monolithic architecture?
- #8: An example of a monolithic service.
- #9: Is it possible to apply the same rigid approach to an entire suite of services? Of course – multiple supposedly discrete systems can be tightly coupled by their service contracts. Example of multiple systems needing upgrading together due to coupling.
- #10: But nobody would design an entire enterprise to be tightly coupled, would they? Microservices are an organisational pattern intended to decouple delivery by spreading around the jam.
- #11: My message - it’s not the architecture’s fault per-se, it’s the method of delivery that is tightly coupled.
- #13: Smaller units of work (stories / tasks). The MVP is not “everything”. Okay to deliver partially implemented features. Hide behind toggle if necessary.
- #15: An example of how to decompose into smaller deliverables and how ordering can be overcome.
- #18: Evolution of calculation engine from single simple console app to multiple services, data stores, scripts, tools, etc.
- #20: No just functions and methods but the structure and architecture. See Michael Stal’s blog.
- #21: Even deploying to a development or test environment is deploying – do it regularly. Minimise the time it takes to get a fix or feature from idea into production. Deploying regularly gets you good at it and minimises the impact of changes as they are smaller and the time-to-fix is shorter.
- #22: Know your system’s behaviour. Instrument everything you can afford to – see the trends and compensate before performance drops off a cliff. Know your clients. Help your clients to help themselves by providing you with non-functional data, e.g. version number, correlation ID, etc.
- #25: Prefer trunk based development by default. Branching has its uses, but know the costs and keep it short, e.g. Spikes. If branching for release, do it late, aim for higher quality first to avoid needing to in future.