I've worked in monoliths, and I've worked with good logically thought out microservices. I'll take the open source microservices model with a good dev team any day of the week.

I can't imagine being in a place where I don't care about how my code runs in production or scales.

> I'll take the open source microservices model with a good dev team any day of the week.

Whether it's monolith or whatnot, what you really want is the "good dev team" part.

If you have to run them all together to get useful, testable functionality, then all you (they) have done is written a -badly designed- monolith (an overly complex, distributed one). Not a bunch of microservices.

Great way to put it. The very definition of a microservice is that it does ONE thing independently of others. The number of dependencies should be kept as low and to as few points as possible.

I've lived the Monolithic nightmare as well. Dozens and dozens of "utility" functions that got reused between unrelated modules, worrying amounts of copy/paste due to leaky abstractions and a build time of an hour even if you're just working on a small part. Not to mention having to run automated tests across the entire codebase just in case some developer has unexpectedly relied on your class.

And in your case I don't know what you can't get the line number and stack trace from a microservice. Likewise you can get tracing between microservices using something like Zipkin.

Personally I think the "truth" lies in between. Bigger services that cover key functional areas.

> Personally I think the "truth" lies in between. Bigger services that cover key functional areas.

This. What the GP was talking about is something like nano-services. Who really writes a whole service stack for every function?

In addition to functional areas, I also like a service when a single job needs to get done. For example, read message from queue, do some processing, put result somewhere. The beauty of the service here is I can write it once, test it, deploy and it just works. I don't have to worry about it randomly getting broken from code changes in a larger monolith.

Those days are not gone. Outside of the HN bubble there's still a lot of successful monolithic application development going on. Not every project needs to scale to the size of Twitter.

From what I've seen it's about 50/50 these days. Most of the monolithic applications still around are legacy J2EE or Ruby on Rails.

People seem to forget that microservices isn't new. It's just SOA all over again.

I believe that a huge amount of SOA in production wouldn't qualify as microservices - especially enterprise SOA.

Heck, I'd bet a lot of enterprise SOA is just a giant crufty monolith with a bunch of its functionality exposed via service endpoints. I suppose that a pretty decent approach - add endpoints to a monolith. As long as the service interfaces remain the same, you can bust it up into as many medium or micro sized services as are necessary on the back end and the users of your services won't notice the difference.

You can also mix'n'match. Have a monolithic entity that does most of the work, and split out the heavy stuff into it's own microservice which can be independently scaled.

(Sub in any other reason to separate a service for 'heavy stuff' - written in a more appropriate language for the function, etc)

Have you tried advocating to change it? I know it's difficular particularly in "enterprisey" environments but sometimes someone will listen...

Sounds more like broken RPC than anything else. I believe grpc has solutions for parts of this, certainly vanadium (v.io) does as well.

You should be able to work on one microservice at a time, run tests on them, and then wrap things up and work on another one. If you need to work on all of them at the same time that means that you managed to couple them together. In that case they're no longer true microservices, just spaghetti.

Then, with .NET it is much easier to end up with gigantic spaghetti solutions with projects that are all coupled to each other.

Coupling is the problem, learn to control coupling. If everything needs to know about everything, how do you expect to have a team that is capable of maintaining that?