Google App Engine is Google Cloud's platform-as-a-service offering. It features pay-per-use pricing and support for a broad array of programming languages.
$0.05
Per Hour Per Instance
Red Hat OpenShift
Score 9.3 out of 10
N/A
OpenShift is Red Hat's Cloud Computing Platform as a Service (PaaS) offering. OpenShift is an application platform in the cloud where application developers and teams can build, test, deploy, and run their applications.
N/A
Pricing
Google App Engine
Red Hat OpenShift
Editions & Modules
Starting Price
$0.05
Per Hour Per Instance
Max Price
$0.30
Per Hour Per Instance
No answers on this topic
Offerings
Pricing Offerings
Google App Engine
Red Hat OpenShift
Free Trial
No
Yes
Free/Freemium Version
Yes
Yes
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
Google App Engine
Red Hat OpenShift
Considered Both Products
Google App Engine
Verified User
Anonymous
Chose Google App Engine
For our organization, we selected Google App Engine which provides a reliable and efficient way to create and deploy apps moreover it supports a lot of languages and provides automatic debugging of code which enables us to deploy code to production as soon as development is …
If you have a small team which is also responsible for development of the product then surely go for it. And if you have a larger team with dedicated person to take care of deployments. Go for cheaper options such as compute engine or AWS (be sure to do your research on pricing …
It's the manageability of the Google App Engine which made it a better option in our case. It's quite straightforward to deploy on App-Engine. No worries for monitoring setup
You can create and scale Kubernetes clusters quickly, but you have to keep an eye on that cluster. In-App Engine, you don't have to worry about infrastructure, but in some scenarios, Kubernetes fits better.
Google App Engine is the first product we picked up to store the mass data. Later we came to know that, firebase database is also similar to Google App Engine. But still, we didn't step into it. We will try it later.
Azure App Service is in par with Google App Engine although you may want to use Azure App Service if you are integrating with other Microsoft IT components, for example SQL Server. Google App Engine is great when in long run, you will be using Google cloud components, for …
App Engine is a much more streamlined system than EC2. There is a fundamental difference between them, but they are used for basically the same thing as far a I could tell -- to serve applications EC2 is certainly more complicated, but if offers more machine-level control if …
Google App Engine is very easy to use and mostly up to date makes it compatible with all old and new devices. The applications are very interactive and the prices are accessible for most users. The prices tend to get slightly expensive as we head on towards higher …
The two giants are Google and Amazon. Both are very similar however Google App Engine allows you to deploy your web applications through platforms like Python where as if you're using AWS, you have full control on the operating system services. Google is good because you pay as …
We were on another much smaller cloud provider and decided to make the switch for several reasons - stability, breadth of services, and security. In reviewing options, GCP provided the best mixtures of meeting our needs while also balancing the overall cost of the service as …
We commonly decide between App Service, Elastic Beanstalk, and App Engine. Normally, we do not have a strong preference for the services, it really comes down to whether or not there are other factors drawing us toward a particular platform. In the case of App Engine, it is a …
I think that Microsoft and Amazon are simply investing more in their offerings, and there are a bunch of cool PaaS solutions out there as well. Google App Engine is solid, and is probably the right choice for some projects. But ultimately one should evaluate each platform …
Google Apps is great for environments where the need for a more robust platform is not necessary if you are looking to have email and cloud collaboration enablement of your working staff. From the stand point of using both, I can see the value of both but it really depends on …
AWS and Heroku are both great, and I use them both extensively for different projects. Google App Engine was chosen because it is much more innovative than AWS, and because Heroku specializes in Ruby on Rails. Even though Heroku supports Java and other services, we feel Google …
With GAE it's a matter of "code your app and deploy it". You don't care on what servers or on how many servers it runs. System administration is done for you. With AWS you still have to be a system administrator with good knowledge and undestanding of load balancers, database …
You can spawn up your own cluster using Kubernetes or Container Engine which will scale automatically when configured properly, but you have to keep an eye on that cluster. In App Engine you don't have to worry about it at all, just ship your code and it will run.
We chose Google App Engine because it supplies the most infrastructure per dollar spent. It's much more expensive to use Amazon EC2 to scale to over a million users. Also, the engine's narrow language support system, while somewhat limiting, makes getting started quickly much …
We left Lotus Notes for the (more versatile) Google Apps. We could never recommend the closed architecture of Lotus Notes. We have evaluated Office 365 and believe the product is compelling. So compelling, that we may consider a platform change…
Google App Engine stands out since it offers everything as being a platform as a service. The other options I used before, such as classical development with servers available either in house or in the cloud still require a lot of management and the software frameworks …
Nothing like OpenShift. Actually, this was our first one. We toyed with maybe doing raw Kubernetes, but with an enterprise company you need an enterprise product.
Comparing the 2, open source Kubernetes is quicker to setup by about 75%, less restrictive, and free of course, but it lacks the security and support of Red Hat, and deploying features is much harder compared to with operators. For buisiness purposes, OpenShift is just more …
Even though Red Hat OpenShift has more overhead than many other Kubernetes flavors, we have selected Red Hat OpenShift because of it's focus on Security and because of it's excellent vendor support.
Red Hat OpenShift has a better security posture than EKS. I enjoy the console on Red Hat OpenShift more as well. I believe there is greater observability for Red Hat OpenShift.
The Tanzu Platform seemed overly complicated, and the frequent changes to the portfolio as well as the messaging made us uneasy. We also decided it would not be wise to tie our application platform to a specific infrastructure provider, as Tanzu cannot be deployed on anything …
Google App Engine is especially well suited for situations where there is a variable workload during the day, e.g. inbound task processing with task queues. In this situation queues can be setup with parameters governing the process speed/scaling which allows you to easily balance performance with cost and meet a good balance.
Red Hat OpenShift, despite its complexity and overhead, remains the most complete and enterprise-ready Kubernetes platform available. It excels in research projects like ours, where we need robust CI/CD, GPU scheduling, and tight integration with tools like Jupyter, OpenDataHub, and Quiskit. Its security, scalability, and operator ecosystem make it ideal for experimental and production-grade AI workloads. However, for simpler general hosting tasks—such as serving static websites or lightweight backend services—we find traditional VMs, Docker, or LXD more practical and resource-efficient. Red Hat OpenShift shines in complex, container-native workflows, but can be overkill for basic infrastructure needs.
Building an application that uses Google's Authentication, means users no longer need to remember an different user id and password. Once they are logged into to Google, they can seamlessly access your application hosted on Google App Engine.
Google App Engine automatically scales up and down. SO if your application receives a spike in user traffic, App Engine automatically launches additional instances of your application to cater for the increased traffic. Once App Engine detects that the spike is usage is over, it automatically scales down to handle the current traffic.
Google App Engine can be easily integrated with Google Cloud SQL, Google Compute Engine, Google Cloud Storage etc, so that you can build out a full application using one or more of Google's Cloud Platform products.
One thing is the way how it works with the GitHubs model on an enterprise business, how the hub and spoke topology works. Hub cluster topology works the way how there is a governance model to enforce policies. The R back models, the Red Hat OpenShift virtualization that supports the cube board and developer workspace is one big feature within. So yes, these are all some features I would call out.
So I don't know that this is a specific disadvantage for Red Hat OpenShift. It's a challenge for anything that Kubernetes face is. There's an extremely large learning curve associated with it and once you get to the point where you're comfortable with it, it's really not bad. But beating that learning curve is a challenge. I've done a couple presentations on our implementation of Red Hat OpenShift at various conferences and one of the slides I always have in there is a tweet from years ago that said, "I tried to teach somebody Kubernetes once. Now neither of us knows what it is."
App Engine is a solid choice for deployments to Google Cloud Platform that do not want to move entirely to a Kubernetes-based container architecture using a different Google product. For rapid prototyping of new applications and fairly straightforward web application deployments, we'll continue to leverage the capabilities that App Engine affords us.
This is the current strategy for the company, most of the products in the organisation are aligning to Openshift and various use cases it support. Also lot of applications are being developed for AI use case, openshift.AI provides opportunity to host and leverage the AI capabilities for these applications
Google App Engine is very intuitive. It has the common programming language most would use. Google is a dependable name and I have not had issues with their servers being down....ever. You can safely use their service and store your data on their servers without worrying about downtime or loss of data.
The virtualization part takes some getting used to it you are coming from a more traditional hypervisor. Customization options are not intuitive to these users. The process should be more clear. Perhaps a guide to Openshift Virtualization for users of RHV, VMware, etc. would ease this transition into the new platform
Redhat openshift is generally reliable and available platform, it ensures high availability for most the situations. in fact the product where we put openshift in a box, we ensure that the availability is also happening at node and network level and also at storage level, so some of the factors that are outside of Openshift realm are also working in HA manner.
Overall, this platform is beneficial. The only downsides we have encountered have been with pods that occasionally hang. This results in resources being dedicated to dead or zombie pods. Over time, these wasted resources occasionally cause us issues, and we have had difficulty monitoring these pods. However, this issue does not overshadow the benefits we get from Openshift.
Good amount of documentation available for Google App Engine and in general there is large developer community around Google App Engine and other products it interacts with. Lastly, Google support is great in general. No issues so far with them.
Every time we need to get support all the Red Hat team move forward looking to solve the problem. Sometimes this was not easy and requires the scalation to product team, and we always get a response. Most of the minor issues were solved with the information from access.redhat.com
I was not involved in the in person training, so i can not answer this question, but the team in my org worked directly with Openshift and able to get the in person training done easily, i did not hear problem or complain in this space, so i hope things happen seamlessly without any issue.
We went thru the training material on RH webesite, i think its very descriptive and the handson lab sesssions are very useful. It would be good to create more short duration videos covering one single aspect of openshift, this wll keep the interest and also it breaks down the complexity to reasonable chunks.
App Engine is a much more streamlined system than EC2. There is a fundamental difference between them, but they are used for basically the same thing as far a I could tell -- to serve applications EC2 is certainly more complicated, but if offers more machine-level control if that's what you need. It can tend to cost more as well. App Engine is far more straightforward but there are limitations if you need to change the environment. But even then, Google Compute Engine also compares to EC2 and stays within GCP.
We utilized the Thycotic Secret Service to manage all our application secrets, resulting in seamless integration with our applications. We developed all the applications using Red Hat Fuse (currently migrated to Quarkus). We used the built-in Kali Linux support of OpenShift to manage and configure the services and API. Additionally, the Red Hat Developer Studio facilitates faster development.
This is a great platform to deployment container applications designed for multiple use cases. Its reasonably scalable platform, that can host multiple instances of applications, which can seamlessly handle the node and pod failure, if they are configured properly. There should be some scalability best practices guide would be very useful
It has allowed us to see where we need to be in the container world. I'm going to call it a net neutral impact, not negative or positive. It has given us a sense of what we are ready for and what we're not ready for. You know where you stand.
You don't know what you don't know, so it helps us know what we want to know.