4 ms·
A huge point of microservices is to create code that is independent of eachother. Your database backend is tightly coupling what should be completely independe
by sbov 9y ago
A huge point of microservices is to create code that is independent of eachother. Your database backend is tightly coupling what should be completely independent services. Microservices were designed to scale your engineering departments just as much (if not more than) your performance. You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. That you cannot see this as a major benefit makes me think microservices are a poor choice for your use case.
- eternalban 9y ago> You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. Let's ammend this: so teams in large organizations +{that lack both a coherent architecture and the ability to devise one} can do independent releases +{by adoptiong the no-architecture architecture}.
- marcuslager 9y ago"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 agoAtlassian 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 agoOn the flip side, cloud hosted jira is soooo slow now.
- tajen 9y agoA 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 agoAnd 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 agoRather 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.
- tomerbd 9y agocan you describe a coherent architecture that will turn microservices uneeded?
- eternalban 9y agoMissed this but in case you read this, well that depends on the purpose of the system, but in most cases modular schemas and allowing for loose coupling via data/message bus does the job.