I keep getting asked how to diagram a microservices architecture, especially when the diagram becomes very cluttered. Option 1: partition the single diagram into many (one per business area, etc). Option 2: create an alternative visualisation (e.g. structurizr.com/share/4241/e…)
5
10
3
36
Next step will be to visualize serverless functions 🤧
1
I've already had that question. 🤣
1
Related. I have a really hard time with splitting my domain into so tiny deployment boundaries. How to keep cohesion and overview?
2
If it hurts, maybe don’t do that :)
2
2
I’ve tried the mental exercise of doing it and I very run into the need to include the same code with different functions (eg aggregate invariants). Seems like splitting atoms.
1
So I’m wondering if there’s something I’m missing in the process?
1
Replying to @jeppec @simonbrown
I’ve never bought into the “tiny” variant of microservices, so I’m the wrong person to comment

Nov 14, 2018 · 8:49 AM UTC

3
3
Replying to @stilkov @jeppec
Ditto. I see it being useful for very niche use cases, but to build a whole system from? Nope.
4
Replying to @stilkov @simonbrown
Me neither. I think the message is that deployment and scalability of serverless functions is so easy that it shifts the balance towards nanoservices. Not convinced though /cc @arnonrgo
3
Serverless is also good from a cost perspective ... "self-provisioned CGI for the cloud era". ;-)
1
1
more replies
Replying to @stilkov @jeppec @simonbrown
Me neither, I split stuff along business services.If I can buy/sell a product that does just that, then It’s likely a micro service that can function well standalone. This seams to be the reasoning also carried out by amazon, if you can sell it standalone then its service