Skip to main content

AWS vs. Google Cloud Services: Which one should you use?

Which is the better option? 

Written by Siddhanth Kumar



The database is a crucial component of most modern software applications. A database allows you to store and manage information in a table format. Moreover, database systems can be hosted on dedicated servers in the cloud, allowing anybody to access them from their local machine. A cloud database can open up opportunities for account systems due to user information being associated with their credentials rather than being stored locally. Luckily, developers are in luck! Big tech companies have created cloud-based database services to allow developers to use databases without too much hassle and personal setup.


For developers currently looking to use a cloud database service, two major options exist Google’s Firebase and Amazon Web Services (AWS) DynamoDB.


In this article, I’ll be reviewing 3 of the most database-related tasks necessary for most modern applications and compare AWS services against Google Cloud Services.


  1. User Authentication:


User authentication is typically completed through the use of a database by storing and associating a username with a password. However, AWS and Google both provide specific services for user authentication.


Google Firebase authentication supports Google, Facebook, Apple, Twitter, Microsoft, Github, along with a classic email and password.


Amazon’s user authentication service, AWS Cognito also supports the platforms listed above.


Moreover, both services have SMS phone number verification to help authenticate real users. However, when compared, Google Firebase authentication is superior due to its ease of use. Google’s Firebase console is extremely streamlined and intuitive to use. Through the use of great UI design, Google makes implementing user authentication easy, while AWS has a more text-based setup process and documentation.


  1. Serverless Functions:


Serverless functions allow developers to separate server-side code into separate functions which can scale to meet load requirements. 

Firebase cloud functions can be triggered through Firestore triggers or through an HTTP endpoint.


Similarly, AWS Lambda Functions can be triggered through other AWS Services such as DynamoDB or an HTTP endpoint. However, to use Lambda functions, developers have to use the AWS API gateway. This means that web and mobile applications have to go through the API gateway to call serverless functions and utilize AWS DynamoDB.


However, for the comparison of these two options, AWS Lambda functions are the clear winner as Google Firestore only supports Node JS version 10 while AWS supports a much wider range of languages including Java, Go, PowerShell, Node.js, C#, Python, and Ruby.


  1. Cloud Storage


Most modern applications do need to store information in databases. However, it is good practice to upload large files such as photos and videos into a cloud storage system. Luckily, Google and Amazon both provide solutions: Firebase Cloud Storage and AWS S3.


While both Firebase Cloud Storage and AWS S3 are solutions to storing large files, S3 is a little bit more robust and has a larger feature set.


In an S3 bucket, files are stored in a nonhierarchical fashion with 10 key-value pairs allowed to describe the file. However, the special features that make AWS the industry standard are versioning capabilities and enhanced security measures. Security can be managed using AWS Identity and Access Management and it’s simple to access this information from your own AWS developer console. S3 also has better-querying capabilities and can connect with other AWS services such as Athena. S3 has better querying capabilities because you can search for any of the properties or keys of the file.


Overall, for cloud storage, AWS’s S3 is a very good offer.


Conclusion:


While both services do mostly the same things, AWS allows for developers to use languages other than Javascript and has a more robust feature set. 


However, Google’s Firebase and Firestore are extremely intuitive and easy to set up. Firebase allows you to get your minimum viable product up faster for many newer developers due to the more UI-based setup. 


Ultimately, Google Cloud Services can help novice developers get on their feet quickly, while AWS  has robust features designed for larger-scale applications.


Comments

Post a Comment

Popular posts from this blog

React - Uncaught TypeError: destroy is not a function

Written by Aryan Mittal While experimenting with useEffect hooks in React and React Native, I came across the following error: Uncaught TypeError: destroy is not a function and my app was unable to run. After debugging and searching around, I found the cause and how to solve it. A simplified version of my code looked like this: The key here is that myFunction is async and the shorthand arrow function syntax I used. The reason the simple code above was crashing my app is due to how the useEffect hook, async functions, and the shorthand arrow function syntax works. One feature of the useEffect hook is a cleanup function. If you return anything from the useEffect hook function, it must be a cleanup function. This function will run when the component unmounts. This can be thought of as roughly equivalent to the componentWillUnmount lifecycle method in class components. In JavaScript, functions marked with the async keyword enable the use of the await feature, which lets developers paus

What’s New in React 17: No New Features?

  What’s New in React 17: No New Features? Written by Aryan Mittal Over two years after React 16 was launched, the long-awaited React 17 was released in October 2020. While the update introduced numerous great changes as always, this release is unique because it contains no new developer-facing features. While React 16 added significant features like Hooks and the Context API, React 17 is mostly considered a stepping stone to ease the transition to future releases. More specifically, the primary purpose of the update was to enable gradual React upgrades. When you upgrade from React 15 to 16 (or, this time, from React 16 to 17), you would usually upgrade your whole app at once. This works well for many apps, but it can get increasingly challenging if the codebase was written more than a few years ago and isn’t actively maintained. And while it’s possible to use two versions of React on the page, until React 17 this has been fragile and caused problems with events. The React team has fix