Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



> 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.


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.


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


ORMs immediately popped into my mind.


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)


Note, Azure support is filed under "unplanned"... 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.



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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: