21–30 of 136 posts
Things like these are taken as dogma or a religion -- and are applied to all things in an organization, for better or for worse. When there's a case for tighter coupling and less services, (and yes, there are cases for it), this memo gets brought up and microservices win the argument.
> Anyone who doesn’t do this will be fired. > Thank you; have a nice day! What a colossal twat.
Always worth reading Yegge's insider take on this - https://gist.github.com/chitchcock/1281611 . The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be t…
Which is a big ask, since
> The problem is that we are trying to predict what people want and deliver it for them. You can't do that.
My business area uses around 200 repositories. APIs aren’t really optional at that scale.
Things like these are taken as dogma or a religion -- and are applied to all things in an organization, for better or for worse. When there's a case for tighter coupling and less services, (and yes, there are cases for it), this memo gets brought up and microservices win the argument.
What is an organizational case for tighter coupling and fewer services? Downsizing with an intent to not grow in the same direction again?
If you have a team of 5 people, launching 50 services is probably not as efficient as 10 services.
You'll have every engineer complaining and stop working to fight their freedom and finally the change has to be reverted. And 5 years later, oh my god, Amazon is doing that, we need to move to that direction as well...
If every part of Amazon is really like that, then it'll make the task of breaking them up much easier!
I wonder how this is accomplished for event driven architectures built on shared event buses.