In today’s world, businesses must keep up with the rapidly evolving technology landscape to remain competitive. Advancing your cloud maturity and increasing the functionality of your cloud presence can be achieved by migrating from Oracle Cloud (OCI) to Google Cloud (GCP). Cloud migration is a popular strategy for businesses to increase their scalability, flexibility, and agility. Google Cloud is an excellent option due to competitive pricing, innovative features, and excellent support. We will explore key infrastructure differences between OCI and Google Cloud and the high-level steps required to begin migration.
You may have already started looking at Google Cloud and begun to notice some key differences. All Cloud Providers do things a little differently from each other. There are a few main areas of difference we will review.
OCI’s utilization of IAM differs from its competitors. OCI’s written policies for IAM and writing out access permissions for a compartment or tenancy can lessen the user-centric experience. However, Google Cloud’s role-based access control (RBAC) structure enhances user-centric capabilities by simply adding a user or assigning a role following the “least privileges” principles.
In Google Cloud, you can assign these roles at the project, folder, or organization level, and they are inherited based on the level they are set at. Therefore, if you have a security team that needs log viewer access to the entire organization, you simply provide them that role at the Org level. If you have an individual who only needs access to Secure Shell (SSH) into VMs in a dev environment, you can provide that access at a “dev” folder level or to individual projects.
Cloud networking across all providers is very similar. There are a few areas where Google has differentiated itself, and it is important to understand these differences while planning your migration.
In OCI, like in other Cloud Providers, to SSH into an instance requires a firewall from OCI’s source IP to the instance IP. OCI does this via security groups and routing protocols. This typically means that you must be on a corporate VPN to SSH, since no one wants to allow all internet traffic or each person’s individual IP. Google Cloud adheres to the same standards, however, if you choose not to connect to a VPN or prefer not to give VPN access to a 3rd party, Google offers a service called Identity Aware Proxy (IAP) for zero-trust scenarios.
IAP allows you to open a single firewall rule from Google Cloud CIDR IP to a target tag, service account, or CIDR IP destination. Users can attempt to SSH from anywhere on any computer, but they must authenticate to a user/group that is authorized with a role that gives IAP access to the instance (there are options here, too, like OS Login roles). Sound too simple? Auditors love simple, and so will you. IAP can be used for more than just SSH. Think public Google Kubernetes Engine (GKE) ingresses with IAP for internal-only applications. You can have the same GKE setup in dev that you have in production, like a public IP, but you have IAP enabled via a BackendConfig resource in dev.
Now users can hit the public IP from home/office/coffee shop and only access the application if authorized. Non-prod and prod are much closer in infra configuration, making changes safer.
While OCI and Google Cloud both have Terraform providers, Google is far more active and much easier to get started with. Those long and impossible-to-remember strings are the heart of OCI resources. Terraform running on OCI can include data blocks being everywhere and module references; therefore, it’s imperative that your Terraform variable files (tfvars) are properly documented so that you can differentiate between OCIDs. The Google provider is similar regarding ids, but ids are more typically readable, and many resources can be referenced by a name instead.
To use firewall rules as an example, Google Cloud allows you to specify the network to attach a firewall rule to by name, OCI requires you to store or look up their IDs. While referencing the resource “oci_core_subnet.test_subnet.id” is fairly simple, there are many times when you might not have access to these resources/modules due to storage and management by separate teams. Referencing the network by human-readable names makes distributed Terraform like this easier to learn, read, and manage.
At 66degrees, we prefer Terraform for its reusability, portability, and dependability. We have developed Terraform modules to support creating a new Secure Landing Zone (SLZ) in a customer’s environment. It’s a great way to get up and running quickly with Google Cloud. Google also has its foundation modules named Cloud Foundation Fabric. These fabric modules can simplify how you implement Google Cloud resources by encapsulating everything you need in logical groupings.
CI/CD on OCI requires a 3rd party tool like Jenkins. Jenkins on OCI is manageable just like it is on Google Cloud; however, Google Cloud might have slightly better plugin support for connecting to Google Artifact Registry than OCI’s. But what if there were other options? What if a Google Cloud or OCI product could handle CI/CD for you?
Google Cloud introduces Cloud Build, a serverless CI/CD platform that runs fast and has automated builds defined in YAML configuration files. Because it is a Google Cloud product, you also get great connectivity to the Google Cloud ecosystem and infrastructure CI/CD, which is what you would expect from a CI/CD product.
“But does it solve the Jenkins security issue?”… it does. Cloud Build is serverless, so there is nothing to manage there. Your builds are performed inside containers so that you can specify the version running in your Cloud Build YAML files. Cloud Build can use its service account to perform actions or impersonate another SA, such as a terraform_sa. Therefore, all changes are only possible if you run terraform referencing that SA and Cloud Build have access to impersonate that Google service account. Finally, everything is logged to Cloud Logging, so alerts can be configured and generated to notify you if builds fail or when triggered.
We have reviewed a few key OCI to Google Cloud differences and discussed Terraform and CI/CD. Since no two migrations are identical, where do you start? You could start by contacting a trusted Google Partner, like 66degrees, who has performed this type of migration before. We have the experts to partner with you to ensure your migration success.
Almost everything that must be completed to migrate to Google Cloud can be done in Terraform. Below are the foundational steps to establishing Google Cloud as you prepare for your migration and departure from OCI.
The process of migrating to a different cloud provider can be overwhelming, however, you deserve a Cloud Provider that’s maturing at the same pace as your business and a trusted partner who relishes in your success. With unmatched scalability, flexibility, and security, Google Cloud empowers your business to innovate faster, reduce costs, and achieve greater business agility. Starting from a well-architected secure landing zone (SLZ) on Google Cloud can jump-start your cloud migration by providing a consistent and repeatable approach to security and the infrastructure foundation that supports your business. 66degress has experts in cloud migrations and SLZ implementations and is eager to help you along your cloud journey. Let’s get you there!
With over a decade of premier partner status, 66degrees aligns with Google Cloud to ensure a seamless experience for our clients — from our shared vision to the way we organize our teams.
600 West Van Buren Street, Suite 603 Chicago, IL, 60607
1125 17th St Suite 2550, Denver, CO 80202
Zona Franca Metropolitana, Edificio Administrativo Heredia Ulloa, 40104, Costa Rica
#447 Arjun Arcade
6th Main Jayachamrajendra Road, Vijayanagar 1st Stage, Mysuru, Karnataka 570017, India
