By Sramana Mitra and guest author Shaloo Shalini
SM: Are you using a platform as a service (PaaS) solution as a base to move your applications to the cloud? Are you using Google App Engine or Force.com or something similar? How are you putting those applications on the cloud?
SB: Well, clouds mean different things to different people. We primarily use virtual machines on the cloud. The really advanced versions of the cloud, which is what the Google App Engine or elastic applications on Azure are, we don’t really use those yet. Not all of our legacy applications are geared to make use of it. We have a very small trial application on Microsoft Azure, and we are not there on the Google App Engine yet; we don’t have anything serious on the Google App Engine.
SM: What about the Google App Engine itself? Have you started evaluating it for this purpose? Again, I hear a lot of different perspectives on the Google App Engine. Do you have anything to add about it?
SB: Well, we have done trial applications on the Google App Engine and it is a very cool platform, in the sense that it is a true cloud. In other cases, when you say cloud you actually mean the platform. So, you take your virtual machine that happens to be in a cloud environment, and the way we access is in terms of specific capacity configurations. We say, give me a 2 CPU, 1GB RAM machine, and I am going to run a regular application on that cloud instance. With clouds, the same application can be run on any 2 CPU 1GB RAM physical machine; I run it on a cloud-based virtual machine with similar configuration specifications. But Google App Engine is not that. Google App Engine deployment is deploying an application and building as many computing units as you use to run that application. If you use one unit it will give you one unit, if you use 10 million units, it will give you 10 million units. But there is no implicit size for it. There is no large instance, small instance, large machine, small machine, kind of configuration associated with it. It is like you have an infinitely large machine on which you run an application, so in that sense it is like the old mainframe days.
SM: What you are saying is the advantage of Google App Engine is that it has the flexibility and scalability to deploy applications almost as a utility?
SB: It is truly a cloud in the sense there is no carving up of cloud-based resources into small virtual pieces that you are making look like a physical machine. In a cloud environment, such an instance is equivalent to, say, 1 GB, 2 CPU physical machines, and your application can never use more than 1 GB even though the cloud itself may have GB capacity in the hundreds. On the other hand, in the Google App Engine’s case, you don’t need to specify the size of the physical machine; you have deployed an application and they will bill you. If you use a lot of memory, they will bill you for it; if you use a lot of CPU, they will bill you accordingly.
SM: So they run Google App Engine as a utility, right?
SB: Yes. To a user, it appears as a single machine of infinite size.
SM: Got it. Are there any other workloads in your organization that you would like to move to the cloud?
SB: We run our learning management system (LMS) on a cloud-based server located on the Amazon cloud.
SM: You have a learning management system on the Amazon cloud?
SM: Which learning management system is that? Is it your homegrown application or an external application?
SB: It is not a homegrown application; we purchased it.
SM: I see, you purchased the software and put it on the Amazon cloud. Would you tell me more about that? Who sells this LMS that they are willing to put on the Amazon cloud?
SB: In India, there are quite a few providers that have started delivering their offerings in the cloud. This particular one is by a company is called ExcelSoft. The reason we are on the Amazon cloud is because ExcelSoft supports their solution on Amazon as it works best with the Amazon cloud.
SM: What is the situation with the Amazon cloud in India? Does it have a delivery center in India especially for Indian customers?
SB: No. The Amazon cloud instances we use for our LMS are hosted on the East Coast of the United States.
SM: Is that a good idea?
SB: I don’t see what difference it makes.
SM: There has to be some kind of latency that users from India observe in using instances from the East Coast of the United States. From a user’s point of view, I can see there is no difference, but from a telecom charges point of view, is it a good idea to have a data center on the East Coast catering to India?
SB: There is no extra telecom charge. Telecom charges are only on the last mile, anyway. It’s the same charge whether you access Google sites locally in India or in the United States. You are not taking a leased line into the United States.
SM: Fair enough! From the Amazon’s point of view, they have to service customers, and they need their own infrastructure. That Amazon infrastructure has telecom charges, right?
SB: No, not at all. See, how the Internet works is that you will finally connect to your nearest backbone carrier. You don’t pay for the worldwide traffic. At times I am using Google or if Google is accessing me, neither Google nor I pay anything special for that kind of access. The backbone infrastructure is part of the cost of everything on the Internet. The Internet is everywhere, so the backbone infrastructure is part of the cost of the last mile itself; there is nothing special about accessing it from anywhere in the world. Otherwise, nobody in Iran would access Twitter.
SM: This is what Akamai specializes in. It may not be an issue when you are not talking about high-volume stuff, probably.
SB: Well, there are no guarantees about speed on the Internet. So Akamai says, if you don’t want a public infrastructure, then I will give you a paid private infrastructure. With Akamai, you will pay separately for the guaranteed bandwidth, but even in the Akamai case you don’t pay by distance; you pay Akamai a fixed charge. We also use Akamai. We paid them a fixed charge based on bytes irrespective of who in the world accesses us or we access.