March 25, 2014 is a day to remember. A day where Google broke through the ranks with a series of announcements that clearly demonstrated that there was no need to play catch up in the Cloud Platform wars. Instead, how about leapfrogging the competition on multiple fronts?  It did exactly that. Check out the Cloud Platform Live Event.

Google India announced the Cloud Platform Roadshow across 5 Indian metros through April – May 2014. The series kicked off in Hyderabad on April 12 and since then has moved across to Chennai, Bengaluru, Mumbai and is set for Delhi this week.

The day-long event had talks on:

• Recent Cloud Platform announcements from the March 25 event
• Pricing Details on the Platform
• Compute Engine : Overview and Live Demo
• App Engine : Cloud Endpoints – writing APIs at Google Scale
• Bridging the gap between PaaS and IaaS : Flexibility + Manageability
• BigQuery : Query TBs of data in seconds ! Yes you can !
• Case Studies of actual customer implementations
• Partner product demos

While I did present at these events, my personal favorites were the Compute Engine and BigQuery sessions, where I learnt a lot. I could not help but hear the wow’s of the audience when they saw what BigQuery can do. Janakiram clearly rocked the audience with his Compute Engine sessions. Googler’s Rohit and Anudeep are all set to make their future talks “must attend” with their ‘jugalbandi’ (fusion or beautiful mix) in presenting technical topics.

If its been a while you have taken a look at the Google Cloud Platform, you owe it to yourself to learn about the various services that are now under a single Cloud Platform umbrella and present a more unified and complete solution.

I was delighted to present the App Engine session during these roadshows and I focused on Google Cloud Endpoints, which provides a service to create RESTful APIs powered by the App Engine platform. If you are looking to scale up your APIs and power it with Google’s infrastructure, Endpoints is the way to go. You can check out my slides.

The number of queries and feedback from the participants was excellent. Some of the questions are solid enough for me to go back and think more on how it can be addressed. It was very encouraging to learn from some of them that they were excited enough to try things out soon and learn more about the platform.

As of writing, the roadshow makes its last stop at Delhi on May 31. If you live in and around Delhi and want to learn about the Google Cloud Platform, come and spend May 31st to get vowed with multiple product demonstrations. Click that Registration link.

This blog post was original published at the following URL : www.xoriant.com/blog/cloud-computing-for-isvs/cloud-computing-the-definition.html

Cloud Computing now finds a way through most technical discussions. Irrespective of the medium (Web Search, Twitter, Online Journals), you will find Cloud Computing being discussed. But ask anyone the definition of Cloud Computing and you will be hard pressed to get two exact definitions from different people.

Some define it as servers available for rent to storage or applications that we access from the browser, etc. All of them are right in ways. But is there a definition that describes the essence of Cloud Computing. While there might be various definitions of that, we shall look at one of the definitions of Cloud Computing in this blog post. It is known as the 5-3-4 Formula.

The 5-3-4 Formula is further broken down into the following:

5 key characteristics

The key characteristics are:

• On Demand Self Service: As the application owner, you should be able to provision additional computational resources for your application, look up reports and perform Administration tasks without requiring human intervention. Cloud vendors are now providing monitoring and provisioning tools where the user is in full control of provisioning things.
• Ubiquitous Network Access: We are living in a world where a desktop and laptop computer is not the only way that people access the Internet. Mobile device access is increasingly becoming a major source of traffic to your application. And it is not just mobile devices but devices fitted in vehicles and even our Televisions that are accessing the Internet. These explosion of device types and various networks around the world brings to the important concept of “ubiquity”. It means that no matter from what device or network , one should be able to reach your application via the public cloud networks. And this access is the cornerstone of cloud computing. Always available and from anywhere.
• Location Independent Resource Pooling: This feature is key to providing your additional resources. As a consumer one should not be worried about how the cloud allocates additional servers, takes care of multi-tenancy and allocation of physical and virtual servers in different geographical locations to meet your demand. Location Independent Resource Pooling is the ability of the Cloud to do exactly that.
• Elasticity: If you have released any online web application you can now look back and see those days where the number of hits to your sites peaked due to a new release or a press announcement. There will be spikes in user activity and you cannot scramble around for additional hardware when that happens. Cloud Computing addresses this through Elasticity. What it means is that the Cloud Vendors will automatically allocate you more resources as your application needs it. Extra Servers, more memory, more storage, etc will be available to your application if the need arises.
• Pay per Use: This is one of the key characteristics and one of the reasons for cloud computing gaining acceptance. Just like you can seldom predict your peak usage, it is important that you pay only for the amount of resources that you use. Cloud Computing vendors have various schemes starting with freemiums and then tiered pricing that clearly specify the quotas that are available based on what they charge you. At any point in time, you can switch between plans and allow for extra charging depending on additional resources that your application might use.

3 delivery models

Cloud Computing is typically delivered in 3 models and each one builds on the other

• IaaS : Infrastructure as a Service. This layer is about providing processing power (CPU cycles), storage, bandwidth, networks and other infrastructural resources. Some of the key players over here are Amazon Web Services (AWS) , Rackspace and others.
• PaaS: Platform as a Service. This layer builds on top of the IaaS layer and provides a developer with a complete stack on which to build applications. The stack comprises APIs that abstract out the low level details and allow the developer to quickly use them to build out the application. The key players in this space are Google (Google App Engine), Microsoft (Azure), Sales Force (force.com) and recent entrants like CloudFoundry from VmWare.
• SaaS: Software as a Service. In simple terms, these are ready made applications that you can use either for free or a fee. You simply need to sign up, optionally pay and login to use the software. Examples of this include SalesForce (CRM), Gmail, Google Apps, etc.

4 deployment models

The 4 deployment models available are given below:

• Public
• Private
• Hybrid
• Community

Typically, the public cloud is what is best known to most of us. While classification does exist for other types like private, hybrid (mix of public/private) and community – they are not that prevalent and no clear classification exists. So for all practical purposes, when we refer to the cloud, it is public and with appropriate authentication and access control mechanisms built in.

So the next time, someone asks you to define “Cloud Computing”, you can simply say “5-3-4”.

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!