4 ms·

Engineering is about trade offs. Microservices are a fairly recent innovation, and there are many kinks that need to be worked out. Another issue is the overhea

Engineering is about trade offs. Microservices are a fairly recent innovation, and there are many kinks that need to be worked out. Another issue is the overhead cost of maintaining a large number of decoupled, independent services. It's plausible to have hundreds or thousands of microservices, and the tools to visualize/manage these systems haven't yet been created.

erichocean 10y ago
> Microservices are a fairly recent innovation Yeah, no. Micro-services are neither recent, nor innovative. Fun fact: a friend of my consults for large pensions funds in The Netherlands. One of the projects he was brought in on earlier this year to get an outside perspective on was this gigantic monument to micro-services that had been built up over a two year period by ~200 developers, at a cost of around 50 million euros. After two months, every developer was fired, the project cancelled, and the entire 50 million euro cost written off. But it had great micro-services, hundreds and hundreds of them!
- austingunter 10y ago
  Correct. Microservices are a fundamental tenant of how Unix pipelines. They go back (at least) to the 70s. Source: https://articles.microservices.com/the-origins-of-microservices-706d65a8acab https://articles.microservices.com/the-origins-of-microservi...
- chadcmulligan 10y ago
  they are to the kids who make web apps - most of this stuff they talk about on the internet is by kids who make web pages for start ups. I used to rant and say similar things, I now see the value of peer reviewed material. Basically 90% of developers advocating things on the internet are not peers, I look for how many projects they've developed successfully in the new gee whiz tech before reading too much. Really most of this stuff was originally thought of in the 70's and 80's, we just keep going in circles.
hinkley 10y ago
I'm often in the minority opinion so I'm used to it, but to me microservices aren't fundamentally different than the message passing systems which we've tried many times. But when something doesn't work we try the opposite of it instead of just less or more. Monolithic server got you down? MICROSERVICES. Microservices got you down? Put everything into one process space! Uh, how about we put all of the related stuff together so we have 8 services instead of 800? Could we maybe try that? How about something really crazy, why don't we give Conway's Law a try and arrange our code around organizational boundaries or vice versa?
tormeh 10y ago
Tell me about it. The problem is moving parts. Whether you spread it out over several programs or not does not matter. If you manage to really decouple programs so they can do useful work independently of one another then that's great. Congratulations to you. But microservices can just as easily turn into one huge program separated into many small ones, none of which make any sense on its own, and now all you've done is make things harder for devops.
- hinkley 10y ago
  I heard a phrase a couple months ago that I believe sums this up. What you want is local reasoning. You need to be able to estimate the scope of consequences of a change so you can act accordingly. You also need to be able to look at a problem and estimate the scope of code that could be causing the problem. We have a bunch of rules and guidelines that work toward that goal but if you don't know the destination you may never arrive.

erichocean 10y ago

> Microservices are a fairly recent innovation Yeah, no. Micro-services are neither recent, nor innovative. Fun fact: a friend of my consults for large pensions funds in The Netherlands. One of the projects he was brought in on earlier this year to get an outside perspective on was this gigantic monument to micro-services that had been built up over a two year period by ~200 developers, at a cost of around 50 million euros. After two months, every developer was fired, the project cancelled, and the entire 50 million euro cost written off. But it had great micro-services, hundreds and hundreds of them!

austingunter 10y ago
Correct. Microservices are a fundamental tenant of how Unix pipelines. They go back (at least) to the 70s. Source: https://articles.microservices.com/the-origins-of-microservices-706d65a8acab https://articles.microservices.com/the-origins-of-microservi...
chadcmulligan 10y ago
they are to the kids who make web apps - most of this stuff they talk about on the internet is by kids who make web pages for start ups. I used to rant and say similar things, I now see the value of peer reviewed material. Basically 90% of developers advocating things on the internet are not peers, I look for how many projects they've developed successfully in the new gee whiz tech before reading too much. Really most of this stuff was originally thought of in the 70's and 80's, we just keep going in circles.

hinkley 10y ago

I'm often in the minority opinion so I'm used to it, but to me microservices aren't fundamentally different than the message passing systems which we've tried many times. But when something doesn't work we try the opposite of it instead of just less or more. Monolithic server got you down? MICROSERVICES. Microservices got you down? Put everything into one process space! Uh, how about we put all of the related stuff together so we have 8 services instead of 800? Could we maybe try that? How about something really crazy, why don't we give Conway's Law a try and arrange our code around organizational boundaries or vice versa?

tormeh 10y ago

Tell me about it. The problem is moving parts. Whether you spread it out over several programs or not does not matter. If you manage to really decouple programs so they can do useful work independently of one another then that's great. Congratulations to you. But microservices can just as easily turn into one huge program separated into many small ones, none of which make any sense on its own, and now all you've done is make things harder for devops.

hinkley 10y ago
I heard a phrase a couple months ago that I believe sums this up. What you want is local reasoning. You need to be able to estimate the scope of consequences of a change so you can act accordingly. You also need to be able to look at a problem and estimate the scope of code that could be causing the problem. We have a bunch of rules and guidelines that work toward that goal but if you don't know the destination you may never arrive.