3 ms·
I second this. You can internally build your monolith in a way that makes a transition to microservices easy. Avoid global state and build single concern proces
by caseymarquis 9y ago
I second this. You can internally build your monolith in a way that makes a transition to microservices easy. Avoid global state and build single concern processes which have their dependencies passed to them on creation.
- le-mark 9y agoAlso note that it is very, very difficult for anyone, inexperienced or experienced, to build a monolith that can later be pulled apart. You're two suggestions are a great start. You have to really design with the major blocks of functionality in mind, and carefully manage dependencies between these blocks AND third party dependencies. So many monoliths are balls of mud, that can't be pulled apart with any reasonable effort. The code may not be spaghetti, but the dependencies and interdependencies are.
- marcosdumay 9y agoHonestly, if one can not create a monolith that isn't a giant ball of mud, one has not chance at all of creating a distributed application, microservices or not, even ignoring quality.
- BjoernKW 9y agoIn that case one not unlikely ends up with an anti-pattern known as The Distributed Monolith, which combines the worst of both worlds.