I will cut the chase by saying GCP is better. Here’s why I think so:

In terms of pricing and customer service I think both are similar (in fact GCP seems just a bit cheaper) so my review is based on technical feature comparison. I want to mention I am not endorsing GCP in this post. I’ve had quite a bit of issues with it – mainly with the customer support. So again by no means this post is an endorsement of GCP but I do think from technical POV its better than AWS and part of the reason for writing this post is to remind myself. In fact as I wrote this post I was surprised as I started enumerating everything and that is again part of the reason for writing the post to make a list of everything I can remember if i have to revisit this topic anytime in future.

1. First, GCPs project management is much better than AWS. GCP allows you to create as many projects as you want under one account and you can seamlessly switch between projects without having to re-login with a different set of credentials. Each project is isolated from another. Compared to AWS this is a godsend and reason enough to prefer GCP over AWS. To my knowledge AWS does not let you create multiple projects within an account [1]. You can create multiple accounts (organizations) but each account has to be associated with a unique email id (why? because some engineer decided to put a unique key constraint on the email id column) and to switch between accounts you have to login with a different set of credentials. This means I have to open multiple browser windows and also keep track of multiple passwords. Very inconvenient. AWS in theory provides a way to switch between sessions in same window but in practice it does not work very well. Every now and then I keep on getting a message that my session has expired and I need to login again. In fact AWS account and organization management is so convoluted it will require you to have a PhD to grasp it. They have multiple identity types – IAM identity is different from IAM Identity Center. List goes on.
2. AWS portal is quite buggy. See below e.g.:
   
   

This is only one of the many emails I have received from AWS when I have filed a case about something not working and they respond back saying its a bug and the team is working on fixing it. On another occassion I was stuck with bugs (note I used plural not singular) in their UI preventing me from publishing a product on AWS Marketplace. Google has better engineers and it shows in their products.

3. One area where GCP shines is with their BigQuery product for big-data analytics processing which IMO is much better than AWS Redshift. Again this is not a surprise when you consider Google is a data company and has been processing massive amounts of data since its inception.
4. Another example is of Cloud Run which allows scaling to zero. AWS has AppRunner but it does not scale to zero and is the most requested feature from the community [1].
5. Another thing I will mention is GCP’s intuitive naming. Names like VM and disks are self-explanatory. Compare to EC2 instance and Elastic Block Storage. Its these small things that make a subtle difference.
6. When creating a VM GCP is clearly showing the Zone and allowing me to change it. Try that in AWS. And the cost is clearly stated. Try that in AWS.

7. Compare the URL I need to login to GCP with the URL i need to login to AWS:
   GCP: https://console.cloud.google.com/compute/instances?project=my-project
   AWS: https://my-acctId-tdme5b43.us-east-1.console.aws.amazon.com/
   Which of these is more user-friendly and easy to remember?
8. AWS fargate and apprunner both don’t not support gpu:
   https://github.com/aws/containers-roadmap/issues/88
   https://github.com/aws/apprunner-roadmap/issues/148
   but Google Cloud Run supports it (https://cloud.google.com/run/docs/configuring/services/gpu) and it also supports websockets.
9. One cool feature GCP provides is AppEngine for which there is no equivalent in AWS.

Issues with GCP:

1. For the poor customers, they make it super difficult for you to create a ticket.
2. Keep getting ZONE_RESOURCE_POOL_EXHAUSTED whenever I try to provision a VM.

These are what I remember for now. Will add more to this list as I remember more. Do you have a different opinion? Let me know in the comments.

Further Reading

• https://nandovillalba.medium.com/why-i-think-gcp-is-better-than-aws-ea78f9975bda – MUST READ
• https://66degrees.com/google-cloud-platform-vs-aws-a-cost-comparison-showdown/

See for yourself what a shit show AWS is

I wanted to provision a DL VM. So I checked this link: https://docs.aws.amazon.com/dlami/latest/devguide/aws-deep-learning-ami-gpu-tensorflow-2.18-ubuntu-22-04.html

when i run

aws ssm get-parameter --region us-east-2 \
    --name /aws/service/deeplearning/ami/x86_64/oss-nvidia-driver-gpu-tensorflow-2.18-ubuntu-22.04/latest/ami-id \
    --query "Parameter.Value" \
    --output text

I get

ami-00cdd016bd7f2b052

and behold what do we get when we try to get the image details:

$ REGION=us-east-2 AMI_ID=ami-00cdd016bd7f2b052 aws ec2 descr
ibe-images   --region $REGION   --image-ids $AMI_ID   --query 'Images[0].{ID:ImageId,Name:Name,Owner:OwnerId,State:S
tate,Arch:Architecture,RootDevice:RootDeviceType,Platform:PlatformDetails,CreationDate:CreationDate,Desc:Description
}'   --output table
--------------------------------------------------------------------
|                          DescribeImages                          |
+--------------+---------------------------------------------------+
|  Arch        |  arm64                                            |
|  CreationDate|  2025-02-22T06:10:04.000Z                         |
|  Desc        |  EKS Auto Node AMI (variant: nvidia, k8s: 1.32)   |
|  ID          |  ami-00003580840480f10                            |
|  Name        |  eks-auto-nvidia-1.32-aarch64-20250222            |
|  Owner       |  975050179949                                     |
|  Platform    |  Linux/UNIX                                       |
|  RootDevice  |  ebs                                              |
|  State       |  available                                        |
+--------------+---------------------------------------------------+

It has changed to arm64 and the AMI ID has also changed.

$ REGION=us-east-2 AMI_ID=ami-00cdd016bd7f2b052 aws ec2 descr
ibe-images   --region us-east-2   --image-ids $AMI_ID  --owners 898082745236 --query 'Images[0].{ID:ImageId,Name:Nam
e,Owner:OwnerId,State:State,Arch:Architecture,RootDevice:RootDeviceType,Platform:PlatformDetails,CreationDate:Creati
onDate,Desc:Description}'   --output table
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|                                                                             DescribeImages                                                                              |
+--------------+----------------------------------------------------------------------------------------------------------------------------------------------------------+
|  Arch        |  x86_64                                                                                                                                                  |
|  CreationDate|  2024-11-06T11:47:41.000Z                                                                                                                                |
|  Desc        |  Supported EC2 instances: G4dn, G5, G6, Gr6, P4d, P5. Release notes: https://docs.aws.amazon.com/dlami/latest/devguide/appendix-ami-release-notes.html   |
|  ID          |  ami-03de840ff9fff792d                                                                                                                                   |
|  Name        |  Deep Learning OSS Nvidia Driver AMI GPU TensorFlow 2.15 (Ubuntu 20.04) 20241101                                                                         |
|  Owner       |  898082745236                                                                                                                                            |
|  Platform    |  Linux/UNIX                                                                                                                                              |
|  RootDevice  |  ebs                                                                                                                                                     |
|  State       |  available                                                                                                                                               |
+--------------+----------------------------------------------------------------------------------------------------------------------------------------------------------+

Svelte is currently my framework of choice for frontend web development.

1. You can bundle your backend (server side code) and frontend into one SvelteKit application but I don’t recommend it. Any non-trivial application will have a sizable backend API and it will only grow over time. Resist the urge and split the backend API into separate ExpressJS app. This way you can hand off backend development to a separate engineer, test the backend independently and if you are outsourcing frontend development, you don’t have to share your backend code. Another benefit is that when you develop mobile clients they can share the same backend. Also this way you can get rid of those pesky cross-origin requests are not allowed errors. That’s half-a-dozen advantages (did you count?) if not more.
2. If you are developing internal applications and don’t care about SEO you can create a SPA and serve it via NGINX or Apache. Just set export let ssr = false in src/routes/layout.js.
3. How do you decide whether a dependency goes under dependencies or devDependency? Use following flowchart: is the dependency used by client-side code or server-side code? If client-side (i.e., browser), it goes under devDependencies. If server-side it goes under dependencies. If you paid attention to tip #1 and all server-side code is in a separate project, all your dependencies can go under devDependencies. Btw, the whole issue becomes a moot point (not applicable) if you will be building the app on the server prior to deployment. Let me explain: when it comes to deployment you have two choices: Option1: the code is built on the same machine on which it is deployed. Option 2: the code is built on a separate machine and the build artifacts are deployed on the deployment machine (i.e., there are separate machines in charge of building the code (CI/CD) and running the code). The dependency vs devDependencies distinction is meaningful only for Option 2. If you are using Option 1, you still need to install all the devDependencies to build your code.
4. SvelteKit docs don’t mention it but the whole section they have on error handling is w.r.t. handling a request to the server and the built-in error handling only kicks into effect if the error happens inside the load function or +server.js. When your application is running in the browser and an error happens, SvelteKit won’t catch it. The browser javascript code is not running on top of any framework. Its the server-side code that runs on top of a framework so the framework is able to catch an exception. This was the biggest gotcha for me and I spent a lot of time debugging why my client-side errors were not being handled (since the docs don’t provide the clarification)
5. The other issue which caused me lot of pain is the dreadful Cross-site POST form submissions are forbidden. If you are using Tip #1 then we side-step the issue entirely. Another benefit of not putting any server-side logic in your Svelte application.
6. Remember process.env does not exist in the browser (this shouldn’t need to be mentioned but I am a backend developer). Use this for env variables on the client-side.
7. There are some important differences between npm run dev and running the application using node build. Of course in the former case you will get hot loading (you don’t have to re-run the app if you make changes to a file) and that’s what we mostly think about but also keep in mind that files like vite.config.ts have no effect when the application is run using node build. You are not using vite in that case so vite configuration does not matter.
8. Understand the role of SvelteKit adapters and the difference between Svelte and SvelteKit. The adapters determine how your application is built (i.e., what happens when you run npm run build) and deployed for a specific platform. Static Site Generation = adapter-static. Static Site Generation != ssr = false. Use Static Site Generation when there is no server-side logic in your codebase – its a pure client-side (browser) application that can be served statically over NGINX for example.
9. I shouldn’t have to say this but make sure to test how the app behaves when there is an error calling the backend. This is my pet-peeve. Often time engineers only test the happy path and there is nothing more embarrassing than an error in the error handling code. This is one thing that differentiates a junior engineer from a senior one. Use a mock backend to test out the UI code thoroughly and decouple UI developer from backend developer – both can develop independently and UI developer need not be blocked on backend developer.
10. For the UI I currently use SMUI and am satisfied with it. I am generally a fan of the look and feel of Google products and the SMUI library has concise documentation with examples. Many other libraries have so much documentation that it becomes difficult to get started and you have to learn a lot of concepts and background just to become productive. You don’t necessarily have to use a UI library. I use it because standard HTML does not provide some UI elements that are present in SMUI (for example standard HTML has no menu). But if you are using a UI library then be consistent and don’t mix and match. What Svelte UI library is your favorite and what is your top tip for Svelte development? Drop me a comment below

Further Reading

• https://www.youtube.com/watch?v=Jf0cjocP8Wk