What do you think of your monolith: Should you tear it down and rebuild with microservices? What would you lose? This talk will explore how we make sensible architecture decisions, and look at how microservice concepts can help us evolve & future-proof our monolithic architecture. The monolith has come in for criticism, some of it deserved, in recent years. Microservices are heralded as the solution to many problems we face with monolithic applications. This talk will explore the reasons underpinning these architecture decisions, and examine if we can apply these principles to evolve our monolithic applications. We’ll learn about coupling, pros & cons of different approaches, and explore real world examples to see how thinking well about architecture choices can benefit us. We’ll even see how monoliths and microservices can work together - is there a best of both worlds?

This talk is drawn from experience managing a complex web application powering our startup business, grown from a single developer to a team of 14 engineers. Over the years we've been challenged as old architecture decisions cause us problems, and engineers look to new, exciting concepts like microservices to solve these.

During these processes, trying to understand why we built things the way we did, we've seen places where the knee-jerk reaction to move to microservices can be damaging, losing important embedded business knowledge from our code base. We've adopted practices to allow microservices ideas to influence how we continue to build and maintain our monolith, gaining control over our systems without losing the underlying experience codified in our systems.

I want to assure developers that tearing things down and rebuilding isn't the only way, that their existing code can be not only maintained well, but valuable because of the lessons it contains. In conversations with developers at a number of conferences I've spoken at, there's often been guilt inherent in how people think of their code vs what they see published or spoken about - I want to try and reverse this in a helpful way.

What you'll learn from this talk:
* How to assess monolith architecture in light of the growth in popularity of microservices
* An understanding of why different architecture styles might be chosen, and how they fit in different situations
* Concepts within a monolith that can gain the advantages of microservices without large scale architecture change
* Ways to mix architecture types and try to achieve the best of both worlds

Comments

Comments are closed.

Mike at 11:45 on 24 Jun 2022

Nice to hear from the other side of the barricade :)

Interesting talk that might make you reconsider your life choices.

Bas at 11:57 on 24 Jun 2022

Nice. Giving me lot of stuff to think about our monolith.

Speaking tip, sometimes the ending of one topic and the beginning of the next was a bit surprising.
Maybe pause a bit longer between them, or lower your voice when you round up one and go to the next.

Timo Bakx at 12:31 on 24 Jun 2022

Good talk. Loved hearing about both sides of the coin. Very good advice on what to use (spoiler: it depends).

Xavier Serrat at 12:32 on 24 Jun 2022

It's been a great talk. Thanks to share that we can have a well-designed system without going to microservices. It's true that it depends on the context, because if the company has so many teams working on the same codebase it might be much easier to split the code based on the teams we have. But it's a difficult decision where there're too many things to take into account.

Sandra at 13:09 on 24 Jun 2022

thank you for clear (numbered) slides, standing up & being engaging (:
switching between slides was useful
I think the term "widgets" comes from WordPress's sample posts

bit much on microservices for a talk about monoliths, felt a little defensive, but I think it was appropriate for some of the more "trendy" opinions.

++ for reiterating basic concepts or pointing to more info
loved the SO programming languages graph

Kaz van Wel at 15:56 on 24 Jun 2022

Thanks, great talk. I'm still on the monolith side, and sometimes consider to introduce a microservice. I pretty much agree on everything you say, be very thoughtful about why you would introduce a microservice and make very sure it fixes more problems than it creates new ones.

It was great to have a talk which had a balance between monoliths and microarchitecture. And why monoliths are not something to be ashamed of.