I work for an IT company as an architect. I design all the infrastructure and systems, and Google Compute Engine is one of the things that we provide solutions for. Customers using the Google Compute Engine use it for lift and shift models when moving from their on-prem environment to the Google Cloud. Usually, they are running the same type of workload they run on their on-premises on the Google Cloud.
One of GCE's best features is the managed instance groups. We typically use managed instance groups for high availability. You can set certain parameters for managed instance groups where if the load of the computer or server increases beyond 80%, for example, the solution will automatically spawn another instance, and the load will be automatically divided between two systems. If the load is 80% of one of the VMs or GCEs, once the load is divided, it comes down to 40%, so the availability of your systems goes up. However, that all depends on the parameters or configurations we put on the instance group. You also have regular health checks on these managed instance groups, which are configurable. If these health checks determine something wrong with the VM, they will automatically kick off or spawn a new GCE instance. This way, the outage time is less. Previously, on-premises, unless somebody reported the issue to the helpdesk saying that a particular service was unavailable, then a support team would need to troubleshoot what went wrong, which takes a long time. At least 30 minutes to one hour. But by using these managed instance groups, we can reduce the outage time, and second, we can configure them with minimal resources, bringing down our cost. And if the load increases, the managed instance groups automatically respond to new things. Subsequently, our costs decrease. We have a wide range of VMs. There are general-purpose VMs that can be used for hosting general-purpose applications. If some of our applications are memory intensive, then we have a lot of VMs in the M1 series. We can use a range of memory-optimized VMs for these things. We have C-series VMs for compute-intensive applications. If we use some mathematical formulas and require a very high throughput from that, there are GPU-optimized VMs used for machine learning or 3D visualizations in rendering software. GPU-enabled VMs are pretty powerful and responsive. Again, the best part is that we can spin them up when we need them, and once we're done with our work, we can shut them down, allowing tremendous cost savings for any customer. Previously, if we wanted a very high-configuration VM, we had to own the entire hardware and have it on our on-prem data center. And once we'd done with a particular activity, the system would just be lying there on our premises. That is not the case now. We use and decommission it, so we're only billed for the time we're using the product. One of the best things is the preemptible VMs or Spot VMs. These are the cheapest VMs in Google Cloud, but it has a string attached to it where Google can shut down these VMs whenever Google teams split. You only get about 90 seconds notice before they shut down this particular VM. There are scenarios where customers can use these preemptible VMs, for example, when running a batch job. Batch jobs are run once or twice daily, depending on the customer's requirement. Once we are done running these batches, we can decommission the VM. Even if, in the middle of this batch job, Google shuts down these VMs, we can pick up the processing from wherever the VM left off. These are some of the beautiful things we have on Google Cloud concerning the Compute Engine.
