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.

We all love IaC and a good CLI, but a refined cloud console that functions well and is easy to navigate is rare to come by in the cloud provider space. OCI and Google have both implemented a search bar in their console. However, Google’s advanced search bar allows you to search by resource name, doc, product, and more—providing an optimized platform designed to advance your cloud experience. From advanced search capabilities to a fully-functioning cloud console, Google Cloud has a developer-ready environment, including Cloud Shell, an online development and operations environment accessible anywhere from your browser. Cloud shell will authenticate you, allow you access to the full CLI, and has many common tools pre-installed. For a deeper dive into all Google has enabled for developers, start with Cloud Shell.

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.

Google’s shared Virtual Private Cloud (VPC) allows for the abstraction of the network layer from other project resources. This enables your network team to access network resources in an isolated project while other engineers solely access the resources they need in a service project. Can you envision how this might make your next audit go? All your firewalls, VPC, subnets, routing, and VPNs are in one project that developers don’t have access to. All your application infrastructure and code are in a service project to which the network team doesn’t have access.

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.

Since we brought up GKE, it is worth discussing all the ways you can run serverless workloads on Google Cloud. While GKE isn’t technically serverless, GKE Autopilot brings the best of serverless to Kubernetes. By eliminating managing nodes, capacity, and limited cluster operations, you can benefit from all the perks of Kubernetes but without the hassle. Google Cloud provides true serverless workloads, including Cloud Run and Cloud Functions. Cloud Run is for deploying containerized applications written in any language on a fully managed serverless platform without worrying about scaling, configuration, or additional infrastructure. Cloud Functions support multiple runtime languages and allow you to create single-purpose functions that respond to events. Everything from when a file lands in a bucket to transferring to a new location and exposing an HTTP endpoint that returns data from a BigQuery query.

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.

• Set up your Organization in Google Cloud
• Connect your IDP and set up SSO
• Set up CI/CD for infrastructure Terraform
• Create your Org structure of folders and projects
• Determine and implement IAM roles at the folder/project levels
• Set up Organization policies that meet your security needs
• Create your network structure of shared VPCs and Standalone VPCs
• Tighten up security by utilizing Security Command Center
• Set up billing reporting, audit logging, and other monitoring needs
• Set up any on-prem or OCI connections (VPN, Peering) needed to move your data
• Create resources in Google Cloud including the landing zone for your applications, data, GKE clusters, GCE Instances, CloudSQL, and other
• Move container images from OCI to Google Cloud
• Set up application CI/CD

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.

66degrees has experts in cloud migrations and SLZ implementations and is eager to help you along your cloud journey. Contact us today to get started. Let’s get you there!