By guest author Shaloo Shalini
SM: What you are saying is that bigger players in the space, such as Salesforce, are going to do that kind of integration and provide that capability to their customers?
NS: Well, I think it will be Salesforce and any company that has data which needs to be processed for analytics. So, a lot of those Salesforce customers who are generating data are going to provide APIs to sift through that data in the cloud.
SM: My sense on Salesforce is that other than providing APIs, they will bring a comprehensive suite of applications into their fold, one that is beyond what they already have. I think they will make a series of acquisitions to provide a comprehensive set of analytics capability within their own offering. Do you agree with that?
NS: Yes. It makes a lot of sense because they already have many support features in their ecosystem which they can use to add specialized solutions such as analytics to their core.
SM: In general, one of the big technology-enabled management trends is the increase in use of matrices. To be able to do matrix-based management in large or small organizations, you need a certain amount of analytics. For example, if you are trying to use cloud computing in your sales domain, you need to get a good handle on forecasting and on stitching that into your financial system. People do this already, but it is a complex process today; those integration points are not easy to deal with.
NS: Yes, I think that is the case. One of my clients called that “integration as a service.” Correct me if what you see is different here, but I believe that such integration is more of a mash-up solution because in the future, many such requirements and functions will be offered as a service. We won’t even need to install solutions to get them up and running and for integration – it will look like a mash-up. There will be applications running on the cloud that will be just for referencing different applications that already sit somewhere else, and we need to make them connect and communicate. Service-type switches might be a part of that model.
SM: Well, that would be ideal, but I don’t believe we are quite there yet in terms of the underlying APIs and the ability of different applications to talk to one another.
NS: No, it is not there right now. But let me give you a good example. When I needed to integrate monitoring services into my application at GigaSpaces, I could use New Relic. New Relic is a monitoring service to which my application can hook up to get monitoring capabilities. When I needed to add analytics to my application, regardless of the service, I could plug into Google Analytics – and that is already happening. Even Web sites are already connected to many of those monitoring and analytics services. It is already there, to a degree. I think the change is happening faster than we all believed it would.
SM: How much time to do think it will be before integrations will become seamless and smooth, making analytics more viable as a way to connect applications?
NS: You are talking about analytics integration, right?
SM: I think that the integration question is the biggest when it comes to analytics. Even in the cloud, ERP vendors are different from CRM vendors who are different from analytics vendors. If I have to do forecasting on a large data set from one of my Salesforce or RightNow applications, well, that is still a pretty complicated task.
NS: Yes. It will remain so for the next three years at least. Unless of course, such functions are provided by the actual vendors – in the case of Salesforce, it will remain relatively complex. There are specialized integrations such as force.com or vmforce.com that will enable more flexibility that I can plug into my system and complement my Salesforce ecosystem. But there is not a generic way in which I can throw in a couple of applications and have them connected to each other. There already are point solutions for certain problems, but generic solutions require more generic interfaces for integration, and we are are just not there yet.
SM: Do you have any thoughts on standardization? Is the entire process of cloud adoption and integration going to become simpler at some point through the establishment of standards?
NS: Well, there are two types of standards. One of them is the de facto standard, for example, the EC2 and Eucalyptus implementing EC2 APIs. The second type includes standards such as vCloud APIs, which VMWare is pushing to define and drive some of its cloud offerings as a standard. We know that standards always lag the industry. So, they are not going to be able to cover the entire universe of the cloud. Within the cloud, in certain domains and groups there will be standards. For example, if you look at computing and network, they are going to be standardized. The rest will lag, if they are standardized at all. If you look at enterprise IT right now, you can see that the majority of enterprise priority services are not only standardized by infrastructure but by business network. The same thing will happen in clouds.
SM: What are the pricing models in the cloud? For example, there is the fixed monthly fee for user licensees model vs. user- based keys, and fees as a percentage of revenues vs. fees as a function of the number of clients. So, there are a variety of pricing models floating around. What are your thoughts on those?
NS: The benchmark clearly is Amazon when it comes to pricing in the cloud. Obviously, Microsoft Azure is getting there with a slightly different model. Microsoft is the closest to Amazon from a competitive perspective. I am not sure that it will have as big an impact as Amazon, though. People will go to Amazon because it provides a wider set of services. So, it is not just from a pricing perspective but from how much it is going to cost. You don’t become an Amazon customer simply because of the cost; you go there for the elasticity, rich framework, and functionality. The same is true for Microsoft Azure. If you need Oracle, Rackspace provides you Oracle. But you go for Azure because you are a Microsoft shop, and using Azure is the only way to deploy Microsoft applications and use Microsoft services in the cloud. Those are the two big players that right now define the benchmark for clouds in terms of pricing models.
SM: Can you summarize what Microsoft is doing compared to what Amazon is doing in terms of pricing strategy?
NS: Microsoft’s case is very interesting. They are providing what they call software by services. It basically means that they believe that the first step the user will go through is to have it all together. They understand that some services will be in the cloud and some will be on-premise, and their strategy is to leverage existing Microsoft users. They are taking steps to ensure that the .NET community or Microsoft community will not need to go somewhere else to use those services. That is where Microsoft is coming from. And Microsoft is approaching the cloud with a large set of services starting from Exchange and regular prepackaged software into software as a service, middleware, messaging, and everything build around its own stack.
Amazon, on the other hand, is taking a more generic view of hosting; let’s call it “hosting++.” What it provides is regular hosting but with a lot of elasticity built in. That is Amazon’s differentiator, and now it is adding services such as Web launchers and the ability to manage applications running on Amazon. For instance, there is a cluster management add-on service running on top of the existing EC2 core services. Amazon is coming from a generic hosting++ approach. Microsoft is virtualizing the existing packaged software; it does not let you put an image on your cloud server resource as Amazon does. Microsoft is more PaaS than IaaS because it does not let you take a generic route when it comes to the OS – it is more like an engine than infrastructure.