Monolith First (2015) • Hacker News Board

Re: Monolith First (2015)

#171

Post by yellowapple » Tue, Jul 18, 2017, 2:50 PM UTC

Even if you're building a monolith, though, you're generally well-served by a monolith that pretends to be a bunch of microservices - i.e. it could be split into microservices easily if the need arises, kind of like how some "hybrid" OS kernels could (in theory) be split into proper microkernels if the internal function calls were replaced with messages (the NT kernel is built this way, IIRC). Each part of this "chunky" monolith should provide a proper internal API, and no other part should have to call into that part's internal functions.

This should be easy to achieve in most "object-oriented" languages (like Ruby; a Rails monolith should have no problem being structured this way, even if quite a few of the ones I've seen in the wild seem to forego this). Erlang (and Elixir by descent) is also well-suited to this, since you can break your application into a collection of processes that - whether individually or in combination with other processes - can act like their own little microservices.

Re: Monolith First (2015)

#172

Post by beat » Tue, Jul 18, 2017, 6:38 PM UTC

quickben wrote: post #169

beat wrote: post #98

Earlier quoted context omitted.

Yes, but if you don't avoid it, you might never get off the ground to the point where you have years of time and tons of money in the first place.

I guess it depends on the viewpoint. Yours sounds valid. Mine comes from the occasional fixing people's messes. But I agree with you, some product is better than no product in most cases.

I have a lot of career experience dealing with legacy software. I feel that pain intensely. But still... a working product with bugs and flaws is better than a not-working product that is elegantly built. Or half-built.

Re: Monolith First (2015)

#173

Post by decisiveness » Thu, Jul 20, 2017, 3:57 AM UTC

What many seem to have missed from this is the bit at the end where Fowler concedes:

> I don't feel I have enough anecdotes yet to get a firm handle on how to decide whether to use a monolith-first strategy.

after linking and mentioning points of a guest post [1] (with which I strongly agree) which argues against starting with a monolith. A key part from that post:

> Microservices’ main benefit, in my view, is enabling parallel development by establishing a hard-to-cross boundary between different parts of your system. By doing this, you make it hard – or at least harder – to do the wrong thing: Namely, connecting parts that shouldn’t be connected, and coupling those that need to be connected too tightly. In theory, you don’t need microservices for this if you simply have the discipline to follow clear rules and establish clear boundaries within your monolithic application; in practice, I’ve found this to be the case only very rarely.

[1] https://martinfowler.com/articles/dont-start-monolith.html

Re: Monolith First (2015)

#174

Post by eternalban » Sat, Jul 22, 2017, 7:32 PM UTC

tajen wrote: post #123

marcuslager wrote: post #97

Earlier quoted context omitted.

"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.

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…

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)

#175

Post by tajen » Sun, Jul 23, 2017, 10:32 PM UTC

tokenizerrr wrote: post #134

tajen wrote: post #123

Earlier quoted context omitted.

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…

On the flip side, cloud hosted jira is soooo slow now.

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)

#176

Post by eternalban » Mon, Jul 24, 2017, 1:08 AM UTC

tomerbd wrote: post #166

eternalban wrote: post #90

Earlier quoted context omitted.

> 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}.

can you describe a coherent architecture that will turn microservices uneeded?

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.