This is a week of EE-related surveys. On Monday, Red Hat released the result of their JBoss Middleware customer priority survey. Specifically, they wanted to learn more about how the 800+ customers that responded think about Java EE in the age of microservices, containers, and the cloud. They found that 64% of customers have large, traditional Java EE applications on-premise. 23% have most of their applications on-premise with some cloud. 13% have more than half their applications deployed in a cloud environment.
The survey predicts that there will be a gradual shift to heterogeneous, hybrid cloud environments.
In June they released JBoss EAP 7, a ‘foundation for Hybrid Cloud Applications’. Voxxed took the opportunity to look back at Mark Little’s thoughts when JBoss EAP 7 was in beta at Devoxx UK in June this year.
Interview: Mark Little
At Devoxx UK, June 2016, Arun Gupta interviewed Mark Little for Voxxed. VP of Engineering for all of the Middleware and mobile efforts within Red Hat, Mark and Arun discussed JBoss EAP 7, OpenShift and Wildfly Swarm.
Tell us more about Middleware project JBoss EAP 7 Beta. How has it been doing and what are the key features around that?
Beta is based on EE 7. We released that 7 weeks ago now. The reception from customers that we’ve been working with are positive. It’s an extremely stable beta, we’ve got some good feedback from people on performance, reliability, and the EE 7 features that we’re working on. So I’m very, very pleased with it. The team has done a fantastic job, we’ve had lots of good feedback and input in terms of features and bug fixes.
What are the other key themes of EAP 7 Beta?
To continue what we do with EAP 6 – which is to ensure that it is a very fast, lightweight, agile platform which is cloud-enabled. We use it a lot in our OpenShift effort and it forms the basis of quite a few of our other products that are now on it – such as Red Hat SSO.
We are continuing to trim down, so people who want to officially start to develop things like microservices and are coming from an EAP/ Java EE background don’t have to throw away all of their existing skill sets. They can actually start with something they understand and then start easily looking at adding layers.
So is that something called WildFly Swarm?
The upstream community effort is called WildFly Swarm. It layers on WildFly. At some point we will be productising it. In the same way EAP is the product version of WildFly, we’ll have something that is the product version of Swarm.
Java EE 7 was released 3 years ago, there is no visible deadline for EE 8. How do you see the future of Java EE evolving?
There’s been a lot of public discussions about how much work is or isn’t happening around EE 7. I understand how that can be quite worrying as despite what some people might say about Java EE it has done something that no other enterprise middleware effort has ever done outside Microsoft – which is to unify the industry. I think Java EE has an incredibly strong future.
Java EE has such a huge base that anybody who thinks that it’s going to vanish overnight hasn’t learnt the lessons of history. Cobol is still around! So I think Java EE has a very strong future just from its existing base. Certainly with Red Hat, we see people coming to Java for the very first time and then going onto Java EE. That bodes well for it’s new lease of life. And then there are things like microservices and the stuff we’re doing in WildFly Swarm. Other companies are doing similar things…
I think Enterprise Java is going to be around for a long time. It may not look like Java EE in 5 or 6 years time, but it’s going to be based on many of the same principles that form Java EE. Certainly from a Red Hat perspective, we’re not considering pulling back. If anything, we’re doubling down on what we’re doing with loads of Swarm advancements etc. So it’s going to be in safe hands. Whether those are Oracle’s hands or Red Hat hands or IBM hands… It’s going to be some combination of that, absolutely.
Oracle and Red Hat… I know how both the companies totally care about the platform and I’m glad you’re confirming that. We’ll talk briefly about OpenShift. What is OpenShift?
OpenShift is Red Hat’s platform as a service. It’s been around for a number of years. We kicked it off 5 years ago. It has evolved a lot more in the past few years.
OpenShift 3 is our latest release – 3.2 is the current one, 3.3. will be out soon. What we did with OpenShift 1 and 2, which pre-dated containers – we had our own concepts of essentially the same kind of things but then Linux containers came out … We decided we would probably stop what we were doing with our own bespoke architecture and move to Linux containers. At the same time we also took on our core OpenShift clustering management with Kubernetes. So OpenShift 3 is essentially a new architecture. It has the same principles – and many of the same tools. Many people don’t necessarily see the Linux container aspect of this but it’s based on Linux containers and Kubernetes.
We do use Docker but there are other flavours of Linux containers and what we’re trying to do is push the Linux container standard. When the standard for Linux containers comes out we want to make sure that we’re at the forefront of that so if, for instance, everybody who is currently on Docker (which is essentially what people think of when they hear Linux containers) decides to move on to something else… Say a new one comes along called ‘Bob’: we want to make sure that OpenShift can target ‘Bob’ so long as ‘Bob’ is compliant with the standards.
So when you say Linux containers, you mean OCI compliant containers. Which makes sense because OCI is going to be the standard – Docker is the first OCI inspired implementation. If tomorrow something else comes along, you don’t want to change.
Exactly. That’s something that’s been at the heart of everything we do at Red Hat. We try and make sure that we embrace the community, open standards, or we embrace proper standards so we don’t tie people in – even to Red Hat.
How will JBoss EAP 7 and OpenShift tie in together for building a nice microservices-based platform?
We’ve had an initiative going on called XPaaS for a while. This is to take all of our middleware products and make them cloud-aware and make sense as a service on EAP 7 Beta, and then eventually the GA is available/ will be available on initiative 3.2. What we’ve done is to work very closely with the OpenShift team and also with WildFly to ensure that when EAP is deployed to OpenShift, you get the advantages of Kubernetes, immutable architectures and the development experience through Eclipse plugins and JBoss tools.
We want to make it very seamless from going from developing on your laptop to developing public OpenShift projects. We’re also working closely with a number of other partners on CI/CD. We’re integrating with Jenkins and creating a nice tooling pipeline. A lot of the teams across all of Red Hat have been working really closely on integrating with Kanban boards so the whole process from dev to deploy including canary testing… all of that is being done very seamlessly.
So it’s not just about taking Docker and Kubernetes and patching them together. At the end of the day I’m a developer and I want to go through a workflow. OpenShift will provide the full workflow. I think in that sense Red Hat is at the forefront of the technology: containers, microservices, JBoss EAP 7 Beta, OpenShift… it seems like great progress.
I like to think so. It is also important that we use this stuff internally at Red Hat. You used to work for Red Hat. If you’d come back and look at what we’re doing, all of our development processes are being re-tooled on exactly the same principles. We are much more agile internally. It’s not perfect yet! But we’re doing canary testing, we’re doing integrations and so on.
Any concluding remarks?
First of all, Java EE, whether it’s 7, 8 or 9 or whatever – I think it has a strong future. I like to think that we are going to be continuing to invest strongly in it.
For the container-OpenShift discussion we had, it’s important that it’s not just taking what you have and sticking it in a Docker container and saying it’s a job done. You have to evolve your processes as well as your software to take complete advantage of everything that’s out there.