These days from what I can see teams in organizations with no ability to devise a sane architecture usually take the microservice route. Management loves this new buzzword. To them it means problems go away.
Atlassian started rearchitecturing around services in 2013. They were 1500ppl at the time. Confluence and JIRA were not only monoliths, but non-multitenant, so they had to have one instance per customer (700Mb RAM JIRA, 700Mb Confluence, a dozen gigs on SSD). The worst was restarting upon upgrades: Easily 3-5 minutes per instance, which, at scale, was a huge burden.
After rearchitecting around services, pieces could be restarted and upgraded independently. As a customer, we didn't notice differences in the UI (e.g. the file storage on AWS).
Epilogue: They had a shared login system, multi tenant and all... which they recently replaced by a third party. Proof that services are replaceable, but also an acknowledgment that simple critical services can be hard at scale.
I personally believe that Atlassian switched to services at the right time, when it's hard to coordinate teams of thousands working on a dozen products, and when the monolithic approach was way past refactoring date ;)
Rather a late reply but Service Oriented Architecture is in fact an architectural approach. "Micro" services deem even the burdern of devising a coherent "service" as too great a burden to tackle.
> Confluence and JIRA were not only monoliths, but non-multitenant, so they had to have one instance per customer (700Mb RAM JIRA, 700Mb Confluence, a dozen gigs on SSD).
I don't understand how you engineer even a monolith like that in the first place.
Could be simplified to just "teams.
These days from what I can see teams in organizations with no ability to devise a sane architecture usually take the microservice route. Management loves this new buzzword. To them it means problems go away.