A few "PAAS"ing thoughts

Google App Engine has suddenly been thrown into spotlight with a critical piece written by Carlos Ble at his blog.

I got my share of mixed feelings while reading his post. Why, you may ask? I have been spending a better part of my free time digging into the Google App Engine, which is a PaaS platform that allows you to write web applications in either Java or Python. Heck, I have even combined all my findings and published them as a free eBook over here.

Should I get all defensive about Google App Engine and try and blast each of Carlos’ points. Actually not. I do not work for Google and neither does my company currently do any work in Google App Engine. All my investigations into Google App Engine has been purely out of my interest and my goal of discovering a good platform to help showcase some of my applications.

What Carlos has mentioned in his blog post should not be construed as a way to get more publicity or the fact that Google App Engine is completely useless. If a platform or product needs to be successful, it needs to have its healthy dose of people who love it, hate it, just about like it, just about manage to work with it and many more feelings in between. Google is not a stupid company, its engineers are smart too and anyone can easily conclude that they know much more about the shortcomings of their App Engine platform than Carlos or its users, like you and me.

If you have the time to go through Carlos’ post and the colorful comments that follow, one thing struck me in particular. The concept of Cloud Computing is not being bashed at all in totality. This model of computing is real and no one is debating that. Given that, it is important to look at the 3 flavors of Cloud Computing: IaaS, PaaS and SaaS. We will keep SaaS aside for the moment. IaaS and PaaS are clearly defined. You need computing resources (Storage, CPU, etc) and complete control to run whatever you want via your own application stack, go with IaaS. Amazon does a fantastic job over there. To anyone dealing with PaaS, it is clear that all vendors in that space mandate a programming model. There are no Ifs and Buts about it.

Let us dig into that a little. By mandating a Programming Model, the PaaS vendors are clearly telling you that your application needs to be written as per their software stack and the APIs that it makes available to you. You cannot just think about taking  your inhouse web application and deploying it on Google App Engine and think that it will work. No. Never. Unless it is a Servlet, doing “Hello World”. Every PaaS vendor addresses infrastructure by wrapping APIs around it. They give you APIs for Authentication, Data Storage, Caching, Messaging, Networking and much more. What does it mean? It means you have to retrofit your application to use those APIs to get maximum mileage out of the PaaS platform. This is because those APIs are closely tied into how the PaaS will provide you elasticity. Let us look at Database support. Since the beginning of time, Google App Engine does not support SQL database storage (I am not talking about its Enterprise edition that has MySQL support). This means that your data storage mechanism has to be written (or rewritten) to fit into the NoSQL like service that the Google Datastore provides. Does it have restrictions? Is there are paradigm shift in thinking to move to that? The simple answer is “Yes”. But which software in this world does not have restrictions? If it was that simple, the world would have needed only one programming language. Anyways, that’s not the point. The point is that you have to adjust as you move to a PaaS platform. PaaS platform mandate a programming model and you need to follow that. As you go through that, you need to modify your thinking first and then your code and measure, measure and measure constantly what is working and what is not? And keep adapting as per that. All companies do that with their products, especially public facing live applications and this is not different.

Will all applications fit within Google PaaS? You don’t need me to tell you that they will not. What is it particularly that I like about Google App Engine. For me, its biggest selling point has been the low cost to entry (don’t mistake that for zero cost of entry!). I have developed several Proof of Concept applications that demonstrate some idea in my head and hosted them all on Google App Engine. Some of the applications are still live and running today. I have a good feeling what works and what doesn’t and have adapted my applications. I find it works best for applications that you have the luxury of writing from scratch. I would be careful to simply assume that my enterprise apps can be hosted tomorrow as-is on its platform, for reasons described above.

I have talked to a lot of folks about Google App Engine. And I intentionally mention to them things like the 30-second limit for requests and the 1000-record limitation. I think when you mention this to any software engineer, the first reaction is akin to an electric shock and then the outpouring starts. Without even thinking about what application they are going to write, they claim this platform is not for them. Here are some of the remarks that I have heard from them in response to the above limitations : How could Google do something like this? A 30 second limit for requests? Do you know my application will need much more than that? What no SQL? What are you talking? Have you lost your mind? Is there even a thing like that? What happened to your education and those C.J.Date RDBMS primers? 🙂

All the above concerns are valid but my only response is that in a PaaS, it is a give and take relationship. You lose your full control over how you write things. In return you get the scalability for a fraction of the cost. You get your IT infrastructure managed without you even understanding it. Once you understand this symbiotic relationship, which is true in every other aspect of our life too, things settle down and then it does not look “cloudy” anymore (no pun intended!)

One more point. There are enough success stories for both Amazon (IaaS) and Google (PaaS). Ask any of them about their journey and there will be stories of pain, adjustments and finally making it work. There will be companies now, who will post their success stories with Google App Engine too to mitigate the bad press. But I personally don’t worry about that. What I am excited about is that this light started by Carlos, will result in more information coming out about Google App Engine and that includes stories from the trenches. I will be keeping my eyes open to scan resources that will spring up and learning more about the platform. Big Advantage to Google App Engine now, if they embrace the open nature of the comments and actually take up some of the limitations, that even they know about, on a war footing!

Finally I would like to conclude, that there is no point in telling people that you need to read the documentation and understand the platform completely before committing your resources to using the particular product or platform. This model does not scale anymore. It does not get you to the market faster anymore. And it goes very much against the fundamental notion of getting the Early Mover Advantage. Think about how many articles in the recent 1-2 years, that you have come across from even giants like Twitter and Facebook, publicly stating that technology X or Y did not work or scale for them, and hence they had to develop that infrastructure themselves or replace it with something better suited to them.  Are we expecting a Google or a Amazon to tell you, “Hey! You know what? Our platform really sucks if you want to do A,B,C.” They can give some general guidelines and best practices but everything else has to be discovered, shared and that is all Carlos is trying to say here. There will be only one winner in the end, the PaaS platform itself.

Long Live Cloud Computing! Long Live IaaS and PaaS!

Advertisements

9 thoughts on “A few "PAAS"ing thoughts

    1. Hello Ara,

      Thank you for your comments. I agree with you that there are limitations in GAE. It will be true of any platform or software in this world. Please share your findings with all of us. The net result of all this will be more information shared among us and the platform in return will get stronger.

      Cheers
      Romin

    1. Hi Santiago,

      Thanks for your comments. You do have a point about the platform being free and how much we can expect in return vis-a-vis professional support. Maybe there in lies an opportunity for someone to provide services and consultancy. 🙂 Maybe it is also a good time for Google, to revamp a “Best Practices” section in the Google App Engine documentation. Cover more detailed examples for different kinds of applications.

      Cheers
      Romin

  1. While I don’t disagree with any of the points Carlos made in his blogpost (because they are all true statements), I would like to point out the following:

    1) The limitations listed in the blogpost are very well-known constraints of GAE. Most of them are listed here, here, here, and here. Google doesn’t try hide them from developers, in fact they emphasize on them in every GAE related session. I knew about these way before I published my first Hello World app in the App Engine. I didn’t have to write an application to stumble upon these limitations – I just watched the GAE youtube videos. I am not saying that every single limitation (e.g. no support for list of serialized objects) is documented, that would be an impossible task, but all the major ones are.
    2) It is fairly evident from the post that the design for the application called for a SQL DB that supports Full-Text search. So I’m not sure why the developers opted for GAE, since GAE is NoSQL with No support for Full-Text Search. Poor architecture decision. If you have already selected a development stack, than your design should account for that stack. You shouldn’t have to create “workarounds” during the development cycle. OR select a development stack that suits your design.
    3) When the developer decided to finally quit GAE (PaaS), they chose Amazon EC2 (IaaS). This is very telling. They didn’t move to another PaaS offering, but to an IaaS offering which gives them full control over the development stack. This tells me that this particular development effort was not well-suited for a PaaS to begin with. So GAE was not the root cause of problems, but working within the constraints of a PaaS and NoSQL offering was.
    4) I completely agree with the stability issues that plagued GAE early this year. I was very disappointed too. Not good for Google’s reputation. So they reimbursed their customers for that time period, and made several improvements to the GAE to prevent those issues in the future. Only time will tell if those stability have been fully addressed.

    Google App Engine works very well for certain things, but not for everything. It is an PaaS offering, not an IaaS. All PaaS offerings have their limitations, and absolutely no freedom for customization of the development stack. This is how they can offer such scalability at a low cost. If the application requires customization of the development stack, than perhaps, PaaS is not the way to go.

    Saqib

    1. Hi Saqib,

      Thank you for the detailed comments – very valuable that you shared your own experience about it. I agree with your points vis-a-vis PaaS and SaaS. I particularly look at any PaaS at not being restrictive in any way. In fact, I look at it in a slightly different way that since they are providing a programming model and API, a certain kind of application will be so easy to write with them. Imagine if in a IaaS, we had to look for how to bring in XMPP, BlobStore and many other services. Yes solutions exist, but you will need to figure out the right image to have all these services.

      Thanks for your comments once more. Very spot on in your analysis.

      Cheers
      Romin

  2. Great article. I would just like to offer a correction about limits. Google has removed the limit on queries so you’re no longer limited to 1000 (yuck). Also, they announced that their next version rolling out in the next couple of months will give cron jobs and task queue requests a time limit of 10 minutes, up from 1 minute IIRC.

    1. Hi Jon,

      Thanks for your comments. You are spot on — the 1000 record limit has been done away with for a while. The upcoming 1.4 Release of the SDK has some excellent features as you have rightly mentioned about the cron/task queue time limit to 10 minutes. I am also excited about the warm instance feature, though you have to be a paying customer to enable that feature — but still, it is going to be available. All in all, some great features are coming in, some could address the current issues developers have and at the same time, I am quite confident Google is going to roll out more as time goes by.

      Cheers
      Romin

  3. Good analysis on Carlos’s feedback. All boils down to this that if you have to select a PaaS then you have to adhere to its limitations or restrictions. Only the stability point mentioned by Carlos seems a genuine grouse.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s