Migrating On-Premises Batch Process to Cloud: Cost-Effective Solutions

Migrating On-Premises Batch Process to Cloud

Question

Your company runs one batch process in an on-premises server that takes around 30 hours to complete.

The task runs monthly, can be performed offline, and must be restarted if interrupted.

You want to migrate this workload to the cloud while minimizing cost.

What should you do?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

B.

https://cloud.google.com/kubernetes-engine/docs/tutorials/migrating-node-pool

When migrating a long-running batch process from an on-premises server to the cloud, several factors should be considered, such as cost, reliability, and scalability. The goal is to minimize cost while ensuring that the workload runs efficiently and can be restarted if interrupted.

Option A: Migrate the workload to a Compute Engine Preemptible VM.

A Preemptible VM is a low-cost virtual machine instance that can run for a maximum of 24 hours before being terminated. These instances are suitable for running short-lived batch jobs, but they are not ideal for long-running batch processes that run for several hours.

Additionally, because the workload needs to be restarted if interrupted, using Preemptible VMs may result in significant downtime and delays, which could lead to additional costs and resource waste.

Therefore, Option A is not the best choice for this scenario.

Option B: Migrate the workload to a Google Kubernetes Engine cluster with Preemptible nodes.

Google Kubernetes Engine (GKE) is a container orchestration system that automates the deployment, scaling, and management of containerized applications. Preemptible nodes can be used to run workloads on GKE at a lower cost.

However, while GKE provides benefits such as scalability, availability, and automatic restarts, it is not the ideal choice for long-running batch processes that can be performed offline. The primary benefit of GKE is its ability to run stateless services that can scale horizontally.

Therefore, Option B may not be the best choice for this scenario.

Option C: Migrate the workload to a Compute Engine VM. Start and stop the instance as needed.

A Compute Engine VM can be started and stopped as needed, making it an ideal choice for long-running batch processes that can be performed offline. This option provides flexibility, scalability, and cost savings.

By stopping the VM when the workload is completed, you can avoid paying for idle resources. Also, in the event of an interruption, the workload can be restarted from the point of failure, minimizing the downtime and resource waste.

Therefore, Option C is the best choice for this scenario.

Option D: Create an Instance Template with Preemptible VMs On. Create a Managed Instance Group from the template and adjust Target CPU Utilization. Migrate the workload.

This option is similar to Option A but provides additional benefits such as automatic scaling, high availability, and reliability. However, it may not be the best choice for long-running batch processes that can be performed offline because of the potential for interruptions and the need to restart the workload from the beginning.

Therefore, Option D may not be the best choice for this scenario.

In conclusion, the best option for migrating a long-running batch process to the cloud while minimizing cost is to migrate the workload to a Compute Engine VM and start and stop the instance as needed (Option C).