Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices and the migrating Unix philosophy

redmonk.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Microservices and the migrating Unix philosophy

#11

Post by pjmlp »

joe_the_user wrote: post #9
pjmlp wrote: post #6

Earlier quoted context omitted.

> They've not read Brooks enough. They never do. It is incredible how those mistakes keep being repeated.

I don't think you can quite call these patterns of failure mistakes. They are effective, reliable way to get certain things up and running in a given time frame and in a decentralized fashion. If you have limited resources and need to have things working in that time frame, decentralized services can be the right decision even if they give you problems later. Further, being a fairly reliable way to do things, they ha…

I did not explain myself well, I was thinking in a more broader sense, including the related project management issues.

Re: Microservices and the migrating Unix philosophy

#12

Post by lgas »

repsilat wrote: post #8

> `cat file | sed | tail` Quite beside the point, but: - You don't want to use `cat`, and - You probably want to pipe `tail` into `sed`, not the other way around. This will be substantially faster if `file` is large, because it lets `tail` be clever about how it finds the last ten lines.

If you're going to nitpick a strawman this hard, you have to say this whole command should just be replaced with "tail file" but presumably the author intended it as an example where in real life there would be options supplied to sed. Those options might cause the number of lines to change, necessitating the tail being after the sed, not before the sed.

Re: Microservices and the migrating Unix philosophy

#13

Post by EGreg »

pjmlp wrote: post #6
hibikir wrote: post #2

Just like in Unix, we see the limits of composability: You can build some very basic, generic tools that are composable and easy to use. the greps and finds of the world. But there are relatively few of them out there, surrounded by a bunch of ugly, hard to read, hard to reuse glue. This is naturally occurring, because each piece of glue is not used many times, and its task isn't all that easy to define. So, taking t…

> They've not read Brooks enough. They never do. It is incredible how those mistakes keep being repeated.

Brooks?

Re: Microservices and the migrating Unix philosophy

#14

Post by brian_cloutier »

EGreg wrote: post #13
pjmlp wrote: post #6

Earlier quoted context omitted.

> They've not read Brooks enough. They never do. It is incredible how those mistakes keep being repeated.

Brooks?

Fred Brooks, author of No Silver Bullet[0] which GP is referring to, and the fairly famous Mythical Man Month[1].

[0] http://faculty.salisbury.edu/~xswang/Research/Papers/SERelat...

[1] http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...

Re: Microservices and the migrating Unix philosophy

#15

Post by andreasvc »

repsilat wrote: post #8

> `cat file | sed | tail` Quite beside the point, but: - You don't want to use `cat`, and - You probably want to pipe `tail` into `sed`, not the other way around. This will be substantially faster if `file` is large, because it lets `tail` be clever about how it finds the last ten lines.

cat helps with readability, as in having the input at the start. It's premature optimization to complain about it, I'm quite sure any performance difference is negligible.

Re: Microservices and the migrating Unix philosophy

#16

Post by repsilat »

lgas wrote: post #12
repsilat wrote: post #8

> `cat file | sed | tail` Quite beside the point, but: - You don't want to use `cat`, and - You probably want to pipe `tail` into `sed`, not the other way around. This will be substantially faster if `file` is large, because it lets `tail` be clever about how it finds the last ten lines.

If you're going to nitpick a strawman this hard, you have to say this whole command should just be replaced with "tail file" but presumably the author intended it as an example where in real life there would be options supplied to sed. Those options might cause the number of lines to change, necessitating the tail being after the sed, not before the sed.

God, I wasn't nitpicking -- I even said my comment was off-topic. I was throwing advice into the void, for the author if they read it or the commenters here.

And it's fairly important stuff for me on a regular basis. At work we generate hundreds of gigs of logs daily, and doing things in the right order with tail and grep etc is often the difference between a script working or not, or between it taking seconds and taking minutes.

Re: Microservices and the migrating Unix philosophy

#17

Post by DanielBMarkham »

lifeisstillgood wrote: post #10
DanielBMarkham wrote: post #7

I blogged about this recently. http://www.whattofix.com/blog/archives/2014/04/f-mono-agile-... Coming from a .NET background, I had an interesting path. I started with DOS-based imperative programming, then databases, then OOP/OOAD, then finally functional programming with F#. Once I truly got on the functional programming bandwagon, I started asking myself what was all this scaffolding for? Why didn't I just build c…

This is my intuition too - we can go an awful lot further than might be supposed with reusable components if we are sensible about the interfaces and streams / lists.

I think the missing piece here is pure FP.

If you're writing pure transforms, you're already creating the micro-services. It's just a matter of where they live. But if you start to play fast and loose with imperative programming, sure, you're going to need some industrial-strength glue. Even then it's going to be a mess.

It'd be interesting to have a pure FP language where you could either compile the entire code as one piece, or automatically split it up into chunks and deploy separately. You could keep the code in one place and the only thing you'd need to tweak would be the chunking. (You could also layer in some DevOps on top of that where certain pieces would talk to other pieces on a schedule, or across a wire, and that could be specified in the code. You could even meld this into a puppet/ansible-style system where not only do you code the solution, but you code the deployment as well. Neat idea. Somebody go make that.)

Re: Microservices and the migrating Unix philosophy

#18

Post by lifeisstillgood »

DanielBMarkham wrote: post #17
lifeisstillgood wrote: post #10

Earlier quoted context omitted.

This is my intuition too - we can go an awful lot further than might be supposed with reusable components if we are sensible about the interfaces and streams / lists.

I think the missing piece here is pure FP. If you're writing pure transforms, you're already creating the micro-services. It's just a matter of where they live. But if you start to play fast and loose with imperative programming, sure, you're going to need some industrial-strength glue. Even then it's going to be a mess. It'd be interesting to have a pure FP language where you could either compile the entire code as…

Erlangs OTP is getting close ...
Post reply on HN