Just in Time Architecture - Macklin Hartley - NDC Porto 2023

This talk was recorded at NDC Porto in Porto, Portugal. #ndcporto #ndcconferences #architecture #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndcporto.com/
Subscribe to our RUclips channel and learn every day:
/@NDC
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
Architecture is the decisions and trade-offs that are appropriate for the problem at hand. While a globally distributed fault-tolerant microservices architecture might be an interesting and fun challenge to build, diving in too early will likely result in disaster. This talk tells the story of a team's journey from a monolithic architecture to event driven microservices, including missteps and learning opportunities they discovered along the way.

[@netspie]

Nice to see an example combing gaming and typical business domains.. really useful for turn-based or timer-based online games. I'll certainly get back to this example when implementing more complex processes in my codebase.

[@maddelasaikarthik7563]

interesting presentation.

[@allanwind295]

Jumping between the two stories (café and game thing) is unnecessarily confusing. Just pick one, ideally, the one based on your experience instead of the toy example.

[@juancruz-theflock]

My key take aways:
* tell those devs who want to use kotlin to go f- themselves and just keep the good ol' monolith
Now, seriously: have we all gone completely insane as an industry? Say it with me: you👏don't👏need👏a👏network👏to👏set👏boundaries. Do it in your code. Be diligent and force devs to respect contexts.
One stateless hosting unit (modular monolith) + a relational database solves 99.9% of all requirements you will ever encounter. Including scaling (just scale horizontally). The RDB is becoming the bottleneck? Do some sharding.
Really guys, we don't need too much complexity to do our job properly.

[@extraterestru26]

Poor enforcement of modularity is a really bad argument against a monolith, same with changes to unrelated code. If you have a proper moodular monolith build, each module communicates through a queue or client to each other and do not share code. And enforcing it is no harder than writing some architecture tests to check for invalid imports from outside a module.
Seems more like you had experience with bad module boundaries than a monoloth. You can have the exact same issue with microservices sharing common code.