Live data from Hacker News

Google and IBM still trying desperately to move cloud market share needle

techcrunch.com

151–160 of 256 posts

Re: Google and IBM still trying desperately to move cloud market share needle

#151

I don't understand why Google doesn't woo silicon valley startups more aggressively. Gcloud is actually a pretty solid service, far more usable at varying levels of technical expertise. A lot of nice integrated tools for high end users (EC2/kub8/cloud console/etc) that gives AWS a good run for their money, and (gcloud web browser, web console, gcutils) for devs not that familiar with cloud tools that are significantl…

> ...and churned out the occasional semi-corn founder who advocates for a gcloud stack... I got the impression that’s the deal with Pivotal. Some ex-Googlers recreated Borg as BOSH (Borg++). Since then they push GCP as their premier public cloud integration despite most customers being in AWS. Their docs on AWS integration blow chunks, and they took their sweet time delivering a (broken) version of PKS for AWS.

I work for Pivotal.

Our internal development environments mostly run on GCP, after migrating from AWS. We chose it because (a) it performs much better and (b) Google would give us the time of day, unlike Amazon. As it happens BOSH made that process manageable for most individual teams because of its design.

We do however spend significant amounts with Azure and AWS, to test our various systems on this platforms.

PKS came to GCP first because the opensource feedstock, CFCR (née Kubo) was co-developed by Pivotal and Google and was first developed on GCP.

As for chunk projection, I can put you in touch with relevant teams for feedback -- jchester@pivotal.io.

Re: Google and IBM still trying desperately to move cloud market share needle

#152
post #121
post #68

Earlier quoted context omitted.

"cloud isn't the big market" sorry lost me there

I'm not sure if you're up for not being dismissive, but I'd honestly like to be corrected if I'm wrong. When I think of this I first think of Digital Realty Trust (DLR), Global Switch, China Telecom, AT&T, Equinix, NTT, Tata Communication, China Unicom, Telefonica, .... True, a lot of their customers must be cloud vendors. At one point, I'm pretty sure AWS was a customer of Equinix in some parts of the world (and the…

Until cloud egress bandwidth costs come down, it will stay that way.

Re: Google and IBM still trying desperately to move cloud market share needle

#153

The reason for IBM's failure is pretty obvious. Their old school bare-metal servers at Softlayer are a good value, but the need for bare metal is decreasing with IO improvements like SR-IOV and real hardware level virtualization (ex HVM on AWS). I've also heard IBM is running that division into the ground. Their cloud offering sucks. Last time I was curious, I couldn't even figure out how much my server would cost. T…

Let us not forget the Google Maps price bump still fresh in everyone’s mind. That was a kind way of reminding customers that Google isn’t serious about cloud. Amazon costs go down routinely. Google costs go up or the services go away.

I once ran some services on GAE right before they hit us with a 4000% price increase and killed our startup right when it was beginning to gain traction. I will never get trapped into a mission critical Google offering again. That and their application graveyard automatically put Google near the bottom of every one of my list of competing alternatives.

Re: Google and IBM still trying desperately to move cloud market share needle

#154

Earlier quoted context omitted.

Let us not forget the Google Maps price bump still fresh in everyone’s mind. That was a kind way of reminding customers that Google isn’t serious about cloud. Amazon costs go down routinely. Google costs go up or the services go away.

Microsoft’s bias towards windows stunted it’s growth severely. It seems googles bias towards its ad-revenue based models is something similar. Specifically, googles inability to adopt a customer-service oriented mindset and customer-privacy will be its end. Is search really it’s core strength anymore? I’d think it’s more it’s ability to reindex in a day and filter out spam. Fundamentally, as long as google offers fre…

Finally, I posit that the app ecosystem, specifically that in iOS, is the killer weapon apple holds against google. Apple literally has infinite source of free developers who can crank out apps rivaling the quality of googles free offerings... all for less than ten dollars an app. iCloudsync has mostly killed google docs and google drives cloud sync advantage across the board. Apples app ecosystem literally is infinitely horizontally scalable, while googles app ecosystem can’t even offer competent customer service for five core apps.. hmmmm I wonder who will win. Ironically parts of iCloud sync are probably using a aws for sure and maybe even google cloud as backbone.

Re: Google and IBM still trying desperately to move cloud market share needle

#155

The reason for IBM's failure is pretty obvious. Their old school bare-metal servers at Softlayer are a good value, but the need for bare metal is decreasing with IO improvements like SR-IOV and real hardware level virtualization (ex HVM on AWS). I've also heard IBM is running that division into the ground. Their cloud offering sucks. Last time I was curious, I couldn't even figure out how much my server would cost. T…

Your Golang mention reads as a total non-sequitur. I'm not even sure what it means. I think you are mad that they didn't provide a way to pin dependencies built-in to the language from the get-go? But few if any languages provide that. In every case I can think of, package management is done by an external tool. The only exception is... oh right, Golang now builds it in, including the ability to pin old versions. Sure it took a while, but what does that have to do with anything else you say here?

If anything Golang is a counter-argument to your thesis about why GCP isn't taking off. You're right that Google has done abysmally with its commitment to keeping services running for the long haul. But Go itself has been remarkably stable and compatible over the years since its introduction. Far moreso than Python, Rust, or JS in the same time period.

Re: Google and IBM still trying desperately to move cloud market share needle

#156
I think by going the "enterprise playbook" route, with an Oracle guy no less, Google are ignoring the long tail at their own peril.

With the cloud market still relatively new, a lot of the adoption decisions, especially in small and mid-sized companies, are not made at C-level, but driven (directly and indirectly) bottom up from the technical teams.

And a major driver there is familiarity with the platform. And familiarity is driven by how easy it is to quickly set something up and play around with to see if it fits your needs. Even appeal for developers' private projects could tip the scales here.

And while Google isn't so bad on the technical end of this, they certainly are when it comes to signing up and to pricing. So, ultimately, AWS has a kind of bottom-up push that G can't match and certainly won't by playing the enterprise playbook.

Add to that their track record with killing services, and their generally less than approachable support, and it's no wonder they're single-digit.

Re: Google and IBM still trying desperately to move cloud market share needle

#157
post #110

Earlier quoted context omitted.

As far as I know, AWS has never abandoned a service. They deprecate services and occasionally make services unavailable for new accounts.

SimpleDB is probably a good example. You can find 5 year old threads discussing whether Amazon is going to kill it. But it appears to still be there.

The business value they’ve gained by earning the trust to not kill services is far higher than their cost to keep some old things in maintenance mode, I assume

Re: Google and IBM still trying desperately to move cloud market share needle

#158

The reason for IBM's failure is pretty obvious. Their old school bare-metal servers at Softlayer are a good value, but the need for bare metal is decreasing with IO improvements like SR-IOV and real hardware level virtualization (ex HVM on AWS). I've also heard IBM is running that division into the ground. Their cloud offering sucks. Last time I was curious, I couldn't even figure out how much my server would cost. T…

Your Golang mention reads as a total non-sequitur. I'm not even sure what it means. I think you are mad that they didn't provide a way to pin dependencies built-in to the language from the get-go? But few if any languages provide that. In every case I can think of, package management is done by an external tool. The only exception is... oh right, Golang now builds it in, including the ability to pin old versions. Sur…

It's an example of how they treat "old" code, services or otherwise. Fixup your code to use new version or you can't build. Replace "build" with "deploy" and you have the policy of GCP. Now it's been a few years and they may have fixed this, but Go was the only language I've ever used that didn't let you pin dependency versions

Re: Google and IBM still trying desperately to move cloud market share needle

#159

Cloud is where Google's reputation for killing products is really going to haunt it. Every time HN commenters complain about Google axing a service, there are lots of "you're making too big a deal about this, no one is leaving Google because they ditched Reader" responses, and for its consumer products that may be true. But decisions about which cloud provider to use are made by C-suite executives, and they absolutel…

At startups and even medium sized tech companies, these decisions are often driven by engineering/ops teams and not by executives. I was on a team trying to decide between staying with AWS and moving to GCP about a year ago, at a company that spends well over $1M/year on infrastructure. The fact that Google has a track record of abandoning products with active users and has repeatedly shown they do not know how to de…

I wonder how you get all this info about the backends behind cloud services. Nearly everything is a huge blackbox from my perspective. Personally, I deploy solutions to AWS too, mostly beanstalk with defined environments, cognito for user authentication, typical latte macchiato cloud user.

Still using my own server for anything in development or for personal stuff or file storage (have you looked at prices? It is basically free now). I mainly use cloud services because people want it fast and cheap but still need an option to scale the solution.

I am content with the services Amazon delivers, but I heavily expect some kind of bubble burst in the future. Development of infrastructure and management interfaces probably isn't cheap either.

So does Google have a better backend than Amazon or Microsoft? I couldn't tell. Only that Microsoft tends to be slower than the competitors, Google tends to ban random users and some of their own services, and just with that Amazon comes out on top. But the fear that a service is deprecated at one point is a permanent undercurrent.

Re: Google and IBM still trying desperately to move cloud market share needle

#160

Earlier quoted context omitted.

Your Golang mention reads as a total non-sequitur. I'm not even sure what it means. I think you are mad that they didn't provide a way to pin dependencies built-in to the language from the get-go? But few if any languages provide that. In every case I can think of, package management is done by an external tool. The only exception is... oh right, Golang now builds it in, including the ability to pin old versions. Sur…

It's an example of how they treat "old" code, services or otherwise. Fixup your code to use new version or you can't build. Replace "build" with "deploy" and you have the policy of GCP. Now it's been a few years and they may have fixed this, but Go was the only language I've ever used that didn't let you pin dependency versions

It's a fair criticism of the older versions of Go - it did not have good dependency management out of the box. Probably due to the famous Google monorepo and how they did not need to tackle that issue head on themselves. However the past few years Go has really addressed this problem, first through the dep project (which has your standard .lock file for pinning dependencies similar to Node) and now go modules (included in the latest Go versions). Now you get dependency management out of the box. Your point is valid but does not reflect the modern state of Go.
Post reply on HN