re: The Rails Ecosystem is Healthier than Ever VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Wait, you're not going to break up Dev.to into microservices anytime soon?
 

Why would they, I see no real benefits in turning this website into microservices.

It is a rather small-focused platform, with a small team developing it and no real concerns in terms of scalability.

 

I was being facetious. There is nothing wrong with monolithic apps.

We worked with a few consultancies leading up to the open source announcement, mostly for a security audit.

I recall one convo where I was describing the system and I said "it's a Rails monolith", and their immediate automatic response was "so you'll want help breaking it up into microservices".

I was like "What, no! I love our majestic monolith". We do use a handful of external services (ours and SaaS), and none of it makes our process simpler. If anything we want to pull more stuff into the core codebase over time.

There are a lot of valid architectures, and monolith is absolutely one of them.

It is amusing to me because a microservice architecture is just a monolith broken up into smaller apps. For a startup, it makes no sense to put the extra planning and context switching onto the team just to have a more trendy setup. As DHH said, embrace the majestic monolith!

a microservice architecture is just a monolith broken up into smaller apps.

I think that's more a result of people doing microservices because it's "cool" and ending up with what I call a "distributed monolith". That said, I totally agree, a majority of web apps don't need a micoservice architecture, especially not to start with.

To be fair, I do see the benefits of microservices in the right scenario.
They allow for small, independent teams to focus on simple, testable and disposable bits of a greater application and this can help reduce time-to-market and embrace continous delivery when building complex and intricated systems.

I worked on a not-quite-microservices-but-still-service-oriented project and it was fun, bits of the application can go online without worrying about the others (we used message queues to decouple them). But it surely was complex to handle and maintain compared to a monolithic application.

Which is why a said "a majority of web apps don't need a micoservice architecture", not "no web app needs a microservice architecture". 😉 But that need emerges as a system grows and shouldn't be assumed from the get-go. Nothing is stopping you from using a message queue to decouple parts of your monolith, which gives you most of the same benefits without any of the incidental complexity.

code of conduct - report abuse