My cloud computing history, until now, has mainly been Google-based, starting with App Engine, and then moving mostly to Firebase. However with CLoud9, my IDE of choice (or at least the best development environment available on a Chromebook) being bought up by Amazon, I thought it time to give AWS a try.
This post compares the strengths and weaknesses of each platform, purely from a hobbiest's point of view - I'm not a professional developer/DevOp/Cloud Guru, I just like to play in my spare time. I've also not looked at Asure, or any other offering, as they have no real appeal to me. I should also state I have something of a bias toward Google, as may be clear if you've been following me since before the dark age.
I'm going to look, primarily, at the services that I would use when creating this blog site - this means a serverless node.js compute environment, static file storage and noSQL database. I'll also taker a look at how the overall list of services compares, I'll take a fairly subjective look useability at the two's offerings, and then at the end I'll mention some other services of interest.
Overview of Services
Both Google Cloud and Amazon Web Services (AWS) offer a range of services that let the user store and process data within the respective company's data centres. Supposedly, this started over a decade ago when Amazon realised they had to provision servers for their busiest seasons, such as Christmas, which went to waste during the rest of the year - why not hire them out the rest of the time. This was soon followed by Google launching App Engine, which has a more targetted use-case of a web app backend.
They each offer the basic low-level services, such as virtual servers, file storage and databases, and higher-level abstractions that provide a more tailored package for a more specific use case. The actual list of services in each case is quite long, so I've highlighted a few of the more interesting below:
- Virtual servers: Google's Compute Engine and Amazon's EC2
- Storage: Google's Cloud Storage and Amazon's S3
- Serverless Functions Runners: Google's Cloud Functions/Firebase Functions and Amazon's Lambda
- Lightweight/noSQL Databases: Google's Firebase Realtime Database and Amazon's DynamoDB
Both companies also offer container services, machine learning platforms, IoT platforms, load balancing services, DNS - the list is quite long.
Firebase technically doesn't come under the Google Cloud branding, from what I can tell, but I think it falls into that same category still.
For the most part, both companies have everything you'd need. Unless you're doing something very esoteric, the chances are you could run your stack on either cloud and you wouldn't notice the difference. In fact, Netflix created
Spinnaker to make swapping between clouds easier.
Amazon has an online developemt enviroment, something Google doesn't really offer - AWS Cloud9 gives you an editor, file tree and virtual server, letting you write, build and test and application in a single place. This is what I'm writing this post on this very minute. I used Cloud9 back before it was owned by Amazon, back when you had to pay for it - now it's part of AWS, it's aproximately free.
Conversely, Amazon doesn't have a good competitor to Firebase (the realtime database, at least). I'll cover this more below.
I would say, on the whole, you couldn't choose between either of these providers based just on the services they offer - it seems as soon as one launches a product, the other is hot on their heels with an alternative. The specfic features, however, may make a difference, and that's what I'll be exploring later.
Useability
I've been working with Google services for far longer than Amazon's so there could be some bias here, but I think I've been honest throught.
I've found Google Cloud prducts really easy to jump into. I can generally get something going pretty easily. AWS I found much harder to get on with. I have no doubt, once you've spent the time with it, it becomes second nature, but the short version of this section is that Google Cloud products just work for me.
There are plenty of Docs available for both providers. Google's are nice and clean, well written, and hide the bits you don't want to see in accordians or drowndowns. Amazon docs are a little harder on the eyes, quite technical, and each doc gives you three different ways of doing most things. The AWS docs also tend to throw you around the place quite a lot, much like an old Haynes manual.
The biggest frustration I've found with AWS is IAM. Whenever you start using new service, you can pretty much guarantee the first "Getting Started" page will say something like:
"You can get started by doing this from your root account, but this is terribly unsafe, so don't actualloy do it. You should set up IAM. To do so, follow this link, then a link on that page, and then a ten-step process. Congratulations, if you managed to follow that just right, you might now be better defended against the bad guys."
IAM itself is a great and powerful tool and, as something of an advocate for good security, I couldn't not use something that goves me that much control. However, I didn't find it that easy to wrap my head around at first.
Conversely, Google used a simpler Owner, Editor, Viewer model, which is easy to understand without even reading the docs. They now have IAM, but I never noticed this change, because it was so easy to use.
Security
needs to be easy - watch any Black Hat talk and you'll see how many mistakes trained security professionals are making every single day. Take the August Smart Lock, a device
specifically designed to secure your home, who's securoty was validated by a third-party pentesting company. The lock was found to have some security flaws in it, even after all of that. Google and Amazon have security bugs disclosed regularly, despite each putting a lot of reaseach money into security. If these guys can't manage it, some bloke like me doing this as a hobby doesn't have a chance. To some extent, I rely on these companies having done the hard work for me and I've found Google had my back the whole way through, kind of like Gandalf, whereas Amazon just gave me a sword and said "make sure you hold the right end son, if you're in a dark cave hiding from Orcs, it'll glow like a flare to let them know where you are". Security rant over.
Compute
With web development being the programming I tend to prefer, and Atwood's Law states "Any application that can be written in JavaScript, will eventually be written in JavaScript." I think it's safe to assume I like to do things in JavaScript. That's not to say it's the best way of doing anything, but tends to be the most convenient.
Since the advent of Node.js, we've been able to use JavaScript on both the client and server side. Until recently, using Node in the cloud required running a virtual server, or a container, and paying to keep it running between hits, or wait for it to boot up every time someone hits after the last instance timed out. Given the size of my audience, this doesn't work too well for me, or you. But now, there is a way. "Serverless", as it's known, lets Google and Amazon run their own servers non-stop, and run the user's sandboxed node jobs as-and-when needed. Google calls this Cloud Functions, and Amazon calls them Lambdas.
In both cases, the jobs can be triggered in a variety of ways. In the case of a website, this is likely to be an HTTP trigger, but they can also be used to process backend jobs like image resizing when a file is added to the file store. They can be very powerful, and tend to be the best way of creating a microservices architechture.
I'll forget this in the round-up at the end, but Amazon has an advantage over Google with serverless at the moment - Google only runs Node version 6, whereas Amazon lets you choose version 8. For me, this kills the Google offering, as version 8 includes async/await, an ECMAscript feature I use quite a lot. Other than this, node 6.14 is actually pretty complete.
Other than that, there's not much to call it on here.
Storage
Both providers offer very similar bucket-storage systems. Google offer Cloud Storage, AWS has S3 (Simple Storage Service). They both let you upload files in a convenient manner, that get stored in a "bucket". This is conceptually similar to a drive, but works differently behind the scenes. They can both takes objects in any form, although in my case this just ends up being common files, and support folders.
They can also both supply serving URLs that clients can use to download the files. This is most commonly used to serve image assets for a website.
I haven't noticed any real difference between the two. S3 was a little harder to configure for public access, but there wasn't a lot in it.
Database
Most websites use some form a database as a backend, unless the site is completely static. Historically, the biggest and fastest databases were relational databases, commonly searched using SQL, which are basically massive tables - think a giant Excel sheet. However, many now prefer a "noSQL" style database, which allow less strict data structures, are generally designed to be distributed across numerous datacentres and are, in my view, more lightweight in how they feel (though probably being more scalable).
Google and Amazon both offer numerous databases, suited to a number of applications. Amazon's DynamoDB is their most relevant offering to this discussion. Google's comparable product is the Cloud Datastore, but I think Firebase fits into a similar niche, but is much more powerful.
I've found DynamoDB very hard to get my head around - to get queries to run efficiently, a careful design is required, and I've found post-query operations are often required to filter the data.
Conversely, Firebase (technically the Firebase Realtime Database, or its newer brother the Firestore) is extremely flexible, and tends to just work for you, however you want to use it. It can be accessed directly by the client in a multitude of useful ways, and is designed from the ground up for multiple users at the same time - like Google Docs for a database.
Firebase makes Google a clear winner here. At an enterprisae scale, it probably isn't the database of choice, but for a hobbiest, it's the best.
Wrap Up
As I mentioned a couple of weeks ago, this blog's running on AWS. As I was going through programming the backend, I felt AWS had a lot of power behind it, and with it I could achieve whatever I wanted.
But as I got deeper into it, I started to feel I may've made a mistake. I was too far in to go back, so continued, learning more as I went. In the future I'll do a post on how the backend actually works.
As a full-time dev, who can spend enough time to really grok AWS, I think I would come to love it. But as a hobbiest, I think Google has a friendlier offering.
I got there eventually, but at the end of it, I remember thinking "I should've stuck with Google". And that's what I'll leave you with.
