Does cloud computing need LAMP?

An article asking who will first offer a LAMP platform as a service offering raises an even more fundamental question: does cloud computing even need the LAMP stack?

James Urquhart
James Urquhart is a field technologist with almost 20 years of experience in distributed-systems development and deployment, focusing on service-oriented architectures, cloud computing, and virtualization. James is a market strategist for cloud computing at Cisco Systems and an adviser to EnStratus, though the opinions expressed here are strictly his own. He is a member of the CNET Blog Network and is not an employee of CNET.
James Urquhart
3 min read

The LAMP stack is a collection of open-source technologies commonly integrated to create a platform capable of supporting a wide variety of Web applications. LAMP typically consists of Linux, Apache Tomcat, MySQL, and either the PHP, Python or Perl scripting languages. Famously used at some of the best known Web businesses (such as Wikipedia), LAMP has seen widespread adopting in corporate and government settings in the last several years.

Fractal Angel

My cohost on the occasional Overcast podcast, Geva Perry, recently wrote a blog post asking a simple but profound question: who will build the LAMP cloud? Who will create the first platform as a service (PaaS) offering, a complete programming environment that hides the operational challenges of running applications in the open-source stack while providing all the tools and compatibility LAMP offers today?

As I initially read the post, I thought "good question." As Geva notes, there is a huge gap in the existing market--almost a bias towards Java and Ruby that ignores the value of LAMP:

Salesforce.com and VMware recently unveiled a Java-focused platform-as-a-service offering, VMForce.com. Meanwhile, Microsoft has Azure, a PaaS offering focused on the .Net stack, and startups Heroku and Engine Yard both deliver Ruby-on-Rails cloud platforms. But who's going to offer a PaaS for LAMP?

Geva goes on to analyze the key players in the market in some depth. For example, Zend Technologies, a business founded by the creators of PHP, may be planning to do so with $9M in funding secured this week. Google, with App Engine, already has a Python offering that goes some of the way toward LAMP, and recently announced MySQL support for later this year, but also seems to be switching its focus to Java.

Geva also runs down analyses of Microsoft Azure, Heroku, and the Ruby community, and Amazon Web services.

After reading Geva's post, however, I was struck by the very first comment he received from Kirill Sheynkman, arguing that the future of LAMP in the cloud may be a moot point:

Yes, yes, yes. PHP is huge. Yes, yes, yes. MySQL has millions of users. But, the "MP" part of LAMP came into being when we were hosting, not cloud computing. There are alternative application service platforms to PHP and alternatives to MySQL (and SQL in general) that are exciting, vibrant, and seem to have the new developer community's ear. Whether it's Ruby, Groovy, Scala, or Python as a development language or Mongo, Couch, Cassandra as a persistence layer, there are alternatives. MySQL's ownership by Oracle is a minus, not a plus. I feel times are changing and companies looking to put their applications in the cloud have MANY attractive alternatives, both as stacks or as turnkey services s.a. Azure and App Engine.

I have to say that Kirill's sentiments resonated with me. First of all, the LA of LAMP are two elements that should be completely hidden from PaaS users, so does a developer even care if they are used anymore? (Perhaps for callouts for operating system functions, but in all earnestness, why would a cloud provider allow that?)

Second, as he notes, the MP of LAMP were about handling the vagaries of operating code and data on systems you had to manage yourself. If there are alternatives that hide some significant percentage of the management concerns, and make it easy to get data into and out of the data store, write code to access and manipulate that data, and control how the application meets its service level agreements, is the "open sourceness" of a programming stack even that important anymore?

This discussion reflects a larger discussion about the future of open source in a world dominated by cloud computing. If you can manipulate code, but not deploy it (because it is the cloud provider's role to deploy platform components), what advantage do you gain over platform components provided to you at a reasonable cost that "just work," but happen to be proprietary?

I'd love to hear your thoughts on the subject. Has cloud computing reduced the relevance of the LAMP stack, and is this indicative of what cloud computing will do to open-source platform projects in general?