My business is a heavy GC user (AppEngine, Datastore, CloudStorage, BQ, ComputeEngine, ManagedVM) and I couldn't imagine achieving what we have achieved in such a short amount of time on any other platform.
We (myself and another guy) started at zero and shipped our product in 3 months on what is effectively an infinitely auto-scalable platform where we don't have to do any devops or carry a pager. I'd much rather work on features than chores. =) 4 months later and we've had profitable growth and zero downtime (knock on wood) and we're hiring.
I would love to be proven wrong really, because I often look at their GC offering, and I /really/ want to dive in, yet I feel that I would risk having to migrate quickly in 2 weeks at some point because they are changing things significantly (either shutting down or other major change).
So to my question: for how long have these services been around in a fashion that is stable (feature-wise, quality-wise etc)? Is there anyone here with a longer history of using Google Cloud offering, able to comment on this?
EDIT: thanks to everyone who replied below. I think I'll give it a try :-)
Disclaimer: I work on Compute Engine, but I'm not a lawyer ;).
"Google may make changes to this Agreement, including pricing (and any linked documents) from time to time. Unless otherwise noted by Google, material changes to the Agreement will become effective 30 days after they are posted, except if the changes apply to new functionality in which case they will be effective immediately. If Customer does not agree to the revised Agreement, please stop using the Services."
https://cloud.google.com/terms/, Section 1.7b
Also, Sections 13.1-13.3 means even though Google promises nt to do something, you really don't have any recourse if they do it anyway and cause you damage.
Although in the grand scheme of things, not the worst terms of service document I have read. The mere fact the drafters addressed the issue is worth ... something.
I like that one. :)
I have a question though, is the prevalence of taglines in any way related to legal requirements? Do you have to stipulate that you aren't a lawyer when stating things because otherwise people to construe it as legal advice, or is it just a fun little identifier of how valid we should consider information to be (like it is in other acronyms of the same type)?
The reason we heavily regulate the practice of law is similar to the reason we heavily regulate the practice of medicine. If you screw something up, the consequences can be bad. If someone takes your advice thinking you know what you are doing, and you are wrong, that person can end up a lot poorer or even in prison. (Though some will argue we regulate it so lawyers can be the only ones charging high fees for legal advice!) Just like one probably shouldn't go around telling folks not to worry about their incredible chest pain and shooting arm pain unless they are a trained medical doctor, the same could be said for those that go around offering home spun legal advice.. ("Yeah man, if you ask the undercover cop if he is law enforcement, he HAS to tell you! Otherwise it is entrapment man...")
Also the reason you always see lawyers preface everything by saying "I'm not your lawyer.. This isn't legal advice... Yadda yaddda yadda" is because once there is an Attorney-Client relationship a lot of stuff happens. The lawyer has a host of duties to the client, from confidentiality, to competence, and many others. That obligation isn't taken lightly and many times if there is any doubt whatsoever whether or not there is an attorney-client relationship, the law will find in favor of one because --- well -- the lawyer should know better. Therefore lawyers will make it annoying clear they aren't your lawyer before spouting off some deep legal thoughts about whatever the topic of discussion is.
I kind of wish people did that for more things: "I am not theologian/windows user/empathetic person, but..."
If I have the same policy (support for 1 year) and I change the contract - the change will only take actual effect after 1 year.
I mean, I'm contractually bound today to provide support for 1 year from today, no? Am I just rambling, or does it make sense?
"We may change, discontinue, or deprecate any of the Service Offerings (including the Service Offerings as a whole) or change or remove features or functionality of the Service Offerings from time to time. We will notify you of any material change to or discontinuation of the Service Offerings."
"We may terminate this Agreement for any reason by providing you 30 days advance notice."
"We may modify this Agreement (including any Policies) at any time by posting a revised version on the AWS Site or by otherwise notifying you in accordance with Section 13.7..."
Stripe, for example, has a data portability clause that allows you to move card data to another payments processor that meets some compliance standards.
That's why I wouldn't build a business on Google, because they have a long history of killing things when they aren't wildly profitable/successful. A $10m/yr profit product is considered a distraction of valuable engineer time unless it has some ulterior goal for the company.
And I'm not saying they should change -- they do what's right for them. One engineer working on some distraction project could instead be moved to ads quality and end up making a change worth anywhere from hundreds of millions/yr to billions.
But they can't have their cake and eat it.
Express has, IME, excellent support, and I haven't seen any Google product (consumer or otherwise) shutdown "all of a sudden".
The ones people point to as examples of Google products being shut down were shut down with very long notice.
I do think that there is a very loud group of people who like to raise the "Google's just gonna shut it down tomorrow" line every time a Google service is mentioned, but it doesn't seem to be based on any real history of Google being any more prone than any other provider to shut down services (consumer or otherwise) on short notice or without a migration path. Maybe that loud group represents a real and commercially-significant feeling about Google in the market and not just a small, loud group that doesn't real effect the market for Google products. But I don't know what you can really do with that, even if it does.
I mean, when people think of AWS services, do "service and stability" really come to mind? IME it's impossible to reach a person unless you're a multi-million-dollar org, and Amazon itself tells customers that AWS services can go down at any time and it's up to the customer to architect the application to deal with it.
If I had to peg a reason AWS gets treated differently in the marketplace, I think it's probably some combination of a) AWS was first to market, and b) AWS revenue seems materially important to Amazon, while Google Compute revenue is a rounding error to Alphabet. Therefore, Amazon has a lot more incentive to keep, maintain, and grow AWS.
I am sorry to hear that, but I can assure you it's not the case. I'm an engineer on a newer (and therefore smaller) AWS service, and I help investigate customer complaints, from customers of all sizes, all the time. I'll also note that not only do we handle cases that come in via our paid support, we also do deep dives for customers who post to our service's forums and indicate issues.
On the other hand, Google takes my Android app off the play store with next to zero details on the reason why and I have next to zero methods to contact them. The only way I was able to get my app back was to remove features via trial and error to determine what part was infringing. Why would i partner with Google again for hosting?
Play is a low margin business per "customer" compared to cloud. This has direct impact on the type of support you can expect.
It makes sense that isn't true but I have to admit it is what comes to mind.
Really made me regret going with app engine a few years ago.
and let me know what you think? This is an iterative effort of course, so more changes to come. Thanks again!
If anybody has a special deal, it's probably Netflix. I suspect even half a million monthly is a smaller account to Amazon.
: https://aws.amazon.com/ec2/sla/historical/ specifically, not the current (better) one
If you plan to offer multi-lingual content, anticipate having viewers in that part of the world, and your content isn't something they would be interested in blocking, it's just a practicality worth factoring in.
Another reason is that I find the GC console a mess. I had to simultaneously use two versions of the console to get different tasks done; they didn't have one console that had all features of the system. Heroku was a lot cleaner and easier to navigate in this respect.
My company is running mostly on Google Cloud and I had just returned from a trip in China where I've verified it.
You can of course run in the AWS Beijing region which requires you to have a Chinese business presence with a ICP license.
It'll be interesting to see what happens now that Google is expanding its presence in China . I ran into some Googlers on the Maps team while in Shanghai - not likely a coincidence.
My pet peeve with cloud services and their web-based admin GUIs is that you have to use the GUI or the APIs to do anything. You can't capture the current configuration and then replay it if anything is misconfigured. You can't save or restore the config. You can't diff the config across versions. Most SaaSes don't even have audit logs, or if they do, they're too minimalistic to provide the ability to get a lot of detail or roll back anything.
My wish list item is a kind of "Puppet for GCE". I write my manifest, push them to the cloud, and stuff happens. If something isn't mentioned in my manifest, it gets deleted. Truthfully, I don't want to use a web GUI at all.
At the very least there should be a way to do an inventory of an account. Recently I needed to take over an older AWS account, and I wanted to find out what was in it — instances, load balancers, buckets, and so on. It's virtually impossible to do this with the management console since the ontology of possibly configurable objects is so huge and complicated, and pretty much everything has a computer-generated hash instead of a human name, so I was surprised when I couldn't find anything.
But part of my point was that while you can code together something with APIs, you still need to write the diffing and converging logic to accomplish what I suggested. For example, if someone has gone through the console and added something, so that you now have a conflict, you want to be able to resolve the conflict. First by either accepting or rejecting the conflicting change, and then, if you rejected it, remove it as part of the next push.
(I work at Google but not on Deployment Manager)
I published a very critical release to my Android app few weeks back and realized that it was not getting published at all. It took me a month to get the problem resolved.
I don't want to buy a cloud service where the support might be nothing more than bunch of "Help yourself" pages.
We've been very pleasantly surprised. The cloud team has been pretty awesome to work with, including lots of engineer<->engineer contact, walk-throughs of systems and code for critical dependencies, and solid support and collaboration. Exceeded our expectations.
I'd echo the sentiment here: my experience of the paid support for GCP has been universally excellent across Compute Engine, App Engine, BigQuery and Cloud Storage. This is across 30ish tickets, some of them quite complex.
The support personnel (and engineering!) also do best effort scanning of Stack Overflow, Server Fault, and per-product mailing lists. You can get links to those here: https://cloud.google.com/support/#community.
Disclaimer: I work on Compute Engine, but not in Support (though I do jump in and support customers!)
Edit: (posted too soon) my main concerns with putting anything on GC are around support, continued support / long-term commitment to the platform, ease of switching (App Engine was a very bad on boarding experience for me when I tried it a few years ago and required lots of GCE-specific ways of doing things in the code), and pricing differences that might make it cost way more in subtle ways to run a thing on GC.
I think it'd be good for Google to start fixing their story around support and commitment to products with everything else under the Google brand before people will be wanting to risk their infrastructure with that brand.
Like I mentioned above, we do have active communities on Stack Overflow, per-product mailing lists (in this case https://groups.google.com/forum/#!forum/gce-discussion) and Server Fault.
That’s... an interesting business model.
which has similar tiers of support.
That being said, Google Cloud support is overly expensive. $150/month Vs. $49/month for AWS Vs. $29/month ($174 minimum commitment over six months) for Azure.
I wish all them had a "per issue" tier. I want to pay for a single ticket/resolution. But at least Google Cloud and AWS don't have a minimum commitment period like Azure (even if Azure is cheap per month).
I'd likely rank them:
- AWS is best (alright price with no commitment).
- Azure is next (amazing price but lame commitment).
- Google Cloud is worst (high price, almost as much as six months at Azure!).
And before you tell me that they offer different things at those price points I DON'T CARE. All I care about is the minimum amount of money I have to pay someone to look at a technical support ticket for me. I don't care if it takes 1 or 48 hours, I just don't want to pay a lot. If I cared about responsiveness I'd be buying the gold plated support with telephone agents.
Google Cloud's $150 to look at one ticket thing really puts me off the entire platform.
Your basis for ordering is their support prices which is just a tiny tiny fraction of Cloud infrastructure pricing. Google Cloud is 50% cheaper compared to AWS. Which is huge. Also, thanks to ease of use (Cloud Shell, SSH from browser ..), Google Cloud will save you lot of man hours.
Also talking about commitment, you need to commit for 1-year / 3-year usage of resources and pay partial or full bill in upfront for discounts. Google beats those prices without any commitment.
Let's compare the Cloud providers on these factors.
It sounds like you're avoiding the generic Google in the same way you'd not buy something from Amazon vs. using AWS.
that's a massive lead (and it's sadly not commonly known). So I agree with you, we need to do better in the perception war, but Compute Engine is hands down the leader in cloud pricing.
Disclosure: I work on Compute Engine (and care a lot about our prices).
Other problem areas for GCS compared to S3/Cloudfront
1. SSL support for custom domains in GCS is lacking.
2. Also SSL does not work for domain-named bucket when using <bucket>.storage.googleapis.com/<object> form. You can only use https://storage.googleapis.com/<bucket>/
This makes using SSL for a static site hosted in SSL very difficult because you can't use relative URLs. Cloudfront has solved it by using URLs of the form http(s)://xxxxxxx.cloudfront.net/<object>
As far as GCS pricing goes (rather than egress), I think we've been more cautious on the "cost per op" but really led again on cost per byte. This was especially true when we launched Nearline, triggering AWS to launch S3-IA (but with lots of caveats like small files and still a 25% higher base rate).
While not integrated directly into GCS / GCP, does going through CloudFlare alleviate some of your concern?
Also cloudflare is a bit confusing. We only want to serve assets and we serve 3TB per month and I'm not sure if cloudflare is OK with that usage in its free tier option.
You have no idea what is actually being offered after reading that. Is it a managed service, a recommended configuration of what.
Almost every Amazon blog post includes a walk through on how you actually use whatever they are talking about. To be fair, this post does link to more documentation, but it's general purpose and describes a variety of solutions.
I just try to forget they are up there. I got to one person at Google, and when they realized I didn't want to advertise, it was "Go to the help boards. I don't deal with that stuff."
Do I still use their products--yes, but don't trust them like I used to. I usually avoid customer service like the flu virus, but thought Google would be different?
I guess they are big enough to not care?
There is a big difference between paying for one of the support offerings, versus being a free user. The status of free users is approximately: free access to the product but no support. If you want customer service then you need to open your wallet.
It's important to separate "I think the support was bad", which would be very interesting to a lot of people who work here, from "I didn't pay for the product so I didn't receive it". Did you pay for support?
You never know what you don't measure and test
Load balancers: Scale to millions of users seamlessly. No warming up, no tickets, ...
PubSub: You can send the whole Internet 10 times in a day through it. Google does that every day
Big Query: Its equivalent to spinning up a 100+ node cluster in a matter of seconds and it can process data at speeds of GB's of data per sec, I heard couple of use cases where the user was able to process at ~ 50 GB/s
Kubernetes: 1000's of nodes running 100's of thousands of containers.
Can't beat that!
Funny you should mention that. :) I work at Google on PerfKit Benchmarker (https://github.com/GoogleCloudPlatform/PerfKitBenchmarker). Not only can you measure and test GCP (and other clouds), but we're trying to make it very easy for you to do so!
(PKB doesn't have a benchmark for App Engine yet, though. Sorry.)
If we're down there is plenty of other alerting to notify us (mostly through Slack). That said, there isn't much we can do other than wait for Google to fix it.
It is part of the trade off that we have to consider, I'm paying Google for devops instead of paying a team to do it for me. If you've ever had to hire a 24/7 support/devops staff, it is a much easier hiring proposition to just rely on Google to do that for us.
IE. "Cloud ops"
If it's truly prohibitive for a single person to live in SF for $50K per year then we should be really concerned about the families that earn $50K from two minimum wage jobs, and need to support 1 to 2 children on top of it.
Also the job in question is "Customer Success", and consists in interacting with customers "through phone, email, and live chat" (from the job description). Those can very well be done remotely.
And many more people live on $50,000 or less everyday working in San Francisco, but commuting from somewhere else in the Bay Area with lower costs.
If you're going to force people to move to the Bay Area to work for you, you need to pay them enough to afford it. Good luck hiring though.
There are people out there paying 50% or more of their take home on their rent/mortgage I imagine - it's just not really considered to be wise move in most cases. 1200/mo for a 1 bed doesn't even sound that bad for what's supposed to be the most expensive city to live in America. I know people in DC who spend 1800/mo on a studio and that's pretty average. You could easily share a room and cut your rent in half if you were smart/willing.
While on one side the 3x rent rule might be just "good sense", most places won't consider you if your salary (or the salary of all tenants) isn't 3x your rent.
That seems to be one of the common and very popular requirements to even have your lease application put aside for consideration, that being income must be 3x the ask for rent. At least this was the case in Austin proper (i.e. inside the city limits, and inside the I-35, Mopac, 183 and Hwy 71 box), I saw similar requirements when helping a friend scout for a place in SFO.
When I was looking for a place I found a landlord willing to negotiate and haggle on the deposit since my income wasn't 3x the rent ask. They took a larger deposit, I signed a lease, wasn't late once.
As with everything, YMMV.
Yeah, that's the same question every scumbag landlord in America started asking themselves a few years ago when demand for rental units started going up.
You don't "need" to spend less than 30% of takehome on rent. If you assume you're going to be running in a treadmill your whole life, and you're satisfied working for subsistence only, then sure, go for it, blow half (or more) of your paycheck on rent. Lots of people in San Francisco and other expensive cities do this.
If you have life goals that don't involve being stapled to a desk forever, it's probably not such a good idea.
I managed to spend 3 years at university living on less than that. I've just spent the last 3 months interning for NZ$20 an hour (~$40k a year), much of that was spent paying about $260 a week for rent (paying rent for 2 places due to contracts). I managed to get along just fine.
Cost of living-wise, where I am isn't radically different from SF.
I know plenty of grown adults that have roomates, because they prefer the quality of accommodations they can afford that way to what they would be able to afford without them. (And not even in places with Bay Area-level high cost of housing.)
If it is unacceptable to you, that's fine, but don't pretend it has something to do with being "a grown adult".
It's a real stretch to say 50k is a livable salary in most of the bay area.
A reasonable approximation is to target no more than 25% of your take home for housing, but you can probably survive closer to 50% for a while if you must. So for 50k, you're looking at something like $800 - $1600 being manageable. You'd be much better off near the other end of the range.
I have tried it last summer and was quite disappointed. CPU-bound programs that completed in a few seconds on my own computer took about ten times as long on AppEngine despite similar nominal specs (GHz and RAM).
Disclaimer: I work on Compute Engine.
Not without risk of giving an argument from authority, your sources are inaccurate. As late as November of last year Snapchat was on stage talking about their broad AppEngine use. (I work on Google Cloud).
App Engine Product Manager here
(I work at Google, but not on App Engine)
If you run multiple modules at once (some serving the frontend, some for longer tasks w/task queues), you can have the best of both worlds and use different scaling options for each.
(I also work at Google, but also not on App Engine)
Google does give an additional level of comfort - seamless scaling, No-Ops, powerful Big Data tools, flexibility.
I'm going to shamelessly promote one of my opinions on this topic when it comes to BigQuery:
I'm going to bookmark this comment and come back to it when Google decides its getting out of the "cloud" compute business.
Why do you think they will do so?
I'm not just paying for a service. I'm paying because I know AWS is in it for the long haul.
This is great for Spotify, just as AWS was great for Netflix (considering both services are terrible at representing true workloads; they're both just control planes serving static content, videos or music). I don't see it dragging a ton of business into Google, just making their acquisitions easier for people who decide to start on GCP or migrate in.
Just my two cents.
Its the heart of their core competency. Its not their principal mechanism for monetizing that, though outside of the core advertising business its also an avenue that they seem to have made one of the most significant, longest push to make a route to monetization, even in the presence of large, dedicated competitors (behind Apps for Work.)
Obviously, any insufficiently profitable business from any vendor will eventually be closed down, either voluntarily or by business failure, but Google Cloud Platform doesn't seem like a particularly likely candidate for closure on any timescale on which any existing cloud platform would be reliable.
For "Google Scale" computing tasks. Not someone with tens or hundreds of virtual machines.
If Google wants to succeed in certain spaces, they need to commit to them for a duration, and evangelize them. I don't see them doing that anywhere as well as Amazon does with AWS.
Anyways both companies provide SLAs, phone and email support, and consultation for a price.
and Sundar (CEO) and Ruth (CFO) mentioned Cloud a lot on Alphabet's most recent earnings call. I'm not disagreeing that AWS is massively important to Amazon, but to say that Google (and Alphabet) aren't serious about Cloud is incorrect.
Edit: It seems to be on purpose, with the use of noscript tags.
I can access most of the sites I routinely visit without JS. E.g. The New York Times works better w/o JS because it doesn't block articles or count how many I've read.
And I don't really care if you you will or will not try to hack me if I visit your site with JS on. There are countless other sites who will try exactly that, so why shouldn't my default be "NO"? And if it's not the sites themselves, it's the shitty ad networks they all use; I don't trust those at all.
IMO it's the epitome of hipster arrogance to display nothing useful to people w/o JS.
What is the word for people who use the internet in some purposely crippled fashion, just so that they can complain about things not working for them? =)
Look at the names themselves CloudStorage Vs Redshift/s3, ComputeEngine Vs EC2. Cookies vs. Oreo.
AWS service names are a brand in themselves while Google service names are too generic.
Angel might be a bit more of a description. https://angel.co/gearlaunch
Anything more, feel free to contact me privately. =)
We are not stealth, but we also aren't the type of company that goes around pushing ourselves down people's throats. The people who are primarily interested in our product know about us through other channels.
That said, we are building the website out more really more from a hiring perspective. It is hard to hire people when all they get is a logo on a homepage. For now, just know that we are a startup that is actually profitable, building a great product that people want and we're growing like mad.
I just like to see what other people can achieve in 3 months of time, it's kind of a motivation for me :)
AWS' core product is AWS. They do a damn fine job of providing this.
GC's core is "who knows what" - they do a damn poor job of even making an offering if switch thousands and thousands of servers to - let alone thousands and thousands of man hours.
Ironically, Google has massive domain knowledge of how to run infra... Yet clueless how to adopt and support and foster companies other than google.
But I've been in the business of fork lifting many people to aws, for all the reasons you'd expect:
Find me a single ops eng on the market who has done scale in GC? Nope.
EDIT: may I please have a rebuttal?
Every user of appengine, for a start. You need to code to their datastore, but apart from that scaling is practically infinite - and completely invisible. We don't need to configure, provision or even * understand * load balancers or geographically redundant servers.
Concrete examples? The royal wedding website was served from appengine a few years back; I imagine you'd be impressed with how that scaled from nothing to phenomenal traffic loads and back again. And Khan Academy, Snapchat, and now Spotify ought to meet your definition of "done scale".
I also want to understand the cost doffs as a
I was at AWS for 6 years (left 2 years ago... today!), and I've always been a proponent of being more open and communicative with developers, but it rarely happened - I guess that AWS' PR policy and such are a big showstopper for these kind of discussions. Although, some individuals did their best (e.g. Jeff Barr) to try to share as much as possible.
It seems that the Google guys know how to do it.
Keep doing it. It will help your business a lot.
Is there a particular ticket (or tickets) you ran into trouble with? I can try to follow up.
It looks like the App Engine documentation was finally fixed. It used to say "If you do not specify a class, F1 is assigned by default." as recently as a few months ago. For a long time the default was actually F1. Then one day my costs went up unexpectedly. The default instance class had changed without notice (at least none that I ever saw). I didn't know that's what had changed though and I emailed billing support just asking what happened. Canned reply email after canned reply email with requests for tons of information they already have (including information I typed into the original support request form). They also had me take screenshots of my console (can they really not look up my information?). And sending me the canned emails takes a week for some reason.
I should probably point out this was billing support. I'm not sure if that's a different department or what but I'm pretty sure they have no idea what they are doing over there (or, at best, just don't have the time or interest to help smaller paying customers).
That said, this falls into that category of things where I can tell you "I'll follow up with the teams involved" but it's unlikely I'll be able to say more than that (unless any result makes it into a public blog post or something).
I will do what I can, though.
I am free to comment on posts about GCP here on HN. If there are workarounds, I can post them. If it's a bug I can comment as such and file it internally. I can express opinions as long as they're clearly marked as my own. I didn't have to take any training or end up on a whitelist; Google expressed their faith in my good judgement when they hired me. If nothing else, it was a morale boost to feel trusted to act responsibly.
At the other end of the spectrum, GCP has started building out in terms of large-scale engagement. Cloud has been a big part of Google I/O; now there's GCP NEXT as a Cloud-specific user conference: https://cloudplatformonline.com/NEXT2016.html. Building more in this space seems easier to me than a cultural change which encourages (rather than prohibits) customer and community engagement on the individual level, but perhaps I'm being naïve.
: I currently work at Google on Compute Engine; I formerly worked at Amazon, although not on AWS.
I used to work at AWS and the things we could say were very controlled. It could just be my team/managers though.
So for now I'm on AWS, using Postgres on RDS and deploying containers with ECS. ECS is a lot simpler than Kubernetes, but since my apps are pretty simple (a half dozen task definitions), it's not a big deal. I really hope Google adds Postgres to Cloud SQL at some point.
And, you can also run Kubernetes on AWS - we have a group focused on making sure it's an excellent experience.
I work for Google Cloud Platform; ping me if you'd like more help with either option.
I did check out ElephantSQL but my pricing needs are somewhere between their $100 and $20 plans and there seems to be a lack of configurability compared to RDS's parameter groups (e.g. enabling extensions).
> you can also run Kubernetes on AWS
I've had success turning up Kubernetes clusters on AWS for demo purposes, but I really don't want to manage a k8s cluster myself (anecdotes I've read about etcd failures / partitions especially scare me). Also I use Terraform for provisioning, and kube-up.sh is not something that fits into that paradigm. I've also made the mistake running kube-up.sh with the wrong arguments after a previous invocation that had created a cluster, which caused it to try and create a new cluster, which wiped the local cache of the previous cluster I had made, making kube-down.sh unable to automatically clean up the old cluster (so I had to do it manually in the AWS console).
The other thing I tried was the kube-aws CoreOS tool, which is nice, but it comes baked with a 90-day expiration due to TLS certificate expiration, so I'd have to set up some sort of PKI process to make that production-ready. All in all just too much work for a single person trying to deploy a small number of containers for small to medium sized projects; if I was a medium-sized company with hundreds of containers and some dedicated DevOps resources maybe it would be worth it, but for myself I'd prefer a turn-key solution like ECS or GKE.
Disclosure: I work on GKE and Kubernetes at Google
The current Postgres offerings are not great. ElephantSQL is extremely expensive compared to their offering: 4 cores, 15GB RAM, 1TB data for $1,000/mo. CloudSQL (2nd gen) with the exact same specs would be $370/mo. Aiven doesn't advertise exact prices until you sign up, so I can't compare, but I see that the number of instances (max 3 nodes) is very small, so not really an option.
I've resorted to running my own MySQL instance inside of Google Compute Engine and setting up replication and off-site backups myself. It's definitely not as convenient as Amazon RDS, but the rest of Google Cloud has some great features like Google Container Engine.
Would love to see an RDS-like solution from Google that runs in a project's private network and supports more than just MySQL.
With RDS one can create a postgres/mysql instance that shares the same internal subnet thus negating need to open it up to external IPs, something I had to do after much deliberation because whitelist individual instance IP is just too much pain.
[edit: I looked at the link, and created a test instance to make sure I wasn't missing on a config setting, still unable to use private network to communicate with Cloud SQL AFAIK]
(Many of the other features of VPC, such as a worldwide network rather than a regional one, were built in from day 1.)
> The differences between AWS networking and Google Cloud networking are significant. This due to the nature of how these services were designed. Google Cloud Platform treats networking as something that spans all services, not just compute services. It is based on Google’s Andromeda software-defined networking architecture, which allows for creating networking elements at any level with software. As a result, Cloud Platform can create a network that fits Google's needs exactly—for example, create secure firewalls for virtual machines in Google Compute Engine, allow for fast connections between database nodes in Cloud Bigtable, or deliver query results quickly in BigQuery.
> To create an instance in Google Compute Engine, you need a network. In Google Cloud Platform, we create a default network for you automatically, and you can create more as needed. Unlike AWS, there is no choice of a public network like Elastic Compute Cloud-Classic. In all cases, you create a private network, much like Elastic Compute Cloud-VPC. Unlike Elastic Compute Cloud-VPC, Google Networking does not have sub-networking, but it does have firewall rules, routing, and VPN. These prerequisites are not necessarily required for all Google Cloud Platform services. Google BigQuery, for example, does not require a network because it is a managed service.
> Most of the networking entities in Google Cloud Platform, such as load balancers, firewall rules and routing tables, have global scope. More importantly, networks themselves have a global scope. This means that you can create a single private IP space that is global, without having to connect multiple private networks, with the operational overhead of having to manage those spaces separately. Due to this single, global network, all of your instances are addressable within your network by both IP address and name.
> Another major difference between Google Cloud Platform networking and Elastic Compute Cloud-VPC is the concept of Live Migration. Under normal circumstances, all hardware in any data center—including Google—will eventually need either maintenance or replacement. There are also unforeseen circumstances that can happen to hardware that can cause it to fail in any number of ways. When these events happen at Google, Cloud Platform has the ability to transparently move virtual machines from affected hardware to hardware that is working normally. This is done without any interaction from the customer.
I too hope so.
In general I wouldn't want to run a relational database in Docker, especially not as some sort of generic cluster of containers; I'd want to give it its own VM with Postgres configuration settings specific to its resources (e.g. using pgtune).
Big Data is the core strength of Google Cloud. Good to see this move by Spotify!
> What really tipped the scales towards Google for us, however, has been our experience with Google’s data platform and tools. Good infrastructure isn’t just about keeping things up and running, it’s about making all of our teams more efficient and more effective, and Google’s data stack does that for us in spades.
What I really really liked about Google Cloud is the ease of use. Spin up a VM, start Cloud shell, SSH into your instance, install a bunch of software and you will know what I mean. It's "Quality" Cloud.
Additional things we liked:
- gcs is way more responsive than S3. also, was fairly painless to migrate our S3 buckets to GCS via the web console.
- peering with cloudflare lets us save on bandwidth costs!
- network load balancer has shown itself to be very reliable and solid for holding open A LOT sustained websocket connections.
- http load balancer has shown itself to be very capable of ssl termination & routing (love that we can route /api to our API servers, and the rest to our static servers). additionally, no pre-warming was required. when we did the datacenter switch, it was just 5 mins of downtime. didn't have to worry about pre-warming for our production load like we would have on ELB.
Things we didn't like:
- salt-cloud's driver for GCE is still lacking. Can't specify disk size for provisioned storage. Can't specify local SSD storage either. Also parallel provisioning didn't work. Something about PyCrypto not liking the way it forked. Not GCE's fault
- billing support non-existent unless you purchase a support plan.
- documentation still needs some work.
Disclaimer: I work in Cloud Support.
Getting shared-storage and indepedently operated/scaled compute clusters on top of that storage isn't easily achievable with the standard Hadoop stack, and building that on top of HDFS is non-trivial.