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!