JPMorgan Chase & Co. Unveils Private Platform-as-a-Service Deployment for its Mission-Critical Application Portfolio on Apprenda
"NEW YORK--(Apprenda, the leader in enterprise private platform-as-a-service, today announced JPMorgan Chase & Co. (NYSE: JPM), a leading global financial services firm with assets of $2.4 trillion and operations worldwide, has selected Apprenda’s platform to develop, deliver and manage its portfolio of internal applications, custom-built in .NET and Java. This significant deal is the largest private PaaS implementation to date, setting a benchmark for how enterprises modernize and deliver data-sensitive private cloud applications.")--
This announcement has a significant impact on two lines of conversation that I regularly have with customers:
1. The PaaS vs IaaS question. In general, among the customers I usually talk to, IaaS has been a nearer-term investment area than PaaS. Many of our clients have steadily been moving from simple data center virtualization projects into more formal IaaS arrangements (either within their own data centers, with service providers running them privately for them or <gasp> on public clouds. However, while application teams at our customers have dabbled in PaaS, few IT departments have made formal moves there, and few in the CIO offices have articulated investment plans there.
There are at least a couple of reasons for this focus on IaaS over PaaS. First, IT Operations has traditionally controlled IT spending and decision making, and IaaS makes sense to people with IT Ops skills and business plans. It's pretty easy to migrate, both conceptually and figuratively, from a virtualized private data center to a formal IaaS environment. We understand VMs, and how to deploy our applications on them via patterns, and have the tools and expertise to manage such an environment. PaaS is a different animal, typically requiring a significant change in management tactics and tools, which often means surrendering that mission to the PaaS provider (and, consequently, having to pay them more for that).
Second, there's the application development transformation required to move to a PaaS posture. Before now, I haven't seen many examples of large companies, with vast application teams, undertaking such a daunting program on a large scale. Not only does this require a significant shift in IT spending decision making from a "bottom-up" approach (driven by application teams) from the "top-down" approach historically driven by IT Ops, but the theoretical cost savings and agility have suffered from a lack of large-scale case studies. The application delivery efficiencies described here are eye-opening on their own, while the infrastructure efficiency gains are a surprising bonus.
2. Public Cloud vs Private Cloud. In talking to our customers about Cloud, I've struggled a bit to articulate the notion of a private cloud built on public cloud principles. If you say "public cloud" to many of our customers they recoil in horror, disgust, or both, at the oft-stated shortcomings around security, data privacy, regulatory challenges, performance, and so on. At the same time, many of them admire some of the principles of the model, such as elasticity, self-service, low management cost via standardization, etc. Consequently, many of them are building what amount to public clouds within their data centers, where they treat their application teams exactly as an IaaS provider would, and enjoy many of the IT cost savings benefits that Cloud providers do.
Once you've decided to construct such a Cloud, it's not as giant a leap to PaaS as it would initially seem. A certain amount of transformation - for both operations and application teams - is already necessary, so it would be worth evaluating how much further it is to go all the way to PaaS, and the application development cost savings that promises.
Finally, and I probably should save this for a dedicated blog entry, customers looking to promote the principles of DevOps through "Test & Dev Cloud" investments, should consider how significantly PaaS would advance the cause of DevOps. Let's talk about that soon.