chuhnk

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.

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

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.

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.

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.

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

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.

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.

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.

Email me at asim@micro.mu

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.

https://github.com/micro/micro https://micro.mu/docs/network.html

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.

Can anyone explain what this means for the future of Docker the company?

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.

OP here. I agree with you completely. People shouldn't be building these frameworks. Let's rally around one or two frameworks per language where appropriate and drive that as the common development method, as we do for infrastructure.

I'll also mention that yes, I agree, in most cases microservices are not the answer. This really comes down to the natural evolution of companies that scale to 50+ engineers split across multiple teams and continuing to grow. The software architecture should model after the org and allow teams to execute independently. If this is possible with monolithic architectures or anything else then that should be the approach taken.

In my case, I came from Google and Hailo, environments in which scale mattered on all levels and I didn't see the tools out there (back in 2015) to solve these problems for everyone else.

Rails is for Ruby. Spring is for Java. Micro is for Go

I see a world in which Micro can be used to write even a single service with a model that can scale to dozens. But more importantly I want to help unlock the reuse of services and the power of what microservices enabled for me at Hailo and what I've seen it do for others.

Micro | SWE, SRE, Dev XP | London, UK | Full-Time | https://micro.mu

Hi, we're Micro, a seed funded early stage startup building an open global services network to empower developers to build, share and collaborate on microservices without having to manage any infrastructure. We're realising the potential of the cloud and beyond.

Micro started as an open source project 4 years ago and has evolved into a platform. We're looking for those who are interested in contributing to open source while staying focused on building a real product at scale.

We're only hiring in London right now. Please reach out at hello@micro.mu or join our slack #hiring channel https://micro.mu/slack/

We've been working on something similar for a few years now. Micro is a runtime for microservices https://github.com/micro/micro. We primarily focused on Go and are moving towards multilanguage via a http api, proxy and SDKs much like dapr.

Looks similar to what we're doing with micro. We started as a Go framework and are moving to a runtime model.

https://github.com/micro/micro https://github.com/micro/go-micro

We're broadly working towards a lot of what you're saying here at https://micro.mu. It's an incremental process which I fundamentally believe needs to begin with giving developers a new method of development guided by a framework. We're leaning more towards the android model of managing a complex runtime and providing the framework for developing in that environment.

We'll probably leverage cloud, edge, personal servers, mobile and any other device in the long term to move services to the user.

I share a lot of your ideas and philosophy. Shame it didn't come to fruition with sandstorm.

Micro | London, UK | Onsite | https://micro.mu

Micro is a seed funded company in London building the future of microservices development.

I spent the past 4 years bootstrapping the most popular Go microservices framework and now we're levelling up to build a platform for developers to massively reduce the complexity of cloud native systems.

To learn more email hello@micro.mu

It's amazing to see more and more finding Go. For a lot of us it's been almost a decade since we started using it. Back then for me it was the perfect blend between C and ruby. Today I believe it's the language of distributed systems and the cloud. I personally think Go ends up with majority marketshare for all cloud native systems and its already going in that direction with the core tools like docker, kubernetes, etcd, grpc all using it. By extension of that I believe a signifcant number of backend systems and services in the cloud will also predominantly be Go based.

This doesn't rule out other languages, its merely an indicator of a trend we've seen time and time again related to platforms. Windows, Linux, Android, etc. Every platform has a dominant language. Other newer up and comers like typescript, rust, swift, kotlin, etc have their place but for their respective platforms.

Go's adoption will accelerate in the next decade but you'll also find it disappear into the background as development as a whole levels up beyond the languages of today.

Only us millenials and older generations will speak of it. The next generation will be preoccupied with an entirely different model of programming.

Micro | London, UK | Onsite | Full time | https://micro.mu

Micro is the simplest way to build microservices. We're a small team based in London focused on providing a vastly superior experience for developers to build microservices without having to worry about the complexity of distributed systems or cloud-native infrastructure. Micro started as open source project 4 years ago and is now turning that into a service.

We're looking for a:

  * Senior Software Engineer (Go and distributed systems)

  * Fullstack engineer (react, graphql, typescript and Go)

  * Services engineer (experience or desire to build microservices)

If you want to build microservices on top of kubernetes I'd recommend go-micro https://github.com/micro/go-micro

After my macbook pro keyboard became completely unusable and keys literally started to fall off I went out and bought a Pixelbook and handed my Macbook in for repair. I'll tell you right now, I'll never go back and I immediately understood that Apple are truly screwed. The macbook is dead and they don't even know it. All developers will eventually move to a Chromebook, Surface or whatever else.

Chrome OS for me is perfect, especially since they introduced linux support and android apps. I can run anything I need, I do not feel like I took a step back, in fact I feel like I leaped forward by pushing towards a cloud first experience. I was already using Google for all my apps, spend most of my time in the browser and I personally have not felt any pain beyond adjusting to my new keyboard layout.

I highly recommend everyone ditch their macbooks and buy a Pixelbook.