
Errant Architectures (2003) - lnolte
http://www.drdobbs.com/errant-architectures/184414966
======
klochner
His take on microservices, 11 years later:

[https://martinfowler.com/articles/microservices.html](https://martinfowler.com/articles/microservices.html)

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

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

------
js8
Is this an April Fools' joke or not? If it is, can someone explain the joke?
If it is not, it seems to me that it contradicts with the current "wisdom" of
microservices.

~~~
vidarh
It doesn't contradict that much of it. Consider that the context was an
environment where people tried to shove CORBA down our throats and insist it
didn't matter where the objects lived (apparently latency wasn't a thing). He
is arguing against distributing objects along class boundaries or similar
granualr splits, and to avoid distribution internally in a backend service
when possible.

Microservices, meanwhile is a reaction to ballooning applications,
increasingly containing many orthogonal services / APIs, and in favour of
splitting them up, with common advice seeking to avoid splitting on boundaries
that will require coordination between the resulting services.

Microservices takes the consequence of the problems Fowler complains about in
the linked article by trying to split applications into individual services
while keeping interdependencies minimal, so that we ideally only pay the
latency cost at the user<->service boundary where we have to pay it anyway,
instead of all over the system, which was one of the major ongoing problems
with the CORBA craze.

~~~
js8
I don't understand. If I compare this (courtesy of klochner):

"In short, the microservice architectural style [1] is an approach to
developing a single application as a suite of small services, each running in
its own process and communicating with lightweight mechanisms, often an HTTP
resource API. These services are built around business capabilities and
independently deployable by fully automated deployment machinery. There is a
bare minimum of centralized management of these services, which may be written
in different programming languages and use different data storage
technologies."

To this:

"Distributing an application by putting different components on different
nodes sounds like a good idea, but the performance cost is steep. [..] How,
then, do you effectively use multiple processors? In most cases, the way to go
is clustering (see “A Better Way”). Put all the classes into a single process
and then run multiple copies of that process on the various nodes."

It looks like a direct contradiction. Personally, I think microservices are
indeed a bit crazy and the latter is a good advice, but I am no MF.

~~~
tcopeland
To me microservices work when you split out things that the core app doesn't
always need. So "promocodes" becomes its own microservice because not all
purchases need a promo code. And now the main app isn't cluttered with promo
code admin logic and UI.

~~~
joshmarlow
Another example that I'm fond of:

Central authentication service that authenticates on user login and passes
back and API token to be used to access other services. With something like a
JWT you don't need to check the User database for every API call.

~~~
vidarh
Exactly. This is how I see microservices as most valuable: When communication
is mediated by the client. And tokens can be great for that in all kinds of
circumstances to allow the client to mediate communications even when trust is
required.

