March 24, 2025 at 12:00 am
Comments posted to this topic are about the item Monoliths and Microservices
March 24, 2025 at 8:45 am
I went to a talk by Dr Venkat Subramaniam at the Manchester museum of Science and Industry. If you get the chance to hear him speak then I can recommend it. He touched on this subject and why he much prefers libraries to frameworks.
For microservices architecture to be effective it takes skill, discipline and a whole lot of active governance. I haven't really seen that holy trinity in the wild and, to be frank, I have rarely seen 2 of the 3.
There is a reason why Kelsey Hightower says "Start with a monolith". I maintain that it is possible to build that monolith where change and evolution are not painful. It takes a lot of thought and attention to detail. You also have to work out where the responsibility boundaries within the software really are.
What I have seen is the people who built a painful monolith leaping into defining a painful microservices architecture making all the same mistakes in new and interesting (may you live in interesting times) ways.
When consuming cloud services, those services might not be as decoupled as you think they are. I came across a situation where a message on a queue was being processed more than once by the same component. The reason was that, to stop multiple queue consumers all grabbing the message, when the message is read it is hidden from all consumers. When the component finishes processing the message it acknowledges the message and the message is removed from the queue.
However, if the component cannot process the message in time then the queue assumes that the message has not been processed successfully and it is made visible on the queue again. Even if the component completes processing its 1st receipt of the message it picks up the revitalised message again.
The solution is to make the timeout, that results in the message re-appearing, greater than the likely maximum execution time for the component. In short, there is an invisible coupling between the queue and the component that was hard to diagnose.
March 26, 2025 at 3:56 pm
Interesting. With queue type stuff, I try to use some way to mark that a process has the message quickly and then mark done. In some of the queueing systems that doesn't work as well, and it's a little scary to hear that story.
I tend to like monoliths for most things. Good comms with different teams do make this easier, and lots of tests for the interfaces/boundary points within a monolith. Most of us aren't spotify/uber/etc. so we can get away with that
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy