The Heroku Platform, now from Salesforce, is a platform-as-a-service based on
a managed container system, with integrated data services and ecosystem for deploying modern apps. It takes an app-centric
approach for software delivery, integrated with developer tools and
workflows. It’s three main tool are: Heroku Developer Experience (DX), Heroku
Operational Experience (OpEx), and Heroku Runtime.
Heroku Developer Experience (DX)
Developers deploy directly from tools like…
$85
per month
Red Hat OpenShift
Score 8.6 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.
We kicked the tires on OpenShift before deciding on Heroku, and found the platform to be much less intuitive and well-documented than Heroku. It felt like we were constantly trying to implement workarounds for esoteric platform problems, and eventually the work became too …
Some APIs are specifically developed to be deployed to certain platforms and usually decision which platform to use is not developer's. Another question is deployment cost and pricing model; in specific cases after price comparison Heroku is often selected among other cloud …
[Red Hat] OpenShift is better as an actual environment, whereas Linode and GCE are more cloud-based VPS services. It depends on how fine you want your control, or if you want to have a certain underlying OS. Red Hat [OpenShift] will do more for you as a platform, but if you …
I tried Heroku. It was too tough to deploy. There were procedures given but no troubleshooting instructions. When I tried OpenShift it was very very easy to deploy and had no compatibility issues. Heroku had troubleshooting issues as well. I was unable to use other services …
Redhat OpenShift has been around for quite a while as I remember. I have found their public cloud to be easy to use and I haven't had to look at any other product. I have checked out Heroku but I am happy with OpenShift.
Cloud Foundry is open-source PaaS, started by VMware and spun out with other VMware-owned open-source code into EMC and VMware's Pivotal Software subsidiary. The Cloud Controller component is responsible for all management tasks. Being the main end point for the Cloud Foundry …
Leveraged Heroku for quick development environments. The tooling was comparable to OpenShift but the cost was much higher. In addition, being able to deploy the same applications in OpenShift Online and in the on premise Enterprise version is a benefit as it allows for …
Heroku is very well suited for startups looking to get a server stack up and running quickly. There is little to no overhead when managing your instances. However, you'll need a background in basic DevOps or system management to make sure everything is set up correctly. In addition, it's easy to accidentally go crazy on pricing. Make sure you're only creating the server instances you need to run the base application and set up an auto-scaler plugin to handle peaks.
Well, in our case, because I have two use cases, one is with the operator, which obviously is super easy with OpenShift because it's just click, click start aside from the issue from the operator. But that's a different interview. And the other point is for the web portal that our portal team uses, it's very easy. Two perform a task needed for them to do their deployment, their pipelines, and their daily Java.
Heroku has a very simple deployment model, making it easy to get your application up-and-running with minimal effort. We can focus on our efforts the unique aspects of our application.
The robust add-on marketplace makes it easy to try out new approaches with minimal effort and investment -- and when we settle on a solution, we can easily scale it.
Heroku's support is quite good -- their staff is quite technical and willing to get into the weeds to diagnose even complicated problems.
It provides you with a landing pad to modernize what you have in a phased approach so you don't have to do it all at once, right? You can take small pieces of work and implement those on OpenShift over time. It enables us to be able to implement things like GI ops configuration as a service, and infrastructure as a service using the tools that are native to OpenShift, which gives us far greater reliability and consistency as far as monitoring for any kind of drift and configuration or unauthorized changes. So it pretty much gives us a lot of visibility on things that are otherwise relatively difficult to see using the old means of doing what we do. So it provides us with a modern set of tools to accomplish all those objectives.
Large price jumps between certain resource tiers (2x Dyno for $50 per month versus Performance Dyno for $250). Free Postgres next jumps to $50 per month.
Marketing/Branding to non-technical stakeholders. As the years pass, I've had to fight more to convince stakeholders on the value of Heroku over AWS.
Improve Buildpack documentation. This is one area where Heroku's documentation is fairly confusing.
Network of observability, so having one single screen to see to have some network-related metrics for the pod levels. Also at the cluster itself level and more importantly is ease of use for troubleshooting when there's any timeout. This has been the single kind of issue I've been facing for my three years of experience with OpenShift and it hasn't been an easy task for such troubleshooting.
Heroku is easy to use, services a ton of functions for you out of the box, and provides a means to get a software product off the ground and managed quickly and easily. The tools provide allows a small to medium size org to move very quickly. The CLI tools provided make managing an entire technical infrastructure simple.
Leverage OpenShift Online constantly at both the free and paid tiers. While AWS is convenient, it often brings more administration than I want to deal with for a quick application (i.e. Drupal or Wordpress blog). OpenShift also simplifies the DNS registration and ability to share application environments with team members
Easy to use web based console and easy to use command line tools; deployment is done directly from a GIT repository. What more could you ask for? The one thing that keeps me from giving it a 10 is that custom build packs are almost incomprehensible. We used one for a while because we needed cairo graphics processing. Fortunately, I was able to figure out a different way to do what we needed so that we could get off the custom build pack.
As I said before, the obserability is one of the weakest point of OpenShift and that has a lot to do with usability. The Kibana console is not fully integrated with OpenShift console and you have to switch from tab to tab to use it. Same with Prometheus, Jaeger and Grafan, it's a "simple" integration but if you want to do complex queries or dashboards you have to go to the specific console
Heroku availability correlates pretty strongly to AWS US EAST availability. We had a couple of times where there was a Heroku-specific issue but not for the last 7-8 months.
Applications deployed to OpenShift clusters stay responsive when peak load hits or when the traffic dies down - since the platform reacts by scaling out or scaling in the deployed applications elastically - achieved through' policy sense and response automation - leveraging monitoring, measuring (metrics), auto-scaling to meet SLAs, SLOs, and SLIs. This approach works for stateless or stateful business logic hosting applications. The deployed applications perform consistently, stably, and securely across many deployment platforms - public clouds, private data centers, at the edge, or on factory floors - hosted by bare metal or virtual environments.
I've used it for many years without facing any major problem. It's not hard at all to get used to it, it's documentation is outstanding and simple. We are close to 2020 and I don't think most of the existing companies or startups should still face old problems such as wasting time deploying code and calculate computing resources.
Their customer support team is good and quick to respond. On a couple of occassions, they have helped us in solving some issues which we were finding a tad difficult to comprehend. On a rare occasion, the response was a bit slow but maybe it was because of the festival season. Overall a good experience on this front.
Be ready to pay a bit more than expected in the beginning if you're migrating from a big server. The application is probably not ready for the change and you have to keep improving it with time.
It's also important to consider that you can't save anything to the disc as it will be lost when your application restarts, so you have to think about using something like S3.
Heroku is the more expensive option for hosting compared to some of the cloud platforms we investigated, but it's worth it for us because of the plug-and-play nature of Heroku deployment. We can be up and running in a few minutes and know with precision how much it will cost us each month to run the application, unlike Amazon Web Services where you have to go to great pains to configure it correctly or else you might end up with a shocking monthly bill. Overall, spending the time to configure Amazon Web Services or one of its competitors is likely the more affordable and powerful choice, because you have control over so many specifics of the configuration. But it also requires the burden of continuing to maintain and update your AWS instance, whereas with Heroku they take care of security fixes and platform upgrades. It's a great service and we are happy to pay the extra cost for the value-adds Heroku provides.
We had some existing apps and were looking for a platform to modernize our app deployments and scale for future growth. Based on Kubernetes, OpenShift offers more flexibility and customization. We could deploy any type of containerized application, not just Cloud Foundry-specific ones. I particularly liked the built-in security and its focus on rapid and automated deployments. Moreover, our cloud strategy isn't set in stone. OpenShift's flexibility means we could deploy on-prem, in multiple public clouds, or use a hybrid approach - something other products couldn't offer as expected.
It's easy to understand what are being billed and what's included in each type of subscription. Same with the support (Std or Premium) you know exactly what to expect when you need to use it. The "core" unit approach on the subscription made really simple to scale and carry the workloads from one site to another.
I'll say a lot of positive impact because when we started making this product aware to all the application domains in our business, they saw how easy to use. I mean we are giving a lot of control to the development team, how they can scale their application, how can they check the health of the application, and what action they can take if they are in any kind of failure or even meeting the business's SLA. So there are a lot of capabilities and those are really new features they can use. Those I think are a good use of OpenShift.
