We use it for
- some of our websites
- one of our main applications for the City of Gothenburg
- automation
- the underlying operating system for our GitLab server.
We use it for
We have many different databases running on RHEL. Among them we have MySQL and POSTGRES and they all run great on RHEL 7 and on RHEL 8.
Using this solution, we can offer our customers an easier way to get a WordPress site, and they can have POSTGRES and Tomcat installations, and these run smoother on Linux than they do on Windows.
We also use both Ansible and Satellite from Red Hat. They are integrated with RHEL and they work like a charm. The integration works great. We use Satellite for patching our RHEL servers and we use Ansible to automate the patching and deployment of config files. That means we don't have to worry that much about the patching. If we want to deploy the same config file to 100 systems, we just run the playbook with Ansible and it's done. We don't have to run it on 100 servers.
The most valuable thing for us is the support that we get from Red Hat for the product. One of our most important applications here in the City of Gothenburg runs on RHEL, so if something happens, we have a partner to get support from.
The solution has features that simplify adoption for non-Linux users. There is an interface that you can activate on RHEL systems, and on other Linux systems as well, so that you will get a graphical user interface instead of just a shell. It's easier for an administrator who is used to only working on Windows.
In terms of the deployment and management interfaces for non-Linux users and Linux beginners, for me it was quite easy to get on with Linux and RHEL. And if you're not using the Cockpit, or graphical interface, then it's a bit harder because then you have to type in everything and you don't get any visual guides. On the RHEL systems that we have, we haven't been using the desktop environment; we only just use the shell environment. But using Cockpit is much easier because then you get a visual, graphical interface.
Sometimes they don't have new versions for applications like Apache or PHP. I understand it's because they have to have support for them, so they can't have the latest version all the time, but that's the main thing I see that could be improved.
So when you use RHEL and you want to install, let's say, Apache or PHP, you do a "dnf install php" and you get a specific version that Red Hat releases. But that isn't the latest version that PHP has released, because Red Hat has to make sure that they can support it. The compatibility with the latest version of Apache or PHP lags because RHEL does not release updates of the latest versions.
It's the same with the kernel. Sometimes they are a bit behind in the kernel version. That's the same issue. They have to test it and support it for so many years so that's why they are a bit behind on the kernel as well.
We've been using Red Hat Linux (RHEL) for more than 10 years. We are using versions 6, 7, and 8.
It's a really stable operating system. It has a lifetime of about ten years per version. It's not like other Linux systems where the lifetime is about five years. It's stable and it runs for a long time so you don't have to change the operating system that often.
It's easy to scale up and scale out.
Of the people using our RHEL systems, some are system administrators and some of them are just consuming power or memory or CPU from the server. They only have websites and they don't come into contact with the underlying operating system.
RHEL accounts for about 10 to 15 percent of our servers. Our usage increases all the time.
The solution also enables you to deploy current applications and emerging workloads across bare-metal, virtualized, hybrid cloud, and multi cloud environments. We only use on-premise in our infrastructure, but you can have it on bare-metal or on cloud or multi cloud. For us, it's been running great. It's reliable.
Red Hat's technical support has been quite good. Sometimes the lead times are a bit long because most of the support is in India, it seems, so there is a time difference. But if we need to get a higher level of support, we can just bump up the priority. So that's really good. We will get help faster.
I don't think our company had a similar solution before RHEL, although that was back before I started with the company. The company started with RHEL because they wanted to have support.
Red Hat, as a company, is a big contributor to the open-source community. That's another one of the reasons that we want to use RHEL the product.
The setup was quite straightforward. It was a bit harder with the latest version, but that was because of our VMware version.
For us, deployment takes about 15 to 20 minutes. Most of the time we get someone who orders it. They want to have a website and they need a server and we will spin up a RHEL server for them in our VMware infrastructure.
For deployment and maintenance there are two of us in the company. I'm one of them, in my role as a systems analyst, and my colleague is an IT strategist, although he mainly works as a system admin as well.
In terms of the solution’s single subscription and install repository for all types of systems, we can have as many RHEL installations as we want because we have a specific subscription that entitles us to have as many RHEL services as we want. We pay for a subscription and with that we get RHEL and Satellite as well.
The best thing to do is to go to developers.redhat.com and get free subscriptions for RHEL products, so you can try them out and see how they work before you go ahead and purchase or subscribe.
As far as I know, there are no costs in addition to the standard licensing fees.
We have Ubuntu, CentOS, and other types of Linux versions. The main difference between these products and RHEL is the support that we get from Red Hat. RHEL is also more capable and more stable and it is more of a well-tested operating system before it gets released.
Try the product out. If you decide to purchase a subscription, don't be afraid to submit a ticket or a support case to Red Hat, because that's why you pay for a subscription. It took us a long time before we started to open support cases, because we thought, "Ah, we can fix this ourselves." But now we use the support system quite often and it works quite well.
One of the things I've learned from using RHEL is that there are applications that work so much better on Linux than they do on Windows.
We need to build a lockdown version of Red Hat Enterprise Linux to build our application on top.
It gives us a stable and secure platform on top of which we can build our applications.
We use Red Hat Enterprise Linux for containerization projects. It allows us to do better application isolation using containers. If I want to take a program that runs on my system and put it in its own network namespace, I can put it in a container. I can put a physical interface in with it and run them together in that container.
It definitely makes it easy to go back and look at all the Open CVEs and things like that.
It works well for us in terms of the portability of applications and containers for keeping our organization agile. We are able to do the kind of things we need to do. We are able to modify the system to do whatever we need to do to get where we want to go.
Things like packaging and the stability you get from things being downstream are valuable. A lot of times, upgrades are more security-based and not feature-based, so things do not break API-wise as we go forward a lot of times.
I feel like it is going all over the place now. Sometimes it is hard to figure out what is going on. I would like more guidance.
We definitely spend a lot of time developing on top of things, but I am not sure what on the Red Hat Enterprise Linux side can be better.
I have been using Red Hat Enterprise Linux for ten years.
It is very stable.
It is very scalable. I would rate it a ten out of ten for scalability.
It has been great when we needed it. We have not needed a lot of it, but we have had no problems when we needed it.
Positive
We did not use a similar solution previously. We have only been using Red Hat Enterprise Linux.
We use it on-premises. We use the ISO installer. We install it via CD ROM on-site.
I was not involved in its initial deployment.
It is the guarantee that we are getting the updates that we could backport into the system and we have a stable system to build on.
We have been using Red Hat Enterprise Linux since I have been with the company. They might have evaluated other solutions before I joined.
To a colleague who is looking at open-source, cloud-based operating systems for Linux instead of Red Hat Enterprise Linux, I would ask, "Why?" We plan to stick with Red Hat as far as we see in the future, and we have no plans to change.
Red Hat Enterprise Linux has not helped us to centralize development. It is not something we are looking to use it for.
We use Red Hat Insights very little. We work mostly in an offline environment. It is hard to use Red Hat Insights in an offline environment.
I would rate Red Hat Enterprise Linux a nine out of ten.
Red Hat Enterprise Linux is the underlying licensing system that our third-party tool uses. It offers convenience. We can open a case when we want to escalate anything.
The tool's insights included with licensing is good. Security patching is also a good feature for us.
I don't like the UI changes that come with different versions.
The tool's support is good. Sometimes, support comes from India. I try to wait and ensure remote support is from the US so that it fits the timeline.
Positive
The product's deployment is straightforward.
We are a big data shop that has around 700-800 nodes.
Red Hat Enterprise Linux Leapp was very helpful. It is very easy to use.
Our servers run for 500 days, and we reboot them every 600 days.
I search through Red Hat Enterprise Linux's knowledge base daily.
We use Red Hat Enterprise Linux 8.6 since the third-party tool is compatible with it.
We use satellites for the operating system and Ansible to do the configuration.
I rate Red Hat Enterprise Linux a nine out of ten.
Red Hat Enterprise Linunx's most valuable feature is patching.
I am not happy with Red Hat's support. It is difficult to find knowledgeable people. It's hard to troubleshoot.
I have been using Red Hat Enterprise Linunx since 2009.
We used Solaris before Red Hat Enterprise Linux. Solaris' environment is closed, while Red Hat Enterprise Linunx is open-source.
Red Hat Enterprise Linunx's knowledge base is good, and you can find answers there.
I rate the product a nine out of ten.
We use containers to create RPM packages for graphics drivers.
The main reason to use Red Hat Enterprise Linux is to maintain support for creating images for various purposes, including what we use for gaming. We rely on a range of supported tools and resources, and this enables us to build images tailored for specific target devices.
The RPM manager is paramount for us, as we need to generate these packages for our customers, enabling them to install the packages on their systems at a later time. The knowledge base they offer has proven to be quite efficient and we haven't encountered any significant challenges.
The technical support should be improved. I believe it would be beneficial to notify the customer in advance of any planned maintenance so that we can better coordinate and plan our customer interactions accordingly.
We have been using it for six years.
Recently, we encountered issues when the Red Hat server was in maintenance mode, and we attempted to capture images directly from another server for our builds. Although I set up alerts for planned downtime on the Red Hat server, I didn't consistently receive these alerts. I would rate it seven out of ten.
Neutral
We follow a weekly patching schedule to fetch the latest updates. Our process involves applying these patches to the image and then generating containers, which we subsequently upload to our registry. We accomplish this using Ansible.
The only inconsistency we've noticed so far is with the server, which might be the only aspect we could potentially raise concerns about. Overall, I would rate it eight out of ten.
We use this solution for disaster assistance.
This solution has increased the speed of our technology. It is easy to troubleshoot using RHEL. RHEL's built-in security features and security profiles for helping to reduce risk and maintain compliance are good. It has also improved our organization's management and efficiency.
The cost of this solution could be improved.
I have been using this solution for four years.
This is a stable solution and we have not had any major issues when using it.
The customer support team are very responsive and always provide the help we need. I would rate the support a nine out of ten.
Positive
We used to use JBoss at my previous company.
I would rate this solution a nine out of ten.
Typically, we use this solution as a base to create and secure container images. Sometimes we use SELinux through RHEL and sometimes we only use RHEL. It is easier to apply STIG baselines to a RHEL system than other systems. We mainly use it for building and securing containers.
RHEL is different than any other Linux distribution folder. Folder locations are different and using this solution makes us more secure.
We are assured of added security because of the STIGs, automation and all the repositories that exist for securing Red Hat and SELinux. We have scripts that can automate the STIGing out of an RHEL machine, RHEL container or an RHEL BM.
It is also easy to troubleshoot using RHEL and follow the same process as other solutions such as Ubuntu, Debian, or Arch.
RHEL's effect on our organization's management and efficiency is noticeable because we check all the compliance boxes when we run STIG machines. It helps us because Red Hat is trusted in the governmental space. It also helps management save people's time by just having use of templated containers.
There's a lot more automation for STIGing out a Red Hat machine than there is in a Ubuntu or a Debian machine and this is one of the most valuable features.
Since it's based off Fedora, I don't like the DNF package manager.
I have been using this solution for six months.
It's very stable. I've never had any breaking issues when upgrading packages or versions.
We run this solution on a really small scale. We are a development group so we're not working on large-scale systems. We generate proof of concepts and then show that to the company for them to use so I can't really speak to how it scales.
Red Hat's tech support and customer service are really good. The Red Hat team are my favorite people to work with. They are easy to work with and genuinely care. I would rate them a nine out of ten.
Positive
The initial setup is mostly straightforward depending on the specific setup. We build our own containers and that is more complex but there are simplex supported setups. In both scenarios, maintenance only involves a few commands and is simple. It is maintained by two security engineers.
From an ROI perspective, this solution helps us win contracts. Contract values are negligible to what the RHEL licensing cost is. It has a really large effect on our contract deals because it gives our work and service credibility.
I would advise others to read up on the solution first. Try Fedora first before you get into Red Hat. There are some similarities and a lot of what you know about Linux transfers over.
I would rate this solution a nine out of ten.
We deploy front-end and back-end software applications on RHEL, and it's our app server. Most of our app servers and our production servers are on RHEL. They're running on RHEL, and that's why they are profiting from it. I2C is the issuer in the processing payment industry. Basically, we do the issuer processing for credit cards, and all the bank magic that happens when you swipe a credit card is handled by us. We're also using RHEL servers for processing debit card payments.
Customer support is valuable. Because most of the Linux distros are open source, most of them don't have customer support. RHEL isn't open source, and that's why I prefer it more than other distros.
Their pricing and documentation can be improved. They need to have developer variance that's more developer-friendly and less costly. They have a free developer version, but that's very limited in terms of features from RHEL. They also need to build their own open source community.
I've been using RHEL for about four months.
RHEL is very stable. Unlike Kali-Linux or Solaris, RHEL solutions are very stable. We have licensed projects, and they must be stable to provide all customers with instructions. They're stable, compared to other Linux options too.
It's very scalable. When you're using the right machine and the right settings or right parameters, it's highly scalable
Technical support from their customer service team is very good. They give responses unlike other Linux distros, and I think RHEL has better customer support.
My current company was using Solaris before. I was using Core Linux for three to four years. From Ubuntu, I shifted to RHEL and Solaris because I changed companies and jobs. We are using RHEL and Solaris in my current job, and I had to shift to these operating systems.
I have used the Ubuntu Linux base, I have used Kali-Linux and Debian. Of all those Linux systems, I think RHEL is much better, but I find Ubuntu much easier to use than RHEL.
Ubuntu is Debian-based, and Red Hat is, I think VM based. Another difference is open source systems have less support. Still, the community of Ubuntu is very strong and answers your query very promptly. But Red Hat is a certified, licensed product, and customer support from them is very good.
RHEL is expensive. The servers or cloud images are quite expensive. But I guess the client groups they target can afford that kind of a license. If you're a small business owner or a student and want to shift to RHEL, you must spend a lot of dollars. The developer version of RHEL has minimal functionality, but it's given away for free.
I would tell potential customers that they should go for the latest releases. If they want to buy it, they should get a developer account from RHEL first and use that dev account before buying it. They might have some hands-on experience before spending too much money on Red Hat.
On a scale from one to ten, I would give Red Hat Enterprise Linux (RHEL) an eight.
