Thinking Out Cloud

Thoughts on Platform-as-a-Service

The recent news about layoffs at Bungee Labs has triggered a discussion about the viability of the Platform-as-a-Service concept. In this post I attempt to map the PaaS landscape and discuss possible strategies and approaches for the platform vendors. But first, to understand PaaS, we need to look at where it fits in the larger picture. PaaS is one of what I view as the three pillars of cloud computing:

1. Software-as-a-Service: Although the term "software" denotes any piece of software, the term SaaS is usually applied to the idea of delivering a complete software application to its end users over the Web, and typically with a subscription or per-usage pricing model. Examples include Zoho and Salesforce.com.
2. Infrastructure-as-a-Service: IaaS is about providing basic IT resources, such as compute power, memory and storage, over a network (typically the Internet) and usually with a subscription or per-usage pricing model. Examples include Amazon Web Services, GoGrid and Flexiscale.
3. Platform-as-a-Service: The term PaaS is often confused as it is actually used to refer to to two distinct elements:
   
   1. Web-based development tools (aka IDE). This could more accurately be refered to as Tools-as-a-Service (TaaS).
   2. A run-time application platform that enables running applications in the cloud, typically on top of an IaaS and delivered as SaaS.

 The two types of PaaS are sometimes confused because vendors often offer them combined as a single solution. Things are further confused because they often include a third, separate, component: that of a development framework or programming model (what is commonly referred to as the API).

To understand this better, let's compare to the more familiar and established world of Java. Building and running a standard Java app requires three main elements: the API (the Java programming language itself), a run-time platform (the Java Virtual Machine, or JVM -- or more accurately, the Java Run-time Environment, or JRE) and development tools (popular IDEs such as Eclipse and IntelliJ). Note that the three are separate from each other. A developer can choose which IDE and which JVM implementation (from IBM, Oracle, Sun or others). Also taking advantage of the Java Run-Time Environment does not require the Java programming language. One can use other interfaces such as JavaScript, Groovy and JRuby.

 The same principles apply to the Java Enterprise Edition (JEE). A developer can choose from a number of application server implementations (the run-time), IDEs and APIs (e.g., Spring Framework or EJB).

 

Armed with this understanding, let's look at Bungee Labs again. They made some crucial decisions with their product, BungeeConnect, which significantly impact the adoption of the product. the first was that they provide all of the elements: the development tools (a web-based IDE), the run-time platform (they may be leveraging other platforms underneath but it is transparent to the user), the hosting (i.e., IaaS) and the API (they offer a proprietary C-like API).

 
Second, they decided that you cannot separate the four elements from one another. They are tightly-coupled. You cannot use their tools without also adopting their API, run-time platform and hosting service. If you like their tools, and want to use them with other run-time platforms, APIs or cloud providers (hosting), too bad.

Third, they didn't leverage standards. Although their programming language syntax is C-like, so it is at least familiar to many developers, it will not execute on other run-time platforms as-is.

The adoption barriers created by Bungee's self-imposed limitations are becoming evident. A developer or company contemplating the use of BungeeConnect are forced to make a strategic, long-term decision about the future of their business: to be locked-in to Bungee's product in almost all aspects of their own product.

 

I don't mean to pick on Bungee. As a fellow entrepreneur, I sympathize. I can also understand the considerations they had when making these choices. For one, the notion of creating a "total solution" seems appealing at first. And from a practical perspective, it is easier to create a more powerful solution when you restrict and control the environment it operates in. Besides, they were being ambitious, and I respect that.

 

Let's look at some alternative approaches that Bungee could have taken (and still can), as well as what other players have been doing.

Go-To-Market Strategy

Generally speaking, achieving adoption for a new platform is a difficult task. It is true that the advent of cloud computing creates an opportunity for new players, but major challenges remain. There seem to be four main approaches to doing this:

• Brute Force: the very biggest vendors have the marketing muster, credibility and resources to make it happen by "brute force." An example of such an approach would be Google App Engine. Google has taken the exact same approach as Bungee -- they provide all four elements -- but they obviously have the market visibility and budgets to achieve fast adoption.
• Open Source: It means two things: first, pricing adoption barriers are removed (i.e., offer it for free and develop premium products and services later). Second, the product source code is available, allowing end users to customize it and the comfort of having access to source if something happens to the vendor. 10gen is an example of a vendor taking this approach.
• Specialized: Focus the platform on a particular segment of the market, instead of trying to be all things to all people. The key is that you have to build a "total solution" for that particular segment. This is reminiscent of Geoffrey Moore's Crossing the Chasm model. Ning is a good example, as it's a platform focused exclusively on building social networking applications. Other forms of specialized platforms could focus on a particular industry or type of application.
• Ride the Coattails:This strategy involves building a platform that allows developers to leverage an existing install base. The Facebook Platform is a good example. Given that today many applications expose their APIs to the general public, vendors other than the 'owner' of the install base can take this strategy.

Target User

Another dimension PaaS vendors should think about is who is the target user of the platform. The typical choices are programmers versus so-called business users (non-programmers). Bungee, Google App Engine and 10gen are all clearly targeting programmers. Ning, on the other hand, allows people without any code-writing skills to quickly create their own social network. They do, however, offer developers the ability to further customize their application through programming.

Totality of the Solution
As already noted, PaaS-related vendors need to decide which elements of the 'stack' they provide. Specifically, do they provide the run-time platform, the development tools, the hosting service, all of the above? And if so, do they lock users into their components or do they allow use of certain components from other vnedors? Here's a list of vendors and the choices they made:

Product	Run-Time	Tools	IaaS	API	Primary Target Users	App Focus
BungeeConnect	Yes	Proprietary web-based IDE	Yes	Yes. Proprietary	Developers	Free form
AppJet	Yes	Proprietary web-based IDE	Yes	Semi-proprietary, JavaScript-based	Developers	Free form
Jboss Cloud	Yes	Stanadard, installed IDEs	No (suports EC2)	Standard (J2EE)	Developers	Free form
GigaSpaces Cloud	Yes	Standard, installed IDEs + Cloud Tools for deployment	No (supports multiple clouds, including EC2)	Standard (Java/Spring, .Net, C++, JavaScript, Groovy, JRuby, JMS, JDBC, Jcache)	Developers	Free form
Aptana Cloud	Yes, for PHP and AJAX1	Aptana's open source installed IDE (based on Eclipse)	Restricted to Aptana hosting2	Flexible IDE for a variety of APIs, including JavaScript/AJAX, PHP, Ruby, Java	Developers	Free form
Force.com	Yes	Yes	Restricted to Salesforce.com hosting	Proprietary		Database-centric
DabbleDB	Yes	Proprietary web-based tools	Restricted to DabbleDb hosting	JavaScript based on JSON schema	Business (developer customization options)	Database-centric
Zoho Creator	Yes	Proprietary web-based tools	Restricted to Zoho hosting	Proprietary	Business (developer customization options)	Database-centric
LongJump	Yes	Proprietary web-based tools	Restricted to LongJump hosting	Java, REST, SOAP	Business	Database-centric, Workflow-centric
Google App Engine	Yes	Standard, installed IDEs + SDK	Restricted to Google App Engine hosting	Python (with limitations) and additional task-specific APIs	Developers	Free form
Coghead	Yes	Proprietary, web-based tools	Restricted to Coghead hosting	Proprietary	Business	Database-centric, workflow-centric
WyaWorks	Yes	Proprietary web-based tools, and accessible via installed IDEs	Provide hosting and allow deployment on any infrastructure	JavaScript, JSP, Java	Business and Developers	Free form
Intuit Quickbase	Yes	Proprietary, web-based	Restricted to Quickbase hosting	Proprietary3 Http API, XML/XSL and a Formula Language	Business	Database-centric
10gen	Yes	Yes, but you can develop code with standard IDE	No, supports multiple clouds	Standard (JavaScript, Python, Ruby)	Developers	Free form
Rollbase	Yes	Proprietary, web based tools	restricted to Rollbase hosting	Proprietary	Business (developers cutomization options)	Database-centric
Morph Labs	Yes	Not provided by Morph	Restricted to Morph Labs hosting	Standard (Java, Ruby)	Developers	Database-centric

Notes to Table:

1. According to a comment posted by Kevin Hakman of Aptana, a Ruby-on-Rails run-time will be available soon.
2. Aptana Actually uses Joyent as the host today (although this fact is transparent to the user). The company plans to add the ability to choose other hosting providers and does not see hosting as part of its business model (see comment by Kevin Hakman below).
3. The QuickBase API is proprietary, but like others on the list, it it can be wrapped by other, standard APIs. The QuickBase user comunity has already done so for Perl, Ruby, PHP and others.

Community and Eco-System

Another important aspect for any platform, PaaS included, is the notion of an eco-system and a community that is built around it. How well the platform vendor encourages, enables, nurtures and promotes this community is of critical importance. There are a number of ways to do this:

• Classic community tools: forums, ability to share and blog, wiki documentation editable by users, etc.
  
• Allow Extension of the Platform: This can be achieved by exposing APIs and/or open sourcing the code and providing the process and tools for submitting extensions, plug-ins and add-ons, bug fixes, etc. 10gen, for example, has open sourced its platform. Many of the other players in the table above are exposing APIs and providing other ways to modify and customize the platform. At GigaSpaces, as another example, we open sourced our API -- OpenSpaces -- and created the openspaces.org community site, which lets developers share their creations.
  
• Create a marketplace around the platform: Often the PaaS vendor already garners interest and attention and can make that marketing prowess available to its own users. Many of the PaaS providers listed here allow their users to list their creations in some sort of a catalog or marketplace. Other users can sometimes clone the creation and extend it, leveraging work that has already be done. In many cases the platform vendor allows its users a way to monetize their efforts. Salesforce.com's App Exchange is a good example of this. By making its platform open and extensible, Amazon enabled a whole cottage industry to develop around its Amazon Web Services platform, with companies such as RightScale.
  
• Access to end-user data: One of the most effective (and tricky) ways to foster an eco-system around the platform is to allow building applications that can access end-user data in other applications. Now when I say "access", I mean that they have the technical ability to do so. The end user, of course, needs to approve such access. For example, when you build an application on Force.com, it can access the contact, account and deal information in the users Salesforce.com application.

If anyone thinks I misrepresented any of the solutions in the table above, or if you have any other thoughts, please comment.

Cloud Deployment Directly from IDE

I knew it wouldn't be long before we start seeing the ability to deploy to the clouds directly from the IDE. The folks at Aptana seem to be leading the pack on this one. Check out this very cool demo of Aptana Cloud. It was sent to me by Kent Langley. It not only lets you deploy to the cloud directly from the IDE (Aptana Studio), it keeps your local project synched with the cloud deployed project. It also comes as an Eclipse Plug-In.

The folks at Aptana have set it up so that you can play around with this without actually giving you credit card info. I also understand that the underlying cloud they are currently using is Joyent.

Linear Scalability Does Exist, Ted

I enjoyed reading Ted Dziuba's I'm Going to Scale My Foot Up Your Ass, I really did. I like the 'tude and I like the style of writing. Reminiscent of the BileBlog (RIP), which some of my colleagues think is juvenile, but I think is hilarious. I loved it all, except for one big problem: Ted is dead wrong on the facts.

Now, I agree with Ted that in many cases the problem is shitty code. But that's exactly the point. Developers should not have to code in a way that requires a degree in computational mathematics (did I get your degree right, Ted?) to get their application to scale.

And I also agree with Ted that memcached isn't the end-all to scalability problems. In fact, I will probably go on a memcached-related rant some other time. But I do think it is a move in the right direction.

Bottom line, Ted, linear scalability does exist and architecture is the problem. To get what I am saying check out this and then read through Nati's blog. If you disagree then, let's talk. Did I mention I work for GigaSpaces?

GigaSpaces Launches OpenSpaces.Org

Today we are announcing the official launch of OpenSpaces.org, the community web site around GigaSpaces' OpenSpaces Framework -- an open source application development framework that extends Spring to take full advantage of the scalability ad performance provided by running your distributed application on GigaSpaces eXtreme Application Platform (XAP).

Check out the projects already underway.

And how about submitting your own project for a chance to win the $10,000 grand prize of the OpenSpaces Developer Challenge? There are $25,000 in total prizes and special $1,000 prizes for 'early bird' concept submissions by February 13 (just the concept, not code). Code submission deadlines are due by April 2.

Congrats to Alit, Michael, Gilad, Uri and the rest of the team for making OpenSpaces.Org happen.

Are Developers Growing in Influence?

Are developers and architects becoming more influential in infrastructure software purchase decisions in large organizations?

Back in September, Matt Asay blogged an interview with Laura Merling of Krugle, which makes a search appliance for software code across the enterprise. In the interview Laura said:

The power for decision making and buying has shifted to the developers, architects and midlevel managers. We are in some very large companies and have not once talked to a CIO! Developers have paved the way with their newfound power.

This "newfound power" that Laura speaks of has to do with open source software. More accurately, it has to do with the fact that most open source software is available for *free* download with a production license. So, presumably, the developers don't need permission from anyone higher-up in the organization to use the product, as there is no purchase involved.

The story goes that this is how Linux, JBoss, MySQL -- and more recently -- Spring and Mule, to name a few, have crept into large enterprises. And one day, after some minor disaster, an executive wakes up and says: "Holy crap! this thing is running on hundreds of our servers, we better get some support". Bam! a seven-figure deal is born, and it was the developers who really made the decision two years earlier.

Obviously, developers have always been influencers and evaluators of the software they will eventually use, but what I described above is a very different dynamic. If this is in fact happening in a major way, it has huge implications to how software used by developers should be marketed and sold.

Not surprisingly, it is very difficult to find hard data on this issue (I've searched). So here's a question:

• If you work at a vendor -- open source or not -- are you seeing this trend?
• If you work at a large company -- as a developer or not -- are you seeing this happen?

Would appreciate any thoughts about this.

Update: Some interesting comments about this blog on TheServerSide, and a thorough analysis by Erik Engbrecht.

Strut Your Stuff: The OpenSpaces Developer Challenge

I am very excited and pleased to say that today we've finally launched the OpenSpaces Developer Challenge. This is essentially a developer competition that invites everyone to submit their projects to the open source OpenSpaces initiative from GigaSpaces. And there are $25,000 in prizes, including a $10,000 first prize. We're no Google (yet), but still, this is real money.

Why have a developer competition?
The quote from Nati, in our official announcement of the competition says it all:

"We've made a huge investment in OpenSpaces internally at GigaSpaces, but we recognize that we have only scratched the surface of its potential," said Nati Shalom, GigaSpaces chief technology officer and founder.  "With this Challenge, we are inviting the developer community to show us what we're missing, while contributing to the community at-large.  Developers will have the added bonus of possibly earning some prizes in the process."

The GigaSpaces eXtreme Application Platform is a broad product with wide applicability. It can be used to implement scale-out architectures with high-performance in a wide variety of use cases ranging from algorithmic trading on Wall Street to social networking applications and search engines. Over time, we received many requests from customers, partners and others to extend the product capabilities in various ways -- many more than we could possibly do in a timely manner internally. We've also seen it being used as an application platform in ways we never thought of. So we decided to take our flagship API, which is based on the Spring Framework, and open source it. We called it OpenSpaces. Now others can contribute and extend the product.

To give you some sense of possible projects -- applications and plug-ins -- see the current projects already in the works. It is an extremely diverse list with projects ranging from PHP and REST APIs to an Oil & Gas exploration application using Microsoft Excel.

The competition is one more step in encouraging the community to participate in this exciting initiative. Some of the participants have already told us that they plan on taking their submissions and actually building a business around them. It was particularly appealing to them with our Start-Up Program offering.

I also want to take this opportunity to thank the distinguished group that has agreed to act as judges in the competition, including:

• Adrian Colyer, CTO, SpringSource
• BJ Fesq, Chief Technical Architect, Bank of America
• Joe Ottinger, Editor, TheServerSide.com
• John Davies, Technical Strategist, Iona
• Julian Browne, Architecture Consultant, RWE
• Keerat Sharma, Platform Engineer, Gallup
• Ross Mason, Co-founder and CTO, MuleSource

So please read more about the Challenge and sign up!

Is Your Development Like Sausages?

Legend has it that 19th century German statesman Otto von Bismarck once said: "Laws are like sausages, it is better not to see them being made." Well, from my experience in the software business, many times that's also the case with product development. With GigaSpaces, luckily, that's not the case.

Guy Nirpaz, GigaSpaces' head of development, just posted My Experience with Scrum. In it Guy describes some of the Scrum agile development practices at GigaSpaces. He posted this as a response to an email he received from a customer who compliments him on the development methodology at GigaSpaces and asks for advice.

We have a world-class development team at GigaSpaces and it's nice to see that customers are not only impressed by the products that Guy's team makes, but are also impressed by how it makes them.

Launching the GigaSpaces Start-Up Program

I'm very excited to announce that today we are launching our Start-Up Program. This is something I have been working on for a while, and I'm glad we finally got it out. We are essentially giving away our products for free -- full use, including production -- to any individual or company with revenues of less than $5 million.

If you want some background on the program go to the GigaSpaces Start-Up Program home page. You may also want to check out the FAQs and the official announcement. [UPDATE: See post and discussion on TheServerSide.]

Now, here's the rationale behind this program:

Why it makes sense for developers and entrepreneurs

This one is kind of a no-brainer.

When starting a new company, entrepreneurs face a tough dilemma. On the one hand, they want to use a robust, scalable, highly-reliable and high-performance application platform, such as GigaSpaces XAP, but on the other hand they want to keep costs to a minimum. As cost is typically the over-riding factor, they often turn to low-cost (or free) software, which is not as robust as GigaSpaces. The Start-Up Program lets them benefit from the best of both worlds.

Furthermore, the way we structured the program, there really isn't any unpredictable point of payment. The company will decide if and when it wants to "graduate" to the commercial license with full 24/7 email, phone and web support, such as any regular paying customer. Until then (in other words, until the point where it  makes business sense), they can just use the support forums for free.

From a technical perspective, there are two main points to keep in mind:

• GigaSpaces is about scalability. Start-ups are about scalability (at least, if they are successful). Scalability means a couple of things here. For one, you can just write your app on your laptop and when you want to test it in a distributed, resilient environment you can just do it with no code changes. See Nati Shalom's post on testability. The other aspect of scalability is of course when you go into production. As usage of your app increases, you simply scale it out on additional servers -- with no architecture or code changes.
• With GigaSpaces, there is no vendor lock-in. We use standard APIs. Specifically, with the OpenSpaces framework (which is open sourced and licensed under Apache), you basically write your application with POJOs and use the Spring Framework. You can also use plain C++ or C# objects, or standard J2EE APIs, such as JMS and JDBC. See also Nati's post: Avoiding Vendor lock-in in a non-standard environment.

Why it makes sense for GigaSpaces' non-startup customers

This one may not be as obvious. At the end of the day, though, it is in the best interest of all of our customers that there will be a robust community around the GigaSpaces products. This is exactly what the start-up program is trying to achieve, alongside other developer community initiatives we have and will be launching. These include our open source work around OpenSpaces and other projects, such as Spring, Mule, Hibernate, GridGain and Jini. It also includes things such as the GigaSpaces XAP Community Edition and many more projects that are in the works.

So it's about adoption, which will serve all of our customers.

Why it makes sense for GigaSpaces

Well, the previous section kind of gives you a clue about that. But also from a straight sales perspective, we see this as a marketing program that allows us to tap into a whole new segment of customers. We believe that this will eventually result in additional revenues to GigaSpaces. There is a basic assumption here: any start-up that will reach a point where their application generates significant revenues or adoption will want enterprise-style support and will pay for the license.

So please check out the program - and join!

Large-Scale Web Sites and Java

Nati Shalom's post, Why most large-scale web sites not written in Java, created a bit of a stir, to say the least, with a raging debate in the comments to the blog and one on TheServerSide and Artima.

And it also got referenced and commented on here, here, and here  - and several others.

Some people interpreted Nati's question as Java-bashing. And that created a silly PHP/Ruby Vs. Java flame war. As I had something to do with this post, as Nati mentioned, I thought that a couple of clarifications are in order.

As anybody who knows Nati and GigaSpaces (and as Guy Nirpaz pointed out), we're Java people at heart. Our product is written in Java. So there was no intention to bad-mouth it in any way.

I agree that the way the title of the blog was worded was a bit provocative, implying that most large scale web apps are not written in Java, but that was merely done to make things more interesting and based on an arbitrary analysis done by Pingdom, based on information they simply aggregated from High-Scalability. So obviously, no, it's not a statistically significant sample, and the word "most" is problematic.

Then, of course, some people rightly asked what is the definition of "large-scale". Again, it's a legitimate question.

But I want to explain what was the motivation for this post. We had an internal discussion on the relevance of GigaSpaces to the world of Web applications. At GigaSpaces (and yes, some of our competitors too - no need to shout) we've been pounding the scale-out drums, the partitioned data drums, the shared-nothing drums (and many other kinds of percussion instruments) for quite some time. In the last year or two it seems that a lot of people -- especially from the Web world -- are joining that funky beat. Google, eBay, Amazon, MySpace, Flickr, YouTube, Wikipedia and many others have published their architectures (and yes, I know some of them use Java) - and spoke of such architectures.

In other words, in the architectures that these folks used to make their Web apps highly scalable, performant and reliable, they are using very similar principles to the ones GigaSpaces has been advocating.

That said, we noticed that many of these folks are going with LAMP stack. The question was whether this is the trend, and consequently, what does it mean for us. If the trend is that Web 2.0 is moving to LAMP, but the enterprise market is still going to be a Java world, we need to make some decisions. If the whole world is moving to LAMP, we need to make some other decisions. And if Java is still dominant (or at least major) in the Web-world, it means yet other decisions and implications.

Although we don't have clear statistics, my intuition is that the trend for Web apps that are coming from start-ups or large pure web players (as opposed to web apps from airlines, banks, etc.) is definitely towards the LAMP stack. However, Java will still remain strong for a while and  especially for Web apps that have to deal with more complex processes in the back-end.

[BTW, I have a theory that 2004 was a watershed year in which many trends changed. It is the year that Spring Framework came out, that the term Web 2.0 was officially coined, that Ruby on Rails was released to the public, and several other interesting events. It would be interesting to see an analysis that compares what Web companies that are pre-2004 and post-2004 use for their infrastructure.]

Another interesting aspect, which Nati raises in his latest post, is that there is a possible convergence between Java and LAMP/RoR in various shapes and forms -- so it is not necessarily a zero-sum game.

Scaling Stateful Applications on Amazon EC2

A lot of people have been writing about how cool the Amazon EC2 service is -- and it is. On his blog, Mike Nicholls does a particularly good job of explaining the advantages EC2 gives to start-ups and entrepreneurs in cost-effectively and easily scaling their business.

I agree with every word Mike says, but there are is a major issue he does not address. It is that even if you have a cost-effectively scalable infrastructure, the fact remains that you need to build your app in a way that it can easily scale-out across many machines -- and grow (preferably linearly), as needed. This is a particularly big challenge when you are trying to build stateful, low-latency or data-intensive applications (or a combination thereof).

For those who have been following this blog, or GigaSpaces in general, you know that it is exactly that challenge we are addressing with Space-Based Architecture and the GigaSpaces eXtreme Application Platform.

Now, we are marrying the two together -- the scalable cost-effective infrastructure of Amazon EC2 with the linear scalability of Space-Based Architecture, including for stateful, high-performance apps. You can utilize the full benefits of SBA, or just the In-Memory Data Grid.

Dekel Tankel and Alon Lahav in my team at GigaSpaces have been doing a great job on this and just today made available a public AMI (Amazon Machine Image) for the GigaSpaces XAP platform. We're still working on improvements and optimizations, but it is ready for people to start playing around with.

• You can find the GigaSpaces AMI here.
• General description in the Amazon Web Services Solution Catalog here.
• Detailed paper with set up instructions and code examples here (PDF).

We're already working with a couple of beta customers on EC2, including some folks who are building a Web 2.0 social networking type site.

And as Luke Flemmer at Lab49 points out, it's a great environment for testing distributed apps.

So please try it out and let me know what you think (and remember it's kinda beta-ish).

BTW, Jason Carreira and others asked for this on this TheServerSide thread. Well, folks, here it is, as Nati promised...