5 ms·

I like how Google tries to masquerade their corporate goals behind the 'portability' banner. Google Cloud is in a distant third place behind AWS and Azure, so o

by bhamta 8y ago

I like how Google tries to masquerade their corporate goals behind the 'portability' banner. Google Cloud is in a distant third place behind AWS and Azure, so ofcourse they don't want developers to have tight coupling to their competitors. This portable cloud strategy is a mirage. I haven't seen anyone migrate providers easily (we tried in my last company). In reality, you have to break the cloud agnostic abstraction to leverage provider specific functionality. And then you are stuck with unmaintainable mess of 'cloud agnostic' APIs mixed cloud specific APIs.

mfer 8y ago
Note, Azure support is filed under "unplanned"... https://github.com/google/go-cloud/issues/76 https://github.com/google/go-cloud/issues/76 Interesting that the #2 cloud provider is listed as unplanned in a library coming out of the Go team.
- spraak 8y ago
  I mean, AWS is #1 so that makes sense, and then their own platform as their second choice to implement, that makes sense too. I don't think it's like a conspiracy that they haven't released the Azure support yet.
- vsekhar 8y ago
  See: https://news.ycombinator.com/item?id=17604358 https://news.ycombinator.com/item?id=17604358
skybrian 8y ago
Having some common types available seems useful for people writing portable libraries. Maybe it's not going to change the world for most developers, but it could help defragment the library ecosystem a bit.
pietroglyph 8y ago
> I like how Google tries to masquerade their corporate goals behind the 'portability' banner. This may further Google's corporate goals, but that doesn't mean it wont actually increase portability, or that it's actually a bad thing for people who want to avoid lock-in. > In reality, you have to break the cloud agnostic abstraction to leverage provider specific functionality. I agree this is a difficulty, but I think that it's also avoidable if you make a disciplined commitment to interoperability. Just as you have to put in the effort to use this new "portable" API, you also have to choose not to defeat the former investment. Saying that this API is useless because you end up using provider specific functionality anyway is like complaining loudly that something is broken when you're using it wrong in the first place.
weberc2 8y ago
Reminds me of the situation with SQL vendor abstractions. SQL even has a standard and it’s still difficult to migrate any nontrivial application.
- sethammons 8y ago
  ORMs immediately popped into my mind.
tybit 8y ago
Yes this is a strategic move on googles part, but that doesn’t make it any less valuable to consumers. Getting less lock in and more choice is good for everyone (except AWS)

by bhamta 8y ago

mfer 8y ago

Note, Azure support is filed under "unplanned"... https://github.com/google/go-cloud/issues/76 https://github.com/google/go-cloud/issues/76 Interesting that the #2 cloud provider is listed as unplanned in a library coming out of the Go team.

spraak 8y ago
I mean, AWS is #1 so that makes sense, and then their own platform as their second choice to implement, that makes sense too. I don't think it's like a conspiracy that they haven't released the Azure support yet.
vsekhar 8y ago
See: https://news.ycombinator.com/item?id=17604358 https://news.ycombinator.com/item?id=17604358

skybrian 8y ago

Having some common types available seems useful for people writing portable libraries. Maybe it's not going to change the world for most developers, but it could help defragment the library ecosystem a bit.

pietroglyph 8y ago

> I like how Google tries to masquerade their corporate goals behind the 'portability' banner. This may further Google's corporate goals, but that doesn't mean it wont actually increase portability, or that it's actually a bad thing for people who want to avoid lock-in. > In reality, you have to break the cloud agnostic abstraction to leverage provider specific functionality. I agree this is a difficulty, but I think that it's also avoidable if you make a disciplined commitment to interoperability. Just as you have to put in the effort to use this new "portable" API, you also have to choose not to defeat the former investment. Saying that this API is useless because you end up using provider specific functionality anyway is like complaining loudly that something is broken when you're using it wrong in the first place.

weberc2 8y ago

Reminds me of the situation with SQL vendor abstractions. SQL even has a standard and it’s still difficult to migrate any nontrivial application.

sethammons 8y ago
ORMs immediately popped into my mind.

tybit 8y ago

Yes this is a strategic move on googles part, but that doesn’t make it any less valuable to consumers. Getting less lock in and more choice is good for everyone (except AWS)