Blog Post

Who Will Build the LAMP Cloud?

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Zend Technologies, whose founders created the programming language PHP and subsequently touts itself as “the PHP company,” said Monday that it raised an additional $9 million. But while the press release offered little information as to the money’s intended use, it did contain a somewhat cryptic quote from its lead investor and board member, Moshe Mor of Greylock Partners (italics mine):

Today’s enterprises are looking to agile Web and Cloud-based technologies such as PHP to deliver business value better and faster…We believe that Zend’s leadership position in the PHP space enables the company to drive its solution to deeper adoption across a broad commercial audience in the U.S. and around the globe.

Since when is PHP a “cloud-based technology” (whatever that means)? I know Mor to be a smart guy, so I can only assume there’s more to his statement than meets the eye — and I believe it has to do with the LAMP stack. and VMware recently unveiled a Java-focused platform-as-a-service offering, 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?

One candidate is, of course, Zend, the commercial company behind PHP, the biggest P in LAMP. Zend is also the driving force behind the Simple Cloud API, which is intended to simplify integration between PHP applications and cloud services. But for Zend, which has operated under a typical open-source commercialization model by offering services, support and premium commercial licenses for on-premise installations, operating a cloud service is a whole new area of competency that requires an entirely new business model.

Google is another candidate. The search giant already has a PaaS offering, Google App Engine, that supports both Java and Python, another one of the Ps in LAMP. But until recently it’s been accused of being a lightweight offering that creates lock-in by forcing developers to use Google-specific programming models, such as with threading and data structure. In fact, because of this, Google’s platform lacked MySQL support, the M in LAMP. And although Google recently rolled out a version of its App Engine tweaked for the enterprise, including support for MySQL, the focus seems to be on Java, not on LAMP.

Heroku is another possibility, perhaps surprisingly given how much the startup is identified with the Ruby community. As Stacey noted in a post about its recent $10 million investment announcement:

“We don’t think the market is going to end up with a Ruby platform and a Java platform and a PHP platform,” Byron Sebastian, Heroku’s CEO, said to me in an interview. “People want to build enterprise apps, Twitter apps and to do what they want regardless of the language.” Sebastian said he sees the round as a huge validation for the Ruby language as a way to build cloud-based applications, but doesn’t want to tie Heroku too closely to Ruby. “The solution is going to be a cloud app platform, rather than as a specific language as a service,” Sebastian said.

I like Sebastian and the Heroku guys a lot, but my head’s still spinning from that ambivalent statement.

Even Microsoft has committed to supporting PHP and MySQL on its Azure platform, behind which there’s already an open-source project called PHPAzure. But the operating system is still Windows, so the Microsoft initiative does not qualify as a LAMP stack cloud.

Finally, Amazon can never be discarded as a significant player whenever it comes to cloud computing. As Derrick Harris has postulated, there’s a strong possibility that Amazon will come out with a PaaS offering. And if it does, a LAMP stack-focused platform makes a lot of sense, given that it already offers a MySQL database-as-a-service offering with its Amazon RDS service.

Then again, there could always be a startup hard at work building the LAMP Cloud. Do you know of anyone else? Would you want a PHP or LAMP platform as a service? Let us know in the comments.

Geva Perry writes the Thinking Out Cloud blog and advises startups and enterprises on cloud computing strategy and marketing. He’s @gevaperry on Twitter.

To learn more about cloud computing, LAMP, PHP and more, join the GigaOM Networ at Structure 2010 on June 23 & 24 in San Francisco.

28 Responses to “Who Will Build the LAMP Cloud?”

  1. We’re (kinda) building the LAMP cloud…

    Our company, has been providing secure LAMP as a service installs for the last month, and it’s been met with pretty good response so far.

    By using the Rackspace Cloud offering, we build extremely secure, nicely configured full LAMP stacks for a one-time fee of $200 and a monthly ongoing fee of as low as $20. The security aspect of it is huge — we only open up what you need, we secure every layer of the LAMP stack as much as humanly possible, and we run a Nessus-level scan over everything when we’re done… delivering you a full report of vulnerabilities & how we patched. We can also layer secured versions of WordPress, Drupal, and Joomla! on top.

    Essentially, the service does about 30-40 hours worth of Sr SysAd / Security Engineer work in just under an hour.

    We’re pricing it so that even independent Designers, Developers, and Bloggers can have a secure solution and not waste their time doing something they aren’t trained to do — getting a LAMP stack secured and properly configured for each and every client.

  2. CloudIgniter is currently in beta as a forthcoming Heroku style cloud service for CodeIgniter php MVC framework. As Heroku only deals with Ruby apps, Cloudigniter will only handle Codeigniter framework. I believe hosting is at Engine Yard too.

  3. It does seems that PHP has been the forgotten language in the Cloud. While Ruby and Python might be newer, sexier languages PHP still makes up a huge amount of web application development. As an example, lists PHP as more popular than both Python and Ruby. While that data is not web app specific it provides a reasonable data point.

    I think the reason we have not yet seen a big push for PHP is because the forward thinking developers and companies who are taking advantage of the cloud are also taking advantage of newer programming languages (i.e. Python & Ruby). As more people start migrating to the cloud we will see increasing demand for PHP platforms the same way we have for Java. Even if PHP is a relic of the hosting generation its popularity and broad use mean it would be foolish not to have in the cloud.

    • There’s no doubt that PHP is a bit late to the party. Maybe precisely because of the strong hosting support you mention.

      “If there are already hundreds of PHP hosters and our apps work perfectly fine on them, why switch?” is the thinking. And this is a perfectly reasonable take on the cloud when you have customers and clients clambering for features and bugfixes.

      What PHPers are missing, on the whole, is the value proposition of the cloud beyond hosting. Scalability, availability, dead simple image and instance management. . . the list goes on.

      The PHPers I’ve met who have tried cloud solutions are hooked. But how do we get the rest of the PHPers to try it?


  4. Finally, there is a way to run PHP on Google App Engine: Quercus. I haven’t used Quercus on GAE, although I can tell you that it performs as well as opcode-cached PHP.

    I’d love to hear from someone who has tried it. Just email me at wllm at wllm . com.


  5. In talking with the guys at Rackspace, their PHP support in Cloud Sites came up. They consider Cloud Sites a good option for PHPers looking for PaaS cloud. I haven’t tried it yet, although I’ve heard many good things about Cloud Servers.


  6. There is another vendor with a very compelling cloud platform for PHP: Makara. They offer a LAMP stack that supports PHP applications with the necessary features to build a killer LAMP cloud: clustering, monitoring, deployment management. . . it’s all dialed in.

    But this is a product, not a service.

    Disclaimer: I’m currently consulting with Makara.


  7. I agree that there is a big opportunity for a LAMP/PHP PaaS offering. I even told a crowd of ~500 that this would make for a great startup in the ZendCon 2009 cloud panel.

    One side note here: you should consider adding GAE as a PaaS offering for Python in your list of PaaS providers. Python is still their chosen horse. Both Google and Microsoft saw Java support as a necessary evil to get their platforms off the ground.


      • Sorry, I meant in this list:

        ‘ and VMware recently unveiled a Java-focused platform-as-a-service offering, 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?’

        I think you’re right on with this list of PaaS providers for specific technologies, and I just wanted to point out that Google could be put down for Python in the same breath.


    • Thomas Lukasik

      Your statement that “Both Google and Microsoft saw Java support as a necessary evil to get their platforms off the ground.” is based on what.. your biased opinion?

      Banks, hospitals and multi-billion dollar enterprises don’t run on LAMP — they run on Java based platforms like IBM and Oracle.

      It’s more reasonable to assume that Google wanted to attract seasoned enterprise developers than to suggest that they added Java support against their will.


      • Good point. I didn’t specifically ask the Azure and GAE guys what their rationale for adding Java support was; I assumed based on their level of support WRT other technologies (mainly .Net working way better than Java on Azure) and the priorities they assigned when they chose to implement first (mainly with Python launching well before Java for GAE).

        To be clear, I’m not knocking Java here. I was actually a Java engineer for 10 years before I took over Zend Framework; if I thought Java wasn’t a great- if not the best- technology for a wide range of problems, I would have focussed my attention elsewhere sooner. I have no doubt that Google and MS added Java support to woo the very advanced- and very lucrative- Java crowd. And I think it’s a win-win. But they obviously have to decide where to allocate resources, and every developer who’s focussing on Java support in Azure is a developer who’s not focussing on .Net.

        All of that said, Java seems to be a much more strategic solution for GAE, if for no other reason than they aren’t investing a ton of resources in building a full enterprise stack with all the bells and whistles like MS is with .Net.

        I hope that clears up any confusion about what I wrote above. If I’m not mistaken, we agree fully on this point. :)

        Thanks for the feedback in any case.

  8. As the creator of the Simple Cloud API and the former cloud strategist at Zend, I have a lot to say here. :) I’ll address a few different things which will work best as separate comments. Geva, I hope you don’t mind a comment DoS attack. ;)


    • Charles – I think that Media Temple (gs) gets close, but in my view doesn’t quite qualify as a LAMP Platform-as-a-Service. But I concede that it is somewhat an issue of definition of PaaS vs. IaaS.

  9. While I am perfectly happy with App Engine, we’ve been hosting Worldwide Lexicon on App Engine for Python for a year and a half now with few issues, I’d like to see a similarly capable option for PHP.

    The primary reasons we went with App Engine over Amazon were:

    1) no sys admin headaches : you just update your code, and it just works. no more provisioning CPUs, etc. this is the main selling point of a platform like this, as it saves a huge amount of money, time and headaches.

    2) redundancy : a platform like this is inherently redundant, and recovers well following an outage (and in many cases degrades gracefully so end users are unaware of an issue). it’s not perfect but compared to issues I’ve had with other hosting companies, quite good especially for the cost.

    At the time, I would have preferred to use PHP since nearly all of our other modules are PHP based except the backend. The cost of transitioning to Python was outweighed by the cost of administering multiple servers, SQL servers, etc, especially during the cash starved build out period. This saved us at least $100,000 mostly in the form of IT support we did not have to hire or outsource, so nearly everything went into building product.

    I’ll probably stick with App Engine and Python for a while since things are working well and it ain’t broke, so it don’t need fixing, but if I am required to migrate in the future, or start another project, I’d like to be able to use PHP with the same level of simplicity.

  10. Saratoga Sam

    Geva’s offhand comment “But the operating system is still Windows, so the Microsoft initiative does not qualify as a LAMP stack cloud” shows how myopic one can be.

    Even it offers the same pricing (which includes Windows licensing cost) as other stacks, Windows or anything Microsoft will never ever be good for you. You can pay $$$ for a RHEL support license but it’s free :D

    • Sam – I have to admit, I don’t completely understand your comment, but I have nothing against Microsoft. I was merely pointing out that it doesn’t qualify as a LAMP cloud, which I believe is an accurate statement.

  11. 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.