https://docs.undo.io/java/Microservices.html
[Edit: for which, by the way, any feedback is welcome - it's technically quite promising but real world experience is worth a lot!]
They don't need to be microservices in order to isolate dependencies, do they?
In Python, for instance, you don't even need containers. Just different virtual environments running on separate processes.
You just invented microservices, lol.
That said, almost always, if you are seriously trying to keep old unsupported dependencies running, you’re violating any reasonable security stance.
I’m not saying it never happens, but often the issues that the code is not understood, and no one is capable of supporting it, and so you are deep in the shit already.
Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)
I think in these discussions, a lot of times people are taking past one another. If I start putting a JRE-targeted application together, I know I can eventually reach for isolated modules if I follow good internal practices, whereas if I'm in Python land it's pretty unattainable.
OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.
OSGi has an in-VM service registry which allows late binding of "services" by interface. This means you can do a lot of sophisticated mixing and matching of capabilities with OSGi, including the ability to load and use incompatible versions of the same library (if need be) in different parts of your code.
More than a decade ago, I built an app server system that used an OSGi base for server-side products and agent systems. I even had a flavor of JBoss running on OSGi (with dramatically faster start up times) before JBoss went OSGi on its own.
But now my teams do their work in Node. Isolation is by process, hopefully, maybe, and we're right smack back in version hell.
Can you actually use them to use two different versions of library C in the same application yet though?
> Eclipse keeps using OSGi just fine
Wasn't the impression I had the last time I tried to fix a bug in an eclipse plugin that touched on the OSGi parts. The codebase felt like a ghost town and I couldn't find any documentation for how it all worked or anyone who knew about it.
Nope, this is functionality that Java (and thus, the module system) does not (yet) provide.
You are correct. As of now, Java Modules have no way to disambiguate versions of the same dependency. This is intentional and by design.
As far as Java is concerned, each class is uniquely identified by ModuleName.PackageName.ClassName. So, if there are 2 versions of the same class that have the same identifier, Java will give you an error at compile/link/run-time.
And if you try to be clever and slap a number at the end of the module name (in hopes of side-stepping this), Java will throw a warning at you, saying that you are likely trying to misuse modules by trying to use them to do dependency management.
If you have to do X,Y,Z to get A done, then you'll do X,Y,Z.
If your language gives you a shortcut and now you can get away with X,Y then you'll drop Z.
And even if your language doesn't give you those shortcuts, if Cool Language lets you do just X or X,Y, you'll naturally want to use Cool Language. So, its a losing game...
KISS is great when applied correctly, but you have to be able to know the level of complexity you'll actually need for the problem at hand, and it is so so very easy to over or under engineer something...
Also JNI won't be isolated which occasionally might be a factor (more likely for stability).
On the other hand one could make colocated multi-process services to work around this while avoiding all the other complexities of microservices.
Hold on - the way you are phrasing this implies that Java Modules allow you to solve the version problem mentioned above. As in, your comment implies that Java Modules have a concept of version, and thus, allow you to pick the correct version of a dependency when defining relationships.
Java Modules explicitly DO NOT have that ability. In fact, the creators of modules went out of their way to discourage the idea of using modules this way. They literally introduced a warning that flags your module if you add a number at the end of it - specifically so that they can discourage the concept of introducing versions into the module system.
The way Java Modules (and Java Classpath before it) works is like this - if you have a module ABC, then that is the only version of ABC as far as Java is concerned. The correct version should be decided upon and provided, but once you hand that version over to Java and press compile/link/run/etc, the concept of version is not existent anymore, as far as Java is concerned.
To better explain this, every Java class has a unique identifier -- the module name + the package name + the class name. That's it. So, if I have version 1 of ModuleName.PackageName.ABC and version 2 of ModuleName.PackageName.ABC, there is no way for Java to disambiguate them, and thus, will throw a compilation/linking/runtime error, saying that you have 2 versions of ABC.
And to further expand on the warning point above, some clever developers tried to work around this by putting the version number in the name somehow (for example, module name = ModuleName1). To firmly discourage this behaviour, the Java developers who made modules released the abovementioned warning, so that this problem could be nipped in the bud.
To summarize, dependency versioning is a problem that Java (currently) does not attempt to solve. It's considered an extra-linguistic concern that is left to the ecosystem to solve (which you should interpret it to mean, they're letting Maven/Gradle/etc deal with this problem (for now)).
Finally, a few members of the Java team are giving some thought to maybe dealing with this problem in the language, maybe with a build tool. There is absolutely 0 confirmation that this will even be given serious effort, let alone released as a feature/tool. But the problem is definitely being considered by some members of the Java Team. In fact, a user on this site (pron) may be able to give some helpful context on this. This is my first comment on this site, and I don't know how to use it, so someone else can try and link him.
Correct me if I'm wrong, but isn't "microservices" when you make internal components into services by default, instead of defaulting to making a library or class?
One way to mitigate the growing pains of a monolithic backend is to split it into a set of independently deployable services that communicate via APIs. The APIs decouple the services from each other by creating boundaries that are hard to violate, unlike the ones between components running in the same process
We just go from 'one' to 'too many' as equally unworkable solutions to all of our problems, and each side (and each person currently subscribed to that 'side') knows the other side is wrong. The assumption is that this means their side is right instead of reality, which is nobody is right.
The moderates are right, but their answers are wiggly and they're too busy getting stuff done to argue with the purists. But the optics are bad so here we go again on another swing of the swingset.
'Some Services' is probably right, but it varies with domain, company size, and company structure (Conway's Law). And honestly developer maturity, so while 7 may be right for me and my peers today, in a year it might be 6, or 9. There's no clever soundbite to parrot.
Going to definitely yoink it for next time I have this discussion. It applies to so many things!
Introducing the Revolutionary "Ten Service Applications" – because Ten is the Magic Number!
Tired of the endless debates about how many services your applications should have? Frustrated with the constant struggle to find the "Goldilocks" number of services? Look no further! The future of software design is here, and it's as easy as 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10!
The "Ten Service Applications" model is here to rescue you from your software design woes. We're not messing around with random numbers like 7 or 12 services. No, we've cracked the code, and it's all about that perfect "ten." You don't need any more services, and you definitely don't need any less. Ten is the answer to all your architectural problems!
So, are you ready to embrace the simplicity, predictability, and coolness of the "Ten Service Applications" model? Join the revolution today and experience software development like never before!
Act now, and we'll even throw in a bonus "Top 10 Services" list to inspire your next project. But remember, you only get 10 services, no more, no less—because why mess with perfection?
The book isn't perfect. The use of afferent and efferent terminology and some of the arbitrary methods to put numbers on decisions weren't ideal. Most of the concepts are sound. The fact that almost every decision has cost/benefit and real world implications for a living product was refreshing. That a monolith can't be cut over instantly with zero effort to a perfect system is absolutely true.
It's good food for thought for anyone considering slicing up a monolith, but maybe don't follow it to the letter.
They don't seem to understand there's a useful middleground of adding fewer, larger data services, etc. It's like SOA isn't a hot topic so people aren't aware of it.
But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)
The best company I worked at had about 5-10 deployable per engineers on average and it worked really well. They were small, deployed almost instantly, dependencies were straightforward, etc.
Monoliths work fine too, it's just different tradeoffs.
Though to understand why this is, you would have to know just how poorly our monolith was designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” and suddenly you end up with this huge spiderweb mess of a database that nobody knows who pulls what from because everyone has connected some sort of thing to it and now your monolith isn’t really a monolith because of it. Which isn’t how a monolith is supposed to work, but is somehow always how it ends up working anyway.
I do agree though, that the “DevOps” space for “medium-non-software-development” IT departments in larger companies is just terrible. We ended up outsourcing it, sort of, so that our regular IT operations partner (the ones which also help with networking, storage, backups, security and so on) also handle the management part of our managed Kubernetes cluster. So that once something leaves the build pipeline, it’s theirs. Which was surprisingly cheap by the way.
I do get where you’re coming from of course. If we had wanted to do it ourselves, we’d likely need to write “infrastructure as code” that was twice the size of the actual services we deploy.
I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith.
More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually finally invest in fixing things.
Perhaps your microservice rewrite goes well because you now know your domain after building the monolith, that is another option.
If you gave me total control over everything, I’d probably build a couple of monoliths with some shared modules. But every time the data is centralised, it always somehow ends up being a total mess. With MicroServices you’ll still end up with a total mess in parts of the organisation, but at least it’ll be in something like PowerBI or even your datawarehouse and not directly in your master data.
Or to put it differently, for me MicroServices vs monoliths is all most completely an organisational question and not a technical one.
I struggle to see how microservices fix this for people; having worked primarily with them for the past 6 years.
Unless it's a shared library, which is why good microservices architecture limit the shared surface as much as possible.
This still happens with microservices though; people can still make terrible architecture decisions and standup terrible services you depend on.
Yes, by the time you get to thousands of services you hopefully have moved past the distributed monololith, if you built one.
I called ours a macrolith.
In the end, i like the viewpoint that microservices are a deployment pattern, not so much an architecture pattern. Usually, you can draw a component diagram (containing an OrderService and a DeliveryService, etc.) and without technical details (execution environment, protocols), you couldn't tell if it's describing multiple microservices or multiple components in one service.
I’m a fan of microservices btw.
Premature optimization and scaling is almost as bad of a form of technical debt as others when you have to optimize in a completely different manner and direction.
Being able to easily use different programming languages. Not every language is a good fit for every problem. Being able to write your machine learning deduction services in Python, your server side rendered UI in Rails and your IO and concurrency heavy services in Go might justify the additional overhead of having separate services for these three.
Due diligence in these cases is rare.
That said, as the article also mentions, "micro" can be a bit of a misnomer; you could have a 50 person team working on a single "micro" service, in which case things like hiring and training are much more natural. (to add, I've never worked in a team of 50 on one product; 50 people is A Lot)
Never again. When I build teams forevermore, I pick the tech stack and I recruit people who know that tech stack, or want to learn that tech stack. And we stick to that tech stack whenever possible.
I didn’t know how to troubleshoot Node, but I did know how to read docs. Suddenly I can troubleshoot Node. Hooray.
I concur with your sentiment, and would also be an absolute dictator for tech stack and workload management. We’re not using Node, we’re avoiding React if at all possible, every dev touching the DB in any way will know SQL, and no one is using Scrum.
Even with just one, it isn't really a single one.
To pick on JS as example, not only there is JavaScript to learn, TypeScript might also be part of the stack, then there is the whole browser stack, and eventually node ecosystem as well.
Take the remaining UNIX/Windows related knowledge to get development and deployment into production going, SQL and the related stored procedures syntax for RDMS backends.
Eventually the need to know either C or C++, to contribute to V8 native extensions or WASM.
Now those folks need to learn about Go, Go's standard tooling, Go's ecosystem, IDE or programmer's editor customizations for Go code, and how to approach all the development workflows they are confortable of from the point of view of a Go developer.
You should always look into existing languages first. There's a lot of "I rewrote this thing into $language for a 100x performance boost" posts, in a lot of cases the comments are like "Yeah but if you rewrote it in the original language you could make it a lot faster too".
For a cool visualisation of this problem, check out https://boringtechnology.club/
1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing
2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment that have different priorities/sensitive business hours time windows
3) system design decisions that cannot be abstracted away are at the mercy of some large clients of the company that are unable or unwilling to change their way of doing things - you can silo the pain.
And to be clear, it's not that these things are "cost free". It's just a cost that is worth paying to protect the simpler monolith from becoming crap encrusted, disrupted with risky deploys, or constrained by business partners with worse tech stacks.