Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> it is better to just de-centralize

Until you want to join and then all of sudden it's not your problem. Then you end up with a "gang" of cowboy analysts running ad-hoc data-dumps against operational datastores affecting production uptime and stability only so that they can do a lookup between the multiple (source_table_column_count * source_table_row_count) sheets in their uber excel document.

I'm all for decomposing the monolith as long as you have a plan for recomposing when it's necessary.



Yep, thats why I said centralizing makes sense -- up until some price point. Beyond that point, you might as well just spend the money on re-composing when you need.


It's not just the technical costs of recomposing to achieve a jaoin; it's also diversity of this kind makes long-term maintenance a nightmare, and moving people/functionality/whatever between apps almost impossible.

If everybody cowboys their own storage, you're risking building up a legacy cruft that's very hard to work your way out of later.

The costs if recomposing later can be prohibitive, if a few particularly poor choices were made early on, and the hidden costs of inflexibility can bite too.

There's nothing wrong with outsourcing storage; that's not the issue - the issue is the culture in which it's easier to just not talk to the rest of the company (assuming the company is small enough to have any kind of cohesion in the firs place). If it's too expensive to talk (or even pick from a few common defaults) beforehand, how are you ever going to interop later on? You're getting the downsides of a large organization without the upsides.


Fair point! Sorry I missed that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: