Comment by vidarh | Hacker News Reader

Comment by vidarh | Hacker News Reader

Parent Full thread

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.

That sounds ideal when you say it like that. The reality is often far removed in my experience, with services calling back and forth hither and thither, which is to say that all you've done is taken the spaghetti that often characterises enterprise software and stretched it out a bit in places. And in so doing what you've done is add a bunch of latency.

The one virtue of the former, non-microservice, situation is that at least you don't have the latency overhead because all that spaghetti is contained in one, or a small number of, processes, rather than spread around all over the place between a large number of processes and instances.

I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces.

Just my two cents, and obviously not a trendy point of view.

I'd be quite interested to see how Martin Fowler's view changes over the next 11 years, assuming he doesn't retire.

And if they do call back and forth, then all of the advice Fowler gave in the initial article still holds. So my point is his earlier views are for the most part not in contradiction with the microservices patterns - if anything, the latter is a evolution of the former, and the combination can basically be distilled down to:

If you must/want to split, split along service boundaries where communication is mostly with the client, and minimise communications surfaces between services. If you do that, you gain ability to scale services separately, and develop them separately.

If there are lots of interdependencies, you have bought yourself lots of latency and reliability issues for little gain elsewhere.

> I'm not saying it's ideal but people who write crap software in monolithic form are only going to do a worse job when faced with the additional complexity of having it all chopped up into little pieces.

I agree with that, and those people should probably start with articles like the linked one to learn to think about latency issues first.

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.

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.

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.

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.

Exactly. I've seen many monoliths which were bloated with pieces of functionality developed for specific needs that other parts of the company had. So your shopping cart API would get promocodes, and coupons, and express delivery, donation offers, credit card selection, support for legacy authentication and so on. And then you had to convert this behemoth from Java 5 or PHP 5 into something modern, but it ended up being too messy and you're stuck.

Yes, implementing all these features as microservice won't simplify the architecture, but you'll at least be able to easily migrate upgrade, remove, replace or scale up pieces of it.

> you'll at least be able to easily migrate upgrade, remove, replace or scale up pieces of it

IMHO, you're painting a very rosy picture here. There is a big assumption that you will want to preserve existing interfaces (REST APIs?) between those microservices. In reality, they probably will be bloated and obsolete just like everything else you have.

And being forced to update "microservice" at a time rather than as a whole, the whole process will actually become more complicated.

Consider that the application generally includes includes a client element that has to communicate with the services via HTTP anyway. In that case it often makes little difference if they communicate with a single app or 10. Often you can hide that it is communicating with more than one with a simple load balancer in front of the services.

If the microservices has to do lots of internal communication using HTTP, then you should consider if you've split them along the right boundaries or not.

Sometimes it may not be avoidable, but if there are lots of dependencies between them, then the rationale for splitting them into separate services rapidly drops.

The two things you quote are consistent assuming the services are mostly independent on the server side and it is the client that handles the coordination.

> The two things you quote are consistent assuming the services are mostly independent on the server side and it is the client that handles the coordination.

And if this assumption ceases to hold during the life of the product? For example, I might suddenly want to do some of the client calls from within the server. What then, you scrap the microservice architecture and rebuild it as a monolith? To me this looks really contrary to YAGNI principle.

Also, I think handling coordination between internal application stuff on the client is a security can of worms. You are exposing your client to information that he would never see if everything was hidden behind one service.

Reply on news.ycombinator.com