Since we launched the Enterprise Cloud Adoption Framework, we have seen plenty of excitement, many insightful questions, and—perhaps inevitably, when it comes to cloud—some confusion. Here are some common questions about rPath and the ECAF.
Q. Why does rPath claim to offer PaaS?
A. We don’t, and never have! We love cloud but don’t sell one. rPath isn’t a cloud vendor or a cloud service provider for PaaS or any other type of cloud.
Q. So why do you call rPath “the Enterprise PaaS company?”
A. While we aren’t a PaaS vendor or MSP, we do have an important role to play in cloud, particularly in large-enterprise private clouds. rPath’s system automation technology embeds into third-party cloud technology stacks, enabling customers to define their own software platforms and offer them as a service to internal and external customers. In other words, rPath addresses the core platform-as-a-service problem for mainstream enterprise.
rPath addresses this problem, not by offering a standalone PaaS, but with with automation that bridges the gap between pure IaaS and actively-developed enterprise application architectures.
Q. Does rPath migrate legacy apps or do P2C/V2C/C2C migration?
A. No. In general, we recommend using commodity virtualization technologies to consolidate legacy servers where possible. rPath plays no role in moving existing sytems. We’re about automating OS/middleware platform construction and maintenance for modern multi-tier enterprise apps.
Q. What does rPath offer?
A. Our main product, rPath Cloud Engine, uses version-controlled, model-driven automation to model, deploy and update operating systems, middleware, and applications for
Windows and Linux across multiple IaaS and virtualization environments. rPath Cloud Engine has a complete RESTful API, and embeds under private-cloud orchestration and self-service portals to manage all the software inside the VM.
While rPath Cloud Engine is not PaaS or Enterprise PaaS, it is often combined with elastic IaaS and third-party self-service/orchestration software to build a multi-vendor solution that we call Enterprise PaaS (EPaaS). rPath is just one of several important components underlying EPaaS implementations.
To be clear, EPaaS is a cloud approach we recommend, not a product. EPaaS means traditional-architecture OS/middleware stacks delivered and maintained on demand. One important application of our product, rPath Cloud Engine, is automating platform stacks within multi-vendor EPaaS solutions.
Q. Why the term “Enterprise PaaS?”
A. Many times we talk to enterprise architects who want OS/middleware stacks offered on demand and maintained by central IT, as a service. Their desired solution differs dramatically from the usual Silicon Valley definition of PaaS (exemplified by Heroku and CloudBees), but it’s clearly not IaaS either. We think the spontaneous emergence of these requirements at multiple customers indicates a gap in the conventional understanding of the NIST cloud model (an understanding that restricts “PaaS” to Heroku-style fully abstract PaaS). Since the compromise solution is more like PaaS than IaaS, we use “enterprise” as a modifier on “PaaS” to describe this stepping stone to full-blown PaaS.
Q. Why do you think the industry needs a new cloud adoption framework?
A. We talk to architects and lead administrators at company after company who understand cloud technology perfectly well, yet see no clear path (or precedent) for how to apply cloud technology to their world of complex, actively developed enterprise apps. And we see the EPaaS pattern emerging without reference to existing patterns. That’s why we have introduced the vendor-neutral ECAF model. It takes a fresh look at enterprise cloud from both infrastructure and app platform points of view, and through that lens, the EPaaS pattern emerges naturally as one of several valid approaches to cloud.
We also talk to CIOs who’ve invested heavily in cloud and are wondering why it still takes months to deploy applications. The reality is that most cloud efforts today are focused on infrastructure. While this is an important piece, infrastructure is only part of the story. The business runs on applications, and applications run on platforms. ECAF provides a cloud adoption model that factors in the importance of application platforms to realizing the potential of cloud.
Q. Are you for or against true PaaS?
A. 100% for! We at rPath are strong believers in PaaS. PaaS is clearly the right approach to build all-new apps (whether for direct use or to implement SaaS). However, for existing complex enterprise app projects on traditional platform technologies, true PaaS simply isn’t applicable (yet). Many analysts and industry experts agree that true PaaS is several years ahead of the enterprise market for mainstream apps. The core problem is that true PaaS achieves efficiency by restricting apps to a tightly defined platform API, while massive in-progress enterprise apps span multiple platform APIs and impose strict version and customization requirements on the underlying platform. Enterprise apps and true PaaS simply aren’t ready for each other yet.
Eventually enterprise development will port apps to PaaS (and PaaS offerings will become richer and more flexible). In the interim, we recommend EPaaS as a strong compromise between agility and compatibility.
Q. Why does the ECAF talk about standardization so much?
A. We see a mutual relationship, and a virtuous cycle, between cloud technology and standardization. Just buying cloud technology won’t help your business if you aren’t ready to standardize your use patterns; it might even make things worse. And in turn, cloud technology drives standardization. IT technology standardization has proceeded steadily but slowly for decades, but cloud is the knee in the curve—the last missing link—that enables dramatic improvement in standardization, speed, and agility.