“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 4 - Transcript
Hello, and welcome to the fourth in a series of videos about JBoss EAP 7 Migration. My name’s Brian Randell, and I work for C2B2, an independent middleware consultancy.
In this video, we’re going to be looking to the future. As part of our ‘WHAT’ stack, it’s Then – then what happens once we’ve migrated to EAP 7. Where does the future lie, and what’s happening in the industry?
I think there are four main industry trends.
The first, is cloud, of course. A lot of companies are now wanting the ability to reduce their overheads - managing their own infrastructure, and abstracting that out to the cloud where they can save lots of time and costs by using a platform service, abstracting that hardware away, and deploying directly onto cloud infrastructure.
And moving to cloud delivered software based services as well, that can integrate with their own applications - and potentially also architecting native cloud applications that make full use of the cloud stacks that are out there.
Automation is another key driver moving forward. You’ve probably of heard DevOps, Continuous Delivery, and Agile as buzzwords in the industry. Everything is now being scripted, everything needs to be done at the touch of a button - the sooner the better, and the quicker the better. DevOps really helps with that – providing you a quick interface and quick continuous delivery integration from development to deployment. Also, methods of Agile. Let’s work for a faster, more prioritised deployment, and let’s make changes more rapid, faster, and more flexible. Let’s work to the priority of the users, let’s work to the needs of the features that are required.
The third one is containers. Containers allow us to deploy small applications fast and at scale. It lends itself to microservices, and because we scale the containers up, we can flex when there’s more demand. We can have more containers, we can have more services to offer, and we can flex down as well when there’s less demand.
That, of course, needs a whole orchestration layer to be able to create and flex and do all that kind of work. With containers, the ability to deploy small applications quickly, efficiently, and effectively is becoming more prevalent in the industry – as is integration.
A lot of the applications we’re using now are integrating with all the other applications that we have. Mostly through API layers – and that whole service oriented architecture that is used to do this with our enterprise patterns to move things. We can look at an application and request information from it, utilise that information and send it off to another application, and this is all part of what’s going on with the Internet of Things – it’s all part of what’s happening in the industry – moving to the cloud, automating everything, putting things into smaller bits with containers, and integrating them all together. It’s where the future is.
And some of the tools and applications we can utilise within those sections can be seen on this slide. We know the main players within cloud are Amazon Web Services, Microsoft Azure - and Google Cloud is coming up and being more prevalent now. Of course, in our Red Hat world, there’s the OpenShift platform which is now using Docker pods, we’ve also got OpenStack, we can do private clouds and have CloudForms that can manage those, so RH has a lot of offerings there.
In terms of the automation layer, Ansible is a product that we can manage the estate with – with our Ansible Towers - and you can also use Chef and Puppet for that as well. And as part of our management layer of those, and for continuous delivery, we can utilise Jenkins and Bamboo as two of the options. There are a lot of options in this space, and types of methodologies that you can utilise there come under the Agile banner where Scrum and Kanban are common ones - used just to make things more agile and quick – and to prioritise the delivery slots and have shorter, fixed time periods for deployment and delivery.
For integration, I’ve only listed JBoss Fuse. there are others on much different platforms, but JBoss Fuse is the Red Hat offering and of course is based on Camel. There are others based on Camel – Apache Service Mix for example, but JBoss is the one worth listing for Red Hat people.
And for containers, of course Docker is the main player for containers and the orchestration service. For Dockers, you’ve got Kubernetes which is quite commonly used. Dockers now provide Docker Swarm, and Amazon and Azure have their own container services that can be used for those as well. It’s worth mentioning in this section OpenShift, and I’ve put it in here as well because it is using containers in its pods – it uses Docker there, but WildFly Swarm is worth mentioning because it reduces the runtime of WildFly to a very small footprint jar, and can provide microservices very easily. And so it’s worth having that because if we’re going to go through microservices type infrastructure, then WildFly swarm is worth looking out for.
That was a very quick look at the future – and this was the last of our four videos in the Red Hat JBoss EAP 7 migration. They’ve been very high level and I’ve skipped through quite a lot, but hopefully they’ll provide some thoughts and provoke some ideas on where JBoss and middleware are likely to be heading.
My name's Brian Randell - I thank you very much for listening and I’ll see you next time.