Micro 3.0 is a platform for cloud native development | Hacker News Reader

Micro 3.0 is a platform for cloud native development

micro.mu

95 pointsasim61 comments

I've been learning golang for backend dev, and for that reason checked your project. Is this sort of like Netlify for the backend?

Are there any examples of how the repository/database layer fits here?

What'll happen to the name m3o when Micro reaches 4.0?

“M3o” refers to the 3 letters in the middle, not the version number (similar to i18n or k8s)

This is correct

Yes! We are Netlify for the backend and in fact our next post will be titled "Netlify for your frontend, Micro for the backend". We think there's really a need to do what Netlify did for frontend to the backend and just help people build APIs and services super fast.

The M3O Docs have some content about getting started with things quickly https://docs.m3o.com/getting-started but we need to add more. The open source docs are a great reference https://micro.mu/reference and otherwise we're working on some sample services in https://github.com/micro/services.

Well luckily M3O is M[icr]o so I think we're going to get away with it for the long term :)

Thanks for replying back to me, I've been having a look and it seems that you guys are very talented.

I'm going to start a new project and if this can help me save time and not have to deal with aws, etc would be great! Depending on cost of course. Hopefully we can get some info in terms of cost.

About the repository/database layer, I found the "store" documentation; just going through things quickly at the moment, but guess that's what store means in the Architecture?

I'll check the examples you've provided and read the documentation properly.

Thank you and good luck!

No worries. Please join the slack at https://slack.m3o.com if you need help or want to engage with the community. For us Store means key-value or crud data storage. I think if that's what you're calling repository for persistence then that's it. If you're thinking repository as in git then that's a separate connective piece from "source to running" which basically you can do by running the git URL.

On the store front. We are working on a data model so we can move beyond key-value which might end up being of interest.

Yes, as in CRUD data storage. I'll join slack.

Good luck Asim, the project is kick ass!

Thank you!

I see that you can point it at a git URL and I see the "running a git source" section of the docs, but I am not seeing how to authenticate to a Github or Gitlab repository if it is not publicly viewable. Do you support that type of authentication?

Yes. See the doc on private repos https://docs.m3o.com/getting-started/private-repos. Hopefully that helps. If not please drop into slack (https://slack.m3o.com) and we can try help further

bdcravens is correct. m3o is a numeronym for 'micro' and does not relate to the version number.

The format of a numeronym is to take the first letter of a string (micro) + x + the last letter of the string, and replace x with the number of characters between both. So, Andreesen Horowitz (the most popular one I'm aware of) becomes a16z. Micro becomes m3o.

Can someone explain the implications of this point of the Polyform license? (It seems perhaps AGPL-like but 'product' could be very broad)

Noncompete

Any purpose is a permitted purpose, except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software.

The only restriction here is selling Micro as a Service e.g AWS can't pick up and sell Micro. This is a common problem in the open source industry and Polyform is trying to create licensing standardisation rather than everyone hand crafting something. For larger orgs in the long term being able to approve a common license rather than 100 bespoke ones.

That may indeed be the intention. IANAL but I wouldn't trust the broadly worded "providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software" to mean that and only that.

Here's a list of the PolyForm licences[0] with the 'PolyForm Shield' one being used. I would have expected the 'PolyForm Perimeter' to be more of the open-source type license, based just on those summaries than one that protects the 'provider' from competition.

[0] https://polyformproject.org/licenses/

ownCloud is currently doing a full rewrite called "ocis" which uses the go-micro stack. It allows us to focus on the business-logic of file-syncing while taking care of all the micro-service plumbing.

Disclaimer: I work for ownCloud.

Why did you guys continue to exist once Nextcloud broke out and took the market? I feel like the insistence of ownCloud and OpenOffice to defy the more open standards their forks (together with nearly all developers) moved toward is... aggravating?

Stop trying to tell the river where to turn. It's already done.

Whoa, I really hope no one ever comes telling you such an offensive thing. If owncloud has customers and/or investors they can develop whatever they want and I will applaude them for sharing the code.

It wouldn't be an issue for me if these legacy products either a. opted for more ethics where their fork showed them the way or b. if they actually produced innovation instead of desperately holding onto big company departments.

OpenOffice, for example, has basically done nothing but maintenance. It's not something to be proud of.

> nothing but maintenance. It's not something to be proud of

What? Absolutely! Maintenance is hard. Maintenance of old/big/complex systems is even harder. Maintaining something for so long with substantial user base is definitely something to be proud for. Everything doesn't need to constantly add features in order for people to be proud of their work. Just adding bug/security fixes once you feel something is feature-complete is also OK.

Not sure where this constant need for changes is coming from, but each to their own. But to look down on people who are doing maintenance is a real shitty thing to do.

I hope you don't work together with others in open source, as they'll also feel saddened by your comment that they should not be proud unless they work on new features.

Having maintained some old open source codebases, I can say that just keeping up with bitrot is at least 1/3 the workload. New versions of the OS, the language, the libraries, etc is not a minor thing to keep track of and update.

I think you've run off with the ball a bit here. I have plenty of respect for maintainers. To the example we're addressing, of OpenOffice: nothing but maintenance is the big deal here. Maintenance is hard, yes but you can also find a developer or two to push the ball ahead a bit and Apache hasn't seen fit to do even that.

I don't think I have. You say your respect it but then say "nothing but maintenance is the big deal here".

My point was, nothing but maintenance is OK too, and sometimes even favorable, depending on what you're working on.

As an example, the software behind HN is pretty much maintenance-only for as long as I've been lurking here. While there is bug fixes sometimes, I don't think there been any new features the last few years. You don't think the people running the HN software should be proud of that?

> OpenOffice, for example, has basically done nothing but maintenance. It's not something to be proud of.

That's a dangerous fallacy. Only innovation and no maintenance is not the way economies grow. Go ahead and take a deep breath -> https://aeon.co/essays/innovation-is-overvalued-maintenance-...

> [...] opted for more ethics where their fork showed them the way [...]

Forking isn't necessarily a bad thing. From a free market perspective it incentives competition, and per my respect, the original company owes nothing to a forked business out of the original codebase. In this particular example both projects took different directions, why would the fork have to take a higher moral grounds in respect to the original?

> Stop trying to tell the river where to turn. It's already done.

After almost a decade of HN I have to say that's one of the most un-HN comments I have ever read.

I think you're confusing daring and innovation with legacy swaddling.

A rewrite in golang where the intent is to solve a lot of scalability,architectural and operational issues which are present in the old codebase.

Additionally we invested a lot in a unparalleled test-suite in this space which runs against the old and new codebase.

How could we innovate further?

I see nothing wrong with OwnCloud doing business as they do. At least they aren't trying actively to kill off their competitors, like Netgate/Pfsense does and yet HNers seem to like them.

Seems like you are mixing up your claims and your premises a bit. Let me try to untangle this. The fork happened, yes, but it did not take the market as you claimed. Also, not “nearly all developers” but barely a dozen of the forkers’ closest friends left ownCloud. I currently have around 50 colleagues in engineering and support alone. ownCloud is doing rather fine, thank you, both as an open-source project and as a company, both with community users and enterprise users.

There are multiple open-source file sync and share platforms. The reason is quite simple: There are multiple ways to implement a digitally sovereign file platform, and different needs call for different feature sets. ownCloud focuses on code quality, reliability and features that security conscious companies and institutions have come to expect. You do not have to like ownCloud, you do you. To your open standards point: I posted here because we use go-micro in our current rewrite, which is by the way under the Apache 2.0 licence. We cherish and embrace open standards and open source, so I don’t exactly get what you mean by “more open standards”. But to answer your first question: we did not die because we were and are in good health, still had and have work to do and, most importantly, have oodles of happy users and customers to serve.

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.

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.

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

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

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

I've been using the previous version for a while, and it's been way too complicated and confusing, so I'm happy to see that version 3 is addressing some of those issues. It's very ambitious and promises great things with the client generation, but it's not that straightforward to set up and use. The cloud might be complex, but a lack of really great docunentation makes Micro just as complex. Good luck to them, though.

Thanks for the feedback. You're right, Micro was trying to do too much, based on prior experiences at other companies that provided the all encompassing platform experience. Once I realised that I started to scale back. With Micro 3.0 we also knew docs was one lagging thing from before and the fragmented projects were causing huge issues. So now we have betters docs https://micro.mu/ and we have a single project https://github.com/micro/micro. The product M3O (https://m3o.com) has its own set of docs, sort of like how Git and GitHub would have different docs.

Hopefully we're headed in the right direction.

What's the resource limit of the plans? Couldn't find it in the pricing page.

It's here https://docs.m3o.com/faq#fair-usage-policy. Sorry it's not in a clear place. I'll look to fix that.

Regarding these two points:

  - Key-Value Storage
  - Event Streaming

Is there specific software used for these--what are its characteristics comparable with?

We use cockroachdb for the storage and nats-streaming for events. We know cockroach is a SQL database but the scaling properties are nice, we know the team and we think we'll leverage the SQL layer too so it's a good fit. On events the reason we chose nats-streaming over Kafka is because of the low memory footprint and because we've been using nats for a long time in Micro and know the creator Derek Collison pretty well. We trust these technologies a lot.

Over time we'll offload these to managed services and potentially allow people to plug and play based on their needs.

Hi people, I'm one of the people working on this. Thanks for your support!

If you want to try the thing in minutes may I advise you to start here: https://m3o.com/start. Pretty much just a couple of commands to get started :)). Cheers

Hi, Great work just one tip, adding syntax highlighting to the start page will help. I noticed you have that similar on landing page tho

Thanks, its raw html at the moment. The front page is using carbon which seems to help. Need to figure out better embedding of commands.

It's not entirely clear from a light perusing of the sites or docs. Is Micro a Go framework or does it support building services in any language?

A lot of the concepts and features seem really useful to what I'm looking to build, but the project will not be built in Go.

At the moment Micro is focusing on Go backends consumed by clients in different languages. I would wait until there is more explicit support for different nackend languages, unless you feel adventurous.

Is there any way to self-host this? If there is a guide that would be awesome!

Yes. Micro is open source and has been so since inception. Here is a quick start to install https://micro.mu/getting-started#install

Somehow could not find this, thank you very much! This looks so cool

No worries. Come join the slack (https://slack.m3o.com) if you need help.

Is there any documentation on how to run multiple instances of Micro which can communicate and share config/secrets? What is the horizontal scaling story?

I really appreciate how simple in aesthetic their blog pages are.

Thank you, that's really appreciated!

Reply on news.ycombinator.com