[kaio]

This article seems a bit arrogant. But I have to acknowledge that they pioneered the trend of microservices in terms of overcomplicated designs and slowness.

Honestly. Some of the most horrifying systems I have worked with were based on the idea that you should be able to swap implementations during runtime. That was the time when OSGi was the thing and (like mentioned in the article) there seem to be only a few how to use OSGi properly. I'm a burned child and certainly don't have the knowledge, either ...but the blog post doesn't give a single reason to change that.

[userbinator]

OSGi is essentially classic bureaucractic enterprise-ism meets OOP dogma cult, and like all "hyperabstraction" in general, greatly decreases systems-level understanding and macro-simplicity (critically important for things like debugging) in order to favour micro-simplicity. To sum it up, "splitting a system into easier to understand parts until each part is trivially understandable causes the actual complexity to become hidden between the interaction of the parts."

[twic]

To sum it up, "splitting a system into easier to understand parts until each part is trivially understandable causes the actual complexity to become hidden between the interaction of the parts."

Is that in quotes because it's a quote? If so, from where? Or is this a form of emphasis?

[userbinator]

I'm not sure. Me and my coworkers have been saying similar things for a while, and it's not really that deep of an observation. Abstraction can't always magically make things easier. It just moves the complexity around, and often increases it if used unnecessarily.

[twic]

Right, it's very similar to things i've said too, but clearly and succinctly put!

I see a similar problem with the common preference for unit tests over integration tests. The mistakes in a system tend to be in the interactions between parts, not in the parts themselves, and by construction, unit tests can't test those.

[gfodor]

If this were printed on a wall somewhere at my first job it probably would have accelerated my career by a decade or so.

[taeric]

As the sibling posts say, that is a great quote and insight. I'm curious if you have more exploring the idea?

[hangonhn]

Yeah. Same here. I worked with OSGi long before I used REST and microservices. To claim that OSGi somehow pioneered this stuff is both arrogant and ignorant. Sure OSGi and microservices share some similar concepts but they are both implementing ideas commonly found in distributed systems. The author just comes across as bitter. I liked OSGi when I first encountered it but for some of my colleagues it was a lot of overhead to do the simplest things. Either they had to learn it all conceptually or they have to rely on a lot of magic from the tooling. I feel that to really understand OSGi you had to know a bit about the nuts and bolts of Java and its internals. This is not common especially even among Java programmers. The advantage of REST microservices is that most developers understand REST and HTTP, etc. People have a much easier time getting REST and microservices (although you really need to know distributed systems to not get yourself into trouble with some boundary cases and failure modes).

[chrisseaton]

> Some of the most horrifying systems I have worked with were based on the idea that you should be able to swap implementations during runtime.

And it's usually such an unnecessary feature!

There's nothing that makes me fear for a project's future more than when they get to the 'we'll make everything a plugin' phase.

[baylisscg]

Yeah, It implies bad things about the expected performance of the JVM or the quality of the application being run. Either startup time or the time taken for the JIT to get a handle on things is apocalyptically bad.

[lallysingh]

A bit? Like there weren't similar systems years before osgi.

Frankly, the fact that osgi solved an important problem and people still don't use it indicates a failure, not a success.