Making a system highly available isn't just about adding redundancy

Reading this, I can’t help but feel that things have got more complicated than perhaps they need to be. Microservices boundaries make most sense to me when they’re aligned with team boundaries, otherwise it just feels like making more work with little or no apparent gain.

> Microservices boundaries make most sense to me when they’re aligned with team boundaries, otherwise it just feels like making more work with little or no apparent gain.

Nothing in the article suggests how services were designed, and I would be surprised if each of the core services mentioned in the article weren't managed by independent teams.

Also, I don't think your concerns are well founded. Think about functionality implemented with function-as-a-service backends. Do you think your architecture is less complex to maintain and operate if you suddenly decide to move all event handlers into a monolith?

Anyone else getting access denied on the page?

> Are you going to rebuild your micro service every time there's a reorg?

I feel like the answer there might be "sometimes", not as something that you'd expect to be done, but something that arises from multiple teams now sharing a service and having some friction due to that. I can conceivably imagine those two teams wanting to split off their individual parts of the functionality to be separate.

With any sort of system, when there are multiple components involved, having clear ownership and being able to iterate quickly can be pretty good - for example, if there's a system that handles the management of all sorts of binary data (file uploads, metadata storage for those) then having one team be responsible for it but other teams just using it can be a good setup.

I would argue that you don't always need to chop up your domain into microservices (depending on the size of your domain), but definitely look into doing that across various technological boundaries (a team for your web API, your auth, scheduled processes and messaging, handling object storage etc.). If you do that too much, though, it's going to become a bit of a mess of granularity.

Regardless of the language or the trendy tech used, people seem to enjoy doing rewrites way more than working with old codebases, especially if their new solution doesn't need to be 1:1 with the old one and therefore they can justify no longer needing to work around certain edge cases. That longing can't really be helped, though.

Honestly, as long as the second system effect doesn't ruin everything and you still make the new codebase better than the old one (i.e. it's small enough to actually be rewritten and testable enough to make sure that it actually works, with the abstractions that you now know you need and have solidified enough to be the right ones, without too strict deadlines and only as much backwards compatibility needed as you can provide, as well as buyin from whoever is paying you), then unironically go for it.

That's way fewer projects out there than people probably think. Plus, a lot of the wrongly started rewrites will go up in flames. Oh and it's probably also going to go wrong if people don't actually know the new language or tech.