Hopefully it's obvious, but everything these days really has to be open. Open standards, such as those activities within the W3C or OASIS, and open source. Vendor lock-in needs to be a thing of the past and open source empowers people to ensure that is the case! Why does open source matter? Open source is at the heart of many of the technological advances over the past decade. Whether it's cloud with Linux, JBoss with Java EE, or Android for mobile, you don't have to look far to see open source footprints. The success of these waves and others is due to the communities that naturally build up around open source, the rapid feedback that users and developers can provide to those projects and, of course, the fact that it's easier to tailor the technologies to the problems at hand.
So what does the platform for the second decade of the 21st Century look like, apart from being open source? It has to be lightweight with a minimal footprint, built for cloud - not the limited definition of it we have today with just servers, but the more natural and future version which includes IoT. It also needs to be dynamic, adaptable, autonomous, self-healing … in some ways similar to a living organism. From a JBoss perspective technologies such as Fuse Fabric8 provide some of these capabilities today. And of course data management (virtualisation) is at the heart of the platform: being able to store and represent data in a range of ways, not just relational, and at such hugh scales, is a necessity.
This is really about modernising the application development platform, turning the development experience from what was needed at the turn of the 21st century to something that will define the next decade and beyond. I've outlined what this new platform needs to do in terms of functionality, but how will it happen? Or let me rephrase: how are we delivering this platform today so that it can be used by a wider range or people to develop an even wider range of applications?
Well for a start SOA is at the heart of this. Whether it's due to integration of disparate services across the clouds and clients, or what some people are calling Micro Services (which is really just SOA so don't be fooled) we're building on Fuse technologies such as Camel, A-MQ and of course Fuse Service Works, including Switchyard and S-RAMP. Back in the early cloud days we'd talk about the Internet Service Bus as a cloud version of the ESB, but these days there really shouldn't be a distinction. The SOA infrastructure, of which ESB is just a part, must be cloud enabled and mobile enabled and IoT enabled (you get the point) from the start. And of course where SOA and services are concerned you need a way of tying them together into business activities or tasks. The act of doing that immediately propels us into a different group of people: we're no longer talking about service developers but business analysts and that requires a very different approach, with very different tools. Fortunately jBPM, Drools and our acquisition of Polymita over a year ago have enabled us to create the new BPM Suite which targets business analysts.
Now we could obviously deploy these services and others into the cloud as individual components. But that fails to see that there are so many common requirements that they share, so many groups of developers or analysts will want to use more than one at the same time, that to not pull them together into a single platform is inefficient to say the least. This common platform is what we call xPaaS and it's definitely an example of where the whole is much more than the sum of the individual parts! Our xPaaS implementation is evolving even as I type, but today it consists of OpenShift and many key JBoss technologies such as:
- Application Container Services Based on Red Hat JBoss Enterprise Application Platform, the application container service delivers aPaaS capabilities that enable developers to build and deploy complex enterprise applications in the cloud.
- Integration Services (currently in developer preview) – Based on Red Hat JBoss Fuse and Red Hat JBoss Data Virtualization, Red Hat’s integration services allow developers to create connections to, in, and with cloud and on-premise applications and data.
- Business Process Services (currently in developer preview) – Based on Red Hat JBoss BPM Suite, the business process services are designed to enable business users to build, run, integrate, and manage business process applications that automate workflows and business processes within and across organisations.
- Mobile Services – Based on the AeroGear project, mobile services simplify and streamline support for numerous mobile client types while extending applications to those devices through capabilities such as push notifications.
And we’ll be releasing more components into xPaaS over the coming weeks and months! If you want an enterprise level Platform-as-a-Service then xPaaS from Red Hat/JBoss is the only implementation that matches the needs of developers today and will continue to evolve as those needs evolve.
What I've mentioned so far is here today. But what about the future? I've already mentioned that the platform we need today is very different from those which we've used in the past, but this is a never ending evolution. For instance, whilst EAP is core to everything we do today and so is Java EE, we're already seeing people develop serious applications with new frameworks such as node.js or Vert.x. For several years we've been talking about JBoss Everywhere and this continues today with our view to these new reactive platforms: we will be ensuring that where these frameworks need transactions, security, caching, replication etc. then we'll use those that we've got rather than reinventing the wheel. And it'll be polyglot too.
Red Hat has strong links for a number of academic institutions around the world. However, certainly within JBoss our strongest links are with Newcastle University, where we work closely with the students, teaching staff and researchers. It's no surprise that many of the JBoss team in our local office have come from there. Therefore, I'm very pleased to hear that the University has received one of only a handful of Centres for Doctoral Training (CDT). We've worked closely with the University on their proposal, which is around Big Data and Analytics, combining the practical elements of a traditional Computer Science PhD with the more theoretical/formal methods from statistical analysis. Congratulations to all of those involved in putting together the submission and getting it approved. And I look forward to the research that is done over the next years and working closely with the University team.
It's been a while since I've had a chance to sit back and put some of my thoughts to (e)paper. I don't know quite what it is but for the past few months (even before 2014 began) I've been snowed under with this or that. I know some of this is down to our (Red Hat/JBoss) success meaning that I'm being pulled in many different directions so it's definitely a good thing in that regard. But it's past time for me to make more time and at least write about some of the things we're planning for Summit/DevNation this year. Now of course I won't go into much detail or I'll spoil the surprises, but here's a taster:
Summit Keynote: once again JBoss will be kicking off the keynotes at Summit and once again we'll be running a demo with a large amount of audience participation. Prizes will also be available but you'll have to wait until the keynote to find out what and how they can be received. It never fails to surprise me how much effort goes into the keynote, with the demo taking up a lot of time and effort from some of our key engineers. All I can say is that there'll be an IoT theme to this!
Summit session: I'm presentation and moderating a session on the future of enterprise middleware. This should be a very participatory session so come along and hear what we think but also make sure we hear what you think!
DevNation BOF: Scott Stark and I (mainly Scott!) will be working with ARM presenters to talk about JBoss, IoT, CoAP etc. and then have attendees try out some of these cool ideas. Come along!
DevNation: there's a hacknight on the Wednesday evening with a number of things going on. One of them is an IoT themed event with ARM, and we'll also be trying to do some cool things with Raspberry Pis. We may even be giving away some of these devices on the night!
Fuse@DevNation: we've got a few very special activities going on at the start of DevNation if you're interested in Fuse related projects and products!
DevNation Party: 'Nuff said! Be there and if you find me maybe I'll buy you a drink or have a few surprise give-aways!
That's about it for now. Summit and DevNation will be very busy whether you're a presenter or an attendee. I hope to find time to put more thoughts to (e)paper soon on what we're doing in a number of areas, such as IoT, messaging etc.
Back in September last year I announced that we were working on xPaaS (enterprise services in the Cloud and specifically OpenShift). xPaaS is a long term effort that will evolve as our products evolve and we put them into the Cloud. However, it's with great pleasure that I can announce we've started the xPaaS releases with iPaaS (Integration-as-a-Service):
You can find out much more about iPaaS by checking out the home page and taking it for a test drive - give us feedback too! As Arun mentions separately, there will also be some relevant sessions at this year's DevNation. And we should be announcing further updates to the xPaaS effort in the coming months, so keep watching.
I've written a couple of blog entries on my personal blog which are related and which people may find interesting. The first is on some work I was doing over Christmas with CapeDwarf running on Raspberry Pis, with the aim to turn them into a private cloud. The second is about the adoption of hybrid cloud, but also repeats what I've been saying for several years that devices such as the Pi (or smaller) need to become part of the cloud. I'm hoping to say more about this at Summit later this year and maybe we'll have some demos to illustrate.
We've seen a couple of announcements already around DevNation and I just wanted to add my own take to this because I've been asked "Where's JUDCon or CamelOne?" The simple answer is that they haven't gone away, but at least as far as Summit is concerned they've been subsumed within DevNation. The reason for this is pretty simple too: when I kicked off JUDCon with the team back in 2010 it was the precursor event to JBossWorld/Summit and the only developer conference we held at that point. Over time we've added OpenShift and other developer conferences with non-JBoss focus and then of course last year we added CamelOne. Each of these conferences have their own identities but when gathered together at the same time and location it can cause confusion, not just in terms of questions like "If I register for JUDCon can I go to CamelOne?" but also in terms of presentations, which often span multiple developer communities and hence these individual conferences, resulting in questions like "Why was that presentation at JUDCon when it clearly should have been at CamelOne?"
Therefore, whilst the likes of JUDCon will continue to exist in isolation (you are going to JUDCon India, right?) and we've restarted the Fuse Days, when gathered together at Summit we'll have just DevNation. The content of this one event will be just as eclectic, the communities just as vibrant and the entertainment just as good, but now it should be a lot easier to understand just what you get for your registration and what you can expect. Of course I'm sure (I hope) there will still be issues with being able to see all of the sessions you want to see because some conflict, but I think that's the sign of a good conference/workshop.
I got the opportunity recently to go to Lyon (haven't been there in about 2 decades!) and present at INSA/CITI as well as give a session at the local JUG. Before I set off I was asked a few questions so that they could post an interview with me. If you're interested, then the interview is here.
I'm hoping that CITI and the Lyon JUG will eventually post the presentations I gave as they're a little bit too big to attach here. However, here's the first slide from my presentation at CITI:
And here's the equivalent from my JUG presentation:
Fortunately in this and age of social networking, I didn't have to worry about taking pictures of the event: others did that for me and I include them here along with my gratitude:
For those people who weren't there and want to see the last slide in more detail, here it is:
I want to thank everyone who attended both presentations and gave me some good questions to answer and things to think about on my journey home. I also want to thank Julien Ponge and Alexis Hassler for inviting me and arranging everything. I do want to do it again!
Back in 2009 I wrote about how it was sad in some ways that Sun had been acquired by Oracle. 4 years later, we now hear that GlassFish is being relegated to the domain of the Reference Implementation. Once again I have mixed feelings about this event. Despite GlassFish being seen as a competitor to our own offerings, there was always a grudging respect for what that team had done, and several of them now work for Red Hat, often as a direct result of those efforts. So in that regard it is sad to see it go. However, what worries me the most about this turn of events isn't so much about the technology, but rather what signals this could send to their open source communities. I will leave that mainly as an exercise to the reader, but it doesn't really take a massive leap to be concerned if you are a member of those communities. Now I'm not going to suggest that Red Hat's projects such as WildFly, or any other open source vendor, are necessarily a better home for those community members who feel that it is time to move on, but I would hope that they would at least take a look and judge us on our track record.
I'm on holiday at the moment but some things are so important that they draw me back temporarily. Red Hat and JBoss before it, has been an active member of the JCP Executive Committee for many years. We've worked with Sun, Oracle, IBM, HP, JUGs and many others to try to ensure that Java the language and Java EE the platform, are open and fully participatory by those who really make our collective thriving ecosystem work. It hasn't always been easy but we're glad to be involved. Whether it's helping to open up the JCP processes, injecting more open source practices, leading JSRs or participating in them, we try to be involved in all aspects of the Java community and standards. This is why being on the JCP Executive Committee is important for Red Hat: we believe that the best way to influence things is from within and being on the Executive Committee gives us that ability.
But an even more important aspect of being on the JCP EC is that everyone gets voted on (or off). As with any election, this is a great way of getting feedback on how well people view you and your approaches. We've been elected on to the EC every time our seat has been up for election, but that does not mean that we take it for granted: far from it in fact! And this time is no different. The elections kicked off recently and myself and Scott Stark represented Red Hat. The results have just been reported and I'm really pleased and proud to report that we've been elected for another two years. As you can see from the results, we got a lot of votes and it pleases me that so many people believe we are doing a good job. I want to thank everyone who voted, whether or not they voted for us (voting is important!); we will ensure that your vote counts.
I wrote an article on InfoQ recently about IoT. This was based upon a presentation I saw whilst at the JCP EC meeting in September from ARM. I found it fascinating, especially given the work we've been doing on things like Raspberry Pis. It was also interesting to hear how important ARM and others see Java in this space. So if you haven't read the article then take a look.
We've been talking about PaaS for several years now. Whether it's outlining our intentions around Enterprise PaaS and then delivering with the first EE6 Platform as a Service, discussing how EAP, EE6 and Java are critical for mobile and cloud, or many presentations and announcements at Red Hat Summits (exercise left to the reader to check these out), I think it's safe to say that we've been leading the push for Cloud, PaaS and relationships with Java. Last week we announced another key presentation update on our PaaS strategy that would happen at JavaOne and I'm pleased to say that's now happened and I can talk publicly about the work that our teams have been doing over the last few months.
We're terming this xPaaS because it is meant to encompass much more than what PaaS has typically come to be associated with (ePaaS, or Enterprise PaaS, is a component of xPaaS). In many ways we've been talking about xPaaS for a couple of years and particularly how technologies and methodologies such as SOA or integration must play within the Cloud and between users of the Cloud. But with the advent of mobile, obvious problems to come such as that indicated by Shannon's Limit, and other changes in the way our industry, xPaaS has come to encompass much more.
Some of our recent acquisitions, such as Fuse (Fabric, Camel), Polymita and efforts like AeroGear, WildFly, embedded device work (e.g., Raspberry Pi) etc. have all contributed to xPaaS in one way or another. We demo-ed some of this during this year's Summit JBoss keynote, and with iPaaS (Integration PaaS) James has been previewing it for many months. The xPaaS announcement brings all of this together and pretty soon developers will be able to use these technologies themselves and provide us with feedback as well as help to evolve it.
Some important highlights for the iPaaS component of xPaaS include: code-less UI - drag/drop/configure deploy - anywhere - public/private cloud, bare metal etc., cloud and SaaS connectors (via Apache Camel), auto-scaling to meet demand - all managed from a central platform, and of course it works on OpenShift.
As I mentioned already, mobile is an important part of Cloud today. So another part of xPaaS is our Push Server which runs on OpenShift and has AeroGear at its heart. But some important things to note about this release is that we have integration with iOS (APNS), Android (GCM), and FFOS/Web (Mozilla SimplePush), with associated client SDKs. There are also sender SDKs for Java, with Node.js, and PHP in development.
And of course just as outside of the Cloud, once you start to create your applications from components and services, BPM (in the form of jBPM, for instance) and related technologies such as BAM, become a necessity. So of course BPM-as-a-Service is an integral part of xPaaS.
Of course I can only give you a taster of what we've just announced. You'll hear more from us over the next weeks and months as we roll out these xPaaS components so you can try them out. Our end goal is supported products and we'll be making other announcements later. For now check out the xPaaS announcement and watch this space. This is when PaaS really enters the enterprise domain!
And a big congratulations to everyone in the teams within Red Hat who have been involved in this announcement and the technologies it showcases! It's a great effort!
We've been pretty busy lately so this is slightly delayed. However, I do want to announce that Red Hat has joined the Google Cloud Platform Partner Program as a Technology Partner. Through this program, Red Hat and Google will collaborate on an open source community project known as JBoss CapeDwarf that increases the portability of Java-based Google App Engine applications and expands the deployment choices beyond Google’s cloud.
The JBoss CapeDwarf community project is an implementation of the Google App Engine Application Programming Interface (API) that enables applications to be deployed on either Red Hat JBoss Enterprise Application Platform (EAP) or its upstream application server project, WildFly, without modification. Red Hat JBoss EAP uses many of its enterprise-grade services such as authorization, transactions, data grid, and messaging to fulfill the Google App Engine API functionality in a way that is transparent to developers, users and the application.
The Google Cloud Platform offers a broad set of APIs for application development, cloud storage, large-scale computing, and big data. CapeDwarf leverages the Google App Engine on top of Red Hat JBoss EAP, regardless of whether it is deployed on premises or in an IaaS environment. Through the Red Hat product portfolio, developers have a path to run Google App Engine applications on a full enterprise-grade stack, using Red Hat JBoss EAP or combining it with Red Hat Enterprise Linux, OpenShift Enterprise, Red Hat CloudForms, or Red Hat Enterprise Virtualization.
CapeDwarf implements all the APIs as defined by Google App Engine for Java. The implementation serves as an integration layer between GAE APIs and services offered by JBoss EAP either out of the box or added by CapeDwarf itself. All data related APIs as well as others (Tasks APIs, Logging API) rely heavily on Infinispan, Hibernate Search, JGroups and Lucene, while the Tasks API also uses the HornetQ messaging system. The User API and the OAuth API rely on the Picket- link library.
Now of course you might ask why? Well ...
No more lock-in: Move your app from the Google cloud to CapeDwarf and back any time.
Google AppEngine on-premises: Now you have the option of initially deploying your app in your own CapeDwarf-based private cloud. When your app outgrows it, you’ll be able to simply migrate the app to Google’s Appspot.
Simple to create cluster: JBoss EAP makes it easy to run a multiple instances in a cluster. CapeDwarf has been implemented to support clustered environments from the start.
Easy debugging and multi-node testing: While the development server provided by Google App Engine can only be run in a singleserver configuration, CapeDwarf allows you to test your app on multiple nodes prior to uploading it to Google Appspot. Through remote debugging, you can also find those elusive bugs that do not show up when running the application on a single server.
Pure Java: CapeDwarf is written in pure Java and is universally portable.
Opensource: The complete CapeDwarf codebase is fully open sourced, which means you can fix any bugs you may find yourself, without waiting for the vendor to fix them.
Then of course there was the traditional JBoss keynote. The team practiced and finalised the demo throughout the previous two days and did a fantastic job!
We had over 1000 people in the room in the end, with many having to stand and watch, and almost as many people who couldn't get in (fire regulations):
But fortunately it went over fairly straighforwardly in the end!
And of course there was the traditional JBoss party, with the (becoming traditional) range of JBoss-themed drinks. I tried hard to sample each and every one of them on the night! I'm not sure if I accomplished this, because my only clear recollections are of discussion quantum mechanics and failure detection with James Strachan at the bar, using alcohol filled glasses to represent subatomic particles!
In conclusion, I think all of the events went very well! The sessions I managed to attend were great and very vibrant. The sessions I was speaking at also seemed to be well received. So overall I'd say it was a success! Onward to next year and San Francisco!