What's microservice-specific about that post? It's mostly about pretty standard perl packaging and deploying, most of which would apply to monolithic equally well (even more so, if your dividing line is DarkPAN-backed modules and not HTTP-isolated (micro-)servers).
The post's equally relevant to a monolithic setup as well. In such a setup, a code artifact (as mentioned in the post) will probably just be a script or a library (now I include a service too).
A toolset like this is a good-to-have for a monolith but a pre-requisite for micro-services (if you want to reuse code as much as possible i.e.), I feel.
The post has been written from a micro-services angle because that's what the setup is like here at Semantics3.
One the other hand, I've seen and read about companies where some forms of reused code are actually seen as code smells in this context. Especially when it comes to models, as one's service idea of what constitutes a 'Customer' might be different from others. Managing that (and redundant data stored in each microservice's private area) requires some heavy tooling...
So I'm always interested in the more specific approaches to communication and storing data when it comes to microservice architecture, which might be an idea for a sequel article ;)
Comments
What's microservice-specific about that post? It's mostly about pretty standard perl packaging and deploying, most of which would apply to monolithic equally well (even more so, if your dividing line is DarkPAN-backed modules and not HTTP-isolated (micro-)servers).
You are absolutely right!
The post's equally relevant to a monolithic setup as well. In such a setup, a code artifact (as mentioned in the post) will probably just be a script or a library (now I include a service too).
A toolset like this is a good-to-have for a monolith but a pre-requisite for micro-services (if you want to reuse code as much as possible i.e.), I feel.
The post has been written from a micro-services angle because that's what the setup is like here at Semantics3.
One the other hand, I've seen and read about companies where some forms of reused code are actually seen as code smells in this context. Especially when it comes to models, as one's service idea of what constitutes a 'Customer' might be different from others. Managing that (and redundant data stored in each microservice's private area) requires some heavy tooling...
So I'm always interested in the more specific approaches to communication and storing data when it comes to microservice architecture, which might be an idea for a sequel article ;)