Last week, I published Part I and Part II of my recent interview with Rajen Sheth, aka the inventor of Google Apps. Throughout Part II, Sheth and I discussed the degree to which the pre-release version of Google's open source browser Chrome represented the sort of browser-side innovations that might take Web-based applications (such as those that are found in Google Apps) to the next level. Google can and does of course push modern day browsers to their limit with the coding it does on the server-side. But there's only so much that can be done on the server-side to take Web applications to the next level before the browser must reciprocate.Beyond some of the forward thinking in browser design represented by Chrome (such as a built-in persistence mechanism for off-line operation of Web applications), there's still plenty of work to be done on both sides of the pipe, particularly when it comes to Google Apps.

Reliability is still an issue for "cloud-based" applications and Google isn't immune to challenges of delivering a highly demanded Web app on scale. Earlier this year, Google's e-mail service Gmail experienced a disruption in service that affected Google Apps users as well as basic users of Gmail.

One of my personal pet peeves with Google's suite of applications is that some of them such as Google Reader (Google's Web-based RSS reader) are still not available to users of Google Apps under their Google Apps ID. The net result is that while I'm logged into Google Apps under one ID (my Google Apps ID), I must log into Google Reader under a different ID in order to use that application. With multiple ID systems under Google's hood, the opportunity for integration between some of Google's applications is lost.

In this Part III of the interview (the final part), I ask Sheth to look forward and tell us what might be coming from Google next in the way of improvements to Google Apps, including what Google might be doing to improve the interoperation of Gmail with the different e-mail clients that people use (and that struggle to work well with Gmail given some of the architectural differences).

DB: What else is missing from the fabric? If persistence is one of the things that's missing, what would you, as the inventor of Google Apps, like to see happen to the browser or for that matter to the Internet to give you a better platform to deliver what you now serve to your customers?

RS: I don't think we know the answer [to that question] quite yet. For example, if you asked me that same question three years ago, I may never have known that things like a Flash player to display video within a browser was going to be absolutely crucial because video is going to be really important. I don't know if we really know what are some of the things that are going to continue to extend this to the next level. I think continuing to add innovation to browsers and to the infrastructure that make the Web paradigm a more and more powerful way to deliver applications will be needed here. That ranges from everything from functionality within the browsers to the pervasiveness of high-speed Internet connections to the kind of infrastructure innovations that are going on for the various clouds where applications are deployed.

DB: Identity seems like a big one.

RS: That's true. Identity is a big thing. Having consistent identity across applications. For example, one of the things we support in Google Apps is SAML so that we don't have to be the arbiter of all identity. We can plug into an identity management system that people might have somewhere else. That's an area where there's going to continue to be some innovation and we need to get to the point where you don't have to have a different identity between your instance of Google Apps versus other cloud providers versus what you have internally with any company.

DB: What about challenges within the Google portfolio. Doesn't Google have to address it's own portfolio first?

RS: Yes, rationalizing identity across Google's applications is part of this step, too. Extending that further will make it even more powerful. We have the notion here that there are multiple clouds out there and there always will be; [clouds] where people are going to use some services from here, some services from there, and they're going to want to make these work together. Figuring out how, from an identity point of view, we can make those integrate, but also from just a pure integration point of view, how can we make it easy for those kinds of integrations to take place, is going to be critical.

DB: Do you pressure the guys from Google Reader, Picasa, etc., to make it so that when someone is logged into Google Apps, they can be logged into those Web applications [from Google] as well?

RS: Certainly we're pushing on it. We're bringing in more and more applications that support the Google Apps identity. There are a variety of reasons why that's a difficult problem to solve.

DB: Such as?

RS: For example, [Google Apps] may have to tie into a corporation's single sign-on system versus a consumer account which doesn't need to. So, there are a variety of systemic things that need to happen to make sure that a corporation can control their Google Apps accounts. For a variety of reasons, it makes it a difficult problem. However, we're working on it.

DB: We talked about this last time. One of the ultimate collaborative applications is tagging. Let's say I tag 15 things for being relevant to a research project that I'm working on with some other people and I'm tagging (labeling) e-mails in Gmail and I'm labeling things in Google Reader. If there was a common identity system between the two of them, I could go in and say show me everything I've tagged for Research Project #1 and it would bring all of these items across all the Google Applications that I use. Any progress there since we last spoke?

RS: I think there's definitely been progress. Not specifically on tagging, but on integration between the apps. One of the best examples is Google Sites. Google Sites gives you the ability to very quickly put up and edit [Web] sites. But we firmly realize that a lot of your content is not in Google Sites. It might be in some calendar somewhere. Or it could be in this document here, or that spreadsheet over there. Or this slide show that you have. So we now have this ability to combine all of that and dynamically pull all of that information from many, many applications into a cohesive site. So, it's one of the examples where we are leveraging a common infrastructure. But definitely, there's more that needs to happen to continue to bring the applications together.

DB: A lot has changed over the last year. We talked about adoption earlier. Any really big enterprise wins that you like to show off to say this is a major win for us and a major win for cloud computing as a proof point?

RS: Yeah, yeah. We've talked about a few this year that have been really, really successful for us and are in various stages of deployment. One of them is the Washington, D.C., government. They migrated all of their employees to using Google Apps for a variety of purposes. Then there's Sanmina, which is a contract manufacturer just down the street here that's using Google Sites for a lot of the things that they're doing. We announced Taylor-Woodrow in the U.K. and Telegraph in the U.K. as well. Postini has had a number of large wins. For example, GE. The academic area has expanded like crazy over the last couple of years.

DB: Earlier this year, Gmail had its share of problems, and was very publicly thrashed [in the blogosphere]. What was the fire drill here and the impact on Google?

RS: We have a rigorous process for dealing with outages like that, including making sure that we're all in the loop and it's escalated to the right level, making sure we are getting regular updates out to the users. For example, on our user forum, you would see updates literally every 15 minutes about the state of where things were at. Outages are not something we would ever want to happen.

After the outage, there are a few things that we've done. First, we held a post-mortem. Not only were we thinking about how to make sure that situation doesn't happen again. [We were asking] "What can we do to prevent similar kinds of situations going forward?" The second thing is to communicate with customers about that. We spoke with many of our customers. We now have a lot of enterprises that are on this system. So we talked to many of our customers about what we did. We'll continue to do more and more about how we communicate with customers during and after an outage.

DB: Amazon had a big outage this year with its S3 storage service as well. Between that outage and Gmail's, do you think confidence may have been shaken in cloud computing at all?

RS: Potentially, but I don't think so in the grand scheme of things. I think if you look at the overall reliability of cloud computing vs. the overall reliability of on-premises systems -- when a system for a 30-person company goes down, you don't hear about it all that much. When Gmail goes out, you absolutely hear about it. So, if you compare the overall reliability of the systems, [Gmail] has still been well more reliable than your typical on-premises system.

DB: It has? Because [Amazon CTO] Werner Vogels said at MIT's Emerging Technologies Conference "We just have to be more reliable than on-premises systems" and that that's pretty much the benchmark and they will get there.

RS: I think we have to be more reliable than that. I think we need to be more reliable than on-premises systems. But we need to continue to improve the reliability and make it better and better and better and add functionality to the infrastructure to make sure that these services are more and more available. We've been doing that a lot here over the course of the last two years to dramatically improve the availability of our systems. We'll continue to do that. Nobody ever wants an outage. But the reality is outages will happen. What we need to do from a preventative point of view is make sure we can prevent these outages and that we can react well and get up and running as quickly as possible in the event of a situation like that.

DB: APIs? Where do the various Google Apps stand in terms of programmatic access via API?

RS: Just about every Google App now has an API. Gmail has the IMAP API that people are using in a variety of ways; everything from bringing mail into a client to more programmatic access of Gmail. Then there's Calendar. A lot of people are using the API to that for a variety of purposes. And then Docs. We've seen some really innovative use cases on top of the Docs API.

DB: Let's talk about IMAP for a second. I've attempted and I do use Outlook on top of Google Apps mail with IMAP as the interface. It leaves a heck of a lot to be desired. I don't think any IMAP client does it really well. You guys must have some feelings about that because, ultimately, it pushes people back to the Web interface, which may not be what they want, particularly for someone like a road warrior who may need access to their e-mail on a plane or something.

For example, today, if I want to delete an e-mail (in Outlook), I cannot press the delete button. I have to drag the mail to a folder that corresponds to the label in Gmail ("Trash") that represents deleted mail, which is different than the folder that Outlook automatically moves mail to when its deleted. When I used Mac Mail, it got very confused. The performance was awful because of the way an e-mail in Gmail can be tagged with multiple labels and how, on the client side, such multilabeling triggers a huge amount of traffic and additional usage of storage as Mac Mail figures out how to simultaneously store the same e-mail in multiple folders.

It seems to me that it's a shortcoming of IMAP as a protocol.

RS: To an extent. There's a variety of things here. We are continuing to improve how we do IMAP. There are limitations of IMAP in general. There are limitations in the clients themselves. Certain clients are very good IMAP clients and certain clients are not. In addition to that, one of the things we're focusing on is how do we continue to improve integration with clients that are out there. I think it applies to mobile clients as well as to desktop clients. So, we're bringing out a variety of functionality, like Calendar Sync on Outlook or on BlackBerry, and using IMAP in a variety of different contexts as well.

But one of the difficulties here is that not everything maps well because one of things that we're trying to do is innovate on e-mail. So, the concept of labels (what Gmail uses to classify mail items) doesn't map directly well into folders because when you put something into a folder, great, you've put it into a folder. But you don't get to leverage the value of Gmail where you can actually put multiple labels on a message. So, we're trying to do more and more to innovate on the mail application itself and make it such that people can use the clients, but make it so that people are comfortable using the Web interface, too.

DB: Does that mean that there will be more plug-ins like Calendar Sync for e-mail clients like Outlook or other popular e-mail clients to make them more Google Apps-friendly?

RS: Yes. Potentially. We're focusing a lot on integration and interoperation as well as focusing on innovation in the Web interface as well.