Earlier quoted context omitted.
Is it really accurate to call it an alpha when there are paying customers?
Not familiar with RBE in particular, but as a rule alpha/preview services are free.
The RBE alpha was not free.
Why I distrust Google Cloud more than than AWS or Azure
241–250 of 251 posts
Re: Why I distrust Google Cloud more than than AWS or Azure
#242[DISCLAMER: I used to work at Google in general, but not at Google Cloud] I'm not sure whether this has been discussed here before, but I'd love to take this forum to share an angle from the tech side of things: IMO, Google is _cursed_ to keep deprecating its products and services. It's cursed by Google's famous choice of mono-repo tech stack. It makes all the sense and has all the benefits. But at a cost: we had to…
I have also worked at Google (in an unrelated department) and completely disagree with this. Maintaining old code & services is a problem everywhere. Monorepo vs multirepo, monolith service vs microservices etc. all have nothing to do with it. There will always be a broken dependency, a service/API/library you rely on about to deprecate, new urgent security patches, an outage somewhere upstream or downstream which yo…
This makes sense. I do not work at Google, we do not have monorepo, and yet many problems feel similar.
The guys who maintain the company infrastructure introduce some changes, send an e-mail notification, and call it a day. The maintenance you need to do at your existing project to keep up with these changes does not count as important work, because it is not adding new features. Therefore it is important to run away from the project as soon as it stops being actively developed.
Re: Why I distrust Google Cloud more than than AWS or Azure
#243Earlier quoted context omitted.
I don't know exactly what's going on at Google, but the key feature request seems to be that one chunk of code be able to depend on a consistent version of the library interfaces. If it wasn't a mono-repo, you could specify a dependency as a particular version of the other repository. But if everything is in the same repository, and one directory of code depends on a past version of library code, then everything fall…
Maybe in java world it was different but when i wrote c++ and go code there breaking existing apis was extremely frowned upon and if they had to do it people usually sent you automated code edit PRs for this
This is about company culture, not the programming language. When someone breaks their API and someone else's code stops working as a consequence, will the first person get told to fix their API, or will the second person get told to fix their application?
Some companies may have a consistent policy about this, in other companies it may depend on which team happens to have more political power.
Re: Why I distrust Google Cloud more than than AWS or Azure
#244This definitely applies to Google's PaaS offerings. Google App Engine looks like a great solution except your app is now entirely stuck on a constantly changing platform. The drop-in components they offer are constantly getting deprecated and re-architected with no clear upgrade path. For example many of their original drop-in components were custom (Memcache, Taskqueues, NDB) and are now deprecated with no interoperability with the now recommended 3rd party components. If you depended on these components you now are either existing in a precarious purgatory or you need to rip out and replace all uses of those libraries which completely reneges on the PaaS value proposition
Re: Why I distrust Google Cloud more than than AWS or Azure
#245Earlier quoted context omitted.
> If you pay for services from Google, then it's a completely different story. We've used Appengine for 12 years now, and every time they've decided to deprecate services, there's always plenty of notice, a superior replacement, and usually lower costs. Really? I've had the complete opposite experience on AppEngine as a paying customer. I was using Python2 AppEngine with ndb and the Users API. Cloud Datastore + ndb a…
This sounds like a mis-characterization of the situation. It is not Google who have moved from Python 2 to 3, it's you . Google still offers and supports the legacy Python 2.7 runtime for App Engine, and will continue to do so indefinitely. The same is true about ndb and Firestore. It may be that you moved from NDB to Cloud NDB (Firestore), but nobody forced you to do it.
That's a fair point.
But I think it's not such a "free choice" when Google announces a service is deprecated given that they're notorious for shutting off their deprecated services. Once Google announces a deprecation, I think it's fair to assume an EOL could come at any time, and I don't want to be caught on the back foot when that happens with not enough time to migrate.
I see that Google now has clear messaging that they will support Python 2.7 AppEngine indefinitely,[0] but I don't recall seeing that messaging in 2019. Internet Archive only has snapshots of that page[1] going back to April 2020, which makes me think they hadn't made it clear until then that this was their policy.
In 2019, I just remember seeing scary warnings everywhere in AppEngine docs of "we strongly recommend you get off of Python 2.7." I talked to Google DevRel folks at PyGotham 2019 and asked them what was going to happen to Python 2.7 AppEngine. They said it was going away but they hadn't picked an EOL date yet.
[0] https://cloud.google.com/python/docs/python2-sunset
[1] https://web.archive.org/web/*/https://cloud.google.com/pytho...
Re: Why I distrust Google Cloud more than than AWS or Azure
#246While I'm not arguing the general point of the article, I will counter point one thing. > Will Google Cloud even exist a decade from now? This seems wildly speculative, and the likelihood of GCP, or its core offerings, not existing any time so soon is next to zero. Google has to royally fuck up for this to be the case, but even if it ends up being case, there will be a string of lawsuits lined up that will likely cos…
Keeping GCP running to satisfy their contractual obligations and continuing GCP as a product sold to the general public are very different things. Shutting down any enterprise product tends to involve ending sales long before you actually shut it down.
That's exactly my point, but I think you articulated it way better than I did.
Re: Why I distrust Google Cloud more than than AWS or Azure
#247Earlier quoted context omitted.
GKE in particular has a very high overhead cost per cluster. That's the only reason I bothered learning kOps and Terraform.
That is incorrect. It costs $75/mo and they give you that as credit. Also why use gke if you’re trying to learn kubernetes? Single instance kubeadm cluster is perfectly fine for that purpose (even better)
If you roll your own cluster without GKE, I believe you have to configure your own load balancers, ingress controllers, etc. Having some of that ready to go out of the box allows you to learn Kubernetes concepts more gradually.
Re: Why I distrust Google Cloud more than than AWS or Azure
#248[DISCLAMER: I used to work at Google in general, but not at Google Cloud] I'm not sure whether this has been discussed here before, but I'd love to take this forum to share an angle from the tech side of things: IMO, Google is _cursed_ to keep deprecating its products and services. It's cursed by Google's famous choice of mono-repo tech stack. It makes all the sense and has all the benefits. But at a cost: we had to…
I can tell you that having a multi-branch code management system doesn't make this easier. You will only pay the tax at a different point in time.
In the monorepo you are forced to update things immediately if something brakes. In the multi-branch system things will get unnoticed for a while. Until you have to update dependency A (either due to a bug, security issue or you want a new feature), and then observe that everything around it moved too. Now a lot of investigations start how to update all those changed packages at once without one breaking the other. I experienced several occasions where those conflicts required more than 2 weeks of engineering time to get resolved - and I can also tell you that this isn't a very gratifying task. Try starting a new build which just updates dependency D and then notice 8 hours later than something very very downstream breaks, and you also need to update E, F, but not G.
I actually preferred it multiple times if changes would lead to breakages earlier, so that the work to fix those would be smaller too. So that's the contrarian few.
Overall software maintainence will always take a siginficant amount of time, and managers and teams need to account for that. And similar to oncall duties it also makes a lot of sense to distribute the maintainence chores across the team, so that not a single person has to end up doing the work.
Re: Why I distrust Google Cloud more than than AWS or Azure
#249Earlier quoted context omitted.
Maybe in java world it was different but when i wrote c++ and go code there breaking existing apis was extremely frowned upon and if they had to do it people usually sent you automated code edit PRs for this
This is about company culture, not the programming language. When someone breaks their API and someone else's code stops working as a consequence, will the first person get told to fix their API, or will the second person get told to fix their application? Some companies may have a consistent policy about this, in other companies it may depend on which team happens to have more political power.
At least during my time there nobody was introducing breaking (at compile time) api changes wily-nily. What did happen was people would deprecate (or “sunset” as pms loved to call it) a runtime api that ppl depended on - i.e shutting down some servers. So splitting the monorepo would do nothing here unless you’re willing to run those services yourself.
Re: Why I distrust Google Cloud more than than AWS or Azure
#250Earlier quoted context omitted.
And FBI is still upset that Apple won't install a back door for them.
But they will let Russia. And bend to china.
"Let" Russia? I am pretty sure that Russia is the one firmly in charge of that decision, not Apple.
It isn't inconsistent to push back on government overreach where it is legal to do so, but conform where they have no other legal choice except dropping an entire market.
Or do you propose another solution?