5 ms·
Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization. They encourage modular patterns whi
by rapind 5y ago
Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization.
They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.
- steve_taylor 5y agoOSGi was supposed to solve this problem. You could start by running all bundles together in the same JVM, then split them across a cluster later if required. But it never quite took off beyond an implementation detail of various application servers.
- kavalg 5y agoOSGi was a horrible dev experience. Lots of quirks and legacy. Nobody wants to maintain that code anymore.
- sackerhews 5y ago> horrible dev experience That's an understatement. It was soul destroying awfulness.
- throwaway1777 5y agoExample of better language modularization? Who is working on this?
- Znafon 5y agoPerhaps some idea and abstractions from Erlang could be interesting to explore in more mainstream languages?
- davedx 5y agoYeah erlang is great
- trixie_ 5y agoPHP, hear me out, each file is basically an independent hot swappable 'service'. I wish more languages/compilers/runtimes had a similar capability.
- diordiderot 5y agoCould you explain this more??
- KronisLV 5y ago> PHP, hear me out, each file is basically an independent hot swappable 'service'. I think that what the OP is referring to is the fact that you can map URLs to PHP files pretty easily and therefore changing what an endpoint does can be as simple as just swapping out a single file for another one. However, that tends to fall apart with most modern frameworks, like Symfony, Laravel, Lumen and Slim, where you will typically invoke a main application file which deals with all of the bootstrapping first (reading configuration, DB connections, logging etc.) and then will hand off control over to a router, which will usually map to a controller of some sort, which may have the actual business/view logic spread over other referenced files, the way as other similar technologies like (Ruby on Rails) do it. Of course, that's not a bad thing, especially since it allows you to follow some of the RESTful conventions, like having path variables without doing rewrites at the web server level, such as /users/12345/photos versus /users/photos.php?id=12345 That said, the whole "mostly single file, maybe with a few common imports" approach can also work fine, as long as your endpoints are kept relatively small. I haven't seen it scale up to large projects that well, at least most of the time.
- diordiderot 5y agoThanks for the reply!
- beefsack 5y agoEven with language modularisation you lose the ability to provision modules independently if they are bundled together in a single service. Microservices and monoliths are opposing extremes on a scale. There is a range somewhere in the middle which is entirely sensible. I feel like I've found my greatest success with my service abstractions by separating things out based on resource and availability needs of the functionality.
- brightstep 5y agoIf you maintain the same interface (same classes, methods, types, etc) it seems to me a module ought to be hot-reloadable within the same process. This is already possible with a loosely-coupled plugin architecture and I could see it being an integrated part of a language.