xPaaS – the intersection where middleware hits the cloud – is a potential game changer for developing and managing apps. We spoke to Red Hat head of middleware Mike Piech  for some insights from the frontline. Are containers killing the PaaS market as we know it? And what languages are we going to see ruling the enterprise in the years to come?

Voxxed: With the rise of containers, do you still see a need for PaaS?

Piech: Right now, containers happen to be the thing that conversations focus on. But, at the end of the day, to build containers and run containers, you still need infrastructure that knows how to deal with them and knows how to manage them with scale and can automate a lot of the day to day housekeeping that comes with them. Whether or not  this solution will still be called PaaS or not in the future  – it’s just a matter of shifting industry semantics.

With OpenShift  technology, for example, we just released OpenShift 3.0 this past summer. We’ve done a major internal retooling to have it support Docker containers.  It had been container based for years, but nobody seemed to care about it and that was fine. But now containers are a big deal, of course it grabs attention. But all of the surrounding mechanism to enable fast deployment, fast restart, automated scaling, and all that sort of thing – that’s just as important as it always was

What stories from the realm of middleware have really grabbed your attention lately? What do you think we should be paying attention to?

So tying this all back to xPaas, the vision and strategy we announced coming up to two years ago right from the get go was about putting JBoss middleware on OpenShift, enabling cloud based development of apps using middleware. And and we’ve continued to roll out against that roadmap that we announced, and in a way the containers and Docker aspect has allowed us to take that to a whole new level.

Right when OpenShift 3 came out, we initially had our JBoss EAP – the app server – as well as our web server, and JBoss AMQ – the messaging capabilities enabled on Docker containers. We’re going to have another bunch of the middleware products available as OpenShift services and xPaaS services on OpenShift by the end of this year. Then, in the first few months of next year, we’ll have the remainder of JBoss middleware deployed and available as Docker container based packages on OpenShift.

Now, one of the further implications of that is how well it allows microservices based architecture. So, if a container is a mechanism, a microservice is an interesting things to do with the mechanism. It’s a great marriage of these fundamental capabilities at the infrastructure level and in what is enabling the developer to doing in terms of architecture. In particular, architecture that’s very adaptive, something that can be changed and updated and evolved in very small increments that are less risky and less disruptive.

It ends up being something that’s not just interesting for technology’s sake, but ends up being a palpable change even at the business level. When you can have developers iterate and adapt so quickly, you can then have rapidly add new capabilities and services. Not services in the technical sense, but services that business customers want to get.

Are you seeing your customers rapidly jump into microservices?

Well, with any new set of approaches, there’s a part of the industry the immediately goes to the extremes. It’s a new hammer and everything looks like a new kind of nail, so they’re trying to use it everywhere kind of naively. And  of course they’re going to get burnt doing that, because it’s not always the right tool for the job.

The promise of microservices is not, hey go do everything you already have as microservices and the world will just become better. You are now able to build things going forward in finer grained modules, with incremental change.

There are plenty of existing applications that are monoliths, and these are perfectly fine existing and running that way. You don’t have to blow everything apart into its atomic constituents – some things will be big, and that’s fine. Leave them that way. Other things will be small and when you’re using PaaS machinery and orchestration like Kubernetes,some things will be big and some things will be small. What it does is it gives the developer a wider range of scale options for different modules. It’s very much a right tool for the job scenario.

Keep calm and optimise your microservices then?

Yeah, that’d be a great T-shirt! As we get more and more of the JBoss middleware as xPaaS and microservices enabling offerings, I still intend to keep expanding the middleware portfolio where we see  emerging needs –  whether it’s big data related, or stream processing.

Finally on to the subject of Java, what’s Red Hat’s take on the trimming of the Oracle evangelist squad given how invested you are in the platform?

Watch this space – we’re certainly not taking our foot off the pedal. Java the language will be here for a very long time, as well Java EE. Now at the same time, all that said, note that the FeedHenry technology is Node.js, and one of the significant aspects of the FeedHenry acquisition for us is that we’re able to move beyond that Java core and to make a real move into Node. We’re investing seriously in Node, joining the industry movements, foundations,  governing boards, etc. Node is the fastest growing alternative/complement to Java in the enterprise application space, so again, watch that space, because we will continue to invest and make moves in there.


Red Hat: Full Steam Ahead for Node.js

| Java Language| 1,281 views | 0 Comments
About The Author
- Editor of Voxxed.com, focusing on all things Java, JVM, cloud-y, methodical, future-fantastic, and everything in between. Got a piece of news, article or tutorial you'd like to share with your fellow Voxxians? Drop us a line at info@voxxed.com

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>