Hacker News Reader

Comment by vsekhar | Hacker News Reader

PM for Go Cloud here (and poster of the Azure feature request).

"Unplanned" on the issue tracker just means we haven't assigned it to a sprint milestone for the team yet.

Azure and more clouds are very much in the works. As an open project, there are many approaches and we're open to all of them.

One other point: since Go interfaces are implicitly fulfilled, anyone can write and share implementations of Go Cloud for new providers or custom services without asking anyone for permission. If you take a look at the implementations we've provided, you'll find it's actually rather easy.

More to come.

View on HN

Hi PM guy. If project is to remain independently cloud-gnostic and people file a lot of bugs and pull requests it'll definitely help Google or Alphabet or whatever deliver that k8s abstraction y'all've workin' on. That's great for you.

My my question is, what if developers want access to innovations in specific cloud providers, such as reduced redundancy storage on S3? Wire up or own provider? Will there be some sort of community-provided provider registry or will we be grepping awesome lists on GH? Are providers extendable in any way?

Thanks and have a sunny day.

This is a great question.

The main goal of Go Cloud is that the abstraction is not leaky and that you don't get access to specific features in the way you are describing in the application itself.

Now if the specificity of the thing you want happens at provisioning time but the API is the same (e.g. choosing to use Aurora on AWS vs standard RDS), then there's no problem. Go Cloud doesn't need to know about that.

If the API changes too, then that's a much different thing, and gets back to the leaky abstraction which we want to avoid. If you can't simply wire new providers to your application code and have it Just Work, then we've done our job wrong.

But remember that it's all Just Normal Go, there's no magic here. It's just standard Go. If you want to write an app that ties itself to something specific on some cloud you can; just write the code you'd write now. But that necessarily means you're tied to that product.

Contributors could also add drivers that not only fulfill your Blob interface but add features that might creep into multiple services. For example, someone could contribute a SuperBlob that fulfills Blob and also adds conditional writes, which GCS supports. On the app side, if they want to check if some feature is available that speeds up operations, they could then see if the returned Blob is also a SuperBlob and if so, perform the more optimized approach.

Usually if you want to use a library like this, you can't really do anything else, but implement the smallest common subset of the services combined.

In the minute you implement something provider specific, you just lost the whole point of this library and you did not needed it in the first place.

Reply on news.ycombinator.com