Apprenda is delivering a nuance to that conversation today with the announcement that it is powering JPMorgan Chase’s development and management of internal applications – on both the Apprenda standard, .NET, and Java. The second part of this announcement is something of a bombshell, I’ve known that Apprenda was working on a Java platform for many months now but to the public it will come as a major shock given the best of breed rhetoric from Apprenda to date. But it’s important to understand that Apprenda has never said that only one development language will meet all the needs of an organization – rather it says that an individual PaaS need to be deeply tailored to a particular language or framework – and, by extension, a PaaS vendor can deliver similarly deep functionality across more than one language.

It seems that this messaging, while outside the orthodox thinking around PaaS, is resonating where it matters, with customers. JPMorgan is using Apprenda across its more than 430 development teams and 2000 custom applications worldwide. According to Apprenda, this is the largest private PaaS implementation to date – a claim that, while unable to be verified exactly, rings true given the nascent nature of PaaS in general, and enterprise PaaS in particular.

The problems that drove JPMC to investigate PaaS in the first place will come as no surprise to anyone who has been listening to the contention of myself and others that PaaS is the future of application development:

• Long lead times for application deployment due to infrastructure provisioning and OS and software stack build and verification
• Inflexible capacity management that requires precise, upfront forecasting and has difficulty in meeting unexpected scaling needs
• Lack of effective cost control with large up-front cost requirements and severe under-utilization of physical and virtual infrastructure
• Redundant effort between development teams that cause developers to treat application architecture patterns, security configuration, high availability, and common services such as application caching as “one off” engagements rather than relying on standards

Apprenda’s platform, plugged into JPMC’s existing IT infrastructure, allowed the firm to move directly from raw infrastructure to a high level private PaaS cloud. JPMC reports that it benefits in the following ways from the move:

• Enterprise Grade – JPMC’s private cloud PaaS operates at a scale for thousands of applications and provides guaranteed availability and global failover—integrating seamlessly with existing IT investments
• “Just Bring Your App” PaaS – removed the friction between developers and IT through single click application deployment and isolating developers and their applications from the infrastructure
• Unprecedented Time to Market – application deployment was reduced from weeks to less than five minutes per application
• Fine Cost Control – created a way to allocate and assign surface resources to developers on an internal “pay as you go” model to keep costs in check and utilization to a maximum
• Standardization of Productivity and Architecture Patterns – achieved an unprecedented ability to write hundreds of new custom applications per year that would leverage the platform and support common application management, plus offer platform services such as messaging and caching and cloud architecture patterns

This can’t be articulated strongly enough, an enterprise like JPMC does due diligence to the extreme, and their comments are glowing in their positivity, This from Ian Penny, Global Head of Distributed Technology Engineering and Architecture:

The size of the JPMC application portfolio is large. We needed a proven, enterprise grade private cloud PaaS that could handle our scale for both .NET and Java. Apprenda has the technology that could deliver on the private PaaS vision of savings and agility, transforming the way we develop and run applications firmwide

This positivity is understandable when one sees some of the metrics since JPMC has deployed Apprenda:

• Application time to market improvement of 59 days
• Utilization increases on infrastructure from an average of 40% to 70%, resulting in a 45% drop in infrastructure costs
• 100% uptime to date with no unscheduled environment outages
• Standardization across development teams in terms of deployment and availability of standard application building blocks, resulting in massive boosts in developer productivity and agility

Oracle wasn’t overly happy at Alex’s comments and counter posted saying that “TechCrunch is Clueless about Oracle Cloud.”

So… some thoughts on all of this;

• Even if Alex was an idiot (and he’s not) without a clue, this was bad. It’s bad form for a vendor to launch ad hominen attacks on a journalist or blogger. This is something I have battled against and it does vendors no favors to get all defensive on it.
• If a well-regarded commentator doesn’t “get” your product offering, chances are it’s your fault and not theirs. In my experience oracle as an organization that is incredibly hard to engage with, I’ve posted about this fact previously. As commentators we may be a complete PITA and maybe even prima donnas, but we’re important and not engaging is stupid. And damaging. And ultimately entirely contrary to your best interests

So, was Alex right? Or was Oracle right?

Well, talking in the back channels with other commentators, there is a pretty overwhelming feeling that oracle bought this on themselves simply because they seem incapable of engaging with us and giving us the visibility to be able to comment effectively on their strategy. True Oracle is known for its… ahem, aggressive ways of doing business and hence it’s not hard to imagine that they’ll continue to focus on lock down, closed, proprietary and not playing nicely with the outside world.

Really I don’t care so much if Oracle is screwed or if they’re going to set the world on fire. I’d simply ask them that if they want to be a part of a conversation, and have the broader commentator community take their story seriously, they’d be better building a model that sees them engage with us all. As a friend said to me via DM;

oracle a bunch of f’wads. could’ve engaged & become part of community vs alienate it..

But all might not be lost. After tweeting about the situation, Bob Evans, Oracle’s SVP of communications pinged me with a message inviting me to get more engaged. Who knows, maybe in 12 months time I’ll have as good an understanding and involvement with oracle as I do with NetSuite or Salesforce – we’ll see….

This is where Temboo steps in. Temboo wants to help developers create and automate interactions between varied data sets. It does so by using the notion of a “choreography” Temboo’s name for pre-built data workflows. Temboo has create an entire library of these “choreos” and ties them to a visual designer all within a browser-based dashboard. With Temboo, a developer can test a Choreo within the browser to test its functionality or down load the Temboo SDK (currently supporting Java, PHP, Python and Ruby) and insert the Temboo code directly into their own application code. These ready-to-use processes are designed to make API integration easy, taking care of authentication, credential management and updates. Right now, the Temboo Library has Choreos for over 70 APIs.

Temboo actally makes sense, they’re abstracting all the niggly details of building to an API away from developers and enabling the sort of visual mashing up of data that Yahoo Pipes tried to do a few years ago. The fact that Pipes never realy took off is perhaps a reflection of the fact that it comes out of Yahoo! rather than any reflection on the product itself. I used Pipes to build some custom data feeds and it was quick, easy and fun. Temboo would seem to take those attributes and add in many more service APIs, and additionally allow developers to extract raw code to insert into their own applications.

Temboo is currently in it’s beta testng phase and accounts are currently free. Signing up gets a developer 10000 calls to temboo per month and 500MB of bandwidth – it’ll be interesting to see how this one develops.

Anyway, Stackato is an infrastructure-agnostic PaaS built on top of Cloud Foundry. It extends Cloud Foundry and enables a private PaaS for Python, Java, Ruby,PHP, Perl, and Node.js applications. As a solution for organizations worried about data in the public cloud, Stackato enables customers to deploy an application to either a full public or a private internal cloud

Focusing on the private arena means that Stackato needs to provide some functionality that is important to enterprise users and in line with this, they are today rolling out some additions to he product;

• New Admin Dashboard: The Stackato Admin Dashboard now offers visibility into the activity and events in a private cloud to help administrators better manage usage
• Application Monitoring with New Relic integration: Earlier this year, ActiveState announced its partnership with New Relic to provide real-time application monitoring. New Relic Standard Edition is now integrated with Stackato for Java, PHP, Python and Ruby applications and is included in Stackato’s standard pricing
• Improvements in Java deployment to Stackato from Spring Tool Suite (STS) and Eclipse: ActiveState enables Java developers to use their existing desktop development environments to deploy directly from their desktop to the cloud.

The offering is now out of private beta and is fully open to any cloud/IT administrators or developers that want to try or test a private PaaS.

Many of us have long said that PaaS holds the future of cloud services – given that large enterprises are till reluctant to move stuff en masse to the public cloud, offering such as Stackato will help broaden the appeal and usage of PaaS. the functionality they’re rolling out today will help allay the concerns and fears of potential users.

…[they] talk about differentiation in terms of user experience. But, ladies and gentlemen, I hear the same from every other PaaS vendor too

I agree with Krish and, given this frame of mind it was a little unlucky for CloudSwing to chose this day to pitch us about the news that their PaaS has gone general availability. CloudSwing is pitching itself as the;

First-ever PaaS for the enterprise with cost tracking and complete customization of technology stacks

The descriptor “first-ever” is a fairly standard item on the press releases I receive – so I wanted to do a little more into CloudSwing. The pitch that CloudSwing gives is that they provide a fully customizable selection of infrastructure, languages and technology stacks, allowing users to chose the combination of components that suite their needs. Alongside this CloudSwing includes built-in “cost management tools” to give visibility over organizational cloud spend.

So – what does this flexibility give? CloudSwing includes pre-built stacks for Java, Ruby, PHP, Javascript with platforms based on Rails, Tomcat, LAMP, node.js, and nginx. Alongside this CloudSwing can be deployed on Amazon or Rackspace and allows mixing and matching of components according to customer’s requirements.

All of which sounds uncomfortably like a relatively standard middleware offering and not so much like the enabling, exciting and automating PaaS we’ve come to know and love. An interesting addition, and one which is somewhat novel, is a built-in cost management offering that gives users visibility over their cloud spend across multiple clouds – this is similar to the functionality offered by Cloudability (see disclosure). I’d be interested to see how wide the functionality of this pend management aspect really is. Finally CloudSwing is integrated with NewRelic to give complete application monitoring to users.

All in all CloudSwing looks both confusing and much like other offerings in the marketplace, which gets me on to a comment raised by a friend opining on the space generally;

I don’t understand why anyone needs another PaaS – it’s gonna be a blood bath next year in the space (analysts are talking of things like “The Coming PaaS World War”)

I can’t help but agree… watch out.

This implementation is the first multi threaded implementation of Ruby to have full production support and hence allows end users to gain benefits of multiple concurrency. Dr Nic Williams, VP of Technology at Engine Yard also points out that “Engine Yard is the first platform to make available all stable, production-ready Ruby implementations, including JRuby, MRI, and Rubinius.”

JRuby itself is a Ruby runtime that runs on the JVM and delivers the advantages of Ruby along with full Java interoperability. Ruby applications running on JRuby benefit significantly from the JVM’s multi-threading and other performance strengths. Engineyard is also bullish about some other benefits that JRuby brings including;

1. Concise syntax (compared to Java)
2. Ruby is dynamically typed, as opposed to Java which is static
3. Ruby supports code blocks
4. JRuby ships with complete Java integration
5. Ruby supports mixins
6. Ruby classes are mutable
7. Ruby programs need no compile step

Three of the JRuby open source project’s four core contributors work at Engine Yard, including Thomas Enebo, Charles Nutter and Nick Sieger. Engine Yard also sponsors the development of Trinidad and employs its primary developer, David Calavera. Trinidad is an application server designed to run Rack applications within Apache Tomcat, a lightweight Java web server and a key enabler for JRuby support.

The bottom line is that much of the enterprise development world still lives in Java – this additional functionality allows those existing assets and programming skills to be synergized with the speed and agility of Ruby. It also sees Engine Yard further its own ambition (and, to be honest, the ambition of most PaaS players) to become a true language and framework agnostic development platform. With the recent acquisition of Orchestra, Engine Yard added PHP to its PaaS along with the original Ruby on Rails, with Java now in the fold that ticks another box, it will be interesting to see which is the next language they go for – perhaps .NET? To push the adoption of this integration, Engine Yard is offering developers 500 free compute hours for JRuby on their platform.

One player that had been a little absent during this discussion was Microsoft – that’s partly because Azure is a somewhat misunderstood beast, and perhaps also because Microsoft is prepared to wait for some of the attention around the new breed of PaaS players to wear off. Not prepared to sit and wait, GigaSpaces is today announcing the enablement of moving Java applications into Azure. The idea being that developers can move their Java applications to Azure without having to worry about code changes and the like. The GigaSpaces solution is offering;

• On-boarding of mission critical Enterprise Java/JEE/Spring applications to Windows Azure
• Continuous availability and failover, elastic scaling across the stack, and automating the application deployment lifecycle.
• Making Windows Azure services natively available to enterprise Java applications
• GigaSpaces Java in-memory data grid
• Control & visibility – Built-in application- and cluster-aware monitoring.
• Vendor neutrality

Available in Q4 this year, the integration will be attractive to enterprises with existing Java workloads that are looking to gain the flexibility and cost benefits of Azure. Deployment is really simple;

1. Prepare a Recipe – A recipe is an execution plan that automates configuration, deployment, monitoring  and scaling of your entire application stack. Cloudify recipes can automate any stack, and require zero changes to your application code. Common Java stacks, such as Spring, Tomcat, and AzureSQL have pre-prepared recipes built in
2. Deploy the Recipe

A single shell command deploys the recipe to the Cloudify manager where the execution starts. The video below gives a demo of the deployment.

The concept behind Cloudant Search is that users should be able to interact with their data instantaneously, without needing to use MapReduce jobs or complex languages. The creators of Cloudant Search also wanted to create a solution that didn’t require the set up of third party r expensive solutions. Cloudant Search is a pretty elegant solution that lets users search using syntax they can grasp quickly. As Cloudant said in their blog post announcing the public beta of Cloudant Search;

Want to easily find all the documents that contain the word “bieber”? This is the Cloudant Search query you have to write;

bieber

Want to find all the records that have “my world” in their title? Just write:

title:”my world”

How about only finding all the artists who were born in Canada in February & March 1994?

type:artist country:canada dob<date>:[1994-02-01 TO 1994-03-31]

How about people who are fan of either Justin Bieber or Justin Timberlake, that live in JBiebz’ hometown in Ontario — wait, what’s it called, Stratwood? Stratburg? Strat- something. Oh, I’ll just search it:

type:person fan-of:(justin (bieber OR timberlake)) city:strat* state:ontario

Queries are served instantly, and new records are indexed immediately upon entering into the database. Cloudant Search is baked directly into the Cloudant codebase and leverages existing, such as the Lucene indexers, CouchDB’s view indexing logic and, Cloudant’s own Dynamo-inspired distribution algorithms. Cloudant Search has also been built to be extremely extensible, users can write their own indexing algorithms, leverage Lucene tokenizers or customize the Cloudant Search indexer itself, with a bit of Java code.

All this ease of use comes with some costs however – Cloudant Search required an initial, one time indexing and, as would be expected from a search product baked into the database itself, this index takes up disk space. Cloudant have limited the availability of some search parameters to limit resource consumption.

If NoSQL truly is the way of the future, then NoSQL will rapidly see some application which face non-technical types. Plain English searches will be imperative once that happens and Cloudant have done well to preempt this requirement with their search product.

In light of the change, and having given a few months for the Heroku deal to settle in, I spent some time with Tom Mornini, CTO and co-founder and Mike Piech, vice president of product management and marketing from Engine Yard to get a general update and have a specific discussion about the free trial.

I started off by asking what the Heroku deal meant for Engine Yard – Mornini was very positive, saying that it really was a validation for the Ruby PaaS approach and has been net positive for EngineYard themselevs. I suggested that perhaps the free trial move was a way to lure some developers away from Heroku, in part due to the under-current of discontent at the acquisition. Mornini denied this – he was uick to differentiate Engine Yard’s free trial approach to the freemium approach of Heroku saying that they see Heroku as the “junk yard for applications” – that since it is free, developers just leave essentially dead applications in place because it is easier. in fact Mornini even quipped that Engine Yard previously referred to Heroku as their own trial account location, given that developers would try the Ruby PaaS concept for free on Heroku and then move to paid accounts with Engine Yard once the trial had been proven.

I then spent some time talking more about the developer ecosystem – Engine Yard are pretty damning of both Java and .NET, going so far as to say that they are both dead languages that will not survive the move to the cloud. I can’t say I agree with this contention – my friends at Expanz (among others) are doing some good work helping .NET applications (and developers) play in this brave new world.

Finally I asked what Engine Yard thought was the rationale behind the Heroku acquisition – if they were reluctant to criticize Heroku, they weren’t so reserved about force.com. Mornini suggested that the ApEx language specifically and force.com generally have been failures in the marketplace, used for little more than customization of salesforce itself. They also indicated some doubt as to how slaesforce would meaningfully integrate Heroku into what they’re currently doing – by way of proof they talked of some marketing messaging they had received as salesforce VCRM customers that was entirely ignorant of what Heroku really meant for salesforce.

In terms of the free trial – Engine Yard has done a good thing – I suspect this move will gain them significant customers and that will help build their credibility and mindshare going forwards.