You're right. It's not very useful if you're just using it for pubsub. Go Micro was always intended as a full fledged framework for distributed systems development and you'll find if you build systems at scale you end up developing a similar framework in house. For those just using messaging or a database my advise would be to go directly to that system. Abstractions are only useful when they work together collectively for the foundation of something more. In our case when everyone is building Micro services we can actually run these absolutely anywhere regardless infrastructure and share them with anyone as a reusable building block.

Are these things necessarily opposed? It doesn't seem impossible to me that a "full-fledged framework" also addresses the most common uses cases in ways that don't leave people befuddled.

I think its really a matter of opinion and choice of development. Some people want to build it themselves, others would prefer to use a standard. Its the difference between using Spring or writing tools around Java. Using small libraries or Ruby on Rails.

Again, I don't think they are necessarily opposed. The examples you give are, sure, but that's a library vs framework distinction.

As a contrary example, take a lot of Unix command-line tools. Things like ls and ps have very sensible defaults that cover up very complex models. Or my experience with Python's Twisted is that it is very rich, but it's simple to do simple things. And cryptography libraries are a great example of where well-chosen defaults are absolutely vital. Same with Wireguard. Is what it's up to very complex? Definitely. Do I need to understand the details to get good results? No.

The truest words spoken here today.

Dapr is attempting to play in the same space as us. Using a standalone server and grpc generated libraries. We're a Go framework first as we believe development is about the tools you put in the hands of the developer meaning how they write code. We deliver the framework as a set of grpc services also which you can start with the command "micro server" and communicate through https://github.com/micro/micro

Micro started in 2014 and from what I could tell molecular took a lot of ideas from it to creat something in the JS ecosystem.

Actually Micro is the exact thing you would use ontop of kubernetes. Micro was built to tame the world of cloud-native complexity and focus on developer needs.

You can think of Micro as an abstraction layer over distribute systems infrastructure, hiding the complexity from the developer and providing a pluggable system which allows it to operate in any environment. This means locally a dev can run with zero deps but in prod someone from the ops team can switch to etcd, cockroach, kubernetes, etc.

Predominantly the majority of our users are using Micro on top of K8s. Their primary focus is productivity and velocity of development when building microservices.

Using this framework on top of kubernetes (which is itself another framework used to managed microservices) sounds like an operational nightmare. Kubernetes is already filled with operational pitfalls so adding more layers on top only increases complexity.

I think Go-Micro looks cool but I wouldn't suggest layering this much more than you already are. Complexity is death for distributed systems so minimizing complexity means maximizing reliability for the systems.

I'm sorry you've misunderstood what this is. This is a Go Framework for microservices development. It's what you use to write services. It's like Rails or Spring. Kubernetes is for running applications not writing them. Kubernetes no opinions about how you write software. We encapsulate the underlying infrastructure and provide a framework for the developer to literally write business logic.

As mentioned by the other commenter one of the big features is service discovery and load balancing - it seems like micro is stepping on k8s feet here and is a bit more than just a framework.

I could see using micro on bare metal (with all features) but trying to get the grasp of mixing with k8s (with all of micro's features). I'm assuming no one is using micro's load balancing and service discovery over k8s? I guess the broader question is, is micro highly coupled to all of its features/functions or is picking and pulling parts of it workable?

The first two features listed on the README are "service discovery" and "load balancing", which is probably where the question is coming from.

yup.

Micro seems like a framework + platform for running micro services (ideally on bare metal). (Not saying there's anything wrong with that though)

Micro focuses on providing distributed systems programming as a single framework, so it takes all the patterns you'd normally leverage and puts them in one place for you to easily build services. We do this with a pluggable model so you can pick and choose underlying infrastructure dependencies or a zero dep model if you choose. Its very powerful and our hope is the next generation of services are built using it.

Given that the functionality incorporates a lot of things one would usually create for a service being run on something like Kubernetes does it run well on Kubernetes? Or are there clashes?

Most of our users run this on kubernetes. Developers want an abstraction that is not kubernetes or infrastructure. Something simpler entirely focused on the development of services. So it fits well. We run it on kubernetes.

Hey! Asim here (author). Feel free to ask any questions. Was not expecting this to hit the front page.

Is it possible to create a tutorial showing features end-to-end (using CLI / Code generation)? I have seen a couple of high quality tutorial series on web - but they are advocating usage of 1.18 version.

Sure, what kind of tutorials are you interested in? Written form or video? We're thinking about doing a video walkthrough series potentially in live form.

Written form please. This saves time in many ways, such as searching for certain chunks of information when trying to form an early opinion on how this product fits one's need. I went through your dev documentation today and the organization is good. I wish you would present the more detailed booking example in the same conversational style as the shorter hello world example at start. When a developer sees the first page with the bullets of interesting features (service discovery, load balancing, etc), they would want to get a broader picture of the architectural approaches combining these features (through coding examples). Interesting work. Thanks for creating it.

Whoa the outright pessimism in this thread is horrific. The guy literally donated $1m to try help a certain aspect of the crisis. What did you do? Did you do anything at all to help? Think about your own actions in the face of this pandemic before criticising others.

I hate to break it to you man but you don't need to be Mother Teresa to critique other peoples contributions.

I don't think anyone in this thread is criticizing pg or his generous donation. More just that the tweet seems very exaggerated and self serving.

Micro | SWE, SRE, Dev UX | Full-Time | ONSITE London and REMOTE

Micro (https://micro.mu) is a seed funded startup building a global services platform for microservices development. We are the creators of the successful open source project Go Micro https://github.com/micro/go-micro. Our goal is to now move beyond the framework and provide developers with a serverless platform to remove the hassle of managing infrastructure.

We're looking for software engineers, SREs and devrel to help build the platform, continue the growth of the open source project and ultimately build the next generation of developer experiences beyond the cloud.

Contact hello@micro.mu or join the slack #hiring channel to learn more https://micro.mu/slack

That's super cool. I feel like the terminal is the window to the soul of the machine and a gateway for exploration. This breathes life into that idea.

Thanks a lot!