7 ms·

I'm living the Microservices nightmare every day at work! Every single function is a service and you have to run 40 docker containers to get something show up i

by msoad 10y ago

I'm living the Microservices nightmare every day at work! Every single function is a service and you have to run 40 docker containers to get something show up in your browser! If there is an issue in one those services it takes a long time to figure out which service was it and why it wasn't throwing a 500 error. Even if they throw 500 status codes you still don't get the nice line number and stack trace in a large application gives you. I think the whole microservices thing is a mistake, I as a developer should not care how this application is running in production. I want to work on a large app and leave the deployment business to someone else. I get it that it's hard to scale a big application but it shouldn't be my concern. I miss the old .NET days where I could run the app on my machine...

PerfectElement 10y ago
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.
- threeseed 10y ago
  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.
  - rpeden 10y ago
    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.
- vacri 10y ago
  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)
threeseed 10y ago
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.
- matwood 10y ago
  > 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.
scrabble 10y ago
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.
- cubaia 10y ago
  > 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.
partycoder 10y ago
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?
lostcolony 10y ago
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.
- MildlySerious 10y ago
  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.
userbinator 10y ago
Have you tried advocating to change it? I know it's difficular particularly in "enterprisey" environments but sometimes someone will listen...
azinman2 10y ago
Sounds more like broken RPC than anything else. I believe grpc has solutions for parts of this, certainly vanadium (v.io) does as well.

by msoad 10y ago

PerfectElement 10y ago

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.

threeseed 10y ago
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.
- rpeden 10y ago
  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.
vacri 10y ago
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)

threeseed 10y ago

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.

matwood 10y ago
> 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.

scrabble 10y ago

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.

cubaia 10y ago
> 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.

partycoder 10y ago

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?

lostcolony 10y ago

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.

MildlySerious 10y ago
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.

userbinator 10y ago

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

azinman2 10y ago

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