Red Hat’s JBoss may be responsible for as much as one-fifth of the world’s active enterprise middleware deployments, giving it a position in the market that many presidential candidates have enjoyed this season: a respectable second place.
Today, Raleigh, N.C.-based Red Hat opened up the public beta process for the new version 7 of its Enterprise Applications Platform (EAP). It brings JBoss in line with the company’s OpenShift PaaS platform, deploying Java applications under a new orchestration scheme that utilizes Docker, and that’s perfectly compatible with Google’s Kubernetes.
“It’s a different process. It’s not what people are familiar with,” admitted Rich Sharples, Red Hat’s senior director for product management, in an interview with CMSWire.
The Dockerization of the Enterprise
OpenShift has already completed a massive architectural transformation, from a largely original scheme to one that actually is more familiar to businesses that employ Docker containers and the new systems of continuous deployment that make use of Docker. It’s not familiar — not yet, at any rate — with folks who’ve managed JBoss deployments for the last dozen years.
“The new way to build and deploy an application,” explained Sharples, “is, as part of the build process, you also get a Docker image that goes straight on to your test environment. If it passes the test, it goes straight through to pre-production, you do some scale testing; and if it passes that, it goes into production.”
Sharples is describing a process of automation for ensuring specific software quality and resilience levels, before it’s made available to end users — before your customers see it.
We haven’t talked much about these processes, which fall under the blanket category “CI/CD,” here in CMSWire. But your organization may actually be trying one out, or even using it at scale, right now.
One major example that has already taken root in many firms is Jenkins, a CI/CD platform from a firm called CloudBees.
Jenkins (whose icon is indeed a butler) breaks down the continuous delivery process into building blocks, or pipelines. These pipeline components use automated scripts to ensure, for example, that code being added to an application properly protects customer data, or that it can’t be used in such a way as to expose systems to vulnerability.
The delivery mechanism of choice for a growing number of these CI/CD systems is Docker containers. So one phrase that could apply to Red Hat’s move with its JBoss EAP is, “getting with the program.”
“Our entire portfolio of middleware products, I would say, are the first broad Java portfolio to be fully Dockerized,” said Sharples. “All of our products are supported in OpenShift, and to be able to do that, we have to Dockerize everything.”
By “Dockerize,” he means changing the delivery mechanism for code to self-contained, “shrink-wrapped” virtual machines, capable of being deployed to production cloud platforms such as OpenStack or Amazon in the same form in which they were delivered for testing.
“This is different from the way people do things today,” acknowledged Sharples.
Learning Opportunities
Webinar
Apr
5
Adopt a Modern Digital-First Marketing Strategy
Learn how to use a composable DXP to your advantage
Webinar
Apr
13
Composable Commerce The Future of Retail
The Adobe Commerce approach to composable and why it's best in class
Webinar
Apr
13
Accelerating Content Velocity Across the Digital Supply Chain
Learn to integrate DAM with upstream tools to improve workflow efficiency.
Webinar
Apr
18
Drive Business Growth Through Customer Service and Support
Defining the future of technology. What is AI’s role in the future of customer service?
What Changes About the Program?
“We believe we can take existing application developers, who are familiar with a certain set of APIs and technologies, and allow them to deploy to a modern, cloud-based infrastructure. But it wouldn’t require them to radically change their applications.
“Our philosophy, all the way through the last five or six years that we’ve been moving our middleware portfolio to the cloud, is that JBoss runs the same everywhere. If you are deploying a JBoss EAP application or ESP or Business Rules [BRMS], and you’re developing on a laptop, or deploying to Windows Server or Amazon EC2 or an OpenShift container, it doesn’t matter — the application is the same.”
The people who will experience the change first-hand are the IT administrators and DevOps professionals who deploy software to production. These are the folks who may already have been testing EAP v7 in private beta, and ascertaining the changes they’ll need to make to their testing and deployment environments.
But while the goal here is not to mandate that Java programs should change in order to meet some new set of specifications, the fact that some of the oldest software in many organizations’ portfolio will soon be governed by more sophisticated, and more rapid, testing and deployment schemes, will indeed open up new possibilities for that software to evolve in ways that it couldn’t before.
“The next generations of developers are not wedded to a single technology,” noted Red Hat’s Rich Sharples. “They will develop some stuff in Scala, PHP, Python, Node.js, JavaScript — this idea of polyglot is established and here to stay.”
Sharples noted that the deployment platforms for modern software have scopes that span the entire planet now. Any one language — even Java EE — can no longer afford to be an island unto itself.
“No customer I’ve ever spoken to is willing to move to the cloud, if it means they have to throw away everything they’ve ever developed,” he said. “They want to be able to bring these existing applications, even Java EE applications, with them — it’s not optional.
“They may well re-architect them at some point,” he did eventually admit. “There may be some decomposition, where they think more about microservices to make software delivery easier. But they’re absolutely not willing to throw away many years of investment in application logic, just to benefit from cloud-based infrastructure.”
Title image “Container ship passing in the distance” by Daniel Ramirez licensed under Wikimedia Commons
