C2B2 logo icon

Is JBoss EAP 7 Migration Right For Your Organisation? Part 1 - The Drivers behind Migration

This is the first in a series of video blogs that explore whether a move to JBoss EAP 7 is an appropriate strategy, and examines the factors that need to be considered.

“With JBoss EAP 7 having been on the market since May 2016, and 7.1 expected towards the end of Q1 2017, JBoss EAP 5 and EAP 6 customers will be acutely aware that product support for those versions is moving inevitably towards the end of its lifecycle. Now more than ever, thoughts are turning to upgrade and migration, with target architectures that should be looking towards RHEL 7, EAP 7 and Java 1.8.” 

Brian Randell - c2b2 Principal Consultant
and JBoss Middleware Specialist


Part 1 - Transcript 

Hello, and welcome to a series of videos on JBoss EAP 7 Migration. My name’s Brian Randell, and I work for a company called c2b2 consulting – an independent middleware consultants.

This series will provide a high-level view into WHAT to do if you’re thinking of migrating to JBoss EAP 7 -  WHAT standing for:

  • Why
  • How
  • the Action you’ll take
  • and Then, what happens after that.

In this particular video, we’re looking at the drivers behind the JBoss migration.

To start with, let’s look at why we’d want to migrate our current JBoss EAP to the new version JBoss EAP 7, and from my point of view, this falls into three categories...

The Key Drivers behind JBoss Migration

The first category would be if your company has a life-cycle management policy – and this kind of thing can be if there might be a support requirement, so that you’re always fulfilling an enterprise support.

There might be a licensing requirement - that you’re under the normal licence rather than any other extended licenses, and there may just be a policy of having to be on a release which is a couple behind the current release out there – just for stability factors. And this is all really just to reduce the risk of the application - the stability of the application and the support of it.

The other category is technology. The technology you use will obviously be part of a solution, and that may be driven by other external projects or other factors. You might want to remain operable within these, and be on a version that is fully tested and supported with all the interfaces surrounding it.

You might find, for example, that one of your dependent technologies (such as Oracle) is managed by a different team, and they have their own life-cycle management plan, which means that they need to upgrade their version for their own reasons – whether it be for licensing or support, and you need to be compatible with those.

And then we have the third high-level contention, which is the opportunity. If you’re moving onto modern new technology, then of course you’re going to get the opportunities that arise with that – with any new features that may come out of that, any enhancements you can make to your own coding because you have the facility to do that, you might be able to streamline your design – this might make it easier to monitor, to be stable, to be more performant, and in this fast-moving world, you’ll be better able to respond to your users’ requirements.

So, I think it really does depend on your policies. I think, sensibly, if you’re in the vein of a couple of versions behind, I think that you’ll be fine. I wouldn’t want to be too old in your versions just because the world is moving apace at the moment.

JBoss EAP Lifecycle Management

So, this slide is just giving you a lifecycle management view of platform lifecycle, and on here you can see that there’s four categories: Red Hat OS, Microsoft platform, JBoss and Java. And you can kind of see on here what level they are at in their different versions in terms of support and extended support.

And one thing you can do with lifecycle management is that you can earmark and target certain release structures on your year, so here I’ve got a couple of instances – the middle of 2017 and middle of 2018. For those, you can target a certain application set - so it might be sensible for example in 2018, in the middle of that year, if you’re looking at a stable, supportable, operable situation, then if you’ve got a Linux platform, then it might be sensible to go for RHEL 7 sitting with JBoss EAP 7, and using Java 8. That is in the middle of fully supported infrastructure – sensible move.

The middle of 2019, things may change slightly, so this is an ongoing update to this lifecycle as you should move forward.

JBoss Architecture Dependencies

We’ll carry on with our next slide, which is the dependencies, and this is a key slide really in terms of working with the other areas that you might work with in your business. JBoss EAP 7 uses all the modern technologies, so it’s all RHEL 7, it needs Java 1.8 and all the most recent technologies, and it’s always sensible to be on a configuration that is commonly used and fully tested. As you know Red Hat has its supported configuration sheet, and it’s sensible to be on one of those supported configurations – not only because Red Hat can support it better, but also because the community will be more likely to have one of those supported configurations, and therefore you’ll get better support from there as well.

Opportunities of JBoss EAP 7

And of course, with the opportunities side, we have the new features. With JBoss EAP 7, it brings you JEE 7 and Java 1.8, which does bring multiple updates and changes. Some of the components that have changed within JBoss, you can see there. The JBoss Web has moved to Undertow, HornetQ has moved to ActiveMQ Artemis, JBoss AS has moved to the Wildfly Core, and there are various things that have been removed and added, and of course, with the updated JEE and also the updated Java, there’s a whole bunch of things that have been upgraded and modified – things that you might be able to take advantage of in your application. It may be something that your developers may be keen to utilise not only for their own interests, but also to ensure that your application is remaining performant and can also respond to users’ demands to have new features.

So, we quickly went through some drivers behind the migration, and I boiled those down into three different areas, with lifecycle management, with the technology – with the dependencies and the interfaces which they use - and also the opportunity for migrating to a new technology stack.

That’s it for this video. Thank you for watching and next time we’ll look through the development challenges – hope to see you again soon.

PART TWO: Working Through Development Challenges
PART THREE: Creating a Migration Strategy and Plan
PART FOUR: Vision - a Guide to the Future