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.
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
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.
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.
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.
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.
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.
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.
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.
Micro | Senior software engineer | London, UK | Full time onsite
Micro is a seed funded startup building a global serverless platform for microservices in the cloud and beyond. Developers have spent too much time reasoning about cloud native infrastructure, docker, kubernetes, etc. We want to abstract all of this away and let you focus on what really matters.
We're a small team based in London looking for others who want to join in the early stages of building a platform and company.
Competitive comp, great stock options, pension, work from home on Friday, and take holidays as you need them.
Interesting to see this. We've taken a similar view for the initial phase of the micro network. Locality is going to matter more and more as we move into the future. Although Cloud still has its place and we don't ignore that either.
This post is really timely. We're going through a wave of innovation in how we ship software but in that we're having to reason far more about the infrastructure. I think we might be reaching the end of that phase and the realisation that none of us really want to touch containers or kubernetes, we just want it to fade into the background. Because at the end of the day software development is still software development and not much has changed there despite the underlying platforms being completely rewritten.
I'd argue that we might once again be on the cusp of true serverless but in a way that might become ubiquitous. If we could unlock a shared platform like GitHub but for running software we'd be in a much better place.
I'm assuming you're from a certain large corporate from whom no one actively engages our community or makes any comments on PRs or creates any issues or contributes anything for that matter and does not actively pay for support.
As a developer and user of open source I completely understand your pain. As a maintainer who has built and managed this project alone for the past 4 years I would tell you that you have many options in how you make use of a completely free open source project with a liberal Apache 2.0 license.
You are entirely free to fork the project, pin your dependency to a certain release, to actively engage in the community, to file an issue when you have concerns and to of your own volition use something entirely different if you are unhappy with your usage of a free tool.
We are in the process of moving from a totally free open source project maintained by one person to a small team building a product and business around these tools. During that period there may be some pain and issues, we'll move fast and potentially break things and in that make many mistakes but hopefully people will engage to help us move in the right direction.
If you are a company who relies on this piece of software for the 24x7 uptime of your business and this adds measurable value to your company then perhaps it would make sense to engage in some sort of SLA or support agreement for this critical software that you currently pay nothing for.
Thank you for the honest feedback. We're moving fairly quickly in regards to the evolution of the framework. Some of that results in breaking changes and you're right we haven't established the right channels for communication. To be quite frank, open source and public library maintenance was never my goal or part of my experience, I build platforms and remain mostly behind the scenes. So I apologise for the pain but hopefully people have found the framework to be useful despite some of the issues.
Your assumption is that the framework handles this complexity for you. This incorrect. It provides abstractions to the developer which then allows them to build on these while allowing them to be swapped out for the most appropriate underlying infrastructure.
The point is that building distributed systems as a whole requires a level of understanding in this space but not one that should require you to initially focus on infrastructure or even take that into consideration while writing software. Ideally you should be given these as abstractions which allows you to build distributed applications and offload operational concerns to the relevant parties while still coherently having the sum of the parts work together.
The tools that you mention are infrastructure. And while an environment, a platform, should be provided that gives you the insights and the relevant foundation, it really should not be the primary concern of the developer.
Developers should not be forced to reason about infrastructure.