Building that glorious monolith. And carving it too. - Glenn F. Henriksen - NDC Porto 2023

This talk was recorded at NDC Porto in Porto, Portugal. #ndcporto #ndcconferences #microservices #architecture #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
To microservice or not to microservice, is that really the question? I'd argue that the best way to start a project is by building a monolith. It will give you better results, faster, than running down the microservice path right off the bat. But we've all heard the horror stories from the big ball of mud monolith that slows all development to a crawl. It doesn't have to be that way. There are some well-established patterns and practices that help us build glorious monoliths, where the code is not a big ball of mud or stale and sticky spagetti.
I'll talk about how we've used techniques like Domain Driven Design, eventing, and API design for keeping our monolith ordered and easy to navigate. Keeping the complexity manageable and our development speed fast.
And we'll show you how to carve out the pieces you need, when you need it, to another service - with a minimum of work.

[@morale3056]

The thing that nobody talks about when coming to any kind of monolith is change management and the test effort involved. I've been on both sides and the whole thing is significantly easy with microservices.

[@djn138]

At around 29:00, he says, “multiple databases are expensive.” Not if you use DynamoDB!

[@vincentcifello4435]

Great talk!
Until...
"Yes! I have a lot of duplicated data. IT DOESN'T MATTER. Storage is cheaper than dirt."
>>> Since when does the cost of storage determine boundaries? Is coupling now inversely proportional to storage costs?
"We have a lot of code in our common libraries, so we just pull in..."
>>> So, multiple "modules" operating on common data. Yikes.
"We have jobs that synchronize across domains every night"
>>> The data is duplicated which results in inconsistent application state that must be corrected with batch jobs during down time every night.
ugh