Makes me wonder.. if an internet shop can build a cloud platform, what does Google come up with? They must have sooo much experience, own tools, people, knowledge in that area, it's hard to imagine how far this can go.
Hopefully it will not be just a half-assed experiment again.
That's like saying that the Wii was produced by a card-game company, or that a wood pulp paper making company makes the Lumia 900.
Companies evolve; Amazon were experienced in managing a lot of servers, and where looking for ways to make money on that expertise (and on the less than 100% used server capacity, although I remember hearing somewhere that within 3 months of introduction, AWS required more server capacity than Amazon-the-store had at the time)
Specifically, Amazon was early to the party on cloud computing because Amazons usage trends vary so widely, their off-peak hours would leave them with thousands of idle servers.
Google has plenty of horsepower to spare, sure, but their usage pattern is much more planned for and expected, so launching a cloud required carving out resources for it, while Amazon just had to make use of excess resources it couldn't find a better use for.
Amazon's experience was a natural fit for PaaS systems. Amazon moved to a service oriented architecture years ago. And that meant that individual teams were responsible for the deployment of their services on hardware. That led to the creation of automation that made that sort of thing easy. Being able to add or remove servers from a deployment group, being able to press a button and push out a build to an entire cluster of machines simultaneously, that sort of thing. Amazon took their experience building those internal tools and built a similar set of systems and tools (AWS) that would be suitable for both internal use and for selling as a service to the public. And it's done well on both of those fronts, AWS has been successful and amazon internally has migrated a significant amount of their back-end services and website front-end hosting to AWS.
I was criticizing your expression. Amazon had A9 search and other ventures before AWS - they were far from being "an internet shop" even back then.
> I think you cannot deny that Amazon had "less to work with" when they started then Google has today. In terms of experience.
Indeed, but there was also less expectation. There wasn't any real competition, so they could get away with a hell of a lot less than Google can get with today.
Google sure is great at technology, but I think they're not nearly as great at doing business as Apple or Amazon are.
Cloud computing is all about creating a good blend of technology and business. If you don't get the business off the ground, you won't have the stamina to seriously invest in the technology, particularly in terms of building lean, scalable operations. Building scalable systems is perhaps 1% inspiration (distributed algorithms), and 99% transpiration (cost-effective operations). If you don't get it right, you'll be looking at this big red number below the line and will have to kill it. The fact that Google is already huge does not matter that much, it's not being big that's hard, it's growing fast and staying afloat.
Indeed, Amazon is an Internet shop. They'll sell anything to anyone, anywhere, and they do so for ridiculously low margins. That's a mighty competitor to be up against. Google on the other hand has never been very successful outside of advertising, and have only been a high margin business.
Not saying that Google won't be successful in this space. If they're willing to lose money on it they could achieve a sizeable market share comparable to Microsoft's. They lack Microsoft's gigantic sales network, but make up for in developer goodwill. However, catching up with the lean operations machine of Amazon seems infeasible at this point. What they could do is focus on their core strengths and open up their massive data sets and tools for all to use. So far they have been very reluctant to do so however, afraid to harm their core business.
I don't think that's the right analysis. Amazon and Google both offered cloud products at about the same time. Amazon had based their business on building out and provisioning tons of "plain vanilla" linux boxes, and then layered a virtualization interface on top. So that's what they offered.
Google had build a highly customized, scaling environment based on their own software layer instead of mere "linux boxes". And clearly it worked great for them. So that's basically what they offered with GAE.
But the problem in the market was that GAE was this weird custom thing, while Amazon was selling a "cloudy" version of the same environment all the developers were already using. So Amazon won -- the market wants linux boxes, even if they aren't as scalable or efficient uses of hardware as Google's stuff.
The point is: Amazon won by circumstance. They happened to have an internal product already that they could sell, and they did. Google had an internal product too, but for reasons beyond the control of its designers, it wasn't a good fit for the market. I don't think either of these has anything to do with being "great at doing business".
I don't know about "doing business" in general but as someone who is a very big fan of both Google and Amazon and who uses lots of services/products from both (but not Adwords as an advertiser), I know I would much rather deal with Amazon when it comes to anything related to customer service.
The thought of dealing with Amazon customer service fills me with warmth. The thought of dealing with Google customer service fills me with dread.
I love Google as long as everything is working, but they (still) really suck when you need to interact with them. And before anyone mentions it, yes, I know this is because "I am Google's product", not their customer, but ultimately that viewpoint seems to have become part of Google's culture and in many ways that does actually make them lesser than Amazon at "doing business", IMO.
Well, even when you're not Google's product - eg you've got paid-for top-tier GAE support - you still can't get 24/7 support, and the system is pretty much completely opaque, and able to be crashed by a single user consuming too many resources (I have caused this).
They're going to need to turn this around if they want to compete with Amazon, who have been very accommodating and helpful to us, even going so far as to send engineers to our offices to help us with aspect of our architecture.
Amazon did not get lucky with their products. They developed them over a number of years, constantly adapting to customer demands and trying various different types of services. Being able to do this is a luxury that start-ups cannot afford, they need to get lucky with their choices, but Google could have done it.
I wasn't making a GAE vs. AWS comparison though. GAE is not in direct competition with AWS. It's a product with a niche market and I wouldn't see it as a failure. It's just something else entirely than building an AWS competitor.
The argument I was making is that Google wouldn't necessarily have the experience in building a lean, scalable business operation that could successfully compete with Amazon Web Services. As a case in point, Google has been running an exact duplicate of Amazon S3 for a while now, but it has yet to really take off.
http://cloud.google.com/products/cloud-storage.html
> Amazon did not get lucky with their products. They developed them over a number of years,
EC2 and S3 today are virtually identical to the services they launched with. I don't think reality bears out your contention.
You're right that they had to add EBS later, but I think if anything that supports my point: the ephemeral "instance store" model was too weird, and customers really wanted something that acted like a virtual hard drive with persistent storage.
Sure, Android is a hugely successful way of protecting their advertising business by controlling the mobile platform. However, the revenue from Android is tiny compared to their advertising revenue, and negligible compared to Apple's revenue for comparable products.
True, but also a technology Google did not invent in-house but bought. Although i don't know how much of the original software developed at Android Inc. got into the first devices. That'd be interesting to know :)
> They'll sell anything to anyone, anywhere, and they do so for ridiculously low margins.
+1, no one ever seems to realize how important this aspect is. "Cloud" providers aren't competing with some fat margin software corp. AWS is a billion dollar business who's used to 1% margin, sinks 100s of millions in infrastructure, and is insulated from a lot of business pressures. Oh, and they control the vast majority of your market. That sounds like a pretty scary competitor.
> Hopefully it will not be just a half-assed experiment again
And that sentiment is _exactly_ why I won't trust my business to whatever they come up with. There's no knowing how seriously and committed they are. Sure, Amazon could do an about face, but they don't have that history, so I'm more comfortable trusting them.
Unfortunately they also have tons of bureaucracy and a serious lack of understanding and execution of great design, making it difficult for them to compete with startups and other, more flexible ventures.
They had a pretty neat fulfillment network before AWS.
Amazon is pretty unique in that they make a lot of their internals available as products, but even before that, the infrastructure was still impressive. What other online store do you use? :)
Yeah, but did they have their own server hardware, data centers, programming languages, CDNs, web frameworks, kernel developers, operating systems, invented new protocols and hosted all kinds of stuff on the internet for billions of users? ;)
But of course, i probably use Amazon for 80% of my online shopping needs, they rock!
Amusing. Your description fits very well for Google, Microsoft and Apple, if we leave server hardware aside, because I don't know exactly what hardware does Microsoft (or Apple) use in their own Datacenters. Does anybody know this?
As someone who has dealt with customer service from the companies Google is competing with in this arena, Google is either going to have to come in at about 25% of the price or seriously up its game in the customer service department.
Agreed. I've been using App Engine for a while and bad customer service is my main issue with it. I can tolerate poor support for free products, but not for business products that I pay a lot for.
Does anyone else think that they missed the boat? 3-4 years ago there was little competition. Now basically EC2 has most of the market. If they want to be successful they have to be not just cool but noticeably better than EC2 and it doesn't seem like google wins that way.
I don't know, EC2 isn't that great to begin with and it's pricing is really not impressive at all. The I/O absolutely awful. There probably is room for biggest companies to compete Amazon, especially Google if they take the business seriously.
When Gates and Allen launched Microsoft they thought they were too late, that there were too many other established companies in the market to be able to find a niche for themselves. When google launched web search was half a decade old and dozens of companies were in the market. When apple launched the ipod mp3 players had already been around for years and gone through many generations.
An absence of competition is a near certain way to gain market share, but the easy way is not the only way. If you have a good enough product you can steal business from the competion and even grow the size of the total market (as was the case with the ipod and iphone).
Not necessarily established companies, but people working on things that would become companies. They thought they were too late and they were pretty close to just going off and doing something else instead.
People still think the same sorts of thoughts today, as we've seen, and they are no more correct.
Are people going to no longer releasing stuff on cloud platforms? I have some loyalty to AWS mainly because I've already figured out how to make stuff work nicely on it. However, for whatever I release next I'd certainly consider a competitor. Particularly if they can provide better i/o performance than EBS.
Google and Microsoft have one advantage : they are already successfully selling to the enterprise(Google apps, Windows platform). Amazon is still in the process of figuring that one out. Google and Microsoft are also not afraid to compete in price, combined with the above it makes them the first credible competitors to Amazon dominance. Will be interesting to see how this plays out.
I think that, for a lot of uses, switching away from EC2 would not be terribly difficult if Google could provide superior service or even just a lower price. If you're just using the basic EC2 services, I don't think there is even any lock-in.
New startups will always be in a position to evaluate where to host their products. I think if Google can offer good service at a competitive price it might make sense for new startups to consider them.
I honestly don't understand comments like this (this is hardly the only one). You know absolutely nothing about their service. You know nothing about what they are offering, what their pricing will be, etc.
I have to guess that it's that people are comfortable with EC2 (I am -- great service) and almost want to hope-away anything that degrades the value of the thing that they do know.
The hosting wars are just starting. There are so many features no one is offering right now. E.g. I want to host my app and data in my own data center, but have an automatic fail over to a cloud provider.
A few issues/questions with that:
1) Local traffic: if this were an enterprise app hosted on premise, with cloud backup, but with some remote users, you'd need to be careful in network configuration. With firewalls, people also access local apps on different IPs than from outside. This may not apply, and certainly can be resolved, but would require some visibility for the provider into your network configuration.
2) Failover: To do this really easily as a service, you'd ideally run 100% of traffic through a third party service. Some of it would get directed into EC2/cloud provider of choice, and some into your colo datacenter. If you're willing to use something like CloudFlare for DDoS/etc. prevention now, this would be the same compromise.
3) Database: Dealing with all the replication issues. If it's static content, this is trivial. Otherwise, you have a consistency problem for databases, etc., and most cloud providers (especially Amazon) want to lock you into weird onsite proprietary data solutions which don't
The best system today is probably to host at a facility with great transport to Amazon Direct Connect nodes (e.g. SV1/SV5 in Silicon Valley -- I'm setting this up now), so you've got fast cheap ways to keep your databases replicated between AWS and the free world/your own colo.
For inbound traffic, for $20/mo, I'd just do Cloudflare; for higher end, you'd have a lot of choices to make. (I haven't tried the higher end cloudflare offerings yet; they do seem to address most of the shortcomings, and are still pretty cheap).
I really hate how confident tech people about shit they've never done and/or just read about on blogs. I understand that apparent confidence is a currency but it's not the only one.
I don't think you need to be 100% precise on every hn comment.
You can do DNS based failover (short TTL), manually or automatically, and it's the easiest to set up using entirely your own infrastructure. This works great if you can tolerate a variable length outage for customers, or where you're not using it to deal with outage, but rather just migrating load -- say provider A suddenly gets expensive, you can migrate away, but don't need to hard kill provider A, at least until any DNS cache has expired.
You can do IP based failover (various techniques -- anycast, which doesn't really work for most apps, making your own announcements of the same netblock, IP address failover below the BGP level/internal to a network, arp stealing on a subnet (not useful across providers but good for HA), etc.
You can use a smart proxy in front of your app (an F5 "Global Load Balancer", something you've developed yourself, nginx with minimal state, or an inexpensive service like Cloudflare or their 1000x more expensive Prolexic competition).
You can do the best thing for non-web apps, a smart client, which knows to go down a list of servers (randomly?) and find the closest or best one. More intelligence in the client = more better.
I've set up all of these except Anycast (which I'd actually love to do sometime, but RIPE jacked my /24) and Prolexic (because I don't want to spend $30-100k/mo). Which is the best really expends, but IMO at least having a plan (even if it takes a week) to switch hosting providers is worthwhile for everyone.
His first example is round robin DNS. Sorry, but the terms DNS failover and round robin are often used interchangeably when you're dealing with business continuity.
Yes, certainly there are other options that increase the complexity, but why not start there? While the impact to users on shitty ISPs or behind proxies is unfortunate, it is relatively easy to implement and low-cost.
Going beyond that increases the complexity and cost exponentially and is certainly not easy.
Yeah, RR is strictly returning a response of a set (>1 records, ideally) to select from each time. Being able to remove those entries based on outages (which really needs a short TTL) is an optimization.
Unfortunately some stupid resolvers cache a single answer set for a long time, but for some applications, you're willing to accept 1/x of attempts fail during an outage (just hit reload, or come back in a bit), since this costs ~nothing to implement.
The basic concept works great for NS, MX, and other protocols where they're designed to retry.
If Google can deliver a semi-decent IaaS offering that works well with App Engine IMO they will have a uniquely powerful platform.
App Engine is often criticized for being expensive compared to AWS, but putting together a production ready setup (i.e., automatic failover in the case of data center failure) on AWS isn't cheap since you need at least two of everything: multiple EC2 instances sitting behind a load balancer (ELB) and redundant databases (i.e., RDS Multi-AZ). I know because I'm setting up exactly this configuration right now for my DNS hosting service (http://slickdns.com).
But if Google's IaaS offering could fix all the fiddly bits that App Engine currently doesn't do (e.g., custom SSL, native binaries) it would surpass AWS in terms of functionality.
Selling bandwidth and white-label servers is easy. Building a production ready arbitrarily scalable web platform is much harder.
I have an extremely, extremely, extremely healthy level of skepticism. We do substantial business with AWS. When they went down and came back up, some of our data was damaged. I called my Amazon rep, who put me in contact with Amazon engineers, who helped us recover. Amazon can do that -- they're a service organization, and they're used to working with customers and making them happy.
Google's customer service, in contrast, has a raison d'etre of avoiding customers. As a customer, the feeling you get is mild disdain. This is necessary -- one support call for Google.com can wipe out the profits from thousands of people. This translate into how they handle the enterprise market. I use Google Apps for my organization. I needed to enable Google+ for a social presence. This required applying into a black hole which, for a long time, did nothing. Support e-mails went to someone who clearly was in the business of neither having nor giving out information.
Here's an experiment for you: Pretend you want to try Google App Engine, but your cell is not on one of the providers Google supports (I've been there). You just a credit card, and a willingness to spend a bit of cash. Try to buy some service. See how far you get.
I use Google internal to my organization for things like Google Apps; if it has issues, employees will deal, and it saves a big chunk of work and cash. For anything customer-facing, I really do want a partner whom I can talk to if there are issues, not a black box designed to reject support requests.
This really makes me wonder what took Google so long. Google practically defined large scale commodity cluster computing with mapreduce (2004). Amazon EC2 was launched in 2006. The closest thing Google has done was app engine, and my understanding is that was not a tremendous success.
Does anyone have any explanations why Google didn't move into this space earlier?
Google doesn't use VMs internally and they probably don't have a scalable SAN (EBS competitor) either, so they don't have as much of an advantage as you might think. Google bet big on a "legacy-free" stack (GFS, MapReduce, BigTable, etc.) and that has worked out great for their internal services but external customers just aren't willing to adopt it (see App Engine).
Perhaps they viewed AWS to be closer to the classic hosting company as opposed to Cloud vendor and their selling point was "scale like us, Google" vs typical RoR+MySQL.
I've always though App Engine is kind of a half-assed version of AWS, so maybe this time they're announcing something worthy of Google's brand. With all all the infrastructure knowledge they have I always felt App Engine was way too poor a service.
GAE sandboxes you with their proprietary libraries, whereas AWS lets you write for unix/windows platform with minimal sandboxing. If you want to write a LAMP stack, you can just write a regular old LAMP stack with AWS. With GAE, you have to learn their java/python server libraries, then their blobstore/google cloud storage/googleQL, and so on.
Thanks for the breakdown. I haven't used t he service yet but I can see how that would be painful to deal with, especially if one wants to move their service in the future.
App engine is a stepchild pos product. It should be deprecated and they should allow socket access, etc so that real web apps can be built on Google services.
for more about the subject here is an interesting read from a google insider talking about their lack of understanding platforms and service oriented architecture. http://steverant.pen.io/
If this includes some sort of public access to borg it could be extremely interesting. No more borg is one of the top 3 things I miss from my days at Google.
"It's the system that manages machines. If you want to run a program that uses x CPU and y memory on 100 machines, you don't specify which machines to run it on. Instead, you request 100 machines using a Borg library."
Competition is always healthy, but its going to be pretty tough for Google to launch something that makes our startup move away from AWS or Rackspace. EBS would be the main service to attack of Amazons.
They don't need to make me move away from AWS, as long as they're competitive I'll use them in parallel. As we've seen lately, having live fail-over is always a good plan when you're hosting with cloud providers.
I strongly prefer not to deal with Google in a business context. It's great when everything is running smoothly. But if things break down, there's usually not a damn thing you can do about it besides post to your blog and pray.
This is good news. We'll have cheaper prices all around! And with that article on Google having their own hardware manufactured, it may end up better than we think.
Shouldn't Google have done this before everyone started migrating off of GAE due to the price hikes, and before AWS pretty much cornered the cloud platform market, and before Dropbox cornered the cloud data storage/sync market, and before Heroku cornered the auto-scaling web services market?
I disagree. I think it's an easier market to get into - it's a proven market that is about to be commoditised (which is a lot of what Google is about).
No-one needs persuading that they need cloud servers now. If Google can produce a a)better, b)cheaper or even c)different service then they've got customers.
The most valuable customers are either on EC2 or their own private hardware. The number of companies who can trivially port their software to Google's new offering are a small fraction of the total market (when accounting for total $ spent).
There's an even bigger problem as well. Google hurt their reputation as a hosting provider when they significantly raised their rates without advanced notice. Companies want to know what their costs will be, and want to know that someone will answer their questions if they have support issues. Google has a negative reputation in both areas.
And where is Nokia, again? They have lost 95% of their value since they were on top, and while popular in other markets, have essentially abandoned the US.
I don't see that AWS has really "cornered" the market. They're leading because they're better, which is a different thing entirely.
Cloud services like EC2/EBS and (to a lesser extent) S3 are really fungible. It's comparatively easy to move between providers, or even to your own hardware if you want. If someone were to come along and offer a comparably performant and reliable service to AWS at half the price, Amazon's customers would flee like rats. Obviously the devil is in the details, but it seems to me like Google is better positioned to offer that kind of value proposition (c.f. Google Drive, whose retail price is already cheaper than S3) than Microsoft or Rackspace.
Basically: linux boxes are a commodity. You can't compete in this market on features. That makes Amazon's (admittedly) dominant position more precarious than it looks.
Something I think would make a good business is someone selling every "tier" of hosting and making transitions push button simple.
For example, press a button and get dedicated vps hosting for your cloud images, press another button and get dedicated physical hosting, press another button and you buy the hardware and switch to a colo relationship, press another button and you get your physical hardware overnighted to anywhere.
If the big players (hi, Amazon) don't do it, then set up IaaS as a Service:
• Push a button and my cloud images move from Amazon to Microsoft Azure to whatever Google's thing is (since that's ostensibly the discussion today). Include RackSpace, Linode, etc. as well for bonus points.
• Pay the bills for me. If Amazon won't handle migrating my images, I'll pay you 1% on top to take my money, pay the bills, and manage the change in billing when I switch providers. Here's your chance to advertise when you negotiate better deals with a competitor: show me how much money I could be saving.
• If I push the button, and there are really obvious things about my cloud images that won't work where I'm going - i.e. things you've tried to move and it didn't work for somebody else - detect that and say "nope, here's what you need to fix." It's not going to catch everything, but kind of like a virus database it should be constantly updated as you hit problems.
• I'm not asking you to do the migration for free. Well, if I want a free migration, I have to accept that it won't transfer perfectly and I'll have to debug it. Or, I can pay you an hourly rate to do the migration and set up a test environment on the new platform, and identify any problems.
I think you may be under the misunderstanding that AWS = EC2/S3. It isn't.
AWS also includes SQS, IAM, SWF, SimpleDB, DynamoDB etc all of which are proprietary with very Amazon specific APIs. As each new developer starts to use these it "locks" them into the platform as a whole. And since many of these are core services I just don't see customers moving to a competitor unless there is a massive difference in price/features.
Also don't forget: NOBODY offers the complete range of unified services that AWS does right now AFAIK.
That's where the money is. Yes, Amazon offers that other stuff. I'm sure someone buys it. I refuse to believe it's a significant fraction of AWS revenue without evidence. Huge numbers of successful sites are built on the core stuff. Are any large sites using the Amazon lock-in features? I'm certainly not aware of any.
I agree that EC2/S3 is where Amazon makes its money and I doubt any large site is using the other features. The services are new and are specialized in nature.
But people ARE starting to look at them and it is an area (PaaS) that is going to become more and more compelling for businesses in the future. And Amazon is right now is the only player I know of in that space. And every new user they attract could well be locked in for life.
But I think you're missing the point. Google App Engine (and Heroku for that matter) is a PaaS product. They were there first, and they lost to the commodity metaphor. You can argue that Amazon will succeed based on the quality of their offering, I guess, but not simply because it's "PaaS". The market has spoken, they don't like that.
PaaS hasn't lost - it's just a smaller market than IaaS (Infrastructure as a Service), and it will take longer to become mature.
IaaS is immediately useful to anyone who needs a Linux box. PaaS needs longer lead times for people to adapt to a new platform.
Amazon's approach to the PaaS market is probably a lot better than Google's.
Google went: here's a new set of APIs, write custom apps to use them.
Amazon let you host standard LAMP apps, and then slowly started offering parts of the stack as a service (oh, you need a database? Here, use our managed one. You need search? We have that. Load balancing? Just use ours, it's easier than doing it yourself.)
Except when you say "AWS has cornered the market", you actually mean "EC2 and S3 have cornered the cloud VM and blob storage markets". Every other AWS service has a ways to go before it can claim to have cornered anything.
No. I think of AWS now as a PaaS and whilst it is a tiny market it is a growth one and Amazon is the big fish. There are lots of companies offering database/search engine/queues as a service but none that offer all of them integrated under a unified security model.
Before I believe your "big fish" theory you'll have to show me numbers or some sort of convincing anecdotical evidence. Every day I see overwhelming evidence from my work that EC2 and S3 are widely adopted in the tech startup community. RDS is a very, very, very distant third. Everything else (beanstalk, elasticache, elastic map reduce...) is not even a blip on my radar.
I don't think ELB is the kind of thing you'd want to use if you weren't on AWS. It's only because they don't do better load balancing or let you build your own (with multiple IPs per box) that you use ELB.
Same with DynamoDB: the only reason I'd use it is because EC2 instances don't come with SSDs. Otherwise, meh.
Right, just a trivial matter of engineering right? ;)
Amazon has a unique advantage here because the systems and technologies needed to run the retail website are very much identical to what's needed to serve up a commercially viable PaaS offering to the public. So much so that amazon is moving rapidly toward self-hosting the web store on aws (a lot of it is already on aws today).
In contrast the way google runs their own services is very different (though in some ways more advanced) and not generally suitable to morphing into commercial cloud services, so they don't have that self-hosting advantage. They certainly have the know how to put out a decent offering though, especially now that the market has spoken so clearly on exactly what it wants.
It goes deeper than that. They've been working on Service-Oriented Architecture for over a decade. I think I heard that Monkeybagel was a satire of Amazon's SOA push.
Nah--I wrote that about Amazon's initial design for an internal-only enterprise backup system, which was created by an MBA and given to me to make happen. (I scrapped it in favor of hiring someone who knew how to do it).
I would love to have someone talk my ear off about the technology behind google's SOA. I have a little bit of experience in the area and the different solutions people come up with for the problems are fascinating.
Waiting for a market to mature before entering isn't the end of the world. As far as "cornering" a market goes, Wikipedia's example is perfect: "Large companies, such as Wal-Mart or Microsoft, are considered to have cornered their markets." Sure, those companies have a substantial base, but that doesn't mean their isn't plenty of room for competitors who can do very well (Target & Apple).
Google has enough resources to enter a market like this and have some instant credibility. We've seen it with Gmail, Google Maps, and many of their other services.
With other aspects of PaaS, Amazon is still gaining ground. SendGrid is probably the leader in mail services.
The market as a whole is still very young. It's very short-sighted to say that Google won't be able to compete with Amazon. And besides, do you actually have full knowledge of what Google is going to release?
In my opinion a digital market is never "cornered", Google simply doesn't know how to improve over those competitors, and how to provide users with a good enough reason to switch. If Google knows its clear that its current organization doesn't allow to pursue the right choices in some areas, and you can notice by looking at several recent "flops" (boutiques.com, g+,...) .
You can have all the money in the world and all the world class runners you want, but your team will still lose if you run even just on a slightly wrong track.
Hopefully it will not be just a half-assed experiment again.