By Eduardo de la Garza Guerra
On December 11, 2024
Cloud providers are complex offerings. With a big variety of services and trade-offs, it can be hard to choose the right one for your project. However, at a high level, there are a couple of core things that you could think about when choosing one. As they are the core of cloud architectures.
Arguably the most important part of a project. Every project needs some form of compute to run applications. It is also normally the most expensive part. Most modern applications use containerization, probably with Docker. Container workloads can be deployed in a spectrum from serverless to self-managed.
AWS Lambda was an extremely innovative product when it was released in 2014. It practically led to the creation of data driven architectures. And popularized event driven architectures as a concept. Google Cloud Functions were released a bit later with similar functionality.
For me Google Cloud Functions just work. I know that a container that runs on my computer will basically always run on GCP. However, when using Lambda things weren't that way. One perfect example is the first time I tried deploying a Fast API server on Lambda. I had to learn about Mangum, which I won't explain right now but was a pain. Specially because it felt unnecessary.
At first glance these 2 offerings might seem very similar. But for me there are at least 2 very relevant differences:
First, Cloud Run can scale down to 0. So if you want to have a service that is just used every now and then. You can deploy it easily and run it cheaply. On the other hand, Fargate has a minimum of 1 instance. Which means you pay for the whole month.
Second, Cloud Run is very simple to set up. Using their CLI, to replicate what the 'gcloud run deploy' command does, you would need dozens of terraform or cloudformation lines for AWS.
I've never worked directly with any of these services, so I can't really say much. But as the most advanced, I would guess they are both very good.
I can't really say that I think Firestore is better than DynamoDB. DynamoDB has a lot of advanced features related to data integrity, scalability, security, etc. But Firestore is definitely simpler. The fact that it doesn't have schemas allows me to build applications much quicker. Building a real life product is faster.
Here I have to give it to AWS. Both for large and small projects. While Cloud SQL is very good, with its pricing being competitive and easy to use. RDS has a better free tier and has more advanced features for larger projects.
One of those things that less technical people tend to rarely, if ever, think about. But it can end up being a big portion of the development. Basically anything that happens or you want to do. From running a process to logging-in a user, needs to be authenticated and authorized.
On the internal side, both services are very similar. Up to the point that they have the same name, IAM. But on the external side, the difference more clear. AWS offering, Cognito is more complex to set up but has a higher level of customization. For many projects, Firebase Authentication can be great since it can allow you to have an enterprise ready authentication system in less than a day.
In this area for me the main difference is pricing. I was very surprised when I first started using AWS Secret Manager. It felt orders of magnitude more expensive when compared to GCP Secret Manager. Looking at the pricing for both services right now, Aws is at $0.40 per secret per month while GCP is at $0.06. That is almost 7 times more expensive. Other than that, both services are very similar. And, if you want to follow rule 3 of the Twelve-Factor App you likely are going to need a secret manager.
Surprisingly, at least for me when I started using cloud providers, in practice networking is a huge factor. In many cases for GCP you didn't even have to know about the network but in AWS to deploy most if not all of computing services you need to have a VPC. That leads to many other requirements. For a big project this might not be a big deal but if neither you nor anyone you work with knows what a VPC is, it can be a big deal.
This is another point that in practical terms ends up being a big deal. For me GCP documentation has always been one of its biggest selling points. To keep it short, it is very good.
AWS was actually the first cloud I tried to use years back. At some point I was very lost and for me the documentation wasn't helpful. I ended up finding documentation for Cloud Run and Fire Base which felt comparatively easier. Specially considering what we already discussed about AWS architecture being naturally more complex. So I switched and never turned back until recently.
Most of the time I've worked with AI I've relied on local or containerized jobs. The only times I tried to use these services was when I needed big GPU's for local LLM's or animations.
In general my conclusion was that AWS needed more setup. All the way from initializing the services. To installing packages on the instances and setting up GPU's to work properly. How ever, with services like AWS Bedrock, AWS seems to have a wider range of services.
Most of the arguments I mentioned revolved around smaller projects or simpler configurations. If you need more complex set ups like multiple regions, networks, permission groups, etc. These arguments might not really apply. And on the other hand AWS has a wider and more mature ecosystem.
In the end, both are great products and which one is better for you will depend on your specific needs. As I've argued I believe GCP can be a great option for smaller projects or smaller teams. But AWS is a great option in the inverse case. And in the end, the best way to know which one is better for you is to try them out. Both have free tiers and you can get a lot of experience with them without spending a dime. Although you might need to spend a lot of time.