They were app developers; the transformation into systems engineers was just a necessity of growing the business. A website that looked pretty and worked smoothly was little more than veneer if the real product — the AWS virtual servers running Heroku’s customers’ applications under the covers of the hip samurai-themed web service — didn’t work. At one point, Lindenbaum joked during a recent call, Heroku had to do a UX refresh “and we literally didn’t have anyone in the company who could build web apps anymore.”

After leaving Heroku and ultimately its parent company Salesforce.com , Lindenbaum is back in the public eye with a new effort called Heavybit Industries that aims to save other startups from Heroku’s early growing pains. The idea came after so many fledgling companies came to Heroku looking for help, and after Lindenbaum got personally involved with some as an adviser or investor. He eventually realized that there’s a lot of institutional knowledge out there about how to build business that serve developers, but there’s also a lot of duplicated effort because the people starting these businesses often don’t know their peers exist, much less what they’re up to.

How Heavybit works

Heavybit is like a co-working-space-meets-incubator-meets fraternity, and Lindenbaum has recruited some of the biggest names in venture capital, application development and developer-focused startups to make sure Heavybit delivers on its promise. It works like this: Companies that have raised some money, gained some traction among developers, and now have to deal with the difficult problems of scaling their code or monetizing their business come to Heavybit. Once accepted, they’re in the “active period” for nine months, which includes a curriculum of weekly talks on technology or entrepreneurship; office hours with experts and investors; and meeting/work space in a building in San Francisco’s SOMA neighborhood.

James Lindenbaum at Structure 2009. (c) Pinar Ozger

Membership in Heavybit is in exchange for equity, and the community has space for between 10 to 15 companies at a time, Lindenbaum said (although it’s really a “membership for life” situation). The first batch of startups includes some more-established ones — Zencoder, Stripe, PagerDuty and Meteor — that will serve as mentors as well as receive mentorship. Other inaugural Heavybit members include Treasure Data, Kodowa, Iron.io, CircleCi, CloudConnect, Keen IO, Codenvy and Backlift.

Early Heavybit expert advisers include Derek Collison (Apcera/VMware/Google), Adam Gross (CloudConnect/Salesforce.com), Jesse Robbins (Opscode/Amazon), Javier Soltero (Acompli/VMware/Hyperic), and Lindenbaum’s Heroku co-founders Adam Wiggins and Orion Henry. Among  Heavybit’s early investor partners are Ping Li (Accel Partners), Chris Sacca (Lowercase Capital), John Connors (Ignition Partners) and Matt Ocko (Data Collective).

Bringing “bad-ass” engineers back from mobile apps

One of Lindenbaum’s goals when putting together the advisers — and one of his continuing goals with Heavybit — is to to put member companies in touch with people who really understand the business and architectural complexities of distributed, multitenant applications. “The reason [these developer-focused] products are so great is because they’re built … by app developers for app developers,” Lindenbaum said. But, like the Heroku team early on, the founders aren’t always skilled in building systems designed to scale.

“The scale curve is much steeper for these companies,” he explained, because the way it usually works is these businesses attract customers who also have their own customers to serve. So rather than handling data for one company, they might be handling data for 20 of that company’s clients, as well.

In order to put his companies in touch with the best of the best of distributed systems engineers, though, Lindenbaum first has to walk those guys back from the Instagram edge. Once you prove yourself at a place like Google or Facebook, Lindenbaum said, “[E]veryone thinks you’re a bad ass. As soon as you say you’re going to build a thing, VCs line up to give you money.”

Unfortunately, he added, many of these people are chasing the past rather than future, trying to cash in their lottery tickets on building the next photo-sharing app rather than on the hairy enterprise-grade systems problems where their skills would really be valuable.

But he has a plan to bring them back to the enterprise side. He intends to push the message of how hard these problems are and how much the cloud services and developer-focused products industries are becoming analogous to traditional heavy industries in terms of the complex but mature supply chains involved.

Essentially, he wants to do the “Got Milk?” ads for the cloud services industry, educating the market so the individual companies don’t have to. It’ll be like a trade association, he joked, “only the non-evil version of that.” Once you shine a light on the difficulty of the problems, Lindenbaum said, the really good engineers come running back to solve them.

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

• How direct-access solutions can speed up cloud adoption
• Cloud and data third-quarter 2012
• Examining open hybrid cloud options for the enterprise

The deal would increase Salesforce’s revenue by $120 million to $125 million in the financial year 2014. Revenue for the company’s full fiscal year 2014 is projected to be in the range of $3.955 to $4.0 billion, an increase of 30 percent to 31 percent year-over-year. The non-GAAP earnings per share will drop to about 16 cents a share for the year. Diluted non-GAAP EPS is expected to be in the range of $0.31 to $0.33. The board of directors of both companies have approved the transaction. The transaction is expected to close late in salesforce.com’s fiscal second quarter, ending July 31, 2013.

Make no mistake — this is one expensive deal. In 2012, Exact Target had revenues of $292.3 million (up 41 percent from 2011) and a net loss of $21 million (down from $35 million in 2011.) Exact Target expects to bring in $370.0 million to $374.0 million during 2013 and lose between $20-to-$22 million.

An Expensive Makeover

Salesforce’s makeover is getting more expensive. It paid about $142 million for Jigsaw in April, 2010. Salesforce paid $212 million for Heroku later that year and shelled out $326 million for Radian6 in 2011 only to open its wallet to spend another $689 million for Buddy Media last year.

But this one is the big whopper and actually the one that makes the most sense for Salesforce, especially from the perspective of goosing up its revenues. However, this shouldn’t come as a surprise mostly because the company had promised to make more “marketing cloud” oriented acquisitions. Of course, raising over a billion in debt last quarter was even more of a hint of things to come.

“The CMO is expected to spend more on technology than the CIO by 2017,” said Marc Benioff, chairman and CEO, salesforce.com. “The addition of ExactTarget makes Salesforce the starting place for every company and puts salesforce.com in the pole position to capture this opportunity.”

Net:Work 2010: Marc Benioff – CEO, salesforce.com

Exact Target, to put it crudely, is an email-based marketing platform, one whose usage has been on an upswing as consumer brands have turned to the internet for the marketing efforts. ExactTarget has big-name customers including folks like Coca-Cola. It also adds more structure to Salesforce’s ambiguous sounding marketing cloud.

On paper, all of CEO Benioff’s moves make sense. Cloud infrastructure is the future of software. Social is a core and vital need for companies and marketing is becoming crucial and strategic necessity in our increasingly distraction-infested world. Bringing it all together with mobile — another area of focus for Salesforce — makes perfect sense. It is a good strategy to take especially as some of the older (software) guard starts to slip. Exact Target brings in enough muscle into the company to go toe-to-toe with Oracle which acquired RightNow, Eloqua and Vitrue.

Will it work?

The question is whether Salesforce actually make all these disparate pieces start to work together and make a gourmet dish called profits from all these ingredients. Many on Wall Street are skeptical, though some of it is because of Benioff’s bombastic “I am always right” style.

The doubters have a reason: the marketing cloud, which until recently was only Radian6 and Buddy Media, only was about 3 percent of company’s revenue — around $100 million. The other businesses, such as Data.com — which consists of the 2010 Jigsaw acquisition – are said to bring in about a $100 million. It isn’t clear how much (or how little) the company makes from Heroku and then there is Work.com, its new business that is an amalgamation of Rypple, Choicepass and other assets. Those are rounding errors for a company that is going to bring in $4 billion this year.

That said, for now, Benioff has enough to standup in front of the world and promise what a friend of mine calls “future bliss.”

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

• Social third-quarter 2012: analysis and outlook
• Infrastructure Q2: Big data and PaaS gain more momentum
• A field guide to cloud computing: current trends, future opportunities

PostGIS is an extension to the PostgreSQL database that many developers use on Heroku’s platform as a service. According to a blog post announcing PostGIS 2.0 support in beta form, Heroku’s Craig Kerstiens wrote:

“PostGIS 2.0 will enable a new class of Heroku applications that leverage location data. Whether you are looking to compute walkability scores to nearby schools, target ads based on GPS locations, or search for apartments by specific neighborhoods PostGIS can help make you build richer functionality into your application more easily.”

Heroku’s sales pitch is that using PostGIS with Postgres gives developers more resources while cutting the number of services they might require.

For example, a developer who might have in the past turned to a proprietary tool like ESRI’s ArcGIS, and then manage that along with the rest of the stack can now stay with an open-source option tightly linked to the database of choice. That means reduced complexity and the ability to build richer location-based functions faster. At its most basic level, PostGIS support means you can perform spatial queries and analysis on your data.

And that could mean more useful apps. Instead of an app that shows you on a map where the nearest Peet’s Coffee is, you could get the best walking route to that location factoring in terrain and real world traffic or other data, according to Kerstiens.

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

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

Salesforce says developers using its tools can build apps that tap into troves of legacy data from existing CRM customers.

Given these developments, and rumblings that public cloud king Amazon Web Services is gearing up its mobile development push, it looks like legacy cloud giants are crowding into a space pioneered by smaller, more focused providers of mobile back-end services. (GigaOM Pro analyst Janakiram MSV has a good take on choosing an MBaaS here — subscription required.)

Who needs an MBaaS?

Salesforce.com’s pitch is that, while there are tons of useful consumer mobile apps, enterprise apps to date are still lacking.  ”It’s hard to build mobile apps that don’t just look nice but are engaging and that comes down to data. They need to be connected into your work data,” said Adam Seligman, VP of developer relations at Salesforce.com. “You have to make it easy to build the apps, the client side stuff, but you also need those hooks into corporate data.”

The new mobile packs, which support three lightweight mobile frameworks — jQuery Mobile, Backbone.js and AngularJS — should help on the ease-of-development front.

Salesforce, which backs both Force.com and Heroku Platforms as a Service (PaaS), subscribes to the school of thought that a specialized Mobile Backend as a Service (MBaaS) — from Parse, Kinvey, Kii or Stackmob — isn’t necessary. Those smaller competitors would no doubt argue that developers need to build applications that connect to myriad applications from many sources — not just those from one company.

Rackspace wraps up mobile stack in an easily deployable package

Rackspace already hosts “tons of mobile apps” but it wants to make it easier for developers and companies to deploy and run them, CTO John Engates said. So the San Antonio, Texas-based company wrapped up a mobile-focused technology stack as a sort of prepackaged cloud for that type of user.

“We want to streamline things. We put together a stack — including Linux, MySQL, PHP, Memcached, Varnish cache in a sort of blueprint that we can deploy consistently and quickly,” he said.

This backend runs in Rackspace’s public cloud infrastructure, but on cloud servers that are dedicated to that customer. “We’re basically running a single tenant infrastructure on a multi-tenant cloud,” Engates said. “Heroku is a multi-tenant platform that lives on Amazon, a multi-tenant infrastructure cloud. We’re trying to build a single-tenant platform atop a public cloud so you can build your own deployment and spec and scale it for what you need.”

Rackspace CTO John Engates

The entire stack is open source and developers can use their SDKs of choice to develop for any mobile device. Rackspace has also signed up some partners to work with its stack: FeedHenry, New Relic, Sencha, SOASTA, StackMob and Trigger.io.

“The idea there is you use our infrastructure but then SOASTA can test your application from many perspectives — not just Rackspace — and throw a load up there to make sure it scales before you deploy it,” Engates said.

Bring on the consolidation

As more of these bigger, broader “cloud” companies add mobile development and hosting capabilities, it may be time for consolidation in the MBaaS business to kick off for real.

Forrester senior analyst Michael Facemire said consolidation in the MBaaS space, which started to happen last year with Apigee’s acquisition of UserGrid, a pure-play MBaaS and Appcelerator’s buy of CocoaFish, will likely heat up now that these bigger players finally see how important mobile developers are to the future of their overall businesses.

And, it will be extremely interesting to see what Google has up its sleeve vis-a-vis Google App Engine (GAE). Oracle, a power among enterprise applications, will be another company to watch.

This story was updated at 7:50 a.m. PST with analyst comment

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

• Cloud computing infrastructure: 2012 and beyond
• PaaS market accelerators, 2012–2013
• Infrastructure Q4: Big data gets bigger and SaaS startups shine

In this case, the security SWAT team deemed this to be a real problem and scrambled to address it. “The team evaluated it and wrote the code for the fix, which actually took very little time and then started scheduling the release,” Josh Berkus, Postgres core team member told me in an interview. And it’s in that scheduling and coordinating the rollout to thousands of Postgres repositories that was really tricky.

When it comes to any big fix or patch, the practice is to create an installer to ease its application. In Postgres’ case, because it runs on virtually every flavor of Linux as well as Windows, they needed to come up with 80 different packagers. “That’s why delay was built into the process,” Berkus said.

“If it were a normal, minor update for bugs, we don’t worry about making them all available at once, but for this, we felt we needed to.”

There  was also the issue of disclosure. You want users to be alert as to what’s happening but you don’t want to “provide a roadmap” of the vulnerability to the script kiddies, Berkus said.

A March 28, message posted up on the Postgresql message board alerted folks of a patch to come April 4. Then Heroku the popular Platform as a Service, which supports lots of Postgres users, posted that it was issuing the patch starting April 1. That timing set off some of the Postgres faithful who felt that Heroku was getting special treatment. It also garnered some press attention and Hacker News comment.

Berkus said there’s a reason for that. Heroku provides the database as a service, not the binary code itself. Heroku requested that early access because it has lots of machines. And, as it turns out, the vulnerability could impact any Postgres user that has port access to the database even if he or she does not have a valid account.

The nature of that vulnerability meant Heroku — which runs on Amazon Web Services– or any Postgres user running on AWS or other public cloud could be vulnerable depending on how they set up their servers. Many customers running on public cloud leave ports open, probably because they don’t know better.

From the Postgres FAQ about the issue:

Any system that allows unrestricted access to the PostgreSQL network port, such as users running PostgreSQL on a public cloud, is especially vulnerable. Users whose servers are only accessible on protected internal networks, or who have effective firewalling or other network access restrictions, are less vulnerable.

Berkus and the folks at Heroku who spoke to me on this issue were quick to assert  that while this was a big vulnerability — much bigger than the last vulnerability back in 2005 —  there was no sign of any exploits.

So, net net net, Heroku rolled out its fix earlier this week. Minor drama ensued. But as of now, the rest of the world is covered as well.

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

• Amazon’s DynamoDB: rattling the cloud market
• Sector RoadMap: SQL-on-Hadoop platforms in 2013
• Cloud and data third-quarter 2012

That’s why the recent Heroku-Rap Genius dustup is important. To recap:  About two years ago Rap Genius, which runs its Ruby-based application on Heroku’s platform as a service, started noticing performance issues. As traffic grew, it dutifully added more Heroku resources, a.k.a. “dynos” in Heroku parlance. But performance still lagged. Rap Genius dealt with lots of customer complaints although its Heroku log files and related New Relic dashboard said nothing was amiss.

Customer mandate: transparency and trust

It turns out that Heroku, the PaaS company acquired by Salesforce.com in 2010, had tinkered with the routing underpinnings of its site in such a way that jobs were not getting deployed optimally. This move from “intelligent load distribution” to “random load distribution,” plus the fact that this change was not documented — let alone publicized —  to customers, was the issue.

In a February 13 Rap Genius blog post detailing the issue, the company said:

“A Rails dyno isn’t what it used to be. In mid-2010, Heroku quietly redesigned its routing system, and the change — nowhere documented, nowhere instrumented — radically degraded throughput on the platform. Dollar for dollar a dyno became worth a fraction of its former self.”

That blog post generated a ton of “up-votes” on Hacker News and probably prompted an apology from Heroku, which TechCrunch covered.

Rap Genius co-founder Tom Lehman described what happened in a recent phone interview: “We had been running 90 dynos at $20,000 a month, which we thought was sufficient based on the incorrect data we were getting, but it turned out that 90 dynos was woefully insufficient. So we upgraded to 300 dynos at $40,000 per month and performance is still bad. We can’t pay $40,000 a month for this.”

On February 16, Heroku issued a more detailed apology and outlined a plan of action including:

• Improving our documentation so that it accurately reflects how our service works across both Bamboo and Cedar stacks
• Removing incorrect and confusing metrics reported by Heroku or partner services like New Relic
• Adding metrics that let customers determine queuing impact on application response times
• Providing additional tools that developers can use to augment our latency and queuing metrics
• Working to better support concurrent-request Rails apps on Cedar

When asked for comment, Heroku referred back to its blog post.

Lehman said his company is in a tight spot. It can’t sustain payments of $40,000 per month. “Unless something changes we have to move.”

The likely destination? Amazon Web Services, a transition he would not take lightly because Heroku does much that AWS cannot. On the other hand, many of Rap Genius’ third-party providers are already on AWS. “I still have love for Heroku. Without it we couldn’t get to where we are today, but they have not been 100 percent upfront with customers.”

In his view, this should not be the end of the story. “We feel Heroku (and therefore Salesforce.com) overcharged and misled a bunch of small (and big!) start-ups and if they indeed did something wrong they should be held accountable.”

As if on cue, Kristensen Law Group started soliciting plaintiffs for a class action suit against Heroku.

The bigger picture

I’ve asked Lehman if he is party to the class action suit and will update when he responds, but lets get back to the broader issue. (Update: Lehman said he is not part of the lawsuit.)

Companies already get the heebie jeebies over the perception that moving to the cloud involves a “loss of control” over their IT. Imagine the impact if they think they can’t trust or believe in the metrics they’re given by their providers.

This is about way more than Heroku and Rap Genius. It’s about customer trust and the lack of that is a real danger to cloud adoption.

Photo courtesy of Shutterstock user 3Art

This story was updated at 8:42 a.m. PST to reflect Lehman’s position on the class action suit.

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

• Cloud and data third-quarter 2012
• Platform as a Service in 2012
• PaaS market accelerators, 2012–2013

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.

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

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