While helping users host applications on five public clouds was one of Appfog’s main selling points, “it’s also become increasingly resource-intensive to maintain so many instances of our infrastructure,” AppFog CEO Lucas Carlson wrote in the email. He referred users to the AppFog Console, which will enable them to clone their application onto new target infrastructure.

Carlson could not be reached for comment Monday morning, but, Generally speaking, PaaS adoption by business users has been sketchy at best. Many developers love PaaS because it makes development and testing very easy, but once the applications are built, many companies prefer to run them in-house (i.e., not on a public cloud). And, more specifically, there have been rumors  that AppFog was seeking investment or even a potential buyout.

AppFog tried to end-run that argument by allowing deployment on private clouds as well, but it’s unclear how well that effort has gone. There has also been angst among companies, including AppFog, that built their PaaS offerings atop the Cloud Foundry framework. That was true when Cloud Foundry resided under VMware, and remains true since it was spun off to Pivotal, which is now selling its own Cloud Foundry PaaS that competes with third-party options.

I’ve reached out to Carlson for comment and will update this story when he responds.

Update: Carlson would not comment on rationale for dropping Rackspace but did say that AppFog has hundreds of paying customers and that his goal is to “build a big company in a big space.” AppFog still supports Amazon Web Services in three regions — North America, Europe and Asia as well as HP’s cloud.

This story was updated at 7:25 a.m. PST with Carlson’s comment.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• The fourth quarter of 2012 in cloud
• Cloud computing infrastructure: 2012 and beyond
• A near-term outlook for big data

The addition of “external committers” to the project could ease tensions brewing among some Cloud Foundry backers — companies that built their own PaaSes atop the Cloud Foundry framework.

But then again, the fact that Pivotal is now selling software/support could open new areas of contention with partners that may want to do the same thing. Such is the life of an open source project where coopetition is the rule of engagement.

As set forth in a new blog post, Cloud Foundry is going to add “full-time external committers” to the process. Governance and openness had been an ongoing issue with the PaaS project according to an exec with one Cloud Foundry vendor. “We just didn’t have any visibility into what was going on [inside the project],” he said.

He would like to see the whole effort turned over to a vendor-neutral foundation for management, as Rackspace did with OpenStack and IBM did with Eclipse. That didn’t happen here but the addition of outside committers is a step in the right direction and, to be fair, some folks in the OpenStack community complained that Rackspace took its sweet time to make its move.

Lucas Carlson, CEO of AppFog, another Cloud Foundry backer, said he’s seen other good signs from Cloud Foundry. He is thrilled, for example, that the code is back on a public Github repository. It had been removed some time ago. “We see it as a sign of a more open approach from the Cloud Foundry team,” he said.

Collaborators or competitors: a fine line

Some history: The worry initially was that Cloud Foundry, despite all the talk of open-source goodness and just plain openness, was too closely associated with one vendor:  VMware. Then, when VMware spun it off to a VMware-and-EMC-backed entity (Pivotal) there was more uncertainty about its future.

There was also concern that some of the Cloud Foundry players were going to take the work they’d done and fork the project altogether because of the lack of visibility into Cloud Foundry plans. Under this definition a “fork” — and yes, I’ll get hate mail on this — that could lead to the creation of several not-always-compatible versions of a project.

For some in the open source community, there is no such thing as a bad fork.But for mere mortals there is worry about an actual ecosystem divergence when many members of the same community start getting their updates from different places instead of relying on a central source, in this case Pivotal. To be fair, there is analogous concern that several versions of OpenStack backed by many vendors — some contributing back more than others — will lead to the same problem. At any rate, that’s the kind of angst Pivotal is trying to lay to rest.

In Thursday’s blog post, James Watters, head of product for Cloud Foundry, reiterated that the project will support multiple clouds, promising “open interfaces, support and continued development on AWS, OpenStack, vCloud and vSphere environments.”

And, he maintained, that the addition of outside committers was always a goal:

” … we are engaged with several organizations about putting dedicated resources on the extended engineering team –we believe this to be a very important step forward. The scale of these external investments is significant and a major milestone in our growth. The heart of Cloud Foundry, however, really comes from individual community contributions and users, so of course, we invite you to join us. All you need to do is send a pull-request.”

Going  orward it will be interesting to see what engineers from which companies will be added as committers. For now, the naysayers appear to be relieved at what Cloud Foundry has done.

Watters endorsed Cloud Foundry’s existing “corporate sponsored, Apache 2 licensed, pull request driven approach” as the right way to go. The outside committers will open up the process going forward, but he also left the door open to further changes. He wrote: “The massive growth of the community and ecosystem requires mediating a diverse set of needs and we will always be open to other governance models for the project in the future.”

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Platform as a Service in 2012
• Infrastructure Q4: Big data gets bigger and SaaS startups shine
• The fourth quarter of 2012 in cloud

CloudBees CEO Sacha Labourey

The goal is to make it easy for developers to develop what they want using CloudBees — taking advantage of its Jenkins-based continuous integration capabilities –  to deploy what they build where they want.

CloudBees CEO Sacha Labourey said his company focuses on the whole application life cycle, not just development, not just deployment. In October, the company announced a similar deal that lets its users deploy on Google App Engine.

“If you’re a GAE user you can subscribe to our services… it’ s not that we’re moving to Cloud Foundry as a company, it’s just that customers have freedom of choice. If you prefer GAE or Cloud Foundry to us for deployment, that’s fine,” he said.

CloudBees users wanting to deploy to Cloud foundry can sign up here. 

Here’s the thing about PaaS: Many developers love them because of the freedom and flexibility they offer when it comes to actual development. Moves like this one mean that deployment options for their finished code (if there is such a thing) are opening up as well.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• The fourth quarter of 2012 in cloud
• Platform as a Service in 2012
• PaaS market accelerators, 2012–2013

The attraction of the multi-vendor Cloud Foundry effort is that, in theory, it would provide customers an array of compatible PaaSes from different vendors. If they don’t like their experience with one, they can move their code elsewhere. But now the prospect of a “fork” looms with some other vendors thinking of splitting off and doing their own iterations. Worst case scenario: that could negate any promise of compatibility. And that raises the old bugaboo of vendor lock-in which even PaaS providers say has restricted business demand for PaaSes.

Some background: late last year, VMware turned over the Cloud Foundry effort and related projects to the Pivotal Initiative spinoff. Since then some of the third-party Cloud Foundry crowd have complained that they have not gotten information  they need from Pivotal. And, they worry that Pivotal or VMware will push its own commercial, competitive version of Cloud Foundry. And so they privately discussed forking the Cloud Foundry code. Any fork or forks raises the specter of a fractured standard.

Sinclair Schuller, CEO of Apprenda, a non-Cloud Foundry PaaS, raised a ruckus last week when he posted his take on the impact of any fork or forks on Cloud Foundry. (Long story short: it will be bad for customers, Schuller wrote.) That caused a kerfuffle which Redmonk analyst Stephen O’Grady addressed in his  blog post. O’Grady tried to downplay the negative impact of forks, writing:

“We reject the notion that forking is an undesirable outcome. Forking is, to the contrary, provably beneficial to modern open source projects – at least from a developmental perspective.”

But O’Grady also conceded that, because Cloud Foundry is not licensed under the General Public License (GPL) — as Linux was — it faces different issues;

“Compatibility, ultimately, is the key to determining whether the forks which are so beneficial to development are a problem for customers. Java, for example, had multiple distinct implementations, which ensured competition and thus continued innovation to benefit customers.”

In his own blog post, cloud pundit Ben Kepes cites “tensions in the Cloud Foundry world, ” and maintains the possibility of a fork should concern customers.

“Quite simply a fork, or even worse multiple forks, too early in a project is a sign of bad governance and questions the validity of the entire initiative. Let me reiterate – these are very early days and any doubt that factions in the community sow in end users minds are wildly damaging to the community. This is especially the case since, from what I’m hearing, some of the conversation around forking is happening for all the wrong reasons – it comes down to vendors making the right decisions for the right reasons.”

I’ve asked Cloud Foundry and some of the third-party PaaS providers for comment and will update this when they get back to me.

Photo courtesy of  Flickr user Marshall Astor – Food Fetishist

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Platform as a Service in 2012
• Cloud computing infrastructure: 2012 and beyond
• Amazon’s DynamoDB: rattling the cloud market

Amazon bests Apple in consumer appeal

Amazon is the most widely admired U.S. company, edging out last year’s favorite, Apple, according to the new Harris Interactive Poll on most reputable companies. The online book seller and cloud services provider ranked in the top five in five of six criteria and its combined  reputation quotient or “RQ” score was 82.62. Apple scored 82.54. Harris takes factors including quality of products and services; workplace environment; social responsibility; financial performance; and emotional appeal to calculate the RQ, querying some 14,000 respondents.

Any score over 80 is viewed as excellent. Amazon got nearly 100 percent positive rankings on “all measures related to trust and tremendous support  and “word of mouth,” according to Harris’ summary. Those words must come as music to Amazon CEO Jeff Bezos’ ears. He continuously champions Amazon’s customer service and low pricing as key to its success — although some bearish Wall Streeters might differ with him on that. (The top 10 “RQ” companies are listed below.)

.

To be fair, Amazon’s top score is more related to its consumer-focused e-commerce service than its less visible (to consumers anyway) Amazon Web Services IT-services-for- rent business

Other fun facts from Harris:

• Bank of America remained in Harris’ bottom 5 companies, but also saw the largest reputation rebound of 6 points.
• Google was the only other tech company in the top ten with an RQ of 81.32
• Microsoft ranked 15th an RQ of 76.46
• Dell came in 26th with 73.05
• IBM logged in at 28th at 72.21
• Hewlett-Packard ranked 34th with  70.01
• Facebook, new to the list, debuted at 42nd with an RQ of  65.63

NTT climbs aboard Cloud Foundry

NTT, Japan’s gigantic telco is making Cloud Foundry the basis of its upcoming Platform as a Service. It  joined Cloud Foundry Core,  a push launched last year by VMware to make its open-source Cloud Foundry the basis for a slew of compatible higher-level PaaSes. And a bunch of companies – AppFog, ActiveState, Uhuru, and Tier 3– now all offer Cloud Foundry-based platforms.

According to a February 12 NTT guest post by Hideki Kurihara, product lead for NTT Communications’ Global Cloud Services on the Cloud Foundry blog, the telco is reacting to customer demand for an agile, flexible development platform:

“But we also hear concerns about vendor lock-in and ability to meet the needs of a complex enterprise environment. We chose to build Cloudⁿ PaaS on top of Cloud Foundry because of its multi-cloud nature, ability to integrate with existing assets, and solid API foundation for adding management and monitoring features. Using Cloud Foundry as the base, we are extending Cloudⁿ PaaS for developers and enterprise customers in Japan. Together with other Cloud Foundry Core partners, we are delivering cloud portability to Japanese users as well as global users of Cloud Foundry.”

The Cloud Foundry Core Definition baseline includes runtimes and services built on Java, Ruby Node.js, MongoDB, MySQL, PostreSQL, RabbitMQ and Redis.

VMware launched Cloud Foundry two years ago  but is now in the process of spinning that work off into the Pivotal Initiative, a move which has some members of the Cloud Foundry ecosystem worrying about what changes could be in store.

States rethink cloud computing sales taxes

Fearing that cloud computing companies will flee for business friendlier environs, several states are moving to remove sales taxes levied on cloud computing services. Last week, a legislative panel in Idaho agreed to hammer out that topic once and for all, according to the Idaho Spokesman Review. The Idaho House’s tax committee said it will introduce legislation that will classify cloud computing services as, well as services, not tangible physical goods the sales of which are taxed.

Nineteen years ago, a state law held that software is taxable regardless of how it is delivered.

Meanwhile, cross country in Vermont, Governor Peter Shumlin is also working to remove a state tax on cloud services, according to VTdigger.com. 

Shumlin’s administration “backed a retroactive cloud computing moratorium that reimbursed businesses for about $2 million in taxes that had already been collected. This time, the proposal would make the exemption permanent,” according to the publication.

Removing yet another source of revenue from cash-strapped states is bound to stir up controversy however.

Feature art courtesy of Shutterstock  userGena96

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Cloud computing infrastructure: 2012 and beyond
• Infrastructure Q2: Big data and PaaS gain more momentum
• Infrastructure Q1: IaaS Comes Down to Earth; Big Data Takes Flight

These two patterns are described well in this recent post from Neal Ford, self-described “Director, Software Architect, and Meme Wrangler” at systems integrator ThoughtWorks:

In my keynote, I defined two types of extensibility/programability abstractions prevalent in the development world: composable and contextual. Plug-in based architectures are excellent examples of the contextual abstraction. The plug-in API provides a plethora of data structures and other useful context developers inherit from or summon via already existing methods. But to use the API, a developer must understand what that context provides, and that understanding is sometimes expensive…The knowledge and effort required for a seemingly trivial change prevents the change from occurring, leaving the developer with a perpetually dull tool. Contextual tools aren’t bad things at all – Eclipse and IntelliJ wouldn’t exist without that approach. Contextual tools provide a huge amount of infrastructure that developers don’t have to build. Once mastered, the intricacies of Eclipse’s API provide access to enormous encapsulated power…and there’s the rub: how encapsulated?

In the late 1990’s, 4GLs were all the rage, and they exemplified the contextual approach. The built the context into the language itself: dBASE, FoxPro, Clipper, Paradox, PowerBuilder, Microsoft Access, and similar ilk all had database-inspired facilities directly in the language and tooling. Ultimately, 4GLs fell from grace because of Dietzler’s Law, which I defined in my book Productive Programmer, based on experiences by my colleague Terry Dietzler, who ran the Access projects for my employer at the time:

---

Dietzler’s Law for Access

Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create, and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions, and users always want 100% of what they want.

---

Ultimately Dietzler’s Law killed the market for 4GLs. While they made it easy to build simple things fast, they didn’t scale to meet the demands of the real world. We all returned to general purpose languages.

Composable systems tend to consist of finer grained parts that are expected to be wired together in specific ways. Powerful exemplars of this abstraction show up in *-nix shells with the ability to chain disparate behaviors together to create new things. A famous story from 1992 illustrates just how powerful these abstractions are. Donald Knuth was asked to write a program to solve this text handling problem: read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies. He wrote a program consisting of more than ten pages of Pascal, designing (and documenting) a new algorithm along the way. Then, Doug McIlroy demonstrated a shell script that would easily fit within a Twitter post that solved the problem more simply, elegantly, and understandably (if you understand shell commands):

tr -cs A-Za-z '\n' |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q

I suspect that even the designers of Unix shells are often surprised at the inventive uses developers have wrought with their simple but powerfully composable abstractions.

Ford goes on to describe the pros and cons of each approach in much more detail, but the key conclusion he reaches is, I think, critical to understanding how one should develop the tools and tool chains that drive new IT models:

These abstractions apply to tools and frameworks as well, particularly tools that must scale in their power and sophistication along with projects, like build tools. By hard-won lesson,composable build tools scale (in time, complexity, and usefulness) better than contextual ones. Contextual tools like Ant and Maven allow extension via a plug-in API, making extensions the original authors envisioned easy. However, trying to extend it in ways not designed into the API range in difficultly from hard to impossible, Dietzler’s Law Redux. This is especially true in tools where critical parts of how they function, like the ordering of tasks, is inaccessible without hacking.

Ford’s distinction is one that finally helps me articulate a key concern I’ve had with respect to Platform-as-a-Service tools for some time now. In my mind, there are primarily two classes of PaaS systems on the market today (now articulated in Ford’s terms). One class is contextual PaaS systems, in which a coding framework is provided, and code built to that framework will gain all of the benefits of the PaaS with little or no special configuration or custom automation. The other is composable PaaS, in which the majority of benefits of the PaaS are delivered as components (including operational automation) that can be assembled as needed to support different applications.

Contextual PaaS

Examples of contextual PaaS include the original releases of Google App Engine, Heroku and other “first-generation” PaaS systems that asked the developer to adhere to specific architecture and consume PaaS-specific classes in the application itself. These systems were incredibly powerful for building applications that were variations of what these frameworks were designed to do, but began to fail quickly for applications that fell outside of that domain.

The classic example is Google App Engine’s limit of 30 seconds for any backend request to complete. Great if you were building a Facebook game, but a requirement that eliminated its use for many multi-step transactional applications. Of course, there were ways to deal with those situations, as well, but they were mostly complicated and added risk to the system.

There is a parallel here with the 4GLs of the late 1990s that Ford talks about in his post. At that time, I worked for Forte Software (acquired by Sun Microsystems in 1999), which built a 4GL development and operations environment for distributed application development. We had a business model where we relied heavily on systems integrator partners to help our customers deliver these often sophisticated applications, and every one of those SIs eventually built a framework environment to make building complex applications “easier.”

The problem? Almost every customer that used one of these frameworks had a requirement (or many) that the framework didn’t handle well. This resulted in either the SIs scrambling to modify their frameworks to support these requirements — inevitably resulting in the framework being much less “easy” to use — or the customer bypassing the framework all together for those needs, resulting in an application that was harder to debug and operate.

Composable PaaS

Composable PaaS systems, on the other had, do much less to anticipate the architecture or functionality of the application built on it, and do much more to simplify the assembly of services, including underlying infrastructure, automation, data sources, specialized data tools, etc. I think the classic example of a composable PaaS is Cloud Foundry, the open source PaaS effort from VMware that’s now part of its Pivotal Initiative spinoff. Modern versions of Heroku, Engine Yard, CloudBees and other also exhibit more of this approach than “first-generation” PaaS systems.

An old, but illustrative, Cloud Foundry diagram.

Perhaps most importantly, however, there are open source “build” tool chains being deployed directly to infrastructure services that exhibit a purely composable approach toward delivering and operating applications. Combining GitHub with Jenkins with Gradle with AWS CloudFormation and Autoscaling and so on gives a fully automated, flexible “platform” for application development and operations — everything you want from a PaaS. The catch, of course, is that you’ll need to assemble and maintain that tool chain over time (rather than letting the PaaS vendor do it for you).

Now, take the concept a step further. Imagine a deployment environment that delivers a wide variety of these individual tools and components and simplifies the process of creating tool chains on demand from them. Imagine that environment would let each development team choose from known tool chain “patterns,” but modify them as they see fit for each project. This, I believe, will be the ultimate general purpose PaaS success, not some hard-and-fast framework-based PaaS.

The concept of composable and contextual applies to a lot more than PaaS and cloud, of course. And it is important to note that it’s not an either/or choice, much like stability and resiliency. Parts of an IT environment should be composable, but there will always be elements where the relative stability of contextual extension makes more sense. And composable systems can leverage API-driven systems that themselves are designed primarily for extensibility via contextual approaches.

The key is to think about each system from the perspective of how it will be used, and to target its extensibility mechanism based on needs. Just remember, however, that choosing a contextual path will dictate a lot more about how your system could be used in the future than a composable approach would.

I’d love to hear your thoughts, either in the comments below, or on Twitter, where I am @jamesurquhart.

Feature image courtesy of Shutterstock user Nenov Brothers Photography.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

At that new outfit, Nielsen will report to Paul Maritz, who will head up that cloud computing/big data spinoff of EMC and VMware, according to a document filed with the Securities & Exchange  Commission.

The move, which according to the SEC document, was official as of December 5 but not widely known. But it comes as little surprise because Nielsen — who was most recently co-president of VMware’s application platform group – was heavily involved with  Cloud Foundry, one of the VMware technologies turned over to the new spinoff. And he and Maritz go way back — they worked together at Microsoft more than a decade ago.

Having said that, there is concern of a continued brain drain at VMware. CTO Steven Herrod, a widely respected exec, is leaving for a VC gig at General Catalyst Partners.

With Nielsen’s move, another piece of the Pivotal Initiative puzzle falls into place.  Personnel from VMware and EMC are shifting around to staff up this new effort which combines IP from both parent companies. Some GreenPlum big data know-how and Pivotal Labs agile development from EMC as well as Cloud Foundry PaaS, Cetas analytics, and vFabric from VMware are flowing into the spin off.  Mark Lucovsky, who helped spearhead Cloud Foundry, is staying at the VMware mothership.

EMC, VMware and Pivotal Initiative folks will talk more specifics about the cloud and big data spin off March 13 at a NY event, VMware CEO Pat Gelsinger said on Monday’s earnings call. 

Feature photo courtesy of Flickr user Luke Kilpatrick

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• The fourth quarter of 2012 in cloud
• Infrastructure Q2: Big data and PaaS gain more momentum
• Cloud and data third-quarter 2012

Williams appears tightly aligned with Cloud Foundry —  one of two customers mentioned on his web page is the Pivotal Initiative and he is working out of the Pivotal Labs office in San Francisco. Pivotal Labs, now part of EMC, is contributing technology to the Pivotal Initiative. Confused? Sorry.

Stark & Wayne is thus far a one-man show. According to  Williams blog post, the company name comes from “the two most famous fictional tool creators – Tony Stark and Bruce Wayne. Every developer can be a super hero. You just need the right tools. Batmobile optional.”

The goal of the startup is to help companies adopt PaaSes. And that’s important — many developers within companies love the freedom and flexibility of building and deploying their applications on a third party pay-as-you-go platform but often their corporate IT overlords are not so enamored of the model. That’s because sticky questions arise if, for example, your PaaS of choice goes away. 

Per Williams’ blog post announcing his move:

“If you’ve used Heroku for your pet projects, then we want to bring you Cloud Foundry for your work projects. We also want to work with you on your projects. If your workplace cares about continuously improving development and operations, then you qualify.”

VMware pushed Cloud Foundry as an open-source foundation for other PaaSes  like AppFog, Uhuru, Stackato, and others. Presumably the Pivotal Initiative will continue down that path although it’s not saying.  Salesforce.com’s Heroku is another market leader. It is unclear how much traction Engine Yard has relatively speaking although Oracle bought a stake in it in November.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Platform as a Service in 2012
• PaaS market accelerators, 2012–2013
• Cloud computing infrastructure: 2012 and beyond

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Infrastructure Q1: Cloud and big data woo enterprises
• Infrastructure Q1: IaaS Comes Down to Earth; Big Data Takes Flight
• Takeaways from the second quarter in cloud and data

The new option, available from AppFog’s site, costs $50 per user for 500MB to 4GB of database storage and 50GB of data transfer. In July, Portland, Ore.-based AppFog launched its ambitious cross-cloud PaaS effort including a free  version for up to 2GB of RAM. Additional monthly plans with more memory started at $100 for 4G, $380 for 16GB and $720 for 32GB. The free version is still available.

Each MySQL and PostgreSQL database instance comes with 500MB of storage; each Redis and RabbitMQ instance comes with 10MB of RAM and 6 concurrent connections; free custom domains and the fastest servers from whichever cloud infrastructure the developer selects.

AppFog CEO Lucas Carlson said he made the move in response to developers who want more storage and other resources.  ”When developers told me that our plans were not quite right for their needs I knew i had to make it better,” Carlson said via email.

The problem with PaaS is that while developers love the freedom to design and develop on that infrastructure, many companies still don’t want to deploy on an outside platform. Another issue is VMware’s decision to spin off Cloud Foundry to a new corporate entity. That has sparked concern about how open the Cloud Foundry development process will be going forward. VMware and parent company EMC have said they won’t discuss details of its spinoff plans until early next year, leaving Cloud Foundry-dependent PaaSes in a bit of a quandary.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• The fourth quarter of 2012 in cloud
• Platform as a Service in 2012
• Takeaways from the second quarter in cloud and data