Bio Sacha graduated in 1999 from EPFL. In 2001, he joined Marc Fleury's JBoss project as a core contributor and implemented JBoss' original clustering features. He became CTO in 2005, remaining in that role when JBoss, Inc. was acquired by Red Hat. In 2007, Sacha became co-General Manager of Red Hat's middleware division. He left Red Hat in April 2009, forming CloudBees in April 2010.
JavaOne is all about exploring Java and related technology. From special exhibitions to demos and partner offerings to community networking opportunities, you'll find an endless source of inspiration as you explore JavaOne 2011. JavaOne offers the best Java-focused content, training and networking.
My name is Sacha Labourey and I’m the founder and CEO of CloudBees. We’re a Platform-as-a-Service company and prior to that I’ve been in middleware for a long time, in open-source. I was at JBoss back in 2001 until 2009, I guess.
What we had is really a Platform-as-a-Service which was mostly running Tomcat-based web applications. There is a real interest for EE 6 Web Profile applications in the field and I know it’s not very trendy to speak about the interest for EE 6 applications, it’s not the most sexy topic you’ll find, yet there is really a silent majority out there which needs that framework for its simplicity and productivity. So it was important for us to support the EE 6 Web Profile, which we just launched this week.
For a lot of things it’s not that different, because we have a standard so any application that fits to the standard will deploy on the PaaS. I think the big benefit of using a PaaS is it brings back power to the developer, so developers are back in charge. The big change is not so much in EE 6 - that’s what your application does - but in anything else. It’s in the kind of productivity you are getting, in the fact that you don’t need to fight for machines or setup or anything like that. You are really just focusing on your application, delivering this application to production and you’re done. As part of the CloudBees PaaS... Everybody has a different definition of what is a Platform-as-a-Service these days. Our definition is that it should not just be a matter of deployment, it’s not just about taking an application and running it in production. It should be about anything in the application lifecycle and that includes development. What we bring, is that we make it extremely easy for an EE 6 web developer to develop an application, build it, test it and then deploy it.
There are a bunch of things we need to do to make it really production-ready, in the sense of by default JBoss is used for developers, so the JBoss team makes it easy to download it, install it, and run it. But it might not be the most secure setup - they have other configurations for that and also in the way we manage sessions, in the way we manage elasticity and so on. Those are the kind of things where we need to intervene to change those configurations and/or code-changes.
It’s pretty interesting what we see on the market and I think we can pretty easily put them in 3 main buckets. You will find the startups, the CloudBees of the world, You have a number of startups out there, and you see a trend these days moving from "We are a PaaS supporting Ruby - for example - or Python" to "We’re a PaaS that supports any language". That’s what is being called "polyglot" which I think is a bad name because the JVM can host many languages. But we see that trend going on and, while being in that category of innovative startups, we very much believe in the depth of a PaaS. We think that to really satisfy use cases and not just mere hosting, we need to have some depth in the type of use cases we support and that makes it easy for a developer to deploy an application and develop it, and so on. That’s the first bucket.
The second bucket are the Cloud providers: Amazon is an obvious one, Google App Engine could be considered as a Cloud provider even though they don’t provide really an infrastructure per se. That is not a well-defined bucket, I think, because a lot of Cloud providers still wonder should they partner, should they build, so that’s still in flux.
The third bucket is obviously the legacy middleware vendors - so that’s Red Hat, VMware, IBM, Oracle. That’s a very important bucket because obviously those companies are the ones speaking to developers today. They have the relationship with the developers and so it’s really somehow up to them to send the signals to developers that the Cloud is the next generation platform. That’s what we are seeing now. In the last few months we had Red Hat come up with OpenShift, we had VMware come up with CloudFoundry and maybe this week we are going to see Oracle come up with a PaaS strategy. I think this signal is being sent to the troops.
The role of private cloud is kind of fuzzy to me. Obviously it’s always easy to explain how company Y with 60,000 servers, found it very interesting to deploy a private cloud. What we see today in most average-size companies (so not the uber-company with a huge soccer field size datacenter) is that virtualization is still the layer that matters today. We think that the PaaS will have to make sure that today’s workload - things like the databases and the data location is the main problem - can be accessed and can be consumed by those PaaSs. But I’m not entirely convinced that the future of the private cloud for the mass market is going to make a lot of sense. Time will tell, but I think the public cloud will be the real destination and hybrid strategies will be a great way to offer a stepping stone to get there, but I have a hard time believing that all small companies and mid-size companies will end up with a full-fledged private PaaS ... or a full private cloud.
I think that’s going to be the main shift; it’s going to be amazing. And it’s already the case, even though it’s not really well advertised today. For example, one of our customers is a mobile phone application company. They have about one million and a half customers. They generate from 15,000 to 20,000 requests per minute on our platform, so it’s really a good-sized application. Yet, this company has 4-5 engineers and that’s it. This is the kind of productivity that has been unmatched in the industry. 5 - 10 years ago, could you find any company with just 4 guys with that kind of load, that kind of customers? It’s totally unmatched. Today, you’ll speak about a few companies in special fields, but the scope of those companies is going to grow and then it becomes a question of, "Can I remain competitive if I don’t embrace that kind of efficiency?" So it’s all about efficiency; it’s all about the cost; it’s all about not having to invest a huge amount of money in CAPEX, just to be ready when the system, the service, is going to be successful. I think it’s going to be a very big shift.
A number of things can be achieved to make it easier to consume application servers in the cloud. First and foremost, I think, the very big underlying theme is that, if you remember in the ‘90s you were kind of building your own application server. It was called object transaction monitors. You would buy your transaction monitor here, your messaging layer there and so on and you would build your own thing. Then EE came up; EE was this big wrapper spec initially, it was not very big but it was taking all of those sub-specs and creating a monolithic application server. That was all great. I think we are going back in the opposite direction now. We are going to the main where all of the resources are externalized. Those resources are multitenant services, like messaging and so on, that can be consumed by multiple tenants, and the application servers focus mostly on computing. They need to be stateless, because stateless is easier to scale, and elasticity is a very important problem. That’s really where we’re going - back in time pretty much. I think that’s going to be a theme.
We also see things like grid will be very important, so I suspect that a number of APIs will have to be offered to allow vendors to hook into that ecosystem. The problems that Java EE 7 will face, even though we participate in EE 7, I think we need to recognize very clearly that it’s always dangerous to standardize things too early, because the feedback we got from the street essentially is relatively weak at this point; it’s still pretty new. We will find the right balance between standardizing what enables the market to move faster, while at the same time not making it blocked in time and force things that would be unnatural to the growth of the PaaS market.
No; the full profile in itself is not so very exciting, but yet there are some services that are interesting. A number of services that are not in the Web Profile would be interesting to bring them back. Yet, going as far as to support the full profile is a stretch.
We're very interested in building the ecosystem. I think it’s great to speak about features and we all like that, but we tend to forget that what made the success of some of the leading operating systems and leading application servers was really the ISV ecosystem. If you were to buy an operating system with no software you could install on, that would be meaningless. The same is going to be true with PaaS vendors - it’s going to be important to be able to on-board a number of next generation ISVs, so SaaS that can further extend the feature set of the PaaS provider. That’s something we're working on extensively. We have a CloudBees ecosystem; we want to further grow that. We think it’s also important to provide a funnel for specific use cases like mobile phone applications. How do we make it easy to those kinds of developers to really leverage the entire chain of development? And so on and so on. So a number of things to work on and, as in any big shift, the type of use cases are just enormous. We just need to make sure not to be spread too thin.