Micro is developer first focused. Meaning the starting point is writing code not deployment. We bake in a Go framework to write backend services. Then micro builds in everything you need. Abstracting away k8s. Everything you need is an importable package. Everything also works out of the box on your local machine using "micro server". No k8s necessary. The majority of the focus for us now is m3o.com. A hosted platform. Otherwise I think k8s is the wrong abstraction for devs. We need access to underlying primitives but also need a workflow thats driven around writing services not operating them.
From my perspective (I've taken cursory dives into micro in the past), micro is analogous to the libraries developed by every company's infra team to decorate teams' APIs (opentracing, metrics, logging, etc), making them consistently useful with minimal impact on developer velocity.
If this analogy is accurate, it means can deploy these however you want. They're kind of like force multipliers on the effectiveness of distributed computing tools (RPCs, logging, etc).
I welcome refinements/corrections of this analogy!
M3O does run on k8s. We personally do it for our hosted offering with some customisation, but also include a helm install in the docs for those that want to run on k8s easily. The goal is to target, local as processes, k8s as containers and then look beyond in future to wasm.
ah okay that makes sense, m3o is basically a microservices framework then? Pull the pieces you need (basic authentication, service communication etc) and all you need to add is your business logic?
