Java in the Cloud: Amazon Joins the Party

Amazon announced today its Elastic Beanstalk offering, essentially providing Java in the cloud. This is great news as it reinforces the message that the future of Java is in the cloud, not on premise.

Yet, beyond the signal it sends to the market, this move doesn’t radically change the current situation. If you are a Java developer, you will find that CloudBees is a more mature and more sophisticated offering. CloudBees is a global platform, from dev to production, which will shield you from IT entirely.

Let’s dig more into how CloudBees’ vision differs from AWS’.

First of all, at CloudBees we think that for the cloud to make sense to developers, it needs to provide a proper answer at all stages of an application’s lifecycle, not just at runtime deployment: code and binary repositories, building, testing, continuous integration, deployment, maintenance, integration with 3rd party systems, etc. We want multiple developers to be able to work as a team on those projects, we want them to know who is doing what, and for the more sophisticated deployments, what staging process needs to be followed before the new version of an application gets pushed to production. We don’t want you to even care about scalability, high-availability or any other IT related issue, we will handle that for you – “servers” are not what’s going to make your applications differentiated business-wise – let us handle that part. Also, let us live patch our platform so it is always the most performing and secure service you can find on the market.

Also, we see a lot of companies afraid about vendor lock-in, and this gets even more sensitive as they consider the cloud as their new platform: not only do they have to care about the software they leverage, but they also need to care about the cloud infrastructure they’ll rely-on as well as the 3rd party services they’ll closely integrate with. At CloudBees, all of our services are either based on Open Source and/or Open Standards: Java, Java EE, Spring, MySQL, SQL, etc. In terms of cloud infrastructure, CloudBees is IaaS-agnostic. We think the choice of a specific IaaS vendor should be up to the customer, either for legal issues or because they might want their Java CloudBees deployments to be collocated with other non-CloudBees deployments

Lastly, much like we think the cloud is the new platform, we believe SaaS vendors are the new ISVs. ISVs are morphing into SaaS vendors and, as part of this transition, the old model of ISVs certifying on top of operating systems and middleware vendors and leverage them as their preferred go-to-market channels doesn’t apply anymore. The new go-to-market for those SaaS vendors are the cloud-native PaaS, and only the PaaS with a partner-friendly approach can succeed, both at the back-end layer (IaaS) as well as at the front-end (PaaS extensions, 3rd party services, etc.). CloudBees is a partner-friendly environment; we are easy to do business with.

This is what we are delivering with our DEV@cloud and RUN@cloud offering and vision, all smoothly integrated.

As the Java expert, CloudBees provides depth and precise understanding of what Java developers’ needs are, coupled with our leading vision of where the cloud is going.

Who said Java was dead?


P.S.: and remember, we will provide a fully integrated CloudBees+Stax offering by the end of this month!

Sacha Labourey, CEO



Sacha Amazon's Beanstalk gives customers complete control in that one can create an AMI that is used by Beanstalk. This AMI can include a customized version of the Tomcat target server with additions such a system libraries include native ones. These libraries can then be referenced in command line arguments to the Tomcat startup script allowing customers to use the best management/monitoring/metering solution (hint: -agentpath, -javaagent) rather than what is offered as some token gesture by a PaaS offering. Will CloudBees RUN@cloud give this same control. I suspect not but I hope you prove me wrong.

William, You are right, we are not going to give that control, that is not our model. We want developers to do development, not system administration. We will automatically maintain your system for you. This is a different model, closer to a SaaS than to a IaaS. Customers who need to add features from 3rd party providers, will be able to do so through "add-ons", without having to mess with AMIs, system libraries, OS versions, etc. Cheers, Sacha

Sorry but I don't subscribe to your vision of the cloud which is reminiscent of the NetDynamics & Silverstream era prior to J2EE. Ease of use followed by lock-in and a complete execution blackbox in terms of QoS, cost and control. I doubt you will get any serious enterprise application that is so unpolluted that it fits all inside a webapp war file. This might have worked for Rails/Ruby but not in the Java world. Time will tell. PaaS IMHO is just a step (and a pretty small one judging by what is being offering) in the evolution of the cloud and utility computing. PaaS 1.0 (its all about apps) will pretty much kill off the notion of App as a deployment & management unit if Amazon does not already. But I will admit its doing to be a bit of a gold rush at the start until the blinkers come off. Premiums of such offerings will be high. I am looking forward to when this all looks much more like a managed telco env but with greater mobility and service/data/compute contextual awareness - and the focus is on activities and flows and not on apps (webapp in particular).

I don't see EE, SQL, and other open standards as lock-in users. AFAICT, there are very few open standards when it comes to SLA and QoS (at least in computing); until then, so those parts will create some lock-in, either through a PaaS providing this as a service, or as library (such as OpenCore)

Sacha maybe "lock-in" is not the most appropriate term because most see this being an explicit (API?) binding to some proprietary aspect of an offering. Lets try "lock-out" because PaaS is all about limiting choice which is largely driven by what is best the for vendor and not for the customer. One of the big complaints about J2EE application servers was the lack of standardization around the plug-out and plug-in of different service provider implementations for various enterprise technologies though typically within each technology specification a service provider interface and contract was defined. Getting this play nicely in an actual server environments was a different matter. With PaaS as its stands today even this option is not available "our way and offerings or hit the road". Openness is very important but this pretty much flies in the face of the PaaS business model which is all about getting customers on board as quickly as possible and locking down the options and environment to increase revenue ("only what we cook up") and limit costs/risks. I prefer the Amazon BeanStalk approach because its adding ease of use and elasticity whilst not completely fencing the customer in. Maybe I have got it wrong. Maybe the new plugin interface is plain old but terribly expensive HTTP wrapped RPC. Openness as long as its Outbound.

I think what you are describing is a IaaS, not a PaaS. You indeed get flexibility with a IaaS, but you also get complexity.

Hi, The above blog is very helpful. Following links are giving the how to use amazon cloud and how to configure your web application on it. Following links may also be helpful to get idea about other java cloud.