Migrating an app from AWS to Google Cloud: A startup’s point of view

Editor’s note: In this post AJ Ross, CTO at Fluxon, discusses the key considerations and comparative technologies for startups looking to move from AWS to Google Cloud.

If you're a startup considering migrating from Amazon Web Services (AWS) to Google Cloud, it’s important to understand the technical differences between them. Luckily, modern cloud platforms are to some extent interchangeable. In our experience at Fluxon, if you’ve already decided to move, you’ll be pleasantly surprised by Google Cloud’s advanced solutions.

When migrating, it’s important to understand not just the costs of your application’s workloads, but also how a cloud platform can lower expenditure thanks to technology that is functionally superior or easier to adopt. For this reason, Google Cloud stands out for a range of proven solutions and APIs that offer attractive features, performance, and reliability all at a competitive price point. In some cases, such as Kubernetes and BigQuery, Google Cloud’s offerings are vastly superior to competitors’.

In this article, I will discuss key considerations and comparative technologies for startups looking to move from AWS to Google Cloud. I will also provide a comparison of the two platforms in terms of features, pricing, and scalability. If you’re looking for a “rosetta stone” of translations from one cloud to the other for common full-stack applications, or to see where Google Cloud is vastly superior to the competition, then read on.

Taking control of Identity Access Management (IAM)

It’s no secret that IAM, with its complicated web of users, groups, roles, and permissions, is one of the more difficult aspects of managing a cloud platform. Both AWS and Google Cloud are highly customizable when it comes to IAM granularity, but it’s important to understand their different approaches.

A major difference you’ll notice with Google Cloud is that there is first-order support for dedicated service accounts. These are effectively users under which your (and Google Cloud’s) programmatic APIs operate. While top-level Google Workspace users are dedicated to human-driven authentication and actions, service accounts are expected to do all of the programmatic work. Google Cloud service accounts provide the benefit of least privilege by creating fine-grained access control. Service accounts are used so extensively in Google Cloud that service accounts are created automatically to run services for you that you tune to isolate roles and servicess, which saves time and effort.

In AWS, nearly every action is governed by a policy and users, which belong to groups and roles, and each action can be checked against a policy. This is different from Google Cloud where, in addition to having generalized roles and policies for each user, resources can also define which users can access them.

For example, on AWS you might create a new user that can access your production database and S3 buckets. To do this you generate a policy that grants access to specific actions on these resources for the new user. On Google Cloud, you create a user or service account, but you set the permissions for that user on the bucket itself. AWS used to have resource-specific policies for S3 buckets, but they have been deprecated for some time.

Where should my application run?

Most of the applications we build at Fluxon are web-based, so determining where and how to deploy our applications is a crucial question. At a basic level, both AWS and Google Cloud offer virtual machines through EC2 and Compute Engine. Both platforms enable you to create VMs by configuring your CPU, RAM, and attached storage parameters. Both platforms also offer opportunities to reduce costs with reserved and spot instances, and both offer VPCs to isolate services securely.

If you’re looking to move your existing VM-based workload to Google Cloud from AWS, you’ll find that the offerings are very similar, with the notable advantages that Google Cloud provides Migration Center for a seamless end-to-end experience, as well as a more modern and holistic interface that can make managing your resources much easier.

However, managing servers adds operational overhead for engineering teams. For this reason, most people start with container-based deployments. Cloud Run is a great solution if you’re migrating a container from an AWS Elastic Container Service (ECS) pipeline, such as ECS Fargate. Cloud Run enables you to host and scale any container easily, and with Cloud Build, you can quickly build a pipeline that deploys new versions of your application.

If you have a workload with microservices or multiple services that need to interoperate, you’ll find that Google Kubernetes Engine (GKE) is best-in-class. GKE is the only managed Kubernetes service that can offer scaling up to 15,000 nodes and delivers multiple types of automation. Unlike the competition, Google Cloud has made it easy to use both Cloud Run and GKE, letting you move between them as needed, without forcing your teams to choose.

If you already have a Kubernetes application on AWS, moving to Google Cloud should be straightforward since there is feature parity in terms of deployment, monitoring, availability, and command-line tools. But with Google Cloud you also have the advantage of Google Cloud console, which provides a cleaner UI for Kubernetes management compared to AWS, which is a bit more fragmented.

Deciding on a database

Both AWS and Google Cloud offer nearly identical options for transactional databases. Both provide fully managed PostgreSQL, MySQL, and SQL Server that are attractive to developers. Both support VM configurability, replication options, and availability zone and replication options for redundancy. But with Google Cloud, you can manage access control through the Identity and Access Management system, so database access can be cleanly integrated with Google Cloud instead of managing users and roles individually on each database.

If you’re looking for lightweight or ephemeral storage such as Memcache or Redis, Google Cloud offers a Redis API-compatible service called Memorystore that is perfect for caching or other high-speed key-value set operations you would expect from Redis. However, keep in mind that Memorystore doesn’t offer persistence. While Memorystore’s more-expensive Standard tier utilizes multiple high-availability replicas, your data isn’t flushed to disk anywhere. This should be fine in theory, but make sure to understand the difference before fully switching to Memorystore.

One area where Google Cloud excels is with reporting databases. If you have a data lake in AWS, you’ll be pleasantly surprised by BigQuery, which is a cost-effective solution for storing massive amounts of data that can be queried with SQL. BigQuery enables you to stream records to it (similar to Kinesis), store them in its own proprietary format (like Redshift), and you can use it to scan external data sources (like Spectrum or Athena).

To migrate data from AWS, check out the Google Cloud Storage Transfer Service (for cross-cloud synchronization) or their Transfer Appliance, a high-capacity storage device that enables you to transfer and securely ship your data to a Google Cloud facility, where your data is uploaded to Cloud Storage. If you already have a business intelligence and analytics platform, it most likely supports BigQuery, but if you don’t you can try out Looker Studio (free) or subscribe to Looker Studio Pro.

Cloud Storage is analogous to AWS S3 — both are cost-effective platforms where you can store and serve objects. However, the pricing options vary on both platforms according to storage class, region, redundancy, data transfer amount and direction, and access frequency. In terms of functionality, many of the Cloud Storage features are very familiar, and Cloud Storage supports the S3 protocol. You can import data from other providers by using the “gsutil” command line utility or with the Storage Transfer Service.

Over to you

Depending on the complexity of your applications, migrating from AWS to Google Cloud could be easy and straightforward, or it could involve a lot of complexity and require a lengthy transition. While many of Google Cloud solutions should be directly translatable from AWS, the hard part is always in the details, such as access control, networking, and other platform idiosyncrasies. In the meantime, I hope this guide has been useful and given you a broad overview of how to approach a transition from AWS to Google Cloud. And while many services are similar, Google Cloud stands out for their easier, more modern interfaces and their stronger security controls.

If you want to learn more about how Google Cloud can help your startup, visit our page here to get more information about our program, and sign up for our communications to get a look at our community activities, digital events, special offers, and more.