Microservices and the migrating Unix philosophy
1–10 of 18 posts
Re: Microservices and the migrating Unix philosophy
#2Just 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 this to Microservices: while we can build a bunch of little services that will be reused everywhere. The large majority of a system will be this kind of glue: You can't make every single piece of code you write be as well defined as grep, but with a service interface. And while you will be able to track what the little pieces do, the bigger command and control pieces will always present a problem. We can't wish complexity away, no matter how hard we try.
So designing a bunch of microservices and hoping most of your problems will be solved is like trying to build something in Unix without perl and shell scripts. But I see companies, today, that think it's a silver bullet. They've not read Brooks enough.
Re: Microservices and the migrating Unix philosophy
#3Just 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…
Right on target, and very apt considering that I'm boarding a plane to GlueCon this afternoon. =)
Re: Microservices and the migrating Unix philosophy
#4The compensation for our failures, or sometimes overcompensation for our failures leads to interesting outcomes. Perhaps the answer lies not in monolithic vs micro approaches so much as knowing what the evolution between the two over time looks like.
Re: Microservices and the migrating Unix philosophy
#5> ...composability does not and can not exist everywhere simultaneously. It just won’t scale. Although the flexibility that a composable infrastructure provides is vital during times of rapid innovation, such that pieces can be mixed and matched as desired, it also sticks users with a heavy burden when it’s unneeded.
This is a good reminder. There is a lifecycle. Know when and where it starts, and when it ends.
Re: Microservices and the migrating Unix philosophy
#6Just 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.
Re: Microservices and the migrating Unix philosophy
#7I 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 composable functions that passed formatted files around?
This is 180-degrees from the way I used to code, but damn, I like it. A lot. I can use the O/S as an integration tool, and the entire deploy/monitor/change cycle is a million times easier.
I wonder how many other OOP guys are going to end up in my shoes in another 10-20 years or so?
Note: I see other commenters are talking about how you can't solve your problems simply by using micro-services. I'd agree with that, with one caveat: if you've coded your solution in pure FP, you've solved your problem in a way that's by definition composable. You can certainly decompose that solution into microservices. I think the question is whether or not you have to "re-compose" them into one app in order to make changes.
Re: Microservices and the migrating Unix philosophy
#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.
Re: Microservices and the migrating Unix philosophy
#9Just 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.
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 have appeal even if your time frame is far enough ahead to see the problems.
Re: Microservices and the migrating Unix philosophy
#10I 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.