5 ms·

"teams in large organizations" Could be simplified to just "teams. These days from what I can see teams in organizations with no ability to devise a sane arch

"teams in large organizations" 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.

tajen 9y ago
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 ;)
- tokenizerrr 9y ago
  On the flip side, cloud hosted jira is soooo slow now.
  - tajen 9y ago
    A bit late to answer, but by their EULA you are not allowed to talk about the performance of their products. Yes, they did that!
- kod 9y ago
  And Jira still can't handle email in a sane fashion... I wouldn't look to Atlassian for anything regarding engineering practices.
- ris 9y ago
  > 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.
- eternalban 9y ago
  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.

tajen 9y ago

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 ;)

tokenizerrr 9y ago
On the flip side, cloud hosted jira is soooo slow now.
- tajen 9y ago
  A bit late to answer, but by their EULA you are not allowed to talk about the performance of their products. Yes, they did that!
kod 9y ago
And Jira still can't handle email in a sane fashion... I wouldn't look to Atlassian for anything regarding engineering practices.
ris 9y ago
> 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.
eternalban 9y ago
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.