Amazon selecting open source Apache Tomcat as the Java application server powering Amazon’s entry into the Java Platform as a Service (PaaS) market came as little surprise to Java vendors and industry watchers. Amazon’s pricing strategy on the other hand will surely surprise some vendors and IT decision makers. Additionally, Amazon’s apparent lack of contributions to the Apache Tomcat project should be considered during Java PaaS selection decisions.

Betting on Java in the cloud
Amazon’s newly announced AWS Elastic Beanstalk beta cloud offering is being positioned as proof that Java is in fact alive and well. Sacha Labourey, CEO at CloudBees, a Java PaaS provider, writes: “This is great news as it reinforces the message that the future of Java is in the cloud, not on premises.” I’d adjust Labourey’s comment to read: “the future of Java is in the cloud, and on premises”.

Amazon’s Jeff Barr explains AWS Elastic Beanstalk as follows:

AWS Elastic Beanstalk will make it even easier for you to create, deploy, and operate web applications at any scale. You simply upload your code and we’ll take care of the rest. We’ll create and configure all of the AWS resources (Amazon EC2 instances, an Elastic Load Balancer, and an Auto Scaling Group) needed to run your application. Your application will be up and running on AWS within minutes.

When the de facto public cloud provider, Amazon, launches a Java-based PaaS offering, ahead of another language such as Ruby, that speaks volumes about Java’s future.

Amazon’s loss leader pricing for AWS Elastic Beanstalk
While AWS Elastic Beanstalk is seen as good news for Java, Amazon’s pricing strategy may not be welcome news for some Java vendors.

Amazon’s Barr mentions, almost in passing, “PS – I almost forgot! You can build and run Elastic Beanstalk applications at no charge beyond those for the AWS resources that you consume.”

Amazon has effectively set the price for the operating system, web server, Java runtime and application server software components of a public Java PaaS at $0.00/hr.

Aside from these software components, functionality to monitor a running environment and proactively provision and scale up and down resources to meet service level agreements would be considered key elements of a PaaS.

Amazon offers these capabilities through Amazon Elastic Load Balancing and Auto Scaling, the latter being a feature of the Amazon CloudWatch monitoring service.

Elastic Load Balancing costs $0.025 per hour per elastic load balancer, while Auto Scaling is available at no charge for an every-five-minute monitoring cycle frequency, or for $0.015 per instance hour if an every-one-minute monitoring cycle is required. When these costs are added into the picture, Amazon’s Java PaaS, excluding hardware, storage and bandwidth charges, costs as little as $0.04 per instance hour including one load balancer. Over a year, this setup would cost about $350.

Amazon’s loss leader pricing strategy poses a challenge for emerging PaaS providers to offer equivalent function at such a low price point. Emerging PaaS vendors will attempt to differentiate versus Amazon’s offering, thereby hoping to defend a higher price point for their offerings.

The price point could also impact established open source based Java providers that have grown based on a lower cost of acquisition value proposition. Enterprises drawn to these solutions for a departmental or less business critical application could become enamored with Amazon’s $350 per year price point. After years of telling IT buyers to make purchase decisions for certain projects based on acquisition cost alone, these open source vendors may have to face the stark reality of their buyers agreeing, and using Amazon’s PaaS as a negotiation tool.

Amazon taking more than it gives to open source?
What’s more troubling for customers is Amazon’s willingness to take seemingly an order of magnitude more from the open source commons than it contributes.

For instance, while relying on the adoption and brand awareness of Apache Tomcat, Amazon is not even a current sponsor of the Apache Software Foundation. Additionally, it appears Amazon is not an active contributor to the Apache Tomcat project.

Amazon is not duty bound to sponsor or contribute to Apache simply because it’s using Apache developed code. However, if Amazon’s Java PaaS is wildly successful, or even successful enough to lower the price point customers are willing to accept for a public Java PaaS, then vendors who fund Apache Tomcat development, and who must now compete with Amazon’s Java PaaS price point, will have to reconsider their investments in the Apache Tomcat project.

Declining vendor sponsored contributions to the Apache Tomcat project would be of concern to the many customers that utilize Apache Tomcat either directly or indirectly, and in a cloud environment or not. Amazon could choose to contribute resources into the Apache Tomcat project to offset declining contributions from existing vendors in the Apache Tomcat community. This would however add to Amazon’s cost structure for AWS Elastic Beanstalk, and thereby necessitate a price increase or for Amazon to accept lower profit margins.

Advice for IT decision makers
IT decision makers interested in deploying public cloud PaaS workloads should start considering Amazon’s AWS Elastic Beanstalk. However, do so while understanding that Amazon’s current pricing may not fully reflect the true costs of developing and delivering a Java PaaS to customers.  Amazon can only rely on the contributions of a community while competing with the main contributing vendors to that community for so long. Also, don’t be surprised if Java PaaS vendors, established or emerging, are unwilling to compete at Amazon’s price point, but would rather offer differentiated value.

Interesting times ahead, for IT buyers and vendors alike.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”