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.