Yes, it's hilarious because - and this isn't going to be a popular (and certainly not a trendy) point of view - you could almost literally take the phrase "distributed objects" from the original article and substitute it with the word "microservices" and otherwise republish it substantially unaltered to make the same points.
</snark>
I am currently working on one of these much vaunted microservices based systems and, let me tell you, there is not one aspect of it - not a single one - that does not suck a perpetually replenished conveyor belt of balls. Not one.
And, yes, performance is straight up dreadful. Sadly I cannot say more in order to protect the guilty.
I beg to differ. Microservices are certainly overhyped, but they aren't as bad as the ORBs of yore.
I see 3 key aspects which are entirely different:
1. Microservices do not necessarily encapsulate storage at object level. You could certainly do that (and naive acceptance of REST may encourage you to do that), but nothing about microservice architecture makes simply exposing your business object the default approach.
2. ORBs abstracted away the distribution model. Of course, this was they main selling point: your method calls could run in a shared library, or end up being sent to an entirely different server. You could start with one and move to other at will with minimal changes to your code. Microservices (and most web APIs in general) are diametrically opposed to this abstraction. Even with auto-generated REST clients, network boundaries are very explicit, and the wire interface is never left for a middleware to decide. Designers make conscious decisions whether to use JSON-API GraphQL or gRPC, whether gzipped JSON is enough for the wired format, or should they go with Protocol Buffers, or perhaps a high performance format like Cap'n Proto or FlatBuffers. Distribution is extremely explicit.
3. ORBs generally use some sort of object pointer, which is hard to scale and even harder to use for high availability. The general assumption was that objects could be stored in memory on one server, or perhaps be backed by a database, but the client code would have no way of knowing that. So you had to obtain a reference anyway, start operating on an object, and finally committing your changes (if you had transaction support at all). This means that you could not migrate an object instance from one server to another, and you couldn't even optimize writing all 30 columns in a DB entry at once, since proper OO design was to have a separate property for each column and to set each property individually.
CORBA and COM essentially forced you into a highly stateful OO model, but microservices don't. If microservices interact with state, it is rarely managed by directly by the microservice itself, so microservice instance are entirely interchangeable. You could even implement an entirely stateless microservice.
If you can replace the "distributed objects" from the original article and substitute it with the word "microservices" then your guilty party are doing microservices in a way Fowler was arguing against even for distributed objects all those years ago.
Doing microservices right involves taking the advice in the linked article: Avoid splitting services when there is no need to; certainly avoid splitting at object/class boundaries - split out functional units that require little communication between them (ideally, split only out things that can fully serve requests from the client, and mediate state in other ways, like e.g. authentatication tokens or signed state); think about latency.
It's about refining the thinking about when it is right to split services up and how to do it without falling in the "CORBA trap" where people tried to make objects metaphorically "floating around the network" for now good reason.
bartread|9 years ago
</snark>
I am currently working on one of these much vaunted microservices based systems and, let me tell you, there is not one aspect of it - not a single one - that does not suck a perpetually replenished conveyor belt of balls. Not one.
And, yes, performance is straight up dreadful. Sadly I cannot say more in order to protect the guilty.
unscaled|9 years ago
1. Microservices do not necessarily encapsulate storage at object level. You could certainly do that (and naive acceptance of REST may encourage you to do that), but nothing about microservice architecture makes simply exposing your business object the default approach.
2. ORBs abstracted away the distribution model. Of course, this was they main selling point: your method calls could run in a shared library, or end up being sent to an entirely different server. You could start with one and move to other at will with minimal changes to your code. Microservices (and most web APIs in general) are diametrically opposed to this abstraction. Even with auto-generated REST clients, network boundaries are very explicit, and the wire interface is never left for a middleware to decide. Designers make conscious decisions whether to use JSON-API GraphQL or gRPC, whether gzipped JSON is enough for the wired format, or should they go with Protocol Buffers, or perhaps a high performance format like Cap'n Proto or FlatBuffers. Distribution is extremely explicit.
3. ORBs generally use some sort of object pointer, which is hard to scale and even harder to use for high availability. The general assumption was that objects could be stored in memory on one server, or perhaps be backed by a database, but the client code would have no way of knowing that. So you had to obtain a reference anyway, start operating on an object, and finally committing your changes (if you had transaction support at all). This means that you could not migrate an object instance from one server to another, and you couldn't even optimize writing all 30 columns in a DB entry at once, since proper OO design was to have a separate property for each column and to set each property individually.
CORBA and COM essentially forced you into a highly stateful OO model, but microservices don't. If microservices interact with state, it is rarely managed by directly by the microservice itself, so microservice instance are entirely interchangeable. You could even implement an entirely stateless microservice.
vidarh|9 years ago
Doing microservices right involves taking the advice in the linked article: Avoid splitting services when there is no need to; certainly avoid splitting at object/class boundaries - split out functional units that require little communication between them (ideally, split only out things that can fully serve requests from the client, and mediate state in other ways, like e.g. authentatication tokens or signed state); think about latency.
It's about refining the thinking about when it is right to split services up and how to do it without falling in the "CORBA trap" where people tried to make objects metaphorically "floating around the network" for now good reason.