As Jelastic grows faster and faster, more and more people are hearing about us and they want to know how we compare to other PaaS available out there. We already did a comparison of Heroku vs Jelastic a little while back, but people wanted more. So here it is.
Why Does This Matter?
If you are already using Jelastic, you most likely don’t see any reason for this post; and I would agree. That said, there are others out there that aren’t sold, convinced, or are sitting on the fence wondering about whether or not making the switch is worth it. Hopefully, this short post will help you understand the biggest differentiators between Jelastic and Google App Engine.
The Big Picture
One of the biggest issues that you have if you want to use Google App Engine is that you can only get it from Google. So, if for some reason the price goes up (wait, that already happened…) or the service quality drops, you really don’t have anywhere to go.
Another huge issue is compatibility. If you are used to using open-source, standard software stacks—the way pretty much everything is going (I’ll talk about this soon when I write about what I learned at the OpenCF Summit)—then you are also out of luck. Most of the major PaaS out there, including Google App Engine, use custom application servers
All that aside, there is a reason that a lot of people still use Google App Engine. It is a good product. But, after reading this comparison, I think that you will see that Jelastic isn’t just good, it is awesome.
Details : The Nitty Gritty
For the sake of brevity, I will keep this list to 10 points and I won’t go over the above-mentioned points about availability and lack of standard software stacks.
Relearning: with GAE you have to do a bit of learning. First you have to learn about their app engine and then you have to make sure that code your app the right way so that it works with the engine.
Code changes: unless you coded your app with GAE in mind, you are going to have to do a bit of recoding, or a lot. This really all depends on your app, but it seems to me that any code changes should be for app functionality and not because the platform demands it.
Portability: code that you write within GAE can’t be ported anywhere else, not even Heroku or DotCloud. It’s special—in a bad way.
Support: very limited customer support and the documentation is woefully inadequate. Though the App Engine Google Groups do answer a lot of questions, there are still a ton of them in there that are not answered.
Errors: if your app doesn’t load within a minute, be prepared for a 500 error from GAE. You didn’t know about that? That’s because it’s not really written anywhere. (it is buried in the forums)
No custom domains. You can’t use HTTPS with your own domain. You have to run everything through yourname.appspot.com. #lame
No ability to do a big update. You have to use map reduce.
No streaming and no long-term connections. Not sure why they did this, but it is counter productive considering that streaming is a huge part of a large part of the web.
If you want to work with Twitter or Facebook, you will probably have to get intermediate servers because every GET and POST from the server to the other is aborted if it does not finish in under 5 seconds. You can change this to 10, but even then, all you are doing is duplicating work and doubling the amount of time it takes for things to get done.
You app is in Google’s hands… God forbid something happened on Google’s end: you would be at the mercy of Google. And don’t bother trying to reach someone at Google to ask for help (see above point about support).
You can’t JOIN two tables: more complexity in your source code in order to make queries.
Databases are really slow. It gets complicated fast here. If you want to know more, read up on how to separate tables using inheritance so you can do searches within. Then get the key. Then obtain its parent so that you can avoid the crazy things that happen if you don’t.
Your development environment server is not the same as the one for production. So, you have to have some tests (you have to come up with these, manual or selenium) to run them against the Cloud: more money.
No access to the file system: more time wasted learning about and then working around this.
Throttling and quota issues: if you are calling third party APIs, you have to keep in mind that those IP’s are shared with other apps.
Youe Java instance might need to be rebooted if it hasn’t been…. Wait. I said I would keep it to 10 points and I am over that.
If you are okay with doing things Google’s way and putting up with all of the roadblocks in place to deploy your app to the Cloud using Google, then GAE is for you.
2012 has for a long time been associated with a whole range of different eschatological beliefs, the common theme being that 2012 will be the end of the world. But, if we are still here at the end of this year, I believe that we will be able to look back and see this year as groundbreaking in a number of ways. This will be the year of all things mobile, HTML5 and 4G, and to a growing number of people, the real year of the Cloud.
Though many people out there are still debating the safety of the Cloud and worry about the implementation of it (see Symantec’s recent “State of the Cloud” survey),
the truth is that once something has made it past “early adopters” (generally this group includes developers) and is working its way through the “early and late majorities” (Roger’s Innovation Adoption Curve) it is going mainstream. If anything, right now, the Cloud is going through the fast acceleration of Roger’s S-curve and not the traditional adoption Bell Curve: there was a period of slow adoption until the social and technical factors aligned for its explosive growth.
All that said, if anything, last year (2011) was the year of the Cloud. Although that can be debated, the truth is that this year is the year of the Platform-as-a-Service. There are a number of reasons for this; foremost among them is the fact that the PaaS is the next step in the evolution of computing, and more specifically, the Cloud.
Without the Cloud, the PaaS as we are seeing it could not exist, but even more than that, the PaaS takes all the advantages of the Cloud and makes them available in a way that eliminates the need for the end user to have to manage any lower level resources or infrastructure. The automation that the Cloud allows for is realized in its proper form with the PaaS.
There are number indicators that support this, from the more mainstream web-centric platforms like Amazon.com, Google, YouTube, Facebook, iTunes and Twitter, to some of the up and coming PaaS that will be game changers for the developer and the product manager, like Google App Engine, Engine Yard, DotCloud and Jelastic.
As more and more developers become aware of the benefits of the PaaS, the move away from the traditional model towards the new, web-centric, browser based model will accelerate. That trend has already started, developers want to be able to focus on what’s important to them—functionality of their application—and not have to worry about the underlying structure. Web hosting providers can take advantage of this by focusing on what they are good at—providing and managing computing resources and infrastructure, servers and hosting, and support for those resources—and then providing a PaaS that users want.
2012 is the year of the PaaS. The Cloud has allowed it to happen. As more and more end users and service providers jump on the bandwagon, the opportunity to take advantage of the developers need for the PaaS will only grow.