Skip navigation
2010

Mark Little's Blog

November 2010 Previous month Next month

Over the years both Red Hat and JBoss have a history of making good strategy acquisitions including, but not limited to, the Arjuna Transaction Service, Metamatrix and, of course, JBoss itself. Well I'm pleased to be able to announce that today we've done it again, this time in the Cloud space with the acquisition of Makara! Makara, if you don't already know, have been doing some great work with JBoss technology in the Cloud for a while now and has a great presence at JBossWorld and Summit earlier this year. To put what they do currently in a nutshell it's provisioning of JBossAS into public and private Clouds, with monitoring and management to enable auto-scaling.

 

Now obviously there's some overlap with projects we've been doing in JBoss and Red Hat, such as SteamCannon and CloudEngine, as well as obvious areas of synergy like DeltaCloud. Plus Makara's technology isn't open source. So that's why the engineering teams across the board have been talking about how best to drive the integration forward and ensure that the considerations of our communities are taken into account. Over the past 10 years I've been "acquired" many times as well as being involved in acquisitions. I've also helped open source a number of previously closed source technologies. To do this right will require time and doing is right is very important for us. So please don't expect to see code appearing immediately, but you will see the Makara team appearing in the forums, IRC and elsewhere to answer any questions that our JBoss.org developers and community may have.

 

So with that, I'll just say a big welcome to the Makara team! It's going to be a great adventure over the next weeks, months and years.

Rich Sharples gives a pretty good overview of our product lifecycle in response to some FUD from Snorcale. As a slight aside, I love it when certain Closed Source companies preach to us and the communities about open source: the words "grandmother" and "sucking eggs" spring immediately to mind! Anyhow, FUD is something that we've seen rather a lot of in recent times; I suppose it's easier to do than actually provide significant technical differentiation, and it's nice for us to keep disproving it!

 

As I said, Rich's post is a good overview. But some of the things that are implicit in it need a bit more explicit discussions. For a start, the open source communities are extremely important to us and we try not to do anything that would affect them adversely. Everything that we do during the productisation process in terms of bug fixes, feature improvements etc. goes back into the community releases. We are not a closed source company that periodically dumps our code into a public repository.

 

The communities, whether they are comprised of people who contribute code, let us know about bugs, or give us use cases and requirements, are critical to the success of our projects and hence our products. Of course we recognise that not everyone will want to purchase a support agreement from us and will be confident enough to self-support. Those individuals and companies are still important to us; they're still a mark of success, both for us and for the community at large! If you listened to some of the FUD you'd think that we walk all over the communities once we get what we want, i.e., the code. Nothing could be further from the truth; just take a look at JUDCon for example. Of course you can't please all of the people all of the time, but to think that an open source company such as Red Hat would do anything to mess with its communities is crazy. I think it shows that companies such as Snorcale are having to resort to the Chewbacca Defence in order to try to confuse everyone and distract them from their own issues around open source.

 

Another thing that is implicit in Rich's description, is what we like to term "baking in the community": this is where the community (including our employees) works to ensure that each release of a project (and hence a subsequent product) is fit for purpose. Our communities feed requirements into each project release via forums, JIRA, emails etc. The development teams, which may well include community developers as well as our employees, then work on any associated new capabilities, or bug fixes, and turn those into new project releases. The communities then take those releases and kick the tyres, providing feedback on what's good and what's bad, what works and what doesn't. As a result, it may be many months, or several project releases, before the project teams and their communities are happy with a particular feature. This is baking in the community, and only something that's been suitably baked makes it into a product.

 

All of the above should help to illustrate some of the trade-offs that are inherent in our approach. The communities are always getting the cutting-edge features and capabilities, some of which may well have been added by our developers on behalf of customers, as well as all bug fixes that we may find during productization. The community releases move forward relatively quickly compared to the products, because we spend a lot of time in the productization process, which might include removing some things from the project releases that aren't quite ready yet, e.g., they haven't had enough bake-time. Those who purchase support for our products (platforms) get a slower moving beast, that offers guaranteed stability over a much longer period of time; it may be months or years before they gain access to the feature set that's available in a project.

 

So in conclusion, we believe the model we use is able to walk that line between project needs and platform needs. It's something that we have been working on for a few years, but which we do evaluate based on feedback from all of our community members, including product customers. It has allowed us to grow our offerings substantially over the past 4 years and retain our leadership position. So let's see how the next 4 years plays out.

marklittle

JBossAS A Service

Posted by marklittle Nov 1, 2010

I started writing this entry a few months back, but what with JavaOne, JUDCon, various customer engagements and a slight smattering of vacation, it's taken me longer than I expected. However, there has been one advantage to the delay: a lot of the reasons I mentioned previously that have taken me away from writing this piece have also helped to re-enforce the fact that we're on the right track.

 

So where to begin? Well I've written quite a few things over the past few months about Cloud and PaaS, whether that's about multi-tenancy, public/private Clouds, JeAS, PaaS, Platforms of Services, Cloud as the death of middleware (it's not!), or our own JBoss efforts in the Cloud. Underlying many of them (particularly those that talk about middleware) is the idea that the Platform for Cloud applications requires many (all?) of the capabilities that we use today in our non-Cloud deployments: just migrating into the Cloud doesn't mean your concerns about security or reliability that made you choose one solution over another for your data centre are invalid; if anything they become even more important! So whether you want to take existing applications into the Cloud (more likely) or develop new ones from scratch, you need the platform you code against and ultimately deploy into, to support those key features, such as security, transactions, messaging etc.

 

But of course Cloud means that you don't want to pay for these aspects, or the platform, and have it sitting around idle for 90% of the time. You only want to pay for it when you use it. This is the pay-as-you-use aspect we're always hearing about: it's a service (hence PaaS). And for those users who are interested in open source, standards based solutions, this is precisely where JBoss middleware comes into play. Today we have many customers who use our enterprise platforms successfully, including EAP, Portal and SOA-P. I wouldn't want to hazard a guess as to how many of them will want to move to the Cloud, but of those who do, and future Cloud-specific customers, they'll naturally expect a service-like arrangement for our platforms. This is precisely what we're doing with the Cloud Foundations effort that I mentioned a few months back.

 

In terms of PaaS, we're working on turning our existing platforms in an "as a service" offering. This includes tooling (e.g., JBDS) as well as monitoring/management aspects. So pretty soon you'll be able to develop your Seam-based application, or your EJB3 pet store, locally and then deploy them "out" to a Cloud running the right version of the JBoss platform you want, which will spin up your application when it's needed. So you'll only pay for what you need (e.g., EAP) when you need it. It'll be JBoss As A Service, or, because it's a cooler play on words, JBossAS A Service!

Filter Blog

By date:
By tag: