Google Cloud revenue could be bigger than ads
uk.businessinsider.com
uk.businessinsider.com
This is where DigitalOcean and Vultr are profiting the most - publishing tutorials, explaining everything and helping to go step by step through the setup with simple notes and comments.
I can understand why they don't do that. Several reasons, 1) they assume people who are looking to build infrastructure in their cloud platform have some experience, if not, extensive experience with operation and building infrastructure. Second, there is a whole support model they sell. Lastly, they have partners to do training. IMO, AWS has done good job presenting intro materials to experienced operation folks in their reInvent videos.
I can go on to defend why I think the entry barrier exists, or how AWS can do better. Here is my only tip to any new AWS customers: your mileage is different so don' start plugging in a dozen AWS native services into your architecture just because everyone is using it. Start simple. In our case, we are forced to use two ELBs in front of our nginx and our router service, which eventually routes the requests to our app server. That's a lot of web servers passing traffic. There should be a native offering of Nginx and Apache IMO. ELB is garbage (I say this with a love and hate passion) if you want to replace Nginx / Apache entirely. Anyway, IMO, the major take away of building a cloud infrastructure is "instance is cheap to recycle [if you have the right tool]."
> This is where DigitalOcean and Vultr are profiting the most - publishing tutorials,
Are you referring to https://www.digitalocean.com/community/tutorials/ ? I find them useful, but some of the community tutorials are suggesting (maybe just me) wrong approach. I don't think DO is the first one, I remember browsing Linode content quite often back in the days.
Anyway, I think the gap is filled by developing a PaaS such as Herkou, on top of IaaS (AWS, GCE, Azure). Of course, you can build one yourself.
I haven't used Google Cloud for long but it had a fairly nice UI actually. And they put their cloud SDK (command line tools) in the Ubuntu Partner repository which I appreciate, makes it almost as convenient as using OpenStack services.
The real problem is not the branding, it's the sheer amount of products. Frankly, the branding should be at the branch-level (Network/Servers/Databases/Data Analysis) rather than at the bottom leaf.
DO is nice, and I use it for lightweight stuff like building a website, but only for that.
When you outgrow Digital Ocean and want to set up larger distributed infrastructure that spans datacenter and regions for high availability (and you hire the people that can run it), then AWS (or Google Compute Engine, Azure, etc) will be a better fit for you.
Lets look at Vultr, that is more complete option compared to DO in my opinion. You get click away following:
-backups
-ddos protection
-internal IP
-storage servers
-dedicated resources servers
With this I can scale up to rather large size. While this is not enough for some startups, for MVP and Bootstraping startups that's more than enough. And frankly once I will grow big enough to hire tech guys, I will just move everything either to dedicated servers or simply to Rackspace or Softlayer for premium cloud solution.
The whole point of my comment was - AWS, Google and Azure - all are loosing to the ones like DO and Vultr in smb market. And while it looks irrelevant now, what stops DO etc. to scale up and offer more services? I bet if not due to their enormous growth rate, they would be already doing this but for a year or two they must focus more on scaling rather than increasing number of products. Once they are ready AWS/Google will be forced to either buy DO for crazy money or rethink their documentation, offering, approach, business model etc.
If I had a small static site that could be served by a few dedicated servers, I probably wouldn't use AWS myself. But, for me, the power of AWS is the elasticity - I can scale from 100 servers to over a 1000 servers and back down to 100 servers in one day - and those servers are distributed across 3 regions. And I have nearly a petabyte of data in S3. If I ran my app on dedicated servers, I'd need to pay for 1000 servers to handle my peak load, and I'd need a large petabyte-scale storage array (well several of them for redundancy).
I'm probably biased in thinking that my use case is more what AWS is seeking since they provide a good API and powerful tools to enable exactly this use case.
I can scale Vultr from 100 servers to 1,000 in 1 day as well (most time this takes is to click things through, not sure if AWS have buy XXX servers at once but if they do, thats good then).
And once again, I am not saying about small websites/static sites. I am talking about startups. Companies that can grow XXXX% a month for first few months, companies that are very careful where they spend money and where they allocate resources.
- We nearly failed our launch due to failure to increase server capacity during peak traffic, Vultr didn't have any more instances in that datacenter. This happened a lot of times and support always answered "We don't know when we will add more capacity".
- Periodic network partitions. In the last two months we experienced a lot of network partitions both on public and private network, some of them lasting for about 2-3 days, our fleet beeing totally partitioned in 2-3 distinct blocks. Even new instances started had private network down (100% packet loss).
- Technical support. We opened a few support tickets asking when private network will be fixed. Usually they respond that everything is fine and I have a configuration issue. I reply with ping/mtr logs and finally they agree there is a problem (which can be easy tested by themselves anyway). Then, they fix the issue after 1-2 days. Good luck fixing this yourself when your external load balancers have no public network connection, and new provisioned instances don't have it, too :)
- They changed instance types. The instances started months ago have a powerful CPU at 3.6Ghz which is shown in all their advertised benchmarks against DO/AWS/etc. Now they are offering 2.4Ghz CPU which is about 60% slower. When I told them about this I received an predefined template response like: "Thanks for your inquiry, we are constantly revising our hardware to meet customer needs".
- They increased pricing. First, the instance pricing was 20% lower than on DO. Then, they changed the price as beeing the same as DO and added a 20% discount. Then, they removed this discount, just telling everybody that they ended the discount period, nothing about the price increase :).
So, we are in the process of migrating everything to Google Cloud. We've been testing it on a staging cluster of 10 nodes and everything works smoothly, so we are in the process of moving the production cluster too. Be aware of small instance types (f1-micro and g1-small), they have very small CPU capacity for production load.
Also, Google offers us a lot of hosted stuff we don't need to manage anymore: DNS, Mysql, Datastore, Object store, etc. We were using Amazon S3 before, but peering from other datacenters (eg Vultr Datacenter, DO) sucks, constantly getting network timeouts, increased latency, etc.
If DO started to offer things like load balancers, managed DBs as a service (similar to DynamoDB and RDS), and Storage (S3). That could change their business quickly. Somewhere between Heroku on AWS is the sweet spot IMO. Heroku is $$$ and very little to no flexibility and AWS almost has too many services now with no focus.
Their target market is large enterprises with massive IT departments staffed with people who "have quite good technological knowledge" - most startups/small companies have probably never fielded an unsolicited sales call from AWS while most enterprise IT staff are probably sick of hearing from them.
Second, pretty much every Google business other than ads could be described as "running on Google cloud" for some definition of Google cloud. Apart from App Engine (which is a completely separate starting point than the rest of GCE and is really more of a solution to Google internal tools than to enterprise customers), the initial cloud offering can roughly be described as "what is the MVP that can run both websearch and gmail". As they gain customers, they gain features.
(note: I used to work on Google App Engine [and Cloud])
Also, why are you comparing App Engine (Platform as a Service) with AWS (Infrastructure as a Service)? Wouldn’t AWS vs. Google Compute Engine be a better comparison?
They really need a us-east and a us-west. Not just for availability, but for latency-critical applications, too.
I never meet people who are. My sense is they're a distant #3.
Maybe they don't have the storage issues Azure does? Or maybe they're worse. Who knows.
AWS has indicated that the network is the bottleneck growing faster at a slower rate than everything else which has huge implications for anything network attached.
There is tremendous IP required to be competitive in the space and admittedly Google may well have built that capability for its own services.
still the number one thing holding Google back has got to be the fundamental lack of knowing how to be an enterprise oriented business. I suppose that can be learned just as Microsoft is learning to be a cloud business.
my final concern is their branding seems komplex I don't like Google "compute engine" as it doesn't flow off the tongue nor does the acronym. Google Cloud does but it's confused if they want to call Google Cloud compute and Google Cloud docs and email all cloud offerings... admittedly Microsoft blurs these lines too. Only AWS can claim to be be the clear compute cloud winner and not need to hide cloud usage numbers in SaaS offerings also sold
What storage issues does Azure have?
"I hope we're going to be the Android of that story," Hölzle said.
This seems like a strange wish given that Apple is making almost all of the money in that market. Surely their goal can't be 'the most popular but not particularly profitable cloud offering'.
Google's strategy with Android is not to make money off it directly. It's to ensure that there is always an open mobile platform with Google services and a decent browser that has a strong market presence. They're actually doing very well at that. But the mission statement for cloud services will be different and presumably include making a profit.
Imagine Oracle is going to push cloud as hard as possible - and they have fuckload of money/resource - (Because they know , their survival depends on cloud business in long term), when you consider big names like Amazon,Oracle,Microsoft are pushing cloud as hard as possible - again because all of them know this is the one of the most important and key technology of future world - , that kind of thinking does not sound very rational.If you don't have best plan , you are going to have hard time . It sounds like google don't have plan and don't want to focus on cloud as much as possible.
But GCP has some big gaps esp when it comes to the network and their firewall vs AWS' far superior security groups. Google has no way to chain rules together right now which can make configuring a pain. Google also feels as though it was really meant for everyone to be super user to take advantage of their web console vs AWS where the amount of ways to segment access is dizzying.
The other advantage Google has is simple no-nonsense pricing. The longer you run a machine, the bigger discount you get. That's pretty much the extent of their pricing schema vs Amazon with their whole reserved instances and you never really know if you're getting the best deal without breaking out Excel and doing some analysis.
I guess in the next few months, it will be interesting to see how they compare to low cost competitors like "Backblaze B2". https://www.backblaze.com/b2/cloud-storage.html https://www.backblaze.com/blog/b2-cloud-storage-frequent-que...
Far away in the sense of bandwidth, latency and transfer costs.
For (nearly) everything else, the opposite is true. Google Cloud stands out in the PaaS-world because of their excellent internal network.
While an excellent offer in their own domain, Backblaze B2 is not comparable at all.
Do you have a link to that memo from Pichai?
Probably the easiest way to illustrate is to take the other examples you gave (search, mail, and browser) and compare to G+. If you're a user and you are used to Yahoo or Altavista but you hear about this new Google search, you can easily check out Google search and start comparing how it works relative to your usual experiences. If you like Google search better, you just start using Google search as your primary engine. Done.
If you had been user@yahoo.com for years and hear about Gmail, you open a Gmail account, start sending and receiving email as user@gmail.com and if you prefer the new service, you set up forwarding on your user@yahoo.com account and tell friends and family to use the Gmail address. Done.
If you had been using Safari and hear about Chrome, you download Chrome and use it for a few days. If you prefer your old Firefox setup you leave Chrome installed or ditch it but if you like Chrome, you just start using Chrome. Done.
But social networking isn't the same as email or a browser or a search engine. It's about communication like email but unlike email, you can't just pick whatever social networking service you prefer and use it. For social networking (at least in the typical Friendster/Myspace/Facebook way we usually think of it), you need everyone to be on the same service in order to communicate with them. Switching services is a lot more work than switching a browser or a search engine and there's no relatively easy "patch" like forwarding for email. For a massive amount of people and orgs, Facebook was the first big social network that they invested their time in. It was the first one that really got widespread adoption among people who may not really do much else on the web. It was the one that your mom and your boss and your neighborhood association and your local bartender all joined.
And when G+ came along, plenty of people (myself included) checked it out because we like checking out new services and Google has put out several that are at least competitive if not definitive (gmail, search, chrome, maps, etc). I won't speak for everyone but I found it much nicer to use than Facebook. There was no Farmville spam. Sorting the contacts that were displayed on your feed or who saw your posts was much more granular and visual than Facebook. The mobile app was much faster and more attractive. It was already tied to your email, voice/video chat, calendar, and photo/video hosting if you had a Gmail account. At the time, Facebook didn't have a lot of these features.
But regardless of whether you liked it or hated it compared to Facebook, it turned out to be irrelevant. Because unlike switching from Yahoo to Gmail or Firefox to Chrome, switching from Facebook to G+ wasn't something that only depended on your interest and relative acceptance of change or effort. Because unless all of your Facebook contacts did the same, it didn't matter which you liked more. The real limit of these kinds of services is that they're not interoperable. And if one (in this case, Facebook) gets a "critical mass" of users who might be resistant to change or switching services, it's nearly impossible to succeed as a competitor.
The only real way it could succeed is by offering something other than Facebook (which is what they're going for now I guess) but they will never be able to succeed as a better Facebook even if they build one.
It was a much different situation with G+ vs FB -- Google was trying to compete for (often irrational) customers and had to convince customers to make the switch to a new social network when they already have a perfect usable social network that costs them nothing that Mom and Dad and the kids are already using so everyone is already there. There's a lot of friction in changing social networks since in order for it to he usable, not only do you need to switch but all of your friends and relatives have to switch too. In comparison, porting code to new API is much easier than getting Aunt Bessie to post her cat pictures on G+ instead of FB.
You can compete against a paid product with lower prices, but you can't compete against a free product with more free, you have to show real value, and G+ just doesn't offer that much value over FB for most users.
One thing people hate to do the most is learn something new. You have a bunch of engineers who already know ins and outs of AWS. Your stuff _works_. Would you consider moving it elsewhere? I didn't think so. Now consider that there are literally thousands of ISVs offering their stuff there, for whom porting to GCP means hiring more people, increasing complexity of the product (so that it could run everywhere), etc. Why would they pick GCP instead of e.g. Azure, which has _insane_ level of sales access to enterprise accounts?
I'm a big fan of AWS, but I purposely avoid using too many AWS services that would lead to me being locked in and able to move if I wanted to. Porting deployment scripts to another API isn't too hard, but having to build and support my own replacement to SQS or DynamoDB (and then port my services to the replacement system) adds a lot more to my costs
DO has a nice product for relatively unsophisticated users that just want to build a website. But when you want to move a large application that spans hundreds or even thousands of servers and scales up and down to meet demand, you're not going to run it on an unsophisticated provider.
You're going to want a provider with rich service API's and enough capacity to let you scale your infrastructure as needed.
Most of DO's customers are not in the target market for AWS or GCE - while those users provide decent revenue from a small amount of compute resources, Google and Amazon are looking for the larger corporate customers that are willing to purchase thousands of compute units and terabytes (or petabytes) of storage.
Hmm, maybe things have changed since, but last I checked their offerings were more expensive than any of the main competitors by a nontrivial margin.
http://www.rightscale.com/blog/cloud-cost-analysis/google-vs...