6 ms·
> Honest Microservices Defined > An app that cannot crash. It has a way to fail gracefully but that doesn't involve some downstream coder poking through your c
by rakoo 6y ago
> Honest Microservices Defined
> An app that cannot crash. It has a way to fail gracefully but that doesn't involve some downstream coder poking through your call stack.
> An app that does one and only one useful business function. What's that? See IST.
> An app that is composable with other apps from the command line.
> An app that uses dynamic, free-form, late-bound text streams to talk to other apps.
> An app that can be reasoned about, modified, or completely replaced by a maintenance programmer many years from now with little or no preparation.
> The app must have tests.
> The app must do what the tests say it does.
> The app cannot do anything that the tests do not cover.
> These tests exist in a compilation unit separate from the app itself and are in no way coupled to it.
> When in doubt, think of your compiled app as a pure function running inside a program. That program is a plain, vanilla, default operating system.
A good chunk of it sounds _a lot_ like the UNIX philosophy, and it is more obvious when looking at the author's article on IST. In that view the services supervisor, like sysvinit, runit or systemd becomes the supercompiler in charge of starting the different services, watching them and restarting them when they fail.
Evidently if we haven't gone this direction and came up with different tools then something must be wrong in this architecture but I don't have enough experience to understand what exactly, unfortunately
- marcosdumay 6y ago> A good chunk of it sounds _a lot_ like the UNIX philosophy Yes, it does _sound_ this way, doesn't it? That's because the UNIX philosophy is misrepresented. Having small self contained pieces of code serves you nothing if they can't be called on many different tasks with different arguments. In theory, you could make generic microservices that behave like UNIX tools. On practice if you try that, your CRUD application will reside 90% in a single service, and you'll have some extra tools for a few more complex parts. (What isn't a bad architecture, by the way, but it's not what people describe as "microservices".)
- rakoo 6y agoIt all depends how your app is split. Maybe you have pagination, and pagination could be extracted. Maybe you have logs, and they are handled outside. For pieces to be truly independent and exchangeable it seems to me it has to happen on more technical jointures rather than functional ones.
- btbuildem 6y agoIt sounds very Erlang-y.. in fact, at the end of the article the author refers to OTP directly
- rakoo 6y agoIt does sound OTP-y indeed, and successful companies have been built on this stack. I was just wondering if it was possible with UNIX and if any company had success doing that (using small programs and pipes everywhere)