There is a lot of interest on microservices from the research community; there are many open-source frameworks that enable you to write/deploy/operate microservice applications with different levels of abstraction. One thing that is missing in the open is (significant) example applications / benchmarks, across which we can compare the different frameworks in terms of ease of use, convenience, performance, etc. Can you give a description or samples of what people are doing in m3o.com?

I think most people are effectively doing some form of CRUD on the backend that's then consumed by web apps or mobile. In our case we've built out a number of example applications in https://github.com/micro/services.

Is it correct that Micro is only compatible with the Go stack? We would be very interested to apply this to our Node/Typescript/Python family of microservices, we've been having many difficulties with K8S and this looks like a level of abstraction that would be perfect for us right now.

I see now that "go, java, typescript, ruby, python clients" is done in the roadmap, but can't find any documentation about it.

We have multi-language grpc clients code generated in https://github.com/micro/micro/tree/master/client/sdk but we need to publish to various package managers or at the very least wrap them in a more clean and simple experience first. It's hard to replicate our Go framework experience in clients so I think to start its around consumption. I think grpc-web based typescript client or OpenAPI generated clients might be the next thing but open to ideas.

Have you tried gapic-generators? They aim to create a full client library from the protos (used to create google’s cloud libraries). E.g. https://github.com/googleapis/gapic-generator-ruby

How is this different from K8's? It just looks like k8 with a little extra boilerplate for microservices (built in key-value store etc)

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.

Does that mean that you could run m3o on k8?

(sounds like m3o is a microservice framework?)

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?

K8s is closer to an infra tool while Micro is a full flegded development model - it's a bit like Rails/frameworks going to the cloud.

I would love something like this for nodejs, my language of choice for microservices.

I will definitely watch how your platform evolves. Good luck!