Image Credit: rPath
rPath (previous CloudAve coverage) has been pushing their offering as Enterprise PaaS. Recently they briefed me on their announcement made this week around VMworld about Enterprise Cloud Adoption Framework. They unveiled this along with Cisco Systems as a way for enterprises to push their legacy applications to cloud. They are arguing that enterprises are not ready to write distributed apps but they want to use legacy apps to run on elastic infrastructure. I fully agree with their positioning that enterprises are going to take some time before they embrace distributed apps in a big way and rPath’s solution is a good fit for their short term needs. However, I DO NOT AGREE WITH THEIR PUSH THAT THEIR SYSTEM IS PAAS (Yes, I am yelling here with caps).
What they are doing is offering a solution that helps with the lifecycle management 0f platforms used by enterprises for running legacy apps on elastic infrastructure. It is not PaaS. Period. No amount of justification can put this solution in the PaaS bucket. It is a clear abuse of the term PaaS for marketing purposes. PaaS is a platform that is available to build and deploy distributed applications on top of elastic infrastructure. Offerings like Heroku, Engine Yard, AppFog, CloudFoundry, Google App Engine, Azure, etc. fall into this category. Some PaaS providers do extend their platform to support legacy apps but when we call something as a PaaS, it is those new age platforms that help run distributed apps without any operational hassles. Just like how legacy applications running on cloud doesn’t maketh a SaaS, rPath’s platform packaging solution doesn’t make PaaS. Nope, Nada, Zilch, whatever term you want to use for negative can come here to their assertion that it is PaaS.
When they briefed me, they did acknowledge that their offering is not PaaS but they are going with it because they couldn’t find another term that fits their offering. They even asked me to suggest terms which they didn’t find suitable for their offering. Whatever may be the reason, it is not PaaS. Period. PaaS has certain characteristics and rPath’s offering doesn’t fit description. rPath is not the first company to use the term PaaS when all they do is packaging everything that is needed to run applications on elastic infrastructure. Standing Cloud was using the term for a while but they realized that it is not working and they are on the right path now. As I told before this is clearly an abuse of the term PaaS and it will definitely confuse the customers who want to use PaaS. Such wrong use of the terms should not be encouraged. When IBM did that, I called them out in my post titled “IBM Pure Application Systems: It is not PaaS. Period. But ……“. I want to do it again in the case for rPath as such confusions hurt the industry as a whole. I have privately called rPath to change the name and they expressed their inability to do so. I am doing it in public and hope other analysts, journalists and bloggers ask them to do the same. Bad move by rPath and it has implications to impact the entire market segment. I am disappointed.
Disclosure: IBM is a client. Salesforce, Engine Yard, AppFog and VMware were sponsors of DeployCon 2012 along with many other PaaS vendors.
Hi Krish, looks like we miscommunicated on a few points.
1. We are always careful to call this concept of platforms on demand “EPaaS” or “Enterprise PaaS,” not PaaS. It’s a new technical concept and term for a derivative of the common PaaS concept. And it is based on what large customers are telling us repeatedly. They want IT to offer, as a service, traditional OS/middleware platforms. They aren’t ready to switch to completely new platform abstractions like Heroku.
While EPaaS isn’t a perfect term, it is an accurate description of the concept, and we received positive, welcoming feedback on it in dozens of face-to-face discussions at VMworld this week.
2. Another point we always strive to make clear: rPath doesn’t offer an EPaaS solution (or any type of cloud). We are not a cloud vendor or MSP. Customers and partners combine our OS and middleware automation technology with third-party self-service automation and IaaS to create their own EPaaS platform-on-demand solutions.
3. The focus of our briefing was not rPath’s products or even EPaaS for that matter. It was about the Enterprise Cloud Adoption Framework, the completely vendor-neutral adoption model we announced at VMworld and at cloudadoption.org. ECAF looks at common cloud patterns, including EPaaS as one instance, from both application and platform points of view. At our VMworld launch party and in many face-to-face discussions this week, response to ECAF was highly positive and engaging.
Thanks again for your feedback on the terminology. I hope ECAF and EPaaS will become more clear and compelling to you over time.
Shawn, I have no issues with ECAF as it fits your description but bringing in PaaS into the naming, even if it is with an E in the front, is causing confusion in the market and it is not good for the industry in the long term. Thanks for your response.