Notice: Undefined index: order_next_posts in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 194

Notice: Undefined index: post_link_target in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 195

Notice: Undefined index: posts_featured_size in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 196

The Other Side of Red Hat – an interview with Craig Muzilla

Not just a Linux company, Red Hat has quite the middleware business, too, says Alex Handy who recently sat down with Craig Muzilla, Red Hat's vice president and general manager of the Middleware business unit...

Craig Muzilla, vice president and general manager of the Middleware business unit at Red Hat, is a busy man. While Red Hat is known for its Linux distribution(s), the company acquired a major enterprise software business in JBoss. That was back in 2006, when words like “SOA” and “AJAX” were all the rage.

We caught up with Craig to check in on what exactly is going on in the world of JBoss Middleware, these days. With the Java world preparing for the release of OpenJDK, JBoss and Red Hat have taken a key role in both the present and future of the platform. The company was even recently responsible for kick-starting the Java EE 7 specification inside the JCP.

Here’s what Craig had to say about the future of enterprise Java, and of the JBoss Middleware platforms…

How is the middleware business doing in this age of cloud computing?
The middleware business here has been doing quite well. It’s been growing at about double the rate of the Linux business. It’s a big growth engine here at Red Hat. We had great strength in all regions last year, including Japan, Brazil, and Latin America. Our goal has been to build out a portfolio of middleware products that would enable us to offer an alternative to proprietary middleware stacks. We’re offeirng ourselves as an alternative by enabling companies to standardize on us, or to use us strategically. We’ve introduced eight major new products in the last couple of years. Now we have high speed messaging, business process management and rules management. We have a portal offering, and a data integrations offering. We’ve really been building out the portfolio. Some of those are doing quite well, in particular the integration products.

The nature of the deals has changed too. Look at four years ago. It was primarily about application servers. JBoss was usually used pretty tactically, for Web-based applications and  non-mission critical applicaitons. Now companies have gotten more secure, and they feel more comfortable with JBoss. The number of companies that have migrated completely is lengthy. Nissan and NTT in Japan, Fed Ex, Geico, Verizon, Ing, the New York Stock Exchange; they’ve all standardized on JBoss now, and use it predominantly in their organizations. They’re migrating away from the big guys, the proprietary Java stacks.

What has been the focus for JBoss Middleware lately?
We’ve been doing more to make the platforms much more flexible by supporting different languages. Not only are we the best place to run Java EE, we have quite a high percentage of customers using us to run Spring, Struts, and Groovy on Grails.

This idea of flexibility is about moving toward operational flexibility. With the next release we have is on the application platform. Our Java EE 6 platform becomes a much more configurable platform.

EE 6 is all about laying the foundation for modularity for the platform, through the new Profiles. How is JBoss taking advantage of this?
What we’re announcing next. JBoss Application Server 7. At the core of this is a micro-services container. We came out years ago with the concept of a micro-kernel. Java EE 5 came out with the idea of a micro-container on top of the Java Virtual Machine. Now we have this concept of more modularity. If you have transactionality in JPA, or caching, or messaging, or clustering security, all of these services can be added or subtracted easily from the micro-services container.

The other thing this does is allowed us to add a lot more manageability capabilities. We’re extending the API so that the platform container can be more easily managed without having to bring in something hard-coded. You can manage and configure and deploy this environment much more easily. We’re doing a lot for flexibility for the developer, but also for the operational excellence and managing it after the fact.

We have a profile which is essentially Tomcat, slimmed down. It’s just the servlet engine, but then you begin to build on top of that with micro-services containers. The problem with Tomcat is that it’s really simple and easy to deploy, but the problem is if you need to scale it up and add services, thats not so easy. If you need transactionality, if you need highly distributed caching capability, you can’t do it easily with Tomcat.

I’d say Tomcat is still healthy. It seems like from the market research data we have, show that its usage hasn’t declined, but it hasn’t increased either. What these other vendors (Mulesoft, SpringSource) are doing is, they all need a container. With Mule, their ESB needs a container, but if you need it to be more than the runtime environment for the ESB, you will not have services to do that. I think that’s the dilemma. Some of these companies are offering their own Tomcat versions, but can that be a rich environment or not?

How goes the work on Java 7, both SE and EE?
We participate in the Executive Committee for Java EE 7, and for SE. We participated in the recent EE 7 announcement. In terms of SE 7, we are on the expert group for that. We’re feeding in our comments and making sure we’re part of the process. We are also the number one contributor, outside of Oracle, to OpenJDK. We have quite a few people working just on OpenJDK. We have had a Test Compatibility Kit (TCK) compliant Java for around 4 or 5 years now, and we ship it with Red Hat Enterprise Linux. We plan on continuing that tradition, and we’re fully behind OpenJDK. I think what is uncertain is what happens beyond the OpenJDK, in terms of what Oracle does.

They may package up another distro based on OpenJDK, with Hotspot and Jrockit. What types of add-ons will they put in that environment? From the market standpoint, they said they want to add value on top of Java, but I think it’s unclear where they’re going to go. We want to make sure the specification itself and the reference implementation is nice, and strong, and healthy, and has all the capabilities at a base level that everyone at the marketplace will need.

What about the Apache Foundation’s dispute with Oracle over the licensing terms of the TCK?
They’ve been a  little mum on that so far. They have not disclosed all of the license terms for the new TCK when SE 7 does comes out. We’re hoping they continue to be benevolent. So far they have been open in terms of the process, we’re waiting to see.

In 2007, Oracle published a number of papers and blogs about the JCP and how it should be run. It was just some in general comments on what some of the best practices should be. They have seemed to slow down a bit in terms of their own stated goals were in the past. At the same time, they have accelerated the release of new specifications. We’ve got one for Java SE 7, and we’ve got one for EE 7, and intentions for SE 8 and EE 8. I think everybody is hoping and being optimistic.

How are you responding to the trend of other languages being run on the JVM?
We have a strategy called open choice. This was the idea of taking anything JVM-based–and some things that aren’t–and being able to make sure you’ve got a runtime that adopts a number of different languages and component models. We’ll run any framework certified against Struts or Spring. Ruby on Rails runs on top of JBoss. With a component model like OSGi, you design your whole application with OSGi and you build OSGi bundles, and we will take and consume all those bundles. We are looking at all of those languages, providing and certifying support of them. We’re saying you still need a runtime, you still need a container and services, and instead of duplicating the effort for every language, and every framework, and having a plethora of environments, you might end up with five or six different platforms. We will leave it up to the developer which languages and models are the best for them, but you will always have the same runtime and same services.

Some vendors are supporting a couple of different things. Others, like VMware are not. They’re saying Spring and Groovy only. We’re embracing the variety in the environment.

How is Seam doing?
Seam is doing very well. It became the Contexts and Dependency Injection (CDI) specification in Java EE 6, JSR 299. It’s really a more modern framework. It’s what Spring had set out to solve six years ago, when they had difficulties with Java EE. We finally have come full circle, where Java EE incorporates some of these concepts with a more modern framework, which is CDI.

Gavin [King, creator of Seam] has also been experimenting with some new languages. Ceylon takes some of the concepts of Seam and puts it into a language. Maybe one could compare it Scala, but talking to Gavin it’s not intended to be a replacement for some of these newer languages and langauge types. We’ve been asked what are we doing with this? Our spirit is that part of open source is a lot of R&D and experimentation. We’re trying to see if what he’s created is interesting to people.

What’s next for JBoss?
What we’re doing is, we’re evolving the application platform, and the seed of this is in Java EE6. It’s where this micro-services container becomes the foundation for everything we do. We start to look beyond monolithic application servers and looking towards application fabrics. You have a very lightweight footprint that can run some things like iPhones and plug-based computers. Things that are highly mobile, yet supports HTML 5, and different clients. It’s dynamic, where you can plug and play services. We’re looking into self scaling and self healing. It’s policy-driven where you reduce a great degree of human intervention. That’s where we’re heading with this.

One can start to see the portfolio acts differently. The ESB or rules management systems that are standalone become part of the fabric. That’s the long term vision over the next several years. In the short term, Red Hat is in a great position to be a major player in cloud. We bring all the pieces to the table. We have KVM, the OS, and all the middleware components, the platform runtime, and the services and components. We bring that all of that to bear.

Tell us about Cloud Forms and Open Shift.
We recently announced Cloud Forms, and OpenShift, which is our platform as a service offering.

The JBoss product line is bringing together all these pieces we have and offering them as services in OpenShift. People can use us as the engine in their cloud. It doesn’t end at the container. Think of an integration service from to an internal ERP. On top of that, you get busineess process management as a service, and user experience and collaboration as a service.

JBoss Application Server 7 is the engine in our middleware offering in the cloud. This goes live within the next several weeks, and JBoss Application Sever 7 is the engine driving that in OpenShift.

What are your goals for your platform as a service?
I think the primary requirement is making it very accessible and easy and to attract developers from corporations that need to do development in the cloud and bring it back on premises. Also, people who have ancillary applications that are mainstream, so it doesn’t make sense to do it on-site, so you do it in the cloud. Why start on premises? Do it in the cloud? For smaller organizations that need Web-based applications, do it right in the platform as a service. I think one of the key requirements is to make it easy for all these audiences to use OpenShift. Second is to make it portable so they can move from cloud to cloud, or cloud to on premises.

We’re trying to embrace applications, whether its Spring or EE or Ruby on Rails, or PHP. We embrace all of these, and let the developers use the workload that best suits their needs.

Stepping back a second, I think Red Hat is always looked upon as only a Linux company. But I think, as people get to know us more, they realize we have really a full portfolio of infrastructure as well as development and middleware offerings, and we bring it all to the table. I think it’s good for all developers that they understand Red Hat is more than a Linux company. It’s a middleware company. It’s a management company. It’s a cloud company.