|
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. |