Skip to main content

Why should your startup deploy on Google App Engine?

To start with, let's hear it from the horse's mouth:

"What Is Google App Engine?

Google App Engine is a Platform as a Service (PaaS) offering that lets you build and run applications on Google’s infrastructure. "
But what does it bring to the table, when it comes to deciding how and where to host your application when you "start up"?
Besides all else, first consideration is cost. As a startup, let's face it, you'll be broke. Pricing for app engine is based on traffic and usage, and while we would want a lot of traffic it won't happen at the onset. Until your product really kicks off, you get it all for free.
The application being built as modules, also allows developers to apply principles guiding enterprise application build. And viola, you have a highly scalable enterprise application built on a robust and high availability platform.
A product at its onset will also be dynamic (hope it is stable before you install, unstable products create bad reputation). You will have a lot of changes to make to your product as you get more knowledgeable about your market, trends and end user behavior. Google app engine allows dynamic install, which means zero downtime for your application, unless absolutely necessary.
All this is great but the question might be asked, what happens when your product, actually, grows big. There will be a point where usage based cost will show diminishing returns. With that argument put forth, considering enterprise like Best Buy are on app engine, that point will not come too fast.
Yet, some day you might want to get out of app engine, diminishing returns or some other reason, and install it on your own hardware. Times change, requirements and decisions too. It is always good to have an exit strategy. And that makes Google app engine a great choice at the onset.
Porting your application out of app engine as and when needed, will be quite easy. Once your product has earned its fair share and you might want to port it on dedicated infrastructure, you sure can. Since the application is developed using standard languages such as Java or Python (hope you choose one of these two only), it can be easily moved to dedicated application containers.
In addition to the ability to port, the app engine applications can, and should, be built as modules. That means, it is not necessary to port the application in one go. That also means parts of the application may never be ported. Integration with Google high replication datastore and Google drive is awesome enough to never go away from.
All in all, it will be a good decision to build your application on Google app engine.

Labels:

Comments

Post a Comment

Popular posts from this blog

Catch hold of that Exception and hide that stacktrace!!!

E xceptions happen!!! Rules are to be followed, too. Time and again, Java developers are told the golden rule to catch specific exceptions and not to catch the generic Exception. The thought process behind that is, applications should not catch runtime exceptions. This is apt as runtime exceptions are an indicator of "bugs" in the code. However, blindly following rules, as always, can have unexpected consequences. If you are developing services that are to be exposed over the wire, it is always a good idea to break this rule and "catch that Exception". Instead, follow the below principles: Service methods should implement a generic Exception block, along with catching declared exceptions, thrown from inner layers of the code.  If needed, the service can throw another exception back to the client. What's important is that we create a new Exception instance to be thrown, along with relevant message for the client. The service can log stacktrace for the E...
Post a Comment
Read more

Using JNDI managed JMS objects with Apache CAMEL

Apache CAMEL uses Spring JMS to work with JMS Queues or Topics. Evidently, we will need Spring to configure and use JMS capabilities provided by CAMEL. Details about how to implement JMS based routes using Apache CAMEL can be found in the CAMEL documentation. However, the documentation leaves a lot to be figured out. In a typical Java EE container, it is usually a good idea to abstract the underlying JMS resources by using JNDI. We can use the below configuration to achieve that. This configuration is tested in Websphere environment, but should work in any JEE container. Create a JMS queue connection factory in the JNDI registry. CAMEL configuration will be able to use only one queue connection factory, even if we have more than one. Create one or more JMS queue or topics, in the JNDI registry, as required. The above two steps are related to generic JNDI configuration for JMS resources. Now we come to the setup required for making these JMS resources work with CAMEL rout...
Post a Comment
Read more

Cassandra data modelling: Redundant data, a tough decision

The biggest challenge around building an efficient data model for Cassandra is data redundancy. Though the basic rules for data modelling with Cassandra, mention the usual RDBMS modelling goals, as non goals for Cassandra (Refer:  Basic rules for C* data modelling ), it builds upon assumptions that clusters are built on commodity hardware, storage is cheap, and as data needs increase more nodes can be added to the cluster incurring very low cost. But in real life we are faced with technical as well as non technical problems. a. Keeping multiple column families in sync can be a major overhead, if the same data is spread across them. What if writes to some CF succeed and some fail? How long and how much will we retry? b. Horizontal scalability may be a truth, but think of a mundane question of where to keep all those heat producing, energy guzzling machines? So how do we model the database that does not allow joins without redundancy? The simple answer is, we do not. Wh...
Post a Comment
Read more