Eek - that's an oversight on our side during the PDF creation (copying from the github readme to Indesign) -- it was suppose to be on the PDF. We'll update.
Not exactly. Yes, I would probably characterize Firebase as a PaaS, but Google Cloud is much more than just IaaS, as it includes some PaaS components, like App Engine.
I would say the general idea behind Firebase is that it is designed to build fully functional applications without any additional components. E.g. you could serve your static web app using Firebase Hosting, manage users with Firebase Auth, use Firestore for data storage (the syncing features of Firestore are truly amazing if you're not familiar with them), and tie things together with Cloud Functions. Also, note that while Firebase was originally pretty heavily focused on mobile, especially native mobile, most of their services work great on the web regardless.
The other thing about Firebase (referencing the previous comment about it being a little weird as a "Cloud in a Cloud"), is that it essentially exists on top of GCP. For example, a Firebase Project is really a GCP project under the covers, Cloud Functions for Firebase are really some syntactic sugar on top of GCP functions, etc. While that can be a little confusing at first, it can provide some great value. We have apps where most of our backend is in GCP (e.g. running Node in App Engine Flexible, using Cloud SQL Postgres for our DB, using Cloud PubSub topics for our eventing system, etc.) but then we use Firebase Auth for our user authentication, Firebase Hosting to serve our React app, etc.
Yes, I'm a definite Firebase fan boy, but that's because I feel like I can be so productive with it, without needing to worry much about underlying infrastructure, while still being easy to integrate with the horsepower of GCP.
I see some Google Cloud folks in the comments, so question for you, if you're able to share:
There seems to be a general fear about Google potentially killing off a product, based on recent history [1]. Now I know most of these are on the consumer side of things, but you can imagine people's concerns if the same thing started happening to Google Cloud products. Is the GCP team aware of these concerns, (or is this just a HN crowd concern) and if so, are there steps being taken to address this perception head on?
When a company like Deutsche Bank [1] signs a 10-year deal, you can be sure that they have been convinced that the products they rely on will not go anywhere.
I don't work in cloud, I work in a completely different part of Tech. However, we do deal with big clients, and essentially it was always a different game for them- extended support for products, alpha/patch releases where necessary, because those businesses drive so much revenue and the last thing you want is for the corporation at an organisational level say "We're a <vendor> client".
That doesn't help the smaller developers though - you just have to hope that Deutsche Bank wants the same things you do, which is.... unlikely.
I think that would be one of the benefits of being Google (or Amazon, or MS) -- their cloud strategy isn't as beholden to a single customer.
Which means they may or may not do a good job of feature prioritization, but it's not always "whatever (big customer) wants."
FWIW, when I worked for a larger GCP customer, they seemed fairly decent at hearing about and addressing concerns. I realize cloud functionality (especially interfaces) is accreted over the years, and can't be delivered all at once.
Comment like this makes me wonder if you ever worked in enterprise before. Plenty of services/products have been cancelled/mothballed on large enterprise contracts once the services/products are no longer profitable, the services/products generally get sunsetted.
What if you aren’t Deutsche Bank? Parts of the products they depend on are mostly safe, what about features they don’t use, but my small shop depends on?
Shh... The product marketing-authored deck on common objections doesn't care about SMBs. No offense to the original comment, but that's such a rehearsed answer that as you mentioned is irrelevant (despite sounding good on the surface) to everyone else.
A contract like Deutsche Bank means dedicated GCP customer engineers, professional service engagements at the highest levels, direct conversations with individual product leaders/managers, roadmaps conveyed to their needs, alphas etc etc.
If it's irrelevant to the Deutsche Bank's of customers, then it's of course fair game to get f'd with.
That actually doesn't mean anything to me when I personally have had to deal with the shut off of many, many Google products and your competition (AWS) is better in every conceivable way.
> your competition (AWS) is better in every conceivable way.
Is that really true? I don't have a lot of experience with Firebase, just notifications and analytics, but working with Cognito and Amplify one- two years ago was like a bad joke, more similar to a fledgling startup than a well-rounded offering.
It rather seems to me that a lot of organisations are moving to GCP; BigQuery and its integrations with other Google products seems like a killer app, and GKE is seen as the better choice for hosted Kubernetes.
I'm still a fan of Red Hat's OpenShift, but I'm actually surprised how well Google seems to be managing their {S,P,I}aaS offerings and strategy in this space.
I had GCP kill my servers without warning because they claimed someone was mining crypto on them (they weren't). That alone was the permanent end to my business relationship with Google.
I should have known better though. Like I said, I've been through a lot of Google shutdowns and various screw jobs (remember the Google App Engine price hike?).
AWS is a professional product. It has warts but it's much more solid than GCP, technically and from a business perspective.
As a user of GCP, this really feels like a HackerNews meme that doesn't have any substance. I have never had a GCP feature killed, but I've had many AWS features mothballed. I am not really sure how to change the perception here since it's easy to say: "Google kills products-- therefore I will never use any Google product†"
We've had to deal with a few. They removed a gcs api a couple years ago and told you to update to the newest version of the sdks. obviously they didnt tell you which version it was actually fixed in, figuring that out was an adventure in itself. everyone's runs off master right? Worse, they hadnt even updated all of them by that point.
We updated to working versions, but support kept telling us we were using the old one. Turns out they didnt update the dataflow runtime, which they own and we cant inspect or update, and they were reporting it to us for us to fix...
What, exactly? AWS is legendary for maintaining compatibility. Steve Yegge's article gives a good break down on how infamous GCP's deprecation practices are.
I was lucky in that GCP killed off the feature I wanted before I ever used it, so I didn't have to get burned in production. AWS has never burned me. (GCP used to have a service to do transformations on images in object storage, which I learned about in an App Engine book. It took me a few hours of searching to even find the deprecation notice. Now I just use https://github.com/awslabs/serverless-image-handler because I don't trust GCP).
For me, AWS Opsworks. It felt like once containers came into vogue, they stopped working on the product and it was nigh impossible to switch back to vanilla Chef.
Oh, I misunderstood what you meant by mothballed. Still, that is honestly a good example of why AWS is so much more reliable than GCP. AWS will keep the service running as-is even if they don't make any changes to it. GCP would just deprecate it instead and kill it off completely. Maybe that hasn't affected you yet, but the available evidence says that it has burnt plenty of people.
We can't even be sure whether GCP itself will be around in 3 years:
> In early 2018, top executives at Alphabet debated whether the company should leave the public cloud business, but eventually set a goal of becoming a top-two player by 2023, according to a report from The Information on Tuesday. If the company fails to achieve this goal, some staffers reportedly believe that Alphabet could withdraw from the market completely. [1]
That's disputed and is not hard data, but there's not any positive reason to believe that GCP will exist after 2023 either.
That alone is more than enough to substantiate what I'm saying, but if you need more examples than just search or read HN a bit, due diligence, etc. I was personally lucky in that I got burned in the planning stages and didn't have to get burned in production, but I still wasted all that planning time and ended up having to use AWS instead.
I understand the problem you’re talking about, but the way you said “available evidence” made me think you had something more data-oriented than Steve Yegge’s blog post and HN comments.
Since you work at Google, you should be well aware of the deprecations. You don't need evidence of their existence, you just don't see it as a problem. Which you are free to do, since it's not a problem for you, it's just a problem for GCP clients, many of whose complaints you seem to be dismissing as not being "data".
GCP doesn't seem to provide a full list of deprecations, but the list for just one service[1] is pretty terrifying when you consider that your app might depend on two or three dozen services, and a deprecation in just one of them forces you to rewrite perfectly good code. A cursory search reveals a number of reports of being repeatedly bitten by deprecations[2][3][4], so no one should be mislead by the dismissals here. [2] has a good cautionary tale of a forced "upgrade" leading to potentially much greater cost.
I do work at Google: I’m not trying to dismiss the concerns and I understand that deprecations are a legitimate concern and carry a significant business cost. It sucks that you got burned a few years ago, and I totally get the why you lost trust in GCP.
I do think Google Cloud is trying to do better and the few deprecations I’ve seen personally have been heavily scrutinized and considered, with a clear migration path for users. I was only asking for data to objectively understand the problem as it stands today, and not to minimize your own experience. I know there are experiences similar to yours, but hopefully there are far fewer in recent years (but its always hard to tell without data).
https://github.com/gregsramblings/google-cloud-4-words -> this is where the PDF appears to be generated from, and it has searchable text of the content in its README on the main page, and links to docs on each, and the mobile content that got left off the PDF.
"Google cancels everything" is a meme, but AWS releasing broken pre-alpha products, letting old ones rot on the vine, and having crazy monetization schemes that are utterly inconsistent with marketing is not a meme, even though they do these things all the time. If GCP wants to win, they need to fix that, because "will I be blamed for the next shitshow" is the key question on every architect / purchasing manager's mind, and right now AWS is winning that battle to a degree that they do not remotely deserve because google is just MIA.
Hell, Google could coordinate with Walmart to hit AWS and Amazon at the same time because there is clearly, shall we say, a degree of cultural continuity between the Amazon and AWS business units.
If I had a dime for every time I see a convoluted architecture in our code that only exists due to the arbitrary hard limits in AWS I'd be able to quit and never again worry about arbitrary AWS limits.
I'm pretty sure they aren't arbitrary at all and are mostly due to managed and serverless offerings backed by duct tape and chewing gum. On a few occasions I have been left with all-but-proof that behind the "let us handle scaling for you" smoke and mirrors is a bash script on an EC2 instance sized by guesswork and hardcoded until you complain, at which point support might be able to shuffle it between instance types to eek out a bit more vertical scaling.
Yes, it's part this and part "let's get rid of the noisy neighbour issue by making everyone whisper" design philosphy. This just arrogantly pushes the scaling challenges back down to the customers who are then forced to buy more AWS services to build workarounds for the scaling limitations in front of them. For Amazon it's a win-win though and they'll keep doing this as long as c-suite fools keep buying.
I spent the first months 2020 building out a database-as-a-service offering that runs in AWS, Azure and GCP (think Cockroach Cloud or MongoDb Atlas model, but for a different database).
That was an instructive project - building the same service in three clouds tells you a lot both about:
- The quality and completeness of foundational services (identity, networking, compute, storage)
- The tooling ecosystem (the quality of the Packer builders and Terraform providers [1] in our case)
- How helpful (or existent) support is, which ranged from an account manager telling us up-front “here’s the way to avoid hitting limits for your design” to not being able to talk to a human at all throughout the entire project, and thus having to phase in beta customer onboarding for that cloud because of the arbitrary limits.
At some point that team should write a full retrospective on this.
[1]: Disclaimer - I have worked on both Packer and Terraform in the past at HashiCorp.
These are personal opinions, based on the project I outlined (and not what I work on now, necessarily!).
Technically:
- Google has the most reliable network, compute and storage (for a given size).
- AWS has the only comprehensible security model for identity, although it's still not complete (e.g. I can't grant a role assigned to an instance profile permission to `DescribeInstances` for itself only). I strongly believe IAM is the crown jewel of AWS, - but wish it would be completed to it's own potential.
- Google has the best "organisations" structure overall, though AWS Organisations is vastly improved over what it used to be.
- Azure's model for network peering between networks in different tenants is complete crazy town and will certainly result in outages when a customer disables the service account required to maintain it.
- Provisioning times in Azure are wildly variable - provisioning a VM with the same image in the same zone often had minutes of difference between fastest and slowest. The other two are much more consistent.
- The Terraform provider for Google is missing many data sources, and almost every type of resource we used needed patching in some important way.
- We had to build "surrogate" Packer builders for Google and Azure to make automation of scratch-build ZFS-on-root Ubuntu images with our platform customisations. I built the AWS version of that builder originally, so that was not much of a surprise.
From a support perspective:
- AWS and Azure were very willing to work with us in getting our service up and running even though we weren't spending a huge amount in the development phase, and it was easy to get in touch with someone to explain what we were doing and request advice.
- It was impossible to speak to a human at Google. Experiencing the kafkaesque automated account policies (e.g. "you can have enough cores to actually bring up a database cluster when you pay your invoice but we haven't issued an invoice yet because your account isn't a month old, and no despite being a company with a multi-year trading history you can't just put money on deposit to prove trustworthiness") actually prompted me to move my personal accounts off GSuite in case a problem ever arose.
Sadly the technical excellence of GCP in several important areas did not (for me) make up for the fact that they are impossible to work as a small business doing something that is not strictly happy path.
Ditto! Sometimes I wonder if the one largest skillsets of becoming an AWS “engineer” is learning to memorise the service names and how they associate to the service offered!
GCP has a few products that AWS doesn't. BigQuery ML and Cloud Spanner are a few that I can think of. These might have approximations on AWS, but not 1-to-1 feature competitors. Plus GCP has one-click integrations with pretty much every Google API out there (analytics, ads, drive, etc).
It's been a minute since I worked with AWS, but they have tons and tons of products. On the order of two, maybe three times as many.
The basic stuff like VMs, storage, networking, and managed postgres/mysql SQL databases are close, but the specialized services can be very different when you look at them closely.
This isn't exactly true. I have worked extensively with Azure, Google Cloud and AWS. While many of their basic services do seem to map 1 to 1 there are enough differences in the details that it's almost like learning a completely new system. At a very high level the basics are relevant, but the differences are much greater than you might expect.
After 2-3 years of working with one then the other, yes and no. They can be quite similar on some accounts, but not quite the same. GCP also has that very Google thing of having very slightly different yet still kind of competing products at the same time.
So does AWS. For just messaging there is SQS, SNS, Amazon MQ, Event Bridge, Kinesis, MSK and probably a couple more tied to product families like IoT and video streaming.
What kind of marketing? Google cloud is a highly complex B2B product. Do you know what salesforce or oracle sells? As both a developer and consumer, I have no idea.
Salesforce sells a CRM is about as descriptive as Google sells a cloud. The Salesforce ecosystem consists of hundreds of products which are together worth $200B+.
This is a point in GCP's favor, since it generally has sane product names. By comparison, to quote some recent Corey Quinn snark, AWS has Lookout for Equipment, Trainium, Glue Elastic Views and SageMaker Data Wrangler.
The major cloud providers REALLY need to focus on fixing years old bugs in their widely used offerings instead of launching new ones. I guess the incentives are out of whack tho, since a working and widely used but slightly broken offering will be used by their existing customers. But if a competitor beats them to the next major thing, they will lose customers as they migrate over to use it. So they're in a kind of arms race against each other to roll out new seemingly obscure offerings in case one of them becomes the next thing and sees widespread adoption.
I wonder if it would be possible to run a site where people submit and rate bugs/enhancements/workarounds in cloud products. E.g. AWS Config doesn't support service X or sharing ENIs across NLB target groups can ruin your day.
The AWS forums used to have bug reports that were ranked by upvotes. AWS didn't seem to pay much attention though, the highest voted bugs stayed that way for years with no change or acknowledgement. I haven't personally been on their forums in years so I have no idea if this is still the case.
It supports ranking, and you can even assign 1, 2, or 3 votes for a specific issue depending on how important it is to you.
Of course, this doesn't matter, because this is just where customers are told to go complain by support. It's like telling an upset child to shout at a wall to get their "feelings out".
A casual stroll through the list of suggestions will quickly uncovers hundreds and hundreds that would be a trivial fix, but has a huge impact on customers. Some of these have languished for years with either no feedback or "WONTFIX".
Azure Active Directory in particular has some shocking open issues.
My favourite is that you can't stop an App Service so that it stops spending money! You can only delete it. If you downgrade it to the Free tier, that removes features by wiping and corrupting you configuration. This keeps coming up over and over, and the response is: "We don't want to, shh, go away"
The next best one is that the Portal team absolutely refuses to implement a default region option in the GUI, forcing 100% of their GUI users to click through that unnecessary extra selection every single time.
What's the use case for something like "VMWare on Google Compute" is it just a API shim to translate VMWare API calls to GCE for companies that are trying to lift and shift to the cloud?
We use it, I'm not on the team that uses it. Basically a lift and shift of our backup data center which came with all sorts of improvements. It's quite a bit more expensive, the projects that it runs in cost more than the rest of our cloud costs in total. But the man hours we've done to set up those other cloud systems (Terraform) are much more costly.
It's a full managed (bare metal) VMware environment.
Basically you get a dedicated cluster of vSphere hosts, with VSAN storage.
Some use cases are: migrating to cloud (for all kinds of reasons, like not wanting to invest in own datacenters and HW anymore) without having to refactor applications, hybrid applications where the front end lives in Google Cloud but the backend requires a more 'traditional' environment, using the cloud for DR, ...
Yeah, I will need a "Google Cloud products in 4 words or less" in 32 words or less, for some cases.
On serious note, I also think it will be good for them, if they mention the 4 word explanation as a sub-title where ever they mention the name. Also applies to AWS.
If you need to publish this you have a product management problem. Arguably, some of these things are features not products, and should not be branded.
The level of complexity is overwhelming, especially for the decreasing marginal returns to effort for most companies for most of these services, I suggest that G and AWS need to take a new approach here.
I'm trying to figure out what the different colour headings mean. Perhaps green means they are keeping it, red means 'scheduled for retirement' and orange is 'we arent sure yet'.
Mobile (Firebase)
* Cloud Firestore: Document store and sync
* Cloud Functions for Firebase: Event-driven serverless applications
* Cloud Storage for Firebase: Object storage and serving Crashlytics: Crash reporting and analytics
* Firebase A/B Testing: Create A/B test experiments
* Firebase App Distribution: Trusted tester early access
* Firebase Authentication: Drop-in authentication
* Firebase Cloud Messaging: Send device notifications
* Firebase Dynamic Links: Link to app content
* Firebase Extensions: Pre-packaged development solutions
* Firebase Hosting: Web hosting with CDN/SSL
* Firebase In-App Messaging: Send in-app contextual messages
* Firebase Performance Monitoring: App/web performance monitoring
* Firebase Predictions: Predict user targeting
* Firebase Realtime Database: Real-time data synchronization
* Firebase Remote Config: Remotely configure installed apps
* Firebase Test Lab: Mobile testing device farm
* Google Analytics for Firebase: Mobile app analytics
* ML Kit for Firebase: ML APIs for mobile