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

So he and his CTO, Alvaro Everlet, spun out a new company to build a platform of software and infrastructure so others could connect devices without having to reinvent the same wheel they had invented so many times before. They called the startup Carriots, and it’s now in the middle of raising a first round of funding.

Like Electric Imp, Carriots, a Madrid-based company, wants to make it easy for people to build out services for connected devices. Electric Imp provides the cloud service as well as an SD card with built-in connectivity. Carriots provides the cloud service, essentially a platform as a service, or PaaS, for the internet of things.

Castillo explained that developers can build the physical product and then link it to a software-based service on the Carriots platform using a few lines of Groovy, a Java-based language. Carriots charges companies for the number of devices they connect to the platform, with the first 10 devices being free.

Carriots has 10 employees and plans to double in size this year, as well as open a U.S.-based office to support growing interest in connected devices and services here. As I see more and more startups eyeing the internet of things, providing some type of back-end platform helps open the field up to a variety of developers who might have an idea but less of a technical background. But I also wonder what devices will work with this type of model.

For example, a consumer-facing device that sells millions might rack up some huge bills, so the team might be better off building out its own infrastructure, especially if it wants to provide access to data via an API. For companies selling to businesses, or with fewer devices, such as Pantry, the startup I wrote about recently that’s building a connected, refrigerated vending machine, it may make more sense.

Of course, if Amazon Web Services has taught us anything, it’s that even large companies like Netflix can benefit from outsourcing their infrastructure if it’s not core to their value proposition. Perhaps the growth of platforms for the internet of things will produce similar examples even as it enables new businesses to come to the fore.

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

• Cloud computing infrastructure: 2012 and beyond
• Infrastructure Q1: Cloud and big data woo enterprises
• A near-term outlook for big data

In a blog post, Heroku’s Zeke Sikelianos said the platform-as-a-service oufit had been seeing great demand from the non-U.S. world, and its second region was now live as a public beta, following a private beta with customers such as Swedish television network TV4.

“Deploying our app closer to our users in Heroku’s Europe region gave us a 150ms improvement in web performance. Based on this win for our users, we’re moving all of our apps to the Europe region,” the post quoted TV4 CTO Per Åström as saying.

The European region, which runs out of Amazon’s Irish data center, comes with all the same features as the U.S. region. Over 60 add-ons are already available for the region, such as Heroku Postgres and ClearDB, and others are on their way. The company has introduced heroku fork to its command-line interface in order to ease the migration of apps from the U.S. region, by copying relevant data and configuration variables.

Data location

European data protection laws are more stringent than those in the U.S., so the two parties have set up a Safe Harbor program for American companies whose services involve the handling of EU citizens’ personal data. Heroku still isn’t part of that program, so technically it’s still not kosher to run services for EU citizens on the platform, even though it’s now using an EU data center.

“Heroku is not yet a registered participant in the Safe Harbor program,” the post read. “We’ve laid the groundwork for becoming Safe Harbor certified and expect to have it soon.

“The Europe region public beta is designed to let you build high-performance apps for European users. It does not currently address data residency or jurisdiction concerns. You should assume that some portions of your app and its data will be in, or pass through, data centers located in the U.S.”

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

• Examining open hybrid cloud options for the enterprise
• Platform as a Service in 2012
• Emerging trends in the non-relational database market

A report I wrote for GigaOM Pro in June 2010 (subscription req’d), entitled “Defining Internal Cloud Options: From Appistry to VMware,” seems like a good starting point for a private-cloud startup edition of “where are they now.” Ignoring the public companies on the list for the time being (with the exception of CA), here’s what has happened to the private companies and startups.

1. Abiquo: Abiquo has a new CEO, a tight partnership with NEC around selling to service providers and appears focused on the European market. The company raised about $14 million in 2010, but hasn’t really made a lot of noise stateside since then.
2. Appistry: Appistry made a huge shift in August 2011 and it now positions itself as a platform for running high-performance applications in areas such as life sciences, defense and financial services. Its biggest area of focus is genomics, where it is even developing new methods for analyzing genomes.
3. CA: CA bought a bunch of cloud startups in 2009 and 2010 — Cassatt, 3Tera, Oblicore and Nimsoft among them — but it has been essentially silent since then in terms of real innovation. Maybe these acquisitions are driving big business, but I was expecting a more-visionary strategy in terms of fusing them into a cohesive and forward-looking whole.
4. Cloud.com: Winner!!! Cloud.com had big-name users and workable technology, and it sold itself to Citrix for more than $200 million in 2011. It has since launched an open source competitor to OpenStack called Apache CloudStack and appears to be doing good business.
5. Elastra: Elastra is no more.
6. Enomaly: Enomaly’s products still technically exist, but Virtustream bought the company in 2011 with the primary goal of repurposing its intellectual property in the realm of cloud federation and gaining a toehold in China.
7. Eucalyptus Systems: If you ask CEO Marten Mickos, everything is great with Eucalyptus, and its whopping $55.5 million in venture capital (including a $30 million round in April 2012) and tens of thousands of downloads of its Amazon-compatible cloud softwware are proof. Ask anyone else and they’ll likely tell a different story.
8. GigaSpaces: GigaSpaces appears to be doing well enough, although it was around well before the term “private cloud.” It has always been much more about its in-memory data grid tech and apps that need dynamic scalability, although it does now offer a Platform-as-a-Service product that’s somewhat disconnected from the legacy business.
9. Joyent: Joyent has always been respected for its engineering chops, although rumors sometimes swirl about how much business the company — which has raised an incredible $115 million — is actually bringing in. Still, it continues to improve its public and private cloud offerings and has landed some big-name users.
10. Librato: Librato looks to have abandoned its resource-management product line to focus on measuring stuff — sensors, server use, whatever.  It wears that hat well, and Heroku is among its loyal users.
11. LongJump: In hindsight, LongJump’s business was not actually a great fit for that 2010 report, and its business appears about the same: you build apps in a user-friendly setting and they can run on LongJump’s infrastructure or your own.
12. Morphlabs: Morphlabs is the master of pivots, although it’s still hanging around and pushing out new products. Now an OpenStack-based cloud-software vendor, it released a new service-provider-focused platform called mCloud Osmium in February.
13. Nimbula: Nimbula, as noted above, is now part of Oracle in a move that is widely believed to be an “acquihire” situation, although neither company will comment on the details.
14. Platform Computing: IBM bought Platform Computing in October 2011 and appears to have refocused the company around its HPC roots. Not that that’s a bad thing — Platform was a $72 million company on its own in a niche market, and I’d guess IBM paid a fair price for it.
15. Virtustream: Another winner! Virtustream has been on fire since 2010 (actually buying up Enomaly) and looks to be the darling of the enterprise cloud space. It’s primarily a public cloud provider, but it has a strong private/hybrid cloud business that ties Virtustream back to customers’ data centers.
16. Voxel: Voxel, whose main business was a public cloud offering, got acquired for $30 million by managed hosting provider Internap in January 2012.

OpenStack is what happened to the private cloud market and forced so many acquisitions, pivots and even one closure. Users, investors and everyone, really, were waiting for some promise of cloud interoperability and portability (aka something other than Amazon, VMware or Microsoft) and OpenStack delivered it. Further, for the service provider community — which has arguably bolstered the sales of private cloud software since its inception — OpenStack provided a relatively engineering-free path to public cloud offerings (compared with building their own from scratch, that is) without fear of being at the mercy of a startup that might fold tomorrow and take its core technology with it.

I haven’t run the numbers, but I’d be willing to bet the majority of venture capital going toward “private cloud” in the past two years has gone to OpenStack-based startups. We’ve also seen nearly every large software vendor pin its cloud ambitions to OpenStack to some degree — Cisco, HP, IBM and Red Hat to name a few. Even Rackspace is now in the private cloud game thanks to OpenStack.

For buyers, a large, well-heeled and deep-pocketed community has to be more appealing than a disparate collection of startups all doing their own thing.

L to R: Marten Mickos of Eucalyptus, Chris Kemp of Nebula (an OpenStack startup) and Sameer Dholakia of Citrix at Structure 2012.
(c) Pinar Ozger

Who’s not doing OpenStack (at least in any meaningful way)? VMware, Microsoft, Amazon Web Services — all companies with their own intellectual property, huge user bases and lots of money to back their visions. They all also have strong public cloud connections (some, obviously, stronger than others).

The cloud startups from 2010 that are still arguably thriving today share similar characteristics. They’ve been big on engineering, won major customers early on and raised a lot of money to help them maintain through any tough times. All but Cloud.com, now part of Citrix, have a very prominent public cloud component, too — which appears critical for a truly seamless hybrid environment — but it has staked out its own claim as the anti-OpenStack.

All of the aforementioned companies are/were doing infrastructure as a service primarily, but we’re already seeing a similar thing happen in the platform-as-a-service space thanks to Cloud Foundry. Providers that weren’t part of that community are jumping on board, and it’s just a few established holdovers that look like they’ll be able to push forward without riding Cloud Foundry’s coattails.

Perhaps this is telling for how the future of anything at the infrastructure or platform layers is going to play out. You’re either really early and really good, or you wait for an open source project — OpenStack, Cloud Foundry, Hadoop, Open Compute, OpenFlow, etc. — and try to build on that. There’s following fast, and there’s following smart.

Feature image courtesy of Shutterstock user Alexey Repka.

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

• Defining Internal Cloud Options: From Appistry to VMware
• Infrastructure Q1: IaaS Comes Down to Earth; Big Data Takes Flight
• Infrastructure Q2: Big data and PaaS gain more momentum

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

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.

ENISA is the agency charged with co-ordinating the fight across Europe, against various worrisome things prefixed with “cyber-”: “cybercrime”, “cyber attacks” and so on. Europe’s new cybersecurity strategy would make ENISA what security expert Ross Anderson recently called “a classified network of military and intelligence agencies”, but the fact remains that the agency is a relatively impartial observer of the security landscape.

When it comes to the cloud, ENISA sees the new approach to computing infrastructure as a “double-edged sword.”  Its report, entitled Critical Cloud Computing, notes as Arbor Networks did, that the concentration of many organizations’ resources in data centers can multiply “the impact of cyber attacks” – effectively, that an attack against one can be an attack against all. It also points to infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) as particularly hot targets:

“The most critical services are large IaaS and PaaS services which deliver services to other IT vendors who service in turn millions of users and organisations.”

There’s also the issue of critical sectors such as finance, transport and energy increasingly putting their crown jewels into the cloud. However, that’s only one side of the coin. ENISA also sees cloud computing as a pretty good defense against, say, distributed denial-of-service (DDoS) attacks on specific services:

“Elasticity is a key benefit of cloud computing and this elasticity helps to cope with load and mitigates the risk of overload or DDoS attacks. It is difficult to mitigate the impact of peak usage or a DDoS attack with limited computing resources.”

With regional power cuts and natural disasters, the agency claimed cloud computing can also provide “resilience.” That depends on how resources are distributed of course – just ask customers using Amazon’s problem-prone Northern Virginia data center. Nonetheless, ENISA pointed to the 2011 Japanese earthquake as an example of a disaster taking out “traditional IT deployments” but failing to down certain cloud services.

As for conclusions, ENISA has a series of recommendations for national cybersecurity agencies that includes a focus on making sure IaaS and PaaS providers stay safe, and figuring out just which public services depend on which cloud services. The agency also sings the praises of standardization in the cloud sector:

“Standardization, especially for IaaS and PaaS services, would allow customers to move workload to other providers in case one provider has suffers a large outages caused by system failures or even administrative or legal disputes.”

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

• Infrastructure Overview, Q2 2010
• How the mega data center is changing the hardware and data center markets
• The future of India’s IT services

An eagle-eyed colleague (thanks Derrick) spotted the Heroku business critical applications page on Tuesday and sure enough, it’s a new offering that goes beyond the all-in-one Heroku services that developers get when they put up their credit card for basic PaaS services. The new services include one-on-one consulting, problem support escalation all based on a custom pricing model.

An exec with a rival PaaS vendor said these new paid options are “right out of the Salesforce handbook for how to monetize cloud.” Salesforce.com bought Heroku, which was then a Ruby-oriented PaaS, three years ago. Since then Heroku has added support for several more languages.

PaaSes like Heroku, AppFog, Google App Engine, and Microsoft Azure, target developers who want to build applications without sweating all the underlying infrastructure stuff. But, to date, the category has struggled for acceptance beyond that demographic. Classic IT types are usually not wild about running company applications on someone else’s platform so they often push to move the finished application back inside the firewall. Higher level services like these might appeal to  corporate developers and their IT counterparts.

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