3 ms·

People talk about building monoliths like it’s some simpler alternative. On the JVM it’s not. When I first started with Java one of the coolest things was that

People talk about building monoliths like it’s some simpler alternative. On the JVM it’s not. When I first started with Java one of the coolest things was that I could embed anything. I could embed Elasticsearch in my web service. Wow! Forget services calling each other! I’ll prototype real quick with everything in one JVM! But that proved impossible! :( It turned out that until Java 9, the JVM has a single namespace for all loaded classes. For me this was the greatest driving force for building out smaller services. You had to be very careful about dependencies and couldn’t just include Elasticsearch—or even much of anything—in your web service even if you wanted to. You’d be in immediate unresolvable dependency hell. I can imagine the insane artifacts people produce when they try to build monoliths on the JVM. Even with JavaScript now you have one huge flat dependency namespace. Good luck building a monolith. I can only conclude that the all the people on this thread who are painting “monoliths” as some easy alternative developers are ignoring due to some inexplicable desire to make things complicated have no idea what they’re talking about.

corpMaverick 9y ago
I think the recommendation is Monolith First https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html You start with a Monolith and break it out as needed. (i.e. When you find out that is not a good idea to embed Elasticsearch ) You avoid premature boundaries that can become a significant constraint.
- linkmotif 9y ago
  My experience in attempting to build a monolith—and, oh I tried—was that it's basically impossible. Forget embedding Elasticsearch for the purpose of running it inside your monlith; just the transport layer drivers (supposing you're not using drivers that work over HTTP) basically add all of Elasticsearch onto your classpath. Good luck building your monolith after that. And that's true for so many things you'd want to use. If you want to build a monolith you basically can't have any dependencies. Or be very experienced in dependency management. This is why I have a microservice that fronts all my Elasticsearch queries. Its artifact has the Elasticsearch drivers, all other microservices that need access data from Elasticsearch talk to this service over gRPC. Any time I want to upgrade Elasticsearch or change something about a query, I only need to do it in one spot. It's great.

corpMaverick 9y ago

I think the recommendation is Monolith First https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html You start with a Monolith and break it out as needed. (i.e. When you find out that is not a good idea to embed Elasticsearch ) You avoid premature boundaries that can become a significant constraint.

linkmotif 9y ago
My experience in attempting to build a monolith—and, oh I tried—was that it's basically impossible. Forget embedding Elasticsearch for the purpose of running it inside your monlith; just the transport layer drivers (supposing you're not using drivers that work over HTTP) basically add all of Elasticsearch onto your classpath. Good luck building your monolith after that. And that's true for so many things you'd want to use. If you want to build a monolith you basically can't have any dependencies. Or be very experienced in dependency management. This is why I have a microservice that fronts all my Elasticsearch queries. Its artifact has the Elasticsearch drivers, all other microservices that need access data from Elasticsearch talk to this service over gRPC. Any time I want to upgrade Elasticsearch or change something about a query, I only need to do it in one spot. It's great.