Why I think GCP is better than AWS
AWS is the best platform to showcase how great GCP is…
I originally posted this on Reddit so I could get a good sample of opinions from other engineers to see how they compared to mine before posting and expanding here. This is my opinion based on my experience with both platforms (two years in each). My bias towards GCP is mostly based on the superior experience I have gotten with it and I am in no way affiliated with Google. AWS is still my second choice as an enterprise option for cloud platform and it would be nice for them to do better. I welcome your comments and corrections, especially if they are informed and constructive, I am happy to learn from you.
Ikea for Cars
If AWS (Amazon Web Services) and GCP (Google Cloud Platform) were both car companies and you wanted to purchase a car, AWS would give you the wheel, a chunky verbose manual and the keys and then tell you to go to twenty different shops they also own to get the rest of the components to put them together yourself the best you can. Sure, maybe you can hire a service and get tools to automate this part, but it still falls on you to assemble these components together and maintain the automation.
The experience of GCP on the other hand is more like collecting the car keys and driving off from the parking lot, with the option of dismantling and customising the car if you wish, but the default is a fully built functioning car with cohesive parts so you can quickly achieve your objectives, which is driving around, not assemble the car.
My first experience working with AWS, before I had much to compare it to, was brief and I didn’t like it; I felt the interface and the way tools and settings were organised was counter-intuitive and weird.
For example assigning a static ip to a server was just bizarre, I kept looking for ways to assign the static ip without knowing that it was meant to be called elastic ip and hidden away in a separate set of menus. These elastic ips were part of a different pool of ips than the ones that were assigned dynamically, so I had to stop a production server to change the ip and also change the DNS pointing to that new ip, this was because my predecessor hadn’t assigned an static ip to the server, my bet is that he probably gave up after ten minutes trying to figure out that it was called an elastic ip.
My second experience working with AWS was after a year and a half working with GCP, and now by comparison I really couldn’t stand AWS, it took me a few months to get accustomed back to use it and I remember that in my first few weeks I actually considered quitting and just accepting GCP roles.
It’s not that AWS is harder to use than GCP, it’s that it is needlessly hard; a disjointed, sprawl of infrastructure primitives with poor cohesion between them. A challenge is nice, a confusing mess is not, and the problem with AWS is that a large part of your working hours will be spent untangling their documentation and weeding through features and products to find what you want, rather than focusing on cool interesting challenges.
Let’s just go over a few of the things that make AWS such a pain to use and how it compares with GCP.
Accounts vs Projects
One of the first differences that strikes you when going from GCP to AWS is accounts vs projects. In GCP you have one master account/project that you can use to manage the rest of your projects, you log in with your company google account and then you can set permissions to any project however you want. So you can have a dev project, a production project, etc. All of this works out of the box and there is absolutely nothing additional for you to do.
In AWS you have accounts, and each account has a separate set of users. There are ways to connect these accounts so your user has permissions on other accounts. One way of doing this is creating a master users account and then adding roles that can be assumed in all other accounts by this master account.
This is not only a pain to set up, it’s very painful to use as well. For example when using terraform scripts you need to coordinate multiple roles across several modules if you need to work across multiple accounts.
Command Line Interface Tools (CLI tools)
Let’s just compare what you have to do in order to use GCP cli compared to AWS provided we are using 2FA and a couple of different projects/accounts.
In GCP after you install the Google SDK, all you need to do is run gcloud init, which redirects you in the browser to a Google login page. Here you can login with your 2FA (which if you have an android phone is as easy as unlocking the phone and pressing okay) and you are done. Your login session is attached to your Google session so when you kill this session you are logged out— very simple.
In AWS you need to create a token that you can use to login with your CLI, simple enough, right? But now we want to use 2FA, and this is where the fun begins.
After you login with your token you then need to create a script to give you a 12 hour session, and you need to do this every day, because there is no way to extend this.
Okay, but that’s not a big deal, you say, after all it’s just a code that you need to input once a day and you can get on with your day after that.
But wait, there is more! If you need to assume roles in another account, you need to create yet another script that creates another profile for you to use.
That’s one step plus two scripts, plus many steps in between. And sure, you can automate much of this or use someone else’s tools you find online (that you most likely will need to tweak), but why? Why do we have to do so much work to use AWS? Why can’t AWS abstract away this pain away from you in the way that Google has done?
Web User Interface
If using the CLI is too painful for you, you can always log in to the portal and use their user interface, although I don’t recommend you do this for everything, in fact I recommend you use it the least possible and only for reference and to check status of your services, always do infrastructure as code as much as you can
The AWS interface looks like it was designed by a lonesome alien living in an asteroid who once saw a documentary about humans clicking with a mouse. It is confusing, counterintuitive, messy and extremely overcrowded.
I can’t even count the times I’ve gotten lost or stumped in the AWS console, sometimes over the most stupid details, like missing that there was a next button hidden on a weird corner. Or trying to use search bars that can only search prefixes (WTF?)
But the biggest frustration I have from the AWS console is how you are always overwhelmed with scores of settings and options you need to fill in before actually provisioning anything.
One example that comes to mind is when someone at work said we should use codebuild/codedeploy to replace Jenkins for ECS deployments. The first engineer tried, he got stuck, the second engineer tried, he got stuck, I tried for hours and I got stuck… in the end I just gave up for lack of wanting to spend any more time on a tool that doesn’t seem to be that popular for CI/CD that I thought was meant to make life easier.
Amazon seems to be particularly terrible at interfaces in almost all of their products though. For example in my Smart TV the Netflix app works flawlessly and is intuitive to use whereas the Amazon Prime app is an abomination, you are constantly accidentally pressing the wrong button or getting lost or the subtitles are often out of sync.
In a rant that a Google engineer who had worked at Amazon wrote a while back he explained the issue with Amazon and Bezos not understanding interfaces (or is it human interaction?) like this:
Jeff Bezos is an infamous micro-manager. He micro-manages every single pixel of Amazon’s retail site. He hired Larry Tesler, Apple’s Chief Scientist and probably the very most famous and respected human-computer interaction expert in the entire world, and then ignored every goddamn thing Larry said for three years until Larry finally — wisely — left the company. Larry would do these big usability studies and demonstrate beyond any shred of doubt that nobody can understand that frigging website, but Bezos just couldn’t let go of those pixels, all those millions of semantics-packed pixels on the landing page. They were like millions of his own precious children. So they’re all still there, and Larry is not.
GCP’s user interface is on the other hand very intuitive to use and whenever you want to provision anything you are given sane defaults so you can deploy anything in a couple of clicks, I have never gotten lost using GCP or needed to consult a million pages of documentation to find out what I needed to do.
This however does not mean that GCP is taking away from you the power to configure things to an intricate detail, it just means they are giving you an example of a working configuration that you can then tweak to your purposes.
There are also other things you can do from the UI in GCP that either work really badly in AWS or are non-existent. For example you can easily open a terminal and ssh into any instance you have spun (provided you set permissions for it) and it works really well.
Another feature you have in GCP that I absolutely LOVE is the ability to view the CLI command that would do whatever settings you have in the console. That makes learning the cli so much easier, it’s far better than scouring the net for examples on how to do anything or trying to make sense of AWS’s gorgeous documentation…
Documentation
You can forgive the documentation in AWS being a nightmare to navigate for being a mere reflection of the confusing mess that is trying to describe. Whenever you are trying to solve a simple problem far too often you end up drowning in reference pages, the experience is like asking for a glass of water and being hosed down with a fire hydrant.
Great documentation is contextual, not referential. If you wanted to learn how to cook a dish, you don’t want someone to point you to a list of ingredients, you want a recipe describing how to use them, and this is where AWS documentation too often fails; it exhaustively describes everything that they have (which is not bad), but they don’t always do a good job at putting the documentation into context.
To be perfectly fair to whoever is tasked to document anything in AWS, it is a lot harder to document something that’s confusing and messy than something that’s simple to use. Extensive and overly verbose documentation is often a sign of complicated and over convoluted software or processes, so in this sense Google Cloud already has an advantage to begin with.
The big problem here is not that AWS doesn’t document enough, in fact it may even document more than GCP, the problem is that documentation is not a substitute for automation. Take this example of long document (that leads to many other documents) telling you how to deploy the alb controller in EKS. All of this incredibly long and tedious process should have been automated by AWS so when you run EKS you can opt whether to have this controller installed or not with a tick box or a cli parameter or an extra option in terraform, as it’s the case in GCP. Instead AWS forces you to go through this lengthy documentation and put this together yourself, which can easily take you a day or more if you want to test and understand everything thoroughly.
The documentation in GCP is generally more clear and concise because they don’t need to teach you how to build everything from scratch like the above example, and while it may not always be perfect I generally found it useful and to the point. If you want other good examples of great documentation look at DigitalOcean — they are great.
GKE vs EKS
If your intent is to use Kubernetes, don’t even bother with AWS, their implementation is so bad I can’t even comprehend how they have the gall to call it managed, especially when compared with GCP
In GCP if you want to spin a cluster, no problem, just a couple of clicks and you are there. The defaults are easy and sane and the entire product feels very cohesive with all the ugly, tedious bits abstracted away from your experience.
With GKE you don’t need to join the nodes, you don’t need to plan or automate for an upgrade of these nodes either, or go through this abomination to use ingress, it’s done automatically or with a couple of easy clicks, and this does not mean you are sacrificing complexity. You can customise a lot, but when presented with sane, simple defaults, it’s a lot easier to understand a product that when being overwhelmed with a barrage of options and trying to figure out how everything fits together as it’s the case with EKS.
̶S̶p̶i̶n̶n̶i̶n̶g̶ ̶a̶n̶ ̶E̶K̶S̶ ̶c̶l̶u̶s̶t̶e̶r̶ ̶g̶i̶v̶e̶s̶ ̶y̶o̶u̶ ̶e̶s̶s̶e̶n̶t̶i̶a̶l̶l̶y̶ ̶a̶ ̶b̶r̶i̶c̶k̶.̶ ̶Y̶o̶u̶ ̶h̶a̶v̶e̶ ̶t̶o̶ ̶s̶p̶i̶n̶ ̶y̶o̶u̶r̶ ̶o̶w̶n̶ ̶n̶o̶d̶e̶s̶ ̶o̶n̶ ̶t̶h̶e̶ ̶s̶i̶d̶e̶ ̶a̶n̶d̶ ̶m̶a̶k̶e̶ ̶s̶u̶r̶e̶ ̶t̶h̶e̶y̶ ̶c̶o̶n̶n̶e̶c̶t̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶,̶ ̶w̶h̶i̶c̶h̶ ̶a̶ ̶l̶o̶t̶ ̶o̶f̶ ̶w̶o̶r̶k̶ ̶f̶o̶r̶ ̶y̶o̶u̶ ̶t̶o̶ ̶d̶o̶ ̶o̶n̶ ̶t̶o̶p̶ ̶o̶f̶ ̶t̶h̶e̶ ̶p̶r̶o̶m̶i̶s̶e̶ ̶o̶f̶ ̶“̶m̶a̶n̶a̶g̶e̶d̶”̶
EDIT: From the time I worked with EKS to the time I wrote this article, AWS added managed node groups. However when going through the console creating EKS resources you still have to go through a lot of options and screens. Also managed nodes need to be created after provisioning the cluster going through yet another set of options and screens. While this is definitely a welcomed improvement, the underlining design ethos that applies to most of AWS is still in EKS, which is what I am ranting about here. Thank you to the EKS team for bringing this to my attention and please don’t take this as a personal attack, I have every confidence of your competence and you are not to blame for the organisational structures that may compel you build products this way.
And yes, I know that there are official terraform modules that take care of most of this work for you and make the job a lot easier and there is also a tool called eksctl developed by Weaveworks which is great, but these aim to simplify a complex solution that should have been abstracted away by AWS by design, not rely on others to make sense of the mess with complex scripts and tools.
Even if you use those tools to create your automation on top of AWS, the fact remains that there are a lot of moving parts underneath that you will always be responsible to orchestrate and make sure that are working and up to date. eksctl for example uses cloudformation templates in the background.
Product Overload
At the time of writing this, there are 169 AWS products compared to 90 in GCP. AWS has been around for longer and therefore they have more offering, and in good Amazon spirits, they constantly and aggressively are expanding this offering to give you more of what you may need (and a lot of what you don’t need) at breakneck speed.
This sounds like a good thing, until you start seeing the amount of half cooked products or near duplicates they have. One good example is Parameter Store and Secret Manager, which are different, but from a practical point of view they can look very similar with Secret Manager mostly just adding rotation of secrets.
Another case of insane product overload is queues, explained well in this article by deps:
GCP has done well integrating their different services together. GCP provides a smaller set of core primitives that are global and work well for lots of use cases. Pub/Sub is probably the best example I have for this. In AWS you have SQS, SNS, Amazon MQ, Kinesis Data Streams, Kinesis Data Firehose, DynamoDB Streams, and maybe another queueing service by the time you read this post. 2019 Update: Amazon has now released another streaming service: Amazon Managed Streaming Kafka. GCP has Pub/Sub. Pub/Sub seems flexible enough to replace most (all?) of AWS’ various queues.
AWS product naming and packaging is also very confusing. For example AWS Control Tower, Landing Zone and AWS Organisations seem like they should be consolidated into one product, and it seems they name these products in parallel, without talking to each other; apparently Control Tower creates landing zones, but they are not the “Landing Zone”. I watched a couple of talks on this and I still don’t fully understand it, like this one, notice the speaker struggling to try to make sense of this mess in three different points. And then in another talk about AWS Organisations, a different speaker explaining what the difference is between Control Tower and AWS Organisations…
GCP on the other hand has fewer products but the ones they have (at least in my experience) feel more complete and well integrated with the rest of the ecosystem, and choosing one product over other doesn’t become an agonising choice that requires extensive research (okay, you still need to research, but not nearly as much)
I used to mock Apple in the past for how limiting they were and how very few features they had compared to Windows and Linux Distros until I started using a Macbook, it was then that it became so clear to me that having an opinionated approach on a few products and tighter integration of the various components often yields a far superior and more stable experience which is similar to the experience that I am having with GCP vs AWS. GCP gives you less and is slower delivering, but what it gives you is far better integrated, simple to use and often works better than its AWS counterpart.
AWS is a lot more Expensive
AWS charges substantially more for their services than GCP does, but most people ignore the real high cost of using AWS, which is; expertise, time and manpower.
With GCP, a relatively inexperienced engineer in platforming tools can pick it up and get his work done in a relatively short time because most of the tedious tasks of piecing all the parts together have been done by Google already.
A task that may take you a day or less to do in GCP, you may spend a week to do the same thing in AWS. One example I can give here is VPC Endpoints. I was working with a terraform cluster installation and I wanted to restrict outbound traffic to the internet. The problem is that if you do this then you are also cutting off traffic to AWS, in order to address this problem you need to set up endpoints. Endpoints essentially allow you to connect to AWS via the AWS intranet as opposed to the internet (Don’t ask me why cloud providers don’t do this by default, it makes no sense to me).
So simple enough, I just add these endpoints and then my job is done. Problem is that I was working with a cluster provisioner in terraform with a lot of moving parts and using multiple AWS services and you cannot set up an endpoint that applies to all AWS services, you can only do one endpoint per service and I had to do a lot of digging trying to figure out exactly all the services that the provisioner was using and add endpoints for each one of them, every time I added an endpoint, I found out I had to add another endpoint, I ended up adding about five of them and then I found out that a couple of the services that I was using didn’t have endpoints for them, so in the end I just had to allow outgoing traffic via a NAT.
Out of curiosity I investigated how to do this in Google Cloud because I had never done it before, just to see how difficult it would be in comparison to AWS and I wasn’t surprised to find out that you can accomplish the same thing just by clicking on a checkbox or activating a setting, and it applies to all services. Also, doing this in GCP is free whereas in AWS you have to pay for each endpoint
The above is just one example, but I have found that generally any task that I want to do in AWS requires far more energy and effort to do than GCP, meaning you are probably going to need to hire far more engineers and need more time and more money on human resources if you are using AWS than if you are using GCP.
The Cost of interrupted Flow
Another significant cost to your organisation if you decide to use AWS is the continuous interrupted flow. Flow is the state where you ideally want your engineers to be a good portion of their time at your company, not only they will be much happier, they will also be a lot more productive.
The problem with using AWS is that because everything is so confusing and complicated to use you will have to spend a lot of time reading documentation and testing to figure out how things work, and the irritating thing is that it won’t be fun experimentation, it will be tedious and trivial issues that should not exist, like the endpoint issue I described above.
Even after you are seasoned in the use of AWS you still spend an inordinate amount of time doing tedious things that you never have to do in GCP. Like inputting your 2FA code every 12 hours, or assuming roles, or just going over pieces and services and putting them together. The more tedious obstacles between you and the task you want to achieve, the harder it is to achieve flow.
Performance
I am not going to do extensive testing in both platforms and post benchmarks for this article since it’s a lot more work than I want to spend on this but I’ll just say that in my experience I felt that performance was almost always better in GCP, for example copying from instances to buckets in GCP is INSANELY fast, I remember being shocked by this because in a previous job I had to do a lot of hourly backups to buckets of large chunks of data in AWS and I always felt the copying was very slow, but this was not the case at all for GCP.
One good example I experienced recently is how slow it is to spin clusters up with EKS. In GKE you can have a fully functional cluster in less than 4 minutes. In EKS it takes about 16 minutes to create just the control plane (and even then it’s not ready!!) and then you have to add another 3 minutes or longer to spin the nodes, although sometimes I had to wait much longer than this for the workers. This may not matter that much to some, but when I am creating new infrastructure I tear it down and recreate it a lot to test that everything is working correctly and to save the company money on weekends and evenings so for me this matters a lot.
There are some latency tests in this article that clearly show that GCP does better across almost all areas when it comes to Network performance.
This article also compares some services between AWS and GCP.
Security
Both AWS and GCP are very secure and you will be okay as long as are not careless in your design. However GCP for me has an edge in the sense that everything is encrypted by default. For example their buckets and their logs are encrypted in transit and at rest. For some bizarre reason AWS does not encrypt buckets or logs by default, you have to enable this. Who the hell would NOT want their data encrypted on AWS servers?
GCP is also continuously publishing its internal models for security like BeyondCorp and BeyondProd, and designing GCP so it’s easier to integrate them for other companies. These security models are generally way ahead of the curve; for example BeyondCorp’s model has just been recently adopted by the National Cyber Security Center, and Google has published this six years ago while providing tools to implement it for quite some time. I am not saying that it is impossible to do the same with AWS, but it wasn’t designed with this intent in mind and it is a lot more difficult to implement. AWS on the other hand seems to have opted for supporting more traditional models of security.
This is a good talk if you are interested in hearing more about GCP security:
And here is an interesting tour of GCP’s datacenter security.
Google is a world leader of Scalable Infrastructure.
I would argue that there isn’t any other company on the planet that does scalability and global infrastructure better than Google (although CloudFlare definitely gives it a run for its money in some areas).
Just to get a grasp of how incredible Google’s infrastructure is, In 2013 Google went down for 5 minutes and the internet traffic of the entire world went down by 40% because people assumed their Internet was broken when Google wouldn’t open.
People trust google a lot more than they do their own internet connections because Google rarely ever goes down, and yet their combined services serve the most amount of traffic in the world.
Google is constantly on the edge developing new technologies that can scale, and once these technologies have been tried and tested enough, they often open source them and put them as part of their cloud offering. These technologies include kubernetes, Golang, Hadoop, and many more
So what’s better about AWS? There has to be something!
As I mentioned I think that AWS certainly offers a lot more features, configuration options and products than GCP does, and you may benefit from some of them. Also AWS releases products at a much faster speed.
You can certainly do more with AWS, there is no contest here. If for example you need a truck with a server inside, then AWS is for you. AWS also has more flexibility in terms of location of your data centres. Other than that… I would chose GCP any day, and I think GCP will cover the vast majority of your cases.
Typical Objections to using GCP
These are some of the objections I heard from people who pick AWS and are weary of choosing GCP as their provider.
But wait, there are lots of third party tools to automate AWS so it’s not a problem
Yes, like the aforementioned eksctl, some of them do an amazing job at this but they are still third party tools. I firmly believe AWS needs to work a lot on their abstraction of needless complexity so there is no need to have so many tools on top of it.
So if GCP is so much better, why so many more people use AWS?
I want to cover some of the reasons that hold back GCP from overtaking AWS, some of them are reasonable, other are pure myths or misperceptions.
They were the first
The principal reason why more people use AWS more than any other platform is that it has been around substantially longer than others. But that alone is not enough to make it king. Even though AWS is over-convoluted and mired with all the problems I just described, it is still a very decent product with excellent uptime and performance so if you are using it, you may not be compelled enough to move another platform, no matter how much better that other platform is.
Aggressive expansion of product line
AWS is much quicker at releasing new products than GCP, although as I mentioned previously, this can be good and bad, in my opinion is mostly bad.
Following the Crowd
Whenever you start working in a DevOps field you are bombarded with the idea that you must study and know how to use AWS in order to fail proof your career. AWS certifications for example are a very popular topic and every other engineer has at least one.
And so it happens that most engineers made a commitment to AWS right from the beginning, spending years of their lives learning this platform and ignoring or glossing over others.
Imagine if you are an engineer with 5 years of experience in AWS with lots of money and effort spent on AWS certifications and you are tasked to do infrastructure at greenfield project, what are you going to chose? Probably not GCP.
Fear that you won’t be able to get another job if you chose GCP
It’s true that there are a lot more jobs that use AWS, but there are also very, very few engineers with extensive experience in GCP compared to AWS. Taking a GCP job or getting a GCP certification will not make you disposable any time soon. Also, many employers are smart enough to recognise that a tool alone is not enough to define the quality of an engineer. I made a transition into another AWS role after having more experience with GCP fine, and even if some employers won’t like this, many others won’t mind.
If you are still doubting that learning and dedicating yourself to GCP is a bad idea, maybe this will change your mind:
Fear that GCP may be abandoned by Google
Google will very often release products to see how the market reacts to them and if they don’t work well, they will abandon them. This is deliberate and a strategy that revolves around trying new things as a source of innovation and also not wasting resources on products that don’t work, which makes sense. Now that the company has started to release paid products like Stadia or GCP there is a perception that they will soon be abandoned.
I highly doubt this will apply to GCP for three reasons:
First, GCP is not just one product, but many products, all of which have involved a monumental amount of engineering effort and time invested.
Second, it would be a PR disaster if Google were to leave out in the cold all the companies that rely on them, especially the big ones like Evernote, Coca Cola, Apple, Spotify, etc. It just won’t happen.
Finally and most importantly, there is absolutely no sign of GCP’s business slowing down, which would make it even more unlikely for them to abandon the platform. Why would you throw out a part of your business that’s generating 2.6 billion as of 2020 and growing each year?
Google doesn’t “eat their own dog food” with GCP
This point doesn’t prove anything in my opinion, but I am just bringing it up here because it seems to be where AWS enthusiasts lean heavily on when promoting the platform, as if it was irrefutable proof that AWS is superior.
There is a perception that because Google doesn’t use GCP for all their products and projects internally, they are not good enough for the public to use. Alternatively there is a perception that Amazon uses AWS for everything so that automatically makes them the most reliable choice — neither of them is accurate.
Google does use GCP for a lot of things internally, including YouTube and Gmail as explained in this page:
Internally, Google uses this infrastructure for several high-traffic and global-scale services, including Gmail, Maps, YouTube, and Search. Because of the size and scale of these services, Google has put a lot of work into optimizing its infrastructure and creating a suite of tools and services to manage it effectively. Google Cloud puts this infrastructure and these management resources at your fingertips.
Amazon also uses AWS to power itself internally but this is not always the case.
It’s true that Google does not use GCP internally for everything but there is a good reason for it. Google is always on the edge trying and testing new innovative technologies, these are extensively tested until they work great and later open sourced and made part of their cloud offering. This is not a bad thing, because as a customer you will rarely get a half cooked product with teething issues.
AWS on the other hand will release a lot more products faster, and as a consequence products will not be as complete as their GCP counterparts which can also be good in the sense they may release some tool that meets your needs and works acceptably well at a faster speed than Google would.
I don’t think neither approach is wrong, but I would prefer to use something that works more reliably than being a guinea pig, especially if I am paying good money for it, which is why I favour Google’s approach in this case.
Another thing I will point out here is that Google contributes way more to the Open Source community and industry overall than Amazon does, which happens thanks to the experimentation going on inside Google.
“You can’t get fired for choosing AWS”
Meaning that AWS is such a safe bet as a platform provider that you could not get fired as a result of choosing it. This is what some people say in the industry to justify picking AWS as the default.
All I can say here is that if your employer fires you for choosing GCP, he is probably not a very good employer to begin with and you deserve a better job, which I am sure you can easily get giving the demand for your skills.
Jokes aside though, if the engineering talent in your company is good, they will make it work both in AWS and GCP, so I wouldn’t worry too much about your choices. Chose the platform that you feel suits your needs best, and yes, GCP is also a very safe bet.
Disdain for Google
For some reason, some people really seem to hate Google. I can completely understand that Google sometimes will do things that are objectionable (and occasionally toying with the very objectionable), but I would argue that Google is not the worst of the lot by a long shot, they are in many ways more ethical than Microsoft, Amazon and Facebook. Some people may disagree with me, but I would argue that Google has not abused its monopoly nearly as much as Microsoft did back in the day (like for example hustling PC vendors to only accept MS Office Suite or withdraw Windows from their machines), and their monopoly has been earned by genuinely being the very best at what they do, which is architecture of scale and search, rather than by locking you down in their ecosystem.
Some of this disdain comes from Google’s attitude towards users and that’s something I can agree that Google can do better, but I wouldn’t say that by choosing AWS you are being more ethical than by choosing Google at all.
Google’s approach is to create products that are so well engineered that they don’t need as much support, and in many ways I prefer this approach to having a nice sales rep buddy who is friendly but I need to contact all the time with issues.
But this AWS complexity is creating so many jobs for us!
Yes, and it does sound like I am shooting myself on the foot by posting this because this is my job. AWS definitely creates a lot more jobs for DevOps, SRE, Sysadmin, Platform Engineers etc. than GCP due to this extra complexity and the lack of desire for the developers themselves wanting to tackle this complexity.
But personally I am not afraid of learning new things, I embrace it and I enjoy it, especially if those new technologies are well designed and simple. So I am okay making this transition.
So will GCP ever catchup to AWS on market share?
It’s hard to tell. One thing that AWS has going for it is that it churns out products like churros, and while I don’t think this is necessarily that great of a thing, it does meet the needs of most businesses, even if fragmented and tedious to work with. Also migrating from one platform to another is such an onerous task that many companies will never bother to do so. That being said, the increasing market share and profits coming from GCP look promising and this ex-googler author of this article, seem very confident that GCP will eventually reign:
My friends ask me if I think Google Cloud will catch up to its rivals. Not only do I think so — I’m positive five years down the road it will surpass them. Because today, Cloud is about helping other companies build software like Google does. All those great things about working at Google? Making them available to other companies — that’s the product market fit.
While I am not so sure if I am as confident as he is that it will just take five years to get there. I believe that down the road people who chose to specialise in GCP today won’t regret it.
Conclusion
So I should always pick GCP then?
No, you should pick whatever fits your needs. If you are a very small company or an independent developer you may even want to give these two a miss and go with DigitalOcean or Linode or some of the smaller companies which are even easier to use and will cover your most basic needs for less money.
AWS is still my second choice as an enterprise cloud provider after GCP. I know there is also Azure, but being a little harsh here, I have a little PTSD from using and supporting Microsoft products in the past, my memories from growing up using windows are daily blue screens and continuous Outlook issues. I just feel that Microsoft has historically been very much focused on the sale, not the quality of the product, they have the capacity to do great things, but they only do them when competition pushes them to do it, and/or have someone to copy from and they stop putting an effort once they reach monopoly. This is a stark contrast from Google or Apple who are very driven by engineering finesse and product design first respectively, not purely sales.
Of course, there are exceptions to this (I love VSCode) and some people swear that Microsoft has gotten much better over the years, but I still feel that this is only a consequence of pressure from the fierce and much better qualified competition, not because of a cultural pivot.
Based on that, if I can help it, I will avoid using Azure, but I can also respect that some people may love it, so I’ll leave it up to them to write their thoughts on it.
Okay then, GCP is perfect, let’s go for it!
Nothing is perfect. You will surely come across things in GCP that you will hate, as I have in the past, but for most people the amount of headaches will be fewer and farther in between than with AWS, and that alone is a good reason to pick it.
Additional Resources
https://kinsta.com/google-cloud-market-share/
https://sada.com/blog/google-cloud/gcp-vs-aws-why-gcp-better-option-2019/
