Google Compute Engine Reviews

My usual use cases for Google Compute Engine involve deploying the backends and APIs only.

What I like the most about Google Compute Engine is SSH access and the different price categories. I have used custom machine types in Google Compute Engine, but not for large servers, only for smaller ones. While the deployments are sometimes much faster compared to the normal or static servers, the velocity is notable.

Currently, I have not found much value in the features or capabilities of Google Compute Engine because I only use SSH access, as I have not used many of their services. It is already set up by a different team, and I have been using them as it is a normal case, similar to a normal Linux server.

I have noticed a positive impact since the deployment of Google Compute Engine; it is simpler. However, for those who are not very much familiar with Google Cloud, it can, at times, be difficult. Also, the freebies are not much from Google's side, referring to the credits, so that users can become more familiar since there is a limited amount or it is case-dependent.

Without trying Google Compute Engine totally, I cannot tell you much about it. From my personal perspective, I suggest that while setting up Google Compute Engine, the process is hard compared to AWS. The complexity increases, especially if we want to access the things over the API; we need to explicitly set up things and can only access the CLI environment of GCP, which is sometimes a hectic task.

I have been working with Google Compute Engine for not more than seven or eight months.

The stability of Google Compute Engine is on par with other servers, akin to using instances from AWS, as no one needs any downtime. Everyone is facing the competition and needs reliable uptime. For instance, I remember when the US East 2 region experienced issues a couple of months ago; it was concerning, but there were no complaints about it. My engagement with Google Compute Engine has only been a small primary work for a few days, as I do not use it daily or anything else regularly.

I would say scalability is how deep my experience goes; I have not worked more than eight months, with about two months for learning and the remaining six months on work that got finalized and handed over to the client. It is entirely dependent on how other teams want to execute their future programs. If it comes to us, we will handle it; otherwise, we will pursue other options.

I do not usually communicate with Google's technical support because I have not had a chance, and from my side, I am comfortable with GCP. I can start with things on my own, and if I do not have any requirements, there is no need to reach out.

For me, the initial setup and deployment of Google Compute Engine were straightforward, but I would not know what others have faced. At times, when I started with GCP during my college days, it was not much easier. Since starting to work with GCP, it is sometimes easier, sometimes hard, and sometimes complex as well; it totally depends on the criteria.

Regarding the pricing and licensing of Google Compute Engine, when I refer to licensing, it implies the price or a credit-based system. While doing my personal projects, I prefer AWS over GCP and usually suggest the same to others because I have tried everything in AWS. It is difficult to recommend GCP due to its complex architecture.

The effectiveness of Google Compute Engine's global network for meeting my applications' low latency requirements totally depends on the use cases; it is not comparing the services of each other. It is essential for the permanent use cases. My experience so far mostly involves GCP, GKE, and GCE, and I have not worked extensively on many other aspects.

I have not experienced the importance of Google Compute Engine's live migration feature for maintaining service availability during maintenance, so I cannot comment on it.

I have not integrated Google Compute Engine with any other Google Cloud services such as BigQuery; I just installed the services, and everything was done by another team.

I would rate this review a seven overall.

I use the solution in my company for a website, specifically for some web applications. I just use Google Compute Engine as a server for my website and my web application.

As far as I know, Google offers the biggest cloud services, and I use it. With the tool, I can scale the services.

The synchronization between two tools, meaning if I have another server outside Google Cloud, as far as I know, I cannot mimic the server in Google Cloud to another server outside Google Cloud. I don't know if Google has the above-mentioned features or not, and if it does have them, then maybe Google can help us set things right and how to make a server mimic either of the servers outside Google. With the hot swap features or if Google Cloud itself is down, we can replace the services with another server. Right now, I have another server outside Google as a backup of a production server. There should be synchronization between servers inside Google and those outside it. The high availability features in Google are only available in Google Compute Engine in different regions. If I have another server outside Google, the high availability features in Google cannot synchronize with such a server.

I have been using Google Compute Engine for a year.

The tool is more stable than our servers outside of Google. I rate its stability a nine out of ten.

Scalability-wise, I rate the solution an eight out of ten.

Currently, the server is handled by our company's integration division, consisting of two users. The server cannot cannot be accessed by random users.

Our company has been using Google Compute Engine for a month on projects.

My company never contacted the solution's technical support as we prefer to contact the vendor.

The solution is deployed on Google Cloud.

The vendor does the product's initial setup phase.

The product may have helped me save some costs, but I have never taken a count of it as it is a safe product compared to the other solutions. Right now, I am just using Google Cloud. I don't have experience using cloud services other than Google. I don't have a comparison to figure out if Google costs more than the other cloud services.

The tool is reasonably priced, considering its scalability features. If we want to extend the server's capacity, we can do it, and I think it's reasonable.

I have never used AI in Google Compute Engine.

I recommend the tool to others since it has high availability features, scalability, and stability.

I rate the tool an eight out of ten.

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.

There have been instances when a customer has tried to deploy a certain number of VMs inside a project, and they come across quota issues. When they come across these quota issues, they have to reach out to the Google support team and ask them to increase their quota. Doing so typically slows down the deployment.

I've worked with the product for about three or four years.

With respect to the solution's performance, we choose the configurations we require, and we have never seen a case where the solution has gone wrong or gone down. Whatever we are expecting from the Computer Engine meets the performance standards. We have had 99.999% uptime, and Google has always met this particular SLA. We have never had any issues with their systems going down or being unavailable.

Google Compute Engine is very scalable. With respect to managed instance groups, we can configure them to go up to any level. The only issue is the quotas because as we keep spawning new VMs, we exhaust our quotas, and we would need to reach out to the Google support team to increase our quotas. GCE also has a huge dependency on applications deployed on Compute Engines. However, with respect to Compute Engine, scalability is not an issue, and we can easily scale it up to our requirements.

The number of users changes from customer to customer. Some customers only have one application deployed on these Compute Engines, and some might have multiple applications to put on a single PC instance.

I am satisfied with their services.

Positive

Depending upon the deployment's complexity, customers with fewer workloads choose a manual deployment. But what we recommend is an automated way. Before deploying workloads on the Google environment, we must build the landing zone and other things. Google has a very good support structure, with many Terraform scripts and code, which can be used to quickly deploy a landing zone. This landing zone platform port is customizable depending on the customer's requirement. We use Terraform codes to deploy the entire landing zone and even the deployment of the VMs. The workload is typically automated.

It defeats the purpose of going onto the cloud when we want a single person to sit and deploy the entire thing. Even though it is much faster when compared to the on-prem version. Very large deployments with more than 100 customers using 500 to 1,000 VMs typically have to be automated. Still, it's not only about deployment but also the maintenance of all these workloads. For example, whichever OS is deployed on the VMs, we have to patch those systems regularly whenever there is some security patch or any patch that comes in. And unless we have an automated solution, we cannot do it manually because it takes a lot of time. But in the Google Cloud case, we have something called a VM Manager, and we can configure this VM Manager to automatically deploy these OS patches onto the VMs. The deployment and maintenance of all the Google Cloud Compute Engine instances are automated.

It takes less than five minutes to deploy the solution.

GCE is pay-as-you-go. If we are using fewer resources, we pay less to Google. And if the load increases, we automatically provision new VMs, and if multiple VMs spawn, we pay for them. As the load goes down, new VMs that were provisioned will be deleted or decommissioned, and our billing will return to normal.

I rate GCE's pricing a five out of ten since it's affordable.

The solution meets all the requirements. I highly recommend Google Compute Engine. Looking at it from the architecture point of view, GCE is as good as working with an on-prem workload. It is very transparent to the end user, who wouldn't know whether it is on Google Cloud or whether it is on Azure or on-premises.

I rate Google Compute Engine a ten out of ten.

I have worked with SAP migration. During SAP migration, we have different flexibility of the classes of compute for the load for SAP's load. My whole career was in SAP. So when I moved to cloud, I also did migration of SAP loads into the cloud.

Google Compute is highly scalable. Their private network is as big as the global internet, which is a significant advantage. Additionally, the flexibility of compute and storage types is quite adapted and designed for SAP's big model.

Google has a lack of focus on their products. They have many products in various areas of the market, but they do not productize or appeal to the market effectively. They should concentrate on productization and marketing. In the SAP environment that I've used, Google's product is stable, however, the initial mapping of it is critical.

I have used Google Compute since 2015.

There have been no glitches or problems with the stability of the SAP environment that we have used.

Google Compute is highly scalable, comparable to AWS. Their zone and region scalability is excellent, and their private network is a big advantage, offering low latency and high security.

Google support could be better. Companies generally do not want to invest heavily in enhancing their support level. They tend to keep it minimal and optimal for cost-effectiveness.

Before using Google Compute, I was in SAP, doing SAP on-premises solutions for our customers.

The setup is easy and straightforward using the Google Dashboards.

One person is sufficient for the execution, and one architect is good enough for the planning.

Google resources are cheaper compared to AWS and Microsoft Azure. Among the three, Google is the cheapest option.

The main advantage of Google Compute is their private network, flexibility of clusters, and scalability. Their pricing is also competitive compared to other major players like AWS and Microsoft Azure.

I'd rate the solution eight out of ten.

Google Compute Engine is the base and the fundamental part of the infrastructure as a product of the Google Cloud platform. Everything is based on the Compute Engine.

We use Google Compute Engine to create instances and then use the instance to connect and integrate with other products on the platform. I'm a data scientist and I use Vertex AI a lot. Each Vertex AI has a fragment called Compute Engine. With Compute Engine, you can integrate the database and use Vertex AI with it.

With Compute Engine, Google manages all hardware. You don't need to provision or pre-provision your computer engine. You don't have to worry about where your Compute Engine is, whether it's in Frankfurt or New York since it solely depends on your demand. It is quite elastic. For example, ten years ago we used the on-premise Compute Engine and we constantly had to worry about scalability. With Google Cloud Compute Engine, there is no need to worry about capacity. If you need it bigger, you can upgrade it. If you need it smaller, you can downgrade. Another thing I like about it is that you pay-as-you-go. I think that the minimum you have to pay for Compute Engine is only one hour. If you don't have to use it, you can just stop it and save a lot of money that way. If you wish to use it continuously, Google offers you a discounted contract. It is very cost-effective and I like its availability as well. 

About eighty people at our company use Google Compute Engine. The data engineering team and the data science team use it.

I would say that Google Compute Engine is easy to use for skilled people and people with a tech background. For regular users who do not have experience with the cloud platform, it is not very user-friendly. If you wish to use Compute Engine, you must know a lot of technical terms such as availability, instance, and scalability. You also need to choose the proper instance for you. In my experience, there is a standard option, an advanced option, and a customized option for Google Compute Engine. You can choose the Compute Engine with high speed or with memory speed. All of this is too much for a person who is not tech-savvy. I am not sure whether they designed it like that on purpose or if they plan on improving it.

I cannot think of any features that need to be upgraded.

I have about five years of experience in using the Google Cloud Platform.

The solution is quite stable. I have not seen Compute Engine crash. The SLA is 99.99%, which is quite high.

So far, I have not escalated any questions to technical support.

I would say I am a GPT expert. I have used DataFlow, PCare, and Vertex AI. I have also used Microsoft.

There is not much difference between Google and Microsoft when it comes to technicality and user experience. It depends on what your organization uses. If your organization chose Microsoft, then you'll use Family. If your organization chose Google, you'll use GCP.

The deployment procedure is quite straightforward.

You have an account, and then you search the account engine. Then you can see the dashboard, create an instance you need, and choose the engine you want to use. You can also choose the storage disk you want to attach with it. This will give you the highest flexibility and you can choose the network you want to integrate with. You do not have to customize it because it also has a default mode which helps you finish the basic settings.

It does not require much maintenance. You can maintain it yourself. For example, our former employee left the company but his computer engine was quite large and cost a lot of money. I downgraded the engine myself and switched to a smaller instance. That saved us around sixty percent of the cost. This just goes to show that you can do almost anything you want with the solution.

It is difficult to calculate the ROI of Compute Engine. Maybe if you combine it with other products, based on Compute Engine it would save a lot of money. For example, we use PCare and Looker for visualization. They are based on the Google Platform. If you use those two, you can save a lot of money that you would otherwise pay for IBM or Tableau.

The unit pricing is affordable and makes sense. The general cost of the solution depends on how your company plans and organizes everything and how the solution architects design it. There are many ways to improve cost-effectiveness. If you do not use it wisely, it could cost a lot of money.

My advice to new users would be to hire a good data engineer since it's only user-friendly for experienced users. They should also think about what is the main trigger for moving to cloud and if they have a precise plan for doing that. 

Using Compute Engine is just the first step. After, you can decide whether you will migrate your database to cloud or not. 

I recommend having at least one data engineer and a solution architect to help create a plan and reach targets.

Overall, I would rate it an eight out of ten.

One of the use cases is autoscaling. It has been quite robust and easy to use for autoscaling. Second, within the console itself, the whole developer experience is far superior as compared to other cloud providers. 

The third, mainly from a networking perspective, is the ability to use multiple regions for load balancing and networking capabilities. I can switch between multiple regions as and when required. 

For specific use cases, in certain types of machines, we don't always get the required compute power. But, it depends from region to region, and sometimes there are resource crunches, and you may not get the required configuration as you need.

The benefits have been mainly from the faster adoption or the ease with which I have deployed this for consumers or my engineering teams. The pace with which I can bring up an infra, that is, the time to market, has been important for me. So that is fast. Again, it's more time-based only, but, yes, the ease with which I was able to migrate from on-prem to Google Compute Engine was quite seamless without having to worry about whether my workloads would continue to run the same or not. So, that was a seamless experience. 

Another one I would specifically highlight is the fact that, from a perspective, most of the cloud providers give that, but I probably am a bit biased towards Google and the way in which it has its storage layer linked.  So, the persistent disk for the local SSDs provides better throughput as compared to some of the other providers, plus it now has these GPUs and TPUs as well.  So that helps a lot.

From a feature perspective, I find API integration, automation capabilities, and features like preemptive and Spot instances valuable. Migration tools have also been useful.  

I also value the ease of adoption and deployment for my engineering teams. The speed at which I can bring up instances is crucial. Migrating from on-premises to Compute Engine was seamless. Additionally, Google's storage layer, including persistent disks and local SSDs, provides better throughput compared to other providers. The availability of GPUs and TPUs is another advantage.

On the console itself, there is something called the recommendations that it provides. So, if I'm underutilizing or overutilizing a machine, it gives me insight into whether I should under-provision my machine or switch to a lower config machine to save some cost. So, that recommendation feature is quite useful.  So, overall, I like the solution's automation, migration, and API integration.

In terms of improvement, one is definitely the licensing piece. So there is a feature, the BYOL (Bring Your Own License) licensing piece, to bring your own license. It is not that straightforward. It requires some support from Google to get it sorted, access those licenses, and configure those licenses. It is not a very straightforward process. So, BYOL definitely needs some sort of improvement out there.

There can be many additional features in future releases. So GCE has been the core, pure module; from a feature set perspective, it has matured enough. But if there could be an auto-switching capability. Autoscaling is there, but it will differ or be restricted to certain types of machines.

So, for example, I use an N2 class machine or a memory-optimized M1 or M2. It will only scale in that particular configuration itself. The configuration might not change. Now, I should have that capability depending on the workload and what I deploy. So, depending on the type of workload, Google should recommend that this should be the recommended configuration based on which the instance can be set up. So, more of an automated configuration or a recommendation is something that I'll look for in future releases.

So, one feature I would like to see is auto-switching, or auto-scaling. The second feature is a recommendation based on the application.

It has been using Google Compute Engine for more than seven years now, right from its inception. I've been an early user of it.

In the past few years, I've been both a partner and a customer. I've experienced both sides. I've used it as a partner, implementing services using Compute Engine, and I've also used it as an end-user to build products. I was working as a partner more than 18 months ago, but currently, I am using it as a customer.

Stability would differ from region to region, but it is almost on a scale of around nine out of ten.

In certain regions, there are resource and bandwidth issues. That's why I'm rating it on the lower side on some markings on that. Otherwise, it's fairly stable.

I would rate the scalability a nine out of ten. The solution offers a high level of scalability, it's able to adapt to our needs.

We have multiple workloads running; on average, any workload running has around 50 to 1000 users. The solution has been used quite significantly because our primary workloads are with GCE. The computing infrastructure relies on GCE. We do have it as a backup site as well. So, 80% of the workload runs on GCE.

We already, like, kind of maxed out our current usage. It will depend on the business strategy or any new application that comes in. We'll definitely expand in that case. But, at the moment, depending on the needs, we have fairly maxed it out.

The customer service and support are fairly good. We are satisfied with the services they provide. They are fast and effective. 

Positive

We were using certain shared hosting services. So, something like what the older generations were using. And then we decided to move to the cloud. So, there were some old-generation computers that were used.

We mainly switched to Google Compute Engine because we wanted to go to the cloud. One was the cloud that had all kinds of better scalability costs and everything. So, combining all this with moving to the cloud was a better option.

In terms of the deployment process, we have two major deployment processes. One is via the console; the other is via the command line interface. And the third is using any Terraform tools like Terraform modules. So I've used all three of them. 

Personally, I'm comfortable with all three. Terraform requires some upskilling and some learning curve. However, the console is quite straightforward to implement and use, as well as the command line interface. So, specifically, using the shell, like, a piece of cake.

The people required for the deployment will depend on the type of implementation and the size of the implementation. I have done it as an individual. I've done deployments with a team of ten engineers as well. Therefore, it depends on the scale of the application itself.

To deploy the lowest spectrum, it would take a few hours. The highest has some additional dependencies; it would take a span of five days or so.

Moreover, the maintenance is fairly minimal. Very rarely, if I have to change certain configurations or if I have to change certain OS parameters based on the applications, only then it requires maintenance. Otherwise, there are instances in which I have been running for the last three years and stable enough.

I cannot quantify ROI, but our application's performance has improved since we moved from an on-prem to a cloud. So, that's one major ROI for us. We saw approximately 60 to 70% improvement.

The pricing is competitive in nature. In certain cases, AWS might be cheaper. In certain cases, GCE might be cheaper. And depending on the region you are hosting, you can get that cost benefit.

I would rate the pricing a five out of ten because it is neutral. The price is fair for the function it provides for the services we receive, and the price is okay for this product. As an end user, I would want the pricing to be cheaper. 

If we need that premium support, those are some additional costs that we would incur or any networking costs that can be incurred. But nothing apart from that.

We did evaluate a few other options. It was mainly AWS that we evaluated. We also evaluated DigitalOcean. We looked more from the ease of usage, the console, and all perspectives; GCE was on the higher end of the spectrum.

So, there are three key takeaways. One is to meet all your use cases from a functionality perspective; the solution is robust enough.

Second is that it is quite intuitive and easy to use from a development perspective as well as from an operational aspect as well. So, the second is from the ease of usage perspective.

Third, from the innovation side of things, GCP has been at the forefront. Whether it is about cost or the features; this solution always been on top of its game. So, they were the ones who brought this per-minute pricing itself. So, the solution has always been on the innovation side of the cloud.

Overall, I would rate the solution an eight out of ten.

Compute Engine is an option to create virtual machines in GCP. We can set up our service now. We can use Compute Engine for load balancing, and we can categorize it into three different types: general purpose, compute optimized, and memory-optimized. There are a lot of CPU options to choose from, so we can select the one that best suits our needs. We can create Compute Engine instances anywhere in the world, and we can deploy our services to them. This ensures that our application has a global presence.

Another feature of Compute Engine is its networking capability. It provides networking capability to VPCs, which are private cloud networks. Compute Engine also provides instance templates. We can define our virtual machine configuration in an instance template and then use that template to create new virtual machines. We don't need to specify the region or other details when we create an instance template because instance templates are global services. We can use an instance template to create a new virtual machine at any time with the same configuration.

Another service provided by Compute Engine is managed instances. It allows us to create a group of identical virtual machines. The virtual machines in a managed instance group all have the same configuration. We can ensure that a minimum number of instances are always up and running, and if an instance fails, Compute Engine will automatically create a new instance with the same configuration. This ensures that our service is never unavailable.

Compute Engine also provides a load balancer to distribute traffic to our virtual machines. The load balancer provides a single IP address for our service, and it distributes traffic to the virtual machines in our managed instance group. This allows us to scale our service up or down without having to change any client code.

It's the managed instance. You never feel any delay or service. If something happens, it will automatically create a new instance with the same configuration.  

It would be better if there was an option to change the background. Like in Gmail, there's an option to change your theme. That's my recommendation.

I started learning about this solution last year. 

It is a stable solution.

It is a scalable solution. Google is trying to make data centers and edge locations to increase its services. Google provides machine learning and artificial intelligence through GCP.  

I used to try AWS EC2. It's a kind of infrastructure. I tried AWS EC2 before I learned EC2. It is helpful to learn GCP. EC2 is also the same. We can create virtual machines in the AWS platform. 

When it comes to the purpose perspective of end users, GCP is much better than AWS, especially for building devices. Also, the network device is very simple. When we create a VM, it is better. When we create resources, like databases, I will definitely go with GCP. And when I compare, I really go with GCP. It is very easy to use and have minimal learning curve.

Everything is simple and useful. The initial setup is not challenging. You just need a credit card and a Gmail account.  If you have a credit card, you can just get a platform account. 

Google is providing money for learning Google Compute Engine. They offer a $300 free trial to new customers. Any beginner can easily get started.

From the maintenance point of view of Compute Engine, there is an option to auto-cost maintenance. So we never experience a delay in our services because our new build to host machines. There is no delay in that case. Nowadays, if something happens in Google Cloud, in case of numbers or necessary traffic, it will be resolved within a day or two.

First of all, you have to analyze your workload and sign which kind of machine type, how much memory you need, and what kind of traffic you expect. Analyze your workload and your requirements. Make a cost explanation of how much you can spend for your service in a month. 

Once you analyze your workload and determine your cost explanation, use the pricing estimation with the price target. And because you are the amount you plan to spend in a month. Find the cost provided by the price package. Compare both. If there is a minor or no difference, both are comparable. Everything is matching, you can go with your requirements and build your infrastructure based on your economy. 

If there is a huge difference, you can reassess your resources in pricing guidelines and make resource changes. But the things you have to come there. If there is no significant difference, you can proceed. Otherwise, change the option. 

And then you will get a solution, how to make both things like we've both things, like the infrastructure, it's preferred in your pricing estimation, and your actual costs. If both are almost similar, you can create it, use it, and deploy it.

Overall, I would rate the solution a nine out of ten.

Google Compute Engine is a typical VM. We use it in Kubernetes host machines. 

The solution is readily available, and software engineers can provision it. It is scalable and allows self-service. 

Google Compute Engine needs to have multi-region support. It would also be nice to have a tracking mechanism. 

I have been using the product since 2015. 

I rate Google Compute Engine's stability a nine out of ten. 

I rate the product's scalability a ten out of ten. 

Google's technical support is bad. 

Neutral

Google Compute Engine's installation is basic. 

We have seen ROI with the tool's use. 

Google Compute Engine's pricing is flexible and the best of all other alternatives. 

I rate the product a nine out of ten. 

We use the solution to host a self-hosted helpdesk.

The solution helps to direct SSH into the machine at the click of a button. It also helps to deploy container images right from the UI. There is no need to manage the containers on the machine. I also like the tool’s Spot provision model.

I would like to improve the solution’s UI while deploying a container. It is sometimes hard to figure out the container’s details and format that you want to deploy. The tool does not give you a guide to finding out the error and why the container is not starting up which could be because you have configured it wrong. This is always a hit on the setup.

I have been using the solution for five years.

The tool is stable.

Our company has more than 1000 users for the tool.

The initial setup is very easy. The deployment took two minutes to complete.

I would suggest new users take a look at Spot instance since it can help you significantly reduce costs. I would like to see dedicated and better UX for container deployment in the tool’s future releases.

Google Compute Engine is easy to use and has great authentication management for Google APIs. The solution can directly escalate and it's easy to get started with.

We use GCE for deploying our applications, websites, web applications, and web services. It deploys our code into production. We use that instance for automated load handling, enabling horizontal scaling and load increases. About 30 to 40 people at my company use it. 

The most valuable feature is auto-scaling. 

I think for three to four years. Three years I would say.

GCE is a highly stable high-availability product.

Compute Engine is highly scalable. We use instance groups, so we configure a single compute instance. It will automatically spin up the same machine and configuration when necessary. 

So the reason is that it's developer friendly and it's easily manageable, it's easier to learn than AWS.

Setting up GCE is straightforward. It usually takes less than a minute to spin up an instance. 

Compute Engine is a pay-as-you-go model, so we don't have any upfront costs. It only bills for the time that the machine is up and running. I can bring down the application at any time, and the billing will stop. The pricing is based on the amount of resources you are using. It's priced similarly to AWS.

I rate Google Compute Engine 10 out of 10.