Chris is the technical co-founder of https://www.inloop.com.au, home of Australian Fintech success stories https://www.flexischools.com.au and https://www.lanternpay.com (Recently acquired by NAB). Since 2021 he has been coaching startup CTOs through Dev Cycles Technology Advisory (https://devcycles.io/page/consulting/) as well as supporting executives & boards with strategic technology advice, and engineering teams with training, mentoring and consulting. To support teams practicing Domain Driven Design, he recently launched an open-source IDE extension called Contextive (https://contextive.tech) to help with common communication challenges between developers and the broader organisation.
More about Chris Simon...
Chris Simon is talking about
Experiences scaling a Modular Monolith to Microservices using the 4+1 Views
The 4+1 views is a way of understanding software intensive systems that focuses on 5 different 'views' of the system, allowing to design and scale different aspects of the system in response to different triggers: 1. The logical view - represents the functional requirements and scales with functional complexity 2. The process view - represents executable processes & how they interact and scales with concurrency and deployment requirements 3. The physical view - represents the hardware & networks that the processes execute on and scales with load and throughput 4. The development view - represents the system as seen by developers - code & development and scales with the number of teams and team size. 5. The Scenarios view - represents the various scenarios in which the system is used & highlights how components in the other views interact as those scenarios play out. Through this lens a modular monolith is a system that has 'scaled up' the logical view (multiple modules, e.g. bounded contexts), but not yet scaled up the process or physical views (singular process, single hardware configuration). Over the last 7 years we used this approach to design and launch a system as a modular monolith - saving time and complexity when the team was small and load was low and allowing simpler realignment of module boundaries as we were still discovering the domain. We then gradually extracted modules into microservices as needed once we were more confident in module boundaries, when load/concurrency necessitated it and as the # of teams grew and needed autonomy. In this talk we'll explore what went well, a few mistakes we made (and how to avoid them) and recommendations for following this approach in the future.
Attendees will: * Understand the 4+1 views * Learn practical do's and don't's for managing 'logical isolation' within a single codebase and single executable process based on real world experience * Understand triggers for 'scaling' each each of the views to manage cost and complexity to grow only as needed * Understand mechanisms for extracting the modules when needed