First of all I think there is merit in trying to do "Netlify for the backend". Or a more flexible and backend focused variation of Vercel (I think they only let

First of all I think there is merit in trying to do "Netlify for the backend". Or a more flexible and backend focused variation of Vercel (I think they only let you do FaaS, correct me if I'm wrong). Services like these provide a constrained, "just works" user (dev) experience. However, I don't like the name "Micro Services". It seems like the authors are trying to hijack a well established term for their brand. This might be incredibly confusing for new developers and at the same time turn off experienced ones. Also there seems to be little explanation of the storage system. From the docs: > State is a fundamental requirement of any system. We provide a key-value store to provide simple storage of state which can be shared between services or offload long term to keep microservices stateless and horizontally scalable. Is key-value standard practice for the target audience? This is a little bit of a point of confusion. Especially if we're dealing with a language like Go, which has many benefits and advantages, but expressiveness is not one of them. So building up ad-hoc relational logic with it seems scary! I'm not too familiar with Go. But from reading some of the example code[0] I get the feeling that there must be some very good reason for avoiding relational. And what confuses me further is the name collision with go-micro[1]. [0] https://github.com/micro/services/blob/master/messages/handler/handler.go https://github.com/micro/services/blob/master/messages/handl... [1] https://github.com/asim/go-micro https://github.com/asim/go-micro