In Defence of Monoliths • Hacker News Board

Re: In Defence of Monoliths

#51

Post by pdpi » Fri, Oct 23, 2015, 8:46 PM UTC

to3m wrote: post #17

pdpi wrote: post #7

Earlier quoted context omitted.

> The higher coupling in most monoliths also restricts a teams ability to try new things and take risks. I think it's you who's missing the point. That right there is why. Turning your monolith into a micro-service architecture should add up to basically: - Wrap your internal modules in your favourite form of RPC - Replace the modules with stubs that call the RPC If you need more work than that, the problem with your…

Don't forget that an RPC call can take longer to complete than a function call. Loose coupling doesn't imply that your program expects operations to routinely take 1ms to return results.

I was replying to a comment that ended with "If performance of technology is the only metric that matters to you, then yes, microservices are probably a horrible idea". I figured that it'd be more effective to make my point without bringing performance into the discussion.

Re: In Defence of Monoliths

#52

Post by jjbiotech » Fri, Oct 23, 2015, 8:49 PM UTC

debacle wrote: post #41

An honest question - has Martin Fowler ever written any code that makes him so much of an authority on software design? I don't disagree with everything he's said, but what contributions has he made that makes him so much of an authority on how I write code?

That's an impressive logical jump you've made there. Starting with a man simply writing a blog post with his opinion on software architecture, all the way to implying that he's an authority on writing code.

He never said he was an authority...

Re: In Defence of Monoliths

#53

Post by pdpi » Fri, Oct 23, 2015, 8:50 PM UTC

cpitman wrote: post #19

pdpi wrote: post #7

Earlier quoted context omitted.

> The higher coupling in most monoliths also restricts a teams ability to try new things and take risks. I think it's you who's missing the point. That right there is why. Turning your monolith into a micro-service architecture should add up to basically: - Wrap your internal modules in your favourite form of RPC - Replace the modules with stubs that call the RPC If you need more work than that, the problem with your…

I get what you're saying, and I've tried both ways: using project structure to explicitly force modularity vs trying to instill culture and practices to preserve modularity within a monolith. I should mention I am a consultant, so I tend to work in enterprise environments with varying levels of practices and maturity. My experience has been that lots of different people will touch a codebase over the lifetime of a pi…

> First, adding coupling is no longer the path of least resistance when you "need to delivery yesterday".

I wouldn't be so sure. More often than not, it's cheaper to set up a new module/library than it is to setup a whole new service, and I've seen plenty of cases where people just tacked functionality on to the handiest service because they needed to get shit done Right Now, and setting up a new service was a waste of time.

Re: In Defence of Monoliths

#54

Post by csears » Fri, Oct 23, 2015, 9:01 PM UTC

I think the choice of monolith vs microservice should be largely driven by the size of your team. Some guidance I heard on a podcast recently (can't recall which) was to only consider microservices if you had more than 50 people trying to deploy code in the same app/system.

Re: In Defence of Monoliths

#55

Post by [deleted] » Fri, Oct 23, 2015, 9:06 PM UTC

patrickmay wrote: post #8

One advantage of a microservice architecture not mentioned in the article is the ability to scale services independently of other services. Being able to fire up more instances to address a bottleneck is often much simpler than managing threads in a monolith.

[deleted]

Re: In Defence of Monoliths

#56

Post by ExpiredLink » Fri, Oct 23, 2015, 9:09 PM UTC

unoti wrote: post #12

There's a dangerous, contagious illness that developers of every generation get that causes them to worry about architecture and getting "street cred" even more than they worry about solving business problems. I've fallen victim to this myself, because street cred is important to me. But it's a trap. An important meta-idea that encapsulates all of this is remember to solve your business problems as your first priorit…

> more than they worry about solving business problems.

That's why companies implement Agile. It's all about "solving business problems". No architecture, no design, no documentation (merely 'user stories'). Dump and re-write instead of maintain. All your problems solved!

Re: In Defence of Monoliths

#57

Post by debacle » Fri, Oct 23, 2015, 9:14 PM UTC

jjbiotech wrote: post #52

debacle wrote: post #41

An honest question - has Martin Fowler ever written any code that makes him so much of an authority on software design? I don't disagree with everything he's said, but what contributions has he made that makes him so much of an authority on how I write code?

That's an impressive logical jump you've made there. Starting with a man simply writing a blog post with his opinion on software architecture, all the way to implying that he's an authority on writing code. He never said he was an authority...

Martin Fowler (not the author) definitely thinks he's an authority. Have you ever heard him speak?

Re: In Defence of Monoliths

#58

Post by debacle » Fri, Oct 23, 2015, 9:28 PM UTC

rcconf wrote: post #29

We've had a lot of issues with micro services. They're extremely difficult to debug and end up being too generic. I argue the reasons why we introduced microservices has merit (massive code base) but does not mean they are simple to use/maintain. Here are some examples: 1. A chat service (race conditions, synchronization issues between the game server and chat service that had to be debugged using sequence diagrams)…

I don't mind to sound crass, but it sounds like you implemented microservices poorly. You could s/microservices/threads/g on your post above and it would point much more to a problem with your implementation rather than a problem with threads.

Re: In Defence of Monoliths

#59

Post by cableshaft » Fri, Oct 23, 2015, 9:42 PM UTC

jjbiotech wrote: post #52

debacle wrote: post #41

An honest question - has Martin Fowler ever written any code that makes him so much of an authority on software design? I don't disagree with everything he's said, but what contributions has he made that makes him so much of an authority on how I write code?

That's an impressive logical jump you've made there. Starting with a man simply writing a blog post with his opinion on software architecture, all the way to implying that he's an authority on writing code. He never said he was an authority...

You Google "Martin Fowler" and the snippet of text that accompanies his personal website is "Object-oriented programming expert and consultant, one of the leaders in refactoring, author of the book 'Refactoring: Improving the Design of Existing Code'"

He's a self-proclaimed "expert" and a "leader". Yes, he's basically saying right there that he is an authority on writing code.

That being said, I've read some of his Refactoring book awhile ago, and it's mostly good advice from what I remember.

Re: In Defence of Monoliths

#60

Post by rcconf » Fri, Oct 23, 2015, 9:43 PM UTC

debacle wrote: post #58

rcconf wrote: post #29

We've had a lot of issues with micro services. They're extremely difficult to debug and end up being too generic. I argue the reasons why we introduced microservices has merit (massive code base) but does not mean they are simple to use/maintain. Here are some examples: 1. A chat service (race conditions, synchronization issues between the game server and chat service that had to be debugged using sequence diagrams)…

I don't mind to sound crass, but it sounds like you implemented microservices poorly. You could s/microservices/threads/g on your post above and it would point much more to a problem with your implementation rather than a problem with threads.

Writing multi-threaded code is hard, writing micro services is even _harder_. I don't think your argument holds here.

Micro services are hard to write, so don't write them unless you absolutely have to.