3 ms·
But then 10 years down the line you'll be scrambling to implement Master Data Management, where you'll try (unsuccessfully) to merge user profiles and data. I'
by BenoitP 5y ago
But then 10 years down the line you'll be scrambling to implement Master Data Management, where you'll try (unsuccessfully) to merge user profiles and data.
I'm very anti-microservices, and rather than implement them for organizational reasons (read: teams unable to work together), I think that the most important business objects need to be maintained at a single point. Managing user identity at a single point is a valid reasons for microservices; like Google does with gmail/search/drive/storage/cloud services/youtube/android/etc.
- fn1 5y ago> where you'll try (unsuccessfully) to merge user profiles and data. Why? Can't a monolith be refactored?
- BenoitP 5y agoI was talking about each silo of data; which is orthogonal to each monolith's code being refactorable. > If each business unit/domain has their own "monolith" This furiously looks like accidental microserviced data; which is kind of ironic considering the original comment was about "Avoid microservices entirely". And yes, important business objects managed by different microservices are a PITA to merge; basically you're going to ask the users themselves to merge profiles, and they'll answer "we're divorced now" / "I like it better having multiple accounts, I get more promo codes" / "Why should I?" / "I don't care" / "Who are you?".
- fouc 5y agoIs that a microservice though? That sounds more like a proper service.