6 ms·

Hey all, author here! Please provide comments and feedback. Happy to answer questions and discuss this old thing called "microservices" and poke fun at the comp

by asim 6y ago

Hey all, author here! Please provide comments and feedback. Happy to answer questions and discuss this old thing called "microservices" and poke fun at the complexity of cloud and AWS.

eatthoselemons 6y ago
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)
- asim 6y ago
  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.
  - eatthoselemons 6y ago
    Does that mean that you could run m3o on k8? (sounds like m3o is a microservice framework?)
    - gen220 6y ago
      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!
    - asim 6y ago
      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.
      - eatthoselemons 6y ago
        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?
- friendly_chap 6y ago
  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.
rfonseca 6y ago
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?
- asim 6y ago
  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 https://github.com/micro/services.
oersted 6y ago
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.
- oersted 6y ago
  I see now that "go, java, typescript, ruby, python clients" is done in the roadmap, but can't find any documentation about it.
  - asim 6y ago
    We have multi-language grpc clients code generated in https://github.com/micro/micro/tree/master/client/sdk 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.
    - wanderer2323 6y ago
      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 https://github.com/googleapis/gapic-generator-ruby
davedx 6y ago
I would love something like this for nodejs, my language of choice for microservices. I will definitely watch how your platform evolves. Good luck!

by asim 6y ago

Hey all, author here! Please provide comments and feedback. Happy to answer questions and discuss this old thing called "microservices" and poke fun at the complexity of cloud and AWS.

eatthoselemons 6y ago

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)

asim 6y ago
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.
- eatthoselemons 6y ago
  Does that mean that you could run m3o on k8? (sounds like m3o is a microservice framework?)
  - gen220 6y ago
    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!
  - asim 6y ago
    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.
    - eatthoselemons 6y ago
      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?
friendly_chap 6y ago
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.

rfonseca 6y ago

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?

asim 6y ago
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 https://github.com/micro/services.

oersted 6y ago

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.

oersted 6y ago
I see now that "go, java, typescript, ruby, python clients" is done in the roadmap, but can't find any documentation about it.
- asim 6y ago
  We have multi-language grpc clients code generated in https://github.com/micro/micro/tree/master/client/sdk 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.
  - wanderer2323 6y ago
    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 https://github.com/googleapis/gapic-generator-ruby

davedx 6y ago

I would love something like this for nodejs, my language of choice for microservices. I will definitely watch how your platform evolves. Good luck!