News for hackers. Stuff that matters.
Re:Monolith First (2015) by sbov on Saturday July 15, 2017 @06:32PM (#14779406)
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.
Re:Monolith First (2015) by eternalban on Saturday July 15, 2017 @11:17PM (#14780294)
> 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}.

Re:Monolith First (2015) by marcuslager on Sunday July 16, 2017 @12:10AM (#14780439)
"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.

Re:Monolith First (2015) by tajen on Sunday July 16, 2017 @05:58AM (#14781328)
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 ;)

Re:Monolith First (2015) by tokenizerrr on Sunday July 16, 2017 @09:00AM (#14781797)
On the flip side, cloud hosted jira is soooo slow now.
Re:Monolith First (2015) by tajen on Sunday July 23, 2017 @06:32PM (#14834769)
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!

Re:Monolith First (2015) by eternalban on Saturday July 22, 2017 @03:32PM (#14828920)
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.
Re:Monolith First (2015) by ris on Sunday July 16, 2017 @12:26PM (#14782686)
> 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.

Re:Monolith First (2015) by kod on Sunday July 16, 2017 @10:22AM (#14782053)
And Jira still can't handle email in a sane fashion...

I wouldn't look to Atlassian for anything regarding engineering practices.

Re:Monolith First (2015) by tomerbd on Monday July 17, 2017 @03:08PM (#14791432)
can you describe a coherent architecture that will turn microservices uneeded?
Re:Monolith First (2015) by eternalban on Sunday July 23, 2017 @09:08PM (#14835271)
Missed 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.