FAQs about rPath, ECAF and Enterprise PaaS

Posted on by
Reply

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.

How to Predict your Private Cloud Readiness

Posted on by
Reply

Cloud readiness is more than market position and organization size. It is profoundly linked to your level of platform standardization.

At rPath (and Opsware before that), I’ve met many IT teams at customer and prospect sites. Thanks to unique business situations and unique decision histories, the world of IT has a wild variety of approaches and processes. That variety keeps IT interesting, at least for IT vendors! In particular, I think that deep variety is why cloud adoption is so uneven and hard to summarize.

Recently we’ve seen a new pattern in our prospects and customers that helps explain and predict cloud fit. Consider this way to slice the world of IT:

  • Slice 1: IT is focused on customer service and works hard to satisfy many internal customers with different requirements. R&D needs a new five-box vCenter cluster? Build it! Sales needs a new AIX box running Oracle? Done! IT builds and maintains persistently unique solutions: snowflakes.
  • Slice 2: IT provides some standard platform offerings with varying degrees of depth. Internal customers have a choice: primo service on a standard platform, or best-effort service on a custom (snowflake) platform. Need a corporate-standard SharePoint instance? No problem. The SLAs on the intranet. Need AIX with Oracle? Really? OK, but it’s going to take a while.

Of course, it’s really a spectrum. So let’s call it the PSL: your platform standardization level.

High PSL isn’t the right choice for every organization. It’s just one of many dimensions in the diverse world of IT.  The pattern we’ve spotted, simply stated is that an enterprise’s platform standardization level is the best predictor of private cloud benefits.

If you are a low-PSL organization with many snowflakes (and not planning to make dramatic changes to that situation soon), IaaS might shave a few hours off VM provisioning time but it isn’t going to change your life, and it will take forever to deploy. PaaS doesn’t make sense even on paper.

For a medium-PSL organization that already sees itself offering solutions “as-a-service,” IaaS makes a ton of sense, and so does PaaS in the form of standardized OS/middleware platforms on demand. No single Tomcat stack can fit the needs of all enterprises, but a single, specialized Tomcat stack might be fine for many internal customers at one enterprise.

What about PaaS in the form of elastic application servers such as Heroku (public), Apprenda (private), or we-should-have-called-it-PaaS-long-ago-platforms like WebLogic? As a centerpiece IT investment, that flavor of PaaS calls for high PSL because apps must be perfect framework citizens. There’s no tweaking the platform with corporate-wide, unusual requirements.

So that’s my hypothesis. Does it makes sense to you?

With that in mind, the first step in evaluating cloud is to understand your platform standardization level:

  • Low (and not increasing anytime soon)? Cloud for you will be a pile of hype! Don’t let cloud vendors waste your time.
  • Moderate? The time is ripe for IaaS and PaaS (as platform on demand). PaaS (elastic application servers) makes sense for specific projects but not for broad-based deployment.
  • High? PaaS (elastic application servers) is the simplest, cheapest, and most agile foundation imaginable.

Cloud readiness is more than market position and organization size. It is profoundly linked to your level of platform standardization. This way of thinking about cloud adoption is what we call the Enterprise Cloud Adoption Framework, recently unveiled by rPath and Cisco at VMworld. It’s a vendor-neutral model aimed to help enterprise IT decision-makers sort through the noise of cloud adoption and shine light on the paths that get you to your desired destination, steering clear of the traps.

Please visit cloudadoption.org for more information on the Enterprise Cloud Adoption Framework, and leave a comment. We’d love to know how this applies to your world today.

 

 

An Open Letter to Krishnan Subramanian of Cloud Avenue

Posted on by
Reply

It’s interesting how national politics tend to influence the tenor of public debate. I suppose the culture of cable news and political attack ads seeps into our water supply, making us all a little too aggressive with our rhetoric. It seems that the truth matters a little less than the theater of it all.

That was certainly my reaction to your screed against rPath. First, I was taken aback by the tone of the attack, which was more personal than philosophical—more of an emotional reaction than a carefully reasoned argument.

If you ask me, this sort of thing is better suited for EdOps than DevOps.

In fact, I failed to detect a logically constructed argument at all. Disguised as editorial was the type of circular argument you find in a schoolyard: You’re not PaaS because you’re not PaaS.

But beyond the head scratching about the tone and intent, I was even more baffled by what you were defending. Is PaaS so mature, accepted and widely adopted that its definition has entered some authoritative canon that should not be challenged, improved or debated? I don’t think so. Today, PaaS offers a promise that most enterprises can’t embrace—it’s too constraining and it forces you to rewrite your apps.

For most enterprises, PaaS offers a beautiful future on a distant horizon.

rPath enables an alternative—enterprise PaaS—which delivers much of the speed and agility of a true PaaS platform without the constraining tradeoffs forced by PaaS.

Does it provide the full agility and elasticity of a true PaaS platform? No. But it’s strong step in that direction, accelerating app delivery for large enterprises in a way that they can adopt today.

I recognize that it’s a nuanced argument. Let’s face it: This is complicated stuff. But we believe that there’s a conspicuous gap in the market smack between IaaS and PaaS. For cloud builders, the paradox is that IaaS isn’t enough and PaaS isn’t ready for existing enterprise apps.

That’s the gap that rPath is targeting. The good news is that it’s working. We’re growing at a steady clip and adding substantial new customers every quarter. It’s still the early days in this market, but it seems that cloud projects are catching up with the hype. And when cloud builders look to PaaS, they see the limitations of today’s offerings—which leads them to rPath.

Good news for us. Perhaps bad news for taxonomical purists. But we’re confident in where we stand and will continue to evangelize a more pragmatic—if more nuanced—position on PaaS as a continuum, rather than a rigidly defined thing.

Rodrigo Flores wrote a great article recently that reflects this sentiment that PaaS requirements follow a continuum. As he suggests, how you think about PaaS will vary based on who you are.

In fact, cloud thinking in general should follow a continuum; enterprises are complex, often cumbersome entities whose requirements run the gamut.

Such was our thinking behind the Enterprise Cloud Adoption Framework, which we announced early this week at VMworld. It’s a tool for thinking through the graduated progression of a cloud transformation by evaluating the benefits and tradeoffs of enabling technologies—including PaaS—as you mature along the cloud journey.

Krish, architectural transformations aren’t black and white—and neither are categories of enabling technologies in the dawn of a market. It’s far too early in this game to let dogma creep in.

How you think about these categories will—and should—vary based on who you are. Not based on artificial definitions that follow parameters set too rigidly before their time.

Be sure to have a closer look at the Enterprise Cloud Adoption Framework (www.cloudadoption.org). Then, let’s engage in a substantive debate that benefits our ecosystem and leave the yelling to the nattering nabobs on cable news networks.

Understanding Enterprise PaaS

Posted on by
Reply

It’s nice to see cloud terminology settle down a bit. One term has recently hit rPath ears from partners and prospects with a consistent definition, and I think it’s one you’re going to hear more and more.

The term is Enterprise PaaS, and the best definition I’ve heard is this: Enterprise PaaS delivers on-demand, transparent middleware/OS platforms for the current generation of enterprise apps.

To understand why such a thing makes sense, let’s look at a prototypical enterprise app, “MobyApp,” combining typical aspects of apps we’ve seen at large enterprises of all kinds.

BYO PaaS

Posted on by
Reply

I spend a lot of time talking to customers and prospective customers about how to deliver on the benefits ascribed to cloud computing within their enterprise.

Often, I find myself talking to folks that don’t care for the term “cloud” at all, given how over-hyped the term has become. Our conversations focus instead on the benefits they are seeking to deliver with improved business agility derived from improved application delivery. Naturally, given rPath’s role in the automation space, we spend a lot of time talking about software delivery and how to most effectively impact those processes.

So you’d expect terms like IaaS and PaaS to turn up a lot, wouldn’t you? And they do — but not the way many industry pundits might expect.

Who’s calling what, what in the cloud

Continue reading →

Never trust a vendor bearing scripts

Posted on by
Reply

I’m sure there’s little doubt about where folks at rPath stand on the topic of scripts. We’ve railed against them over the years, because we believe they’re a flawed approach to automating complex software deployment, configuration and change.

We think scripts create false comfort that tricks you into believing you’ve introduced control and efficiency when what you’ve actually introduced is more complexity to manage.

So, why are we bringing it up again? Because the darn things won’t go away! :) Continue reading →

CloudStack Appliances

Posted on by
Reply

CloudStack has been in the news a fair bit recently, and for good reason: Citrix re-homed the open source cloud infrastructure under the Apache umbrella and clearly parted ways with OpenStack. I’m not going to re-hash the various arguments being made for and against this move (others have — and continue to do so — with great gusto). You can also read my colleague, Shawn Edmondson’s, blog on the topic.

Instead, I wanted to highlight a piece of work we did in support of the CloudStack changes that I think has technical merit and highlights at least one current technical difference between CloudStack and OpenStack.

Continue reading →