For more than 10 years, Red Hat JBoss Middleware has been a successful business that deeply represented the Red Hat DNA: open source software. We expanded our product portfolio with projects created and imagined by the open source community; we decided to support other projects with contributors; and we also opened the source of technologies we acquired. Somewhere along the way, Linux containers, Kubernetes, and docker happened which made us realize that containerization of applications is the base for your next 20 years. The caveat in this is that a platform is only as important as the applications you run on top of it. In other words, a platform not running applications is not realizing its value. With that in mind, we made an important decision and investment to evolve our application portfolio in similar ways that we ask our customers to do to theirs: let’s take our Red Hat JBoss Middleware products, commonly deployed on Linux and Windows machines, and make them available as containerized deployments.
With the announcement of the availability of JBoss Data Virtualization for OpenShift we now have 100 percent of our Red Hat JBoss Middleware runtime portfolio containerized and available in Red Hat OpenShift, an enterprise-ready Kubernetes distribution with value-added capabilities that go from deploying your already packaged container images, to delivering a DevOps pipeline for an iterative development process.
The available technologies are:
- Red Hat JBoss Enterprise Application Platform (JBoss EAP)
- Red Hat JBoss BPM Suite intelligent process server
- Red Hat JBoss BRMS real time decision server
- Red Hat JBoss Data Virtualization
- Red Hat JBoss Fuse Integration Services
- Red Hat Single-Sign-On
- Red Hat JBoss Data Grid
- Red Hat JBoss Web Server (Apache Tomcat)
- Red Hat JBoss A-MQ
There have been a number of lessons learned in this process, which we passed to our partners and Red Hat Consulting so that they can not only enable themselves, but also teach our customers how to become the software company they need to be in order to stay competitive. Below you’ll see two examples of the lessons we learned.
Consistent Environments – Consistent Experiences
It’s not news that most of the time spent during the installation of a technology is related to the characteristics and peculiarities of the ecosystem on which it will run. We don’t have the utopia of thinking we’ll get to a point where we’ll be able to predict 100 percent of the environment’s characteristics, but we have gotten much closer to that with OpenShift and Kubernetes. One example is session replication (“clustering”). Instead of having to enable multicast, or configure an external tool to notify who participates in a cluster, you can now just ask the OpenShift platform for that. Sounds great! And this is what we did. The fact that we know where, for example, JBoss EAP and JBoss Data Grid are running enables us, with the proper authorizations in place, to ask OpenShift who the other nodes of the cluster are. With this capability, we integrated that into the JBoss EAP for OpenShift product, meaning that cluster enablement is a zero-configuration effort; it just works.
Another example of the advantages of application-level-awareness is the fact that the platform can also configure JVM memory constraints that can comply with the constraints you have specified for the Linux container in which it’s running.
These are just a couple common examples of how containerizing products in the Red Hat JBoss Middleware portfolio transforms them from isolated products to integrated application services within the OpenShift platform. Your developers can just call out to native services, and your Ops team can ensure that those services are running on a scalable container platform. Here’s a great example of a customer that leveraged the services of OpenShift and JBoss to rapidly improve the ability for developers to update applications. Faster delivery times for applications means greater revenue opportunities for your business.
Managing Image Updates – Security, Compliance and Stability
We often see developer teams that produce JARs/WARs/EARs, ZIPs, or RPMs and then hand them over to an operations team, together with a nice 70 page document that explains why they will have a bad weekend; or in other words, ‘Method of Procedure for Deployment and Configuration of Application Project-Temporary-HR‘.
For far too many companies, this is today’s reality. The differences in expectations for the different teams is what adds extra steps, verifications and authorizations to your deployment processes. Added time prevents your customers from experiencing the new capabilities developed for that application.
The good news? Containers are here to help. A great part of Red Hat’s value to our customers and the community has always been our ability to manage the lifecycle of open source software. Think of it as similar to having to maintain your own applications updates, but the majority of your developers are Red Hat employees. And instead of tens and sometimes thousands of different applications, you have millions, with more coming and going every minute – that’s open source software.
Being a developer for most of my career, I don’t remember seeing a Java developer that would care about what version of glibc was being used, and even more if that glibc was updated and secure. One day I discovered that glibc was a dependency of my Java application; but how? It’s simple. My .war file would run on Tomcat, which would run on OpenJDK, which required glibc. So my Ops team would always have to care about more things than I did, which were the dependencies of my application. In fact, lots of things depend on glibc, just like your nice Node.js app.
Now imagine if there was a packaging model that would, apart from a Linux kernel, include all the dependencies of your application? This is what a container image does. It integrates Ops and Devs teams (read DevOps) because of its standard packaging format that now addresses concerns that previously were only Devs’ or only Ops’.
This is great, but at Red Hat we suddenly had a realization: if glibc is a formalized dependency of your app (it always was, you just didn’t know it), does it also mean that I have to keep an eye on it? Well, yes and no, because Red Hat does that for you, and this is how.
When you deploy your JBoss EAP application on OpenShift using the container image we provide, Red Hat manages the life cycle of all the dependencies of JBoss EAP, and we can ship a new image whenever our security team, that has established trust, identifies that a dependency needs updating. This translates to another ‘C’ in your CI/CD process: continuous security.
The same happens with our cumulative patches for our products. We are releasing new image versions almost instantaneously with the release of a cumulative patch. This is Red Hat continuing to deliver to its value of managing the life cycle of open source software.
Are You Ready for Simplified Application Services?
We believe the future is bright for our Red Hat JBoss Middleware products on OpenShift, and you can expect a more specialized experience for the products that can enable you to consume queues, topics and caching without having to worry about the infrastructure delivering it – and these are just a few examples.
I want to thank a few of our customers, such as Amadeus, Keybank, Airbus, Produban, Swiss Railway and all the OpenShift Commons members that have been together with us on this journey of trust and knowledge sharing that benefits everyone.