Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monolith First (2015)

martinfowler.com

Post reply on HN
Print view View original

81–90 of 356 posts

Re: Monolith First (2015)

#81

Post by thatswrong0 »

rizpanjwani wrote: post #69
thatswrong0 wrote: post #68

Earlier quoted context omitted.

That's what my company has done. We have a microservice-like architecture, but discourage dependencies on other services. If we need to use one service in another, we use dependency injection (which allows us to switch out the communication protocol later if need be) or talk over a message bus instead. The idea was that we would figure out later which sub-services actually need to be split out based on usage. AFAIK,…

Does each microservice/module have its own db?

Nope. Everything lives in one big DB, but services are not allowed to touch each others tables directly - communication must be done through service API endpoints.

Re: Monolith First (2015)

#82

Post by adrianN »

diroussel wrote: post #54
pjmlp wrote: post #51

Earlier quoted context omitted.

Here is the thing, whatever you write doesn't work without linking, so no we never moved away from it.

But is linking the right way to couple business logic from two different organisational units? That is the question being discussed.

Why do you think that something other than linking is superior?

Re: Monolith First (2015)

#83

Post by diroussel »

tutfbhuf wrote: post #65
diroussel wrote: post #54

Earlier quoted context omitted.

But is linking the right way to couple business logic from two different organisational units? That is the question being discussed.

> But is linking the right way to couple business logic from two different organisational units I think it's not, but I would like to hear other opinions.

I'm not sure why you are being down voted. In context of calling business logic we have moved away from linking.

I guess the context is only implelied in your parent post.

The rise of the network API in the last 20 years has proven it's own benefits. Whether you are calling a monolith of a microservice, it's easier to upgrade the logic without recompiling and re-linking all dependencies.

Re: Monolith First (2015)

#84

Post by mattacular »

vergessenmir wrote: post #78

The main takeaway for me is clean modularity in a system with strong decoupling, the modules can be in a single application boundary (a monolith) or across multiple (services or microservices). The design challenge becomes making sure that your modules can execute within the monolith or across services. The work to be done can be on a thread level or process level. The interfaces or contracts should be the same from…

Could you elaborate on the framework you mentioned for flipping between process and thread models? That sounds interesting. Was it released or just used internally for some projects?

Re: Monolith First (2015)

#85

Post by rdsubhas »

diroussel wrote: post #54
pjmlp wrote: post #51

Earlier quoted context omitted.

Here is the thing, whatever you write doesn't work without linking, so no we never moved away from it.

But is linking the right way to couple business logic from two different organisational units? That is the question being discussed.

Article and parent is not about two different organizations units.

Most of microservice implementation is within a single team. That is the real question being discussed.

Re: Monolith First (2015)

#86

Post by chrisvalleybay »

vergessenmir wrote: post #78

The main takeaway for me is clean modularity in a system with strong decoupling, the modules can be in a single application boundary (a monolith) or across multiple (services or microservices). The design challenge becomes making sure that your modules can execute within the monolith or across services. The work to be done can be on a thread level or process level. The interfaces or contracts should be the same from…

This definitely sounds like an interesting approach.

I think however defining these modules and the interfaces between them is the hard part. Part of this work is defining the bounded contexts and what should go where. If I understand DDD correctly this shouldn't be done by «tech» in isolation. It's something that's done by tech, business and design together. This is hard to do in the beginning – and I would argue that it should not be done in the beginning.

When starting out you've just got a set of hypothesis about the market, how the market wants to be adressed and in which way you can have any turnover doing it. This isn't the point when one should be defining detailed bounded contexts, but should instead just be experimenting with different ways to get market fit.

Edit: typo

Re: Monolith First (2015)

#87

Post by hayst4ck »

yuppie_scum wrote: post #72
hayst4ck wrote: post #46

Earlier quoted context omitted.

It is easier to isolate business logic with a microservice architecture, but as the microservice graph gets more complicated so too does administering it. How do you make graphs that make sense of your various microservices? How do you make sure code doesn't get stale/all versions are compatible/rolling back code doesn't take out your website? How do you do capacity planning? How are service specific configurations d…

The answer to your questions is, hire competent SRE’s.

An SRE might help you build systems, but that is a lot of system to build depending on number of microservices. Managing the complexity of N services comes at a cost, maybe that cost is in how seamless and wonderful the testing infra is.

A very well built monolith is very easy to manage.

Most product devs want to trivially build a feature, not deal with the complexities of running a service in production. Abstracting away a request handler is going to be an easier overall system than abstracting services.

As for the oncall/onboarding etc, SRE is there to support and enable, not to be an ops monkey, so that stuff scales with number of services/engineers.

Re: Monolith First (2015)

#89

Post by ergo14 »

lmm wrote: post #45
ergo14 wrote: post #44

Earlier quoted context omitted.

Weird, we do it with Python all the time. Just don't use globals/threadlocals everywhere and you will be good.

As long as you're not using any libraries/frameworks that use them.

I don't think we've ended up with libs that share state in a dangerous way, maybe we got lucky.

Re: Monolith First (2015)

#90

Post by bni »

vergessenmir wrote: post #78

The main takeaway for me is clean modularity in a system with strong decoupling, the modules can be in a single application boundary (a monolith) or across multiple (services or microservices). The design challenge becomes making sure that your modules can execute within the monolith or across services. The work to be done can be on a thread level or process level. The interfaces or contracts should be the same from…

Like EJB that had remote interface, but you could also call the code directly without network in between?
Post reply on HN