Export (0) Print
Expand All

Software as a Service

 

Click ARCast: Software as a Service to listen to this ARCast.

Ron Jacobs:   Welcome, friends, welcome back to ARCast. Hey, you know, some people say I say that friend thing too much. But I like this to be a friendly place. And, speaking of friends, today I have a couple of colleagues of mine on this show, Fred Chong and Gianpaolo Carraro. Now, Gianpaolo, sometimes we call him GP just for short--easier for our American tongues to say. He is very happy, of course, with the outcome of the World Cup. Gianpaolo and Fred have been thinking about this area called Software as a Service. And, it's, you know, it's an exciting area, lots of developments are going on, and we think the trend of the future is more and more in this direction where you will be using services in the... just out of the cloud somewhere, you don't even care where they are, what platform they are running, you just care what they do. So, let's give it up for Fred Chong and Gianpaolo Carraro.

Hey, this is Ron Jacobs, coming to you once again on the ARCast show, this time, from my office in Redmond, where I am not at frequently, but, you know, I am today after being gone for, I don't know... It's gone for over 2 weeks, but forward back, and this time I am joined by two colleagues, Gianpaolo and Fred. Guys, welcome to ARCast.

Gianpaolo:   Hi, Ron. How are you?

Fred:   Hello.

Great, great globetrotter. [Laughs]

Ron Jacobs:   Yeah, I am fresh back from a trip to Egypt and Israel, and that was a lot of fun and... but, you know, today we'll be talking about SaaS. Now, when I was growing up, and if I talked back to my mother too much, she said, "Stop sassing me." OK. But that's not what it is; now, we are talking about... What is... Gianpaolo, what is SaaS, anyway?

Gianpaolo:   SaaS stands for Software as Service, which is this very popular trend that many people are seeing in the industry. And one of the things that, you know, Fred and I have been spending some time on is really understanding SaaS from an architectural perspective. What is it that you need to do as an architect to really shift your application to a delivery model that is not the "on-premise" model, but really deliver your software as a service?

Ron:   Ok. So, thinking about software as a service, Fred, is there any example where we can look at? I mean, is somebody out there actually doing this now?

Fred:   Yeah. So the, sort of the Big Daddy image that comes to people's mind when they talk about software as a service is salesforce.com, who is offering a… not an on-premise version of the CRM software, but one that does not require an on-premise installation, one that can be accessed over Internet.

So, what they're offering is really a set of Customer Relationship Management software, I suppose. So, the difference is that in… When people wanted to by a line-of-business applications like a CRM application and pass, for example, and… Currently, they would go to a vendor, CRM vendor, whether it's Microsoft or somebody else, and installation of such software and maintenance of such software is typically quite complex. So, they will have to buy the server, install it on-premise, then they have to worry about on the ongoing maintenance of that, and so on and so forth. But with the Internet version of CRM, one that, for example Sales Force is offering, they can actually get all the functionality without having to install any of the software in-house.

Ron:   Yeah, you know, in the late '90s, before I came to Microsoft, I used to work with a couple of CRM vendors, and I recall what it was like. I was under dev team, but I saw, you know... These customers would come up, they had, it was, like, a minimum of a million dollars to buy this CRM software, and then you had to have a large project team assemble, there was customization work that had to be done, there was, you know, put together the servers, have a team to manage and monitor that. You also even had to have your own kind of helpdesk support for users of the CRM system. It was really a substantial investment on behalf of the customer to say, "We're gonna bet on this." But I can hear already, you know, some people are going, "OK, but you probably get something better, though, if you buy the internal thing." I mean, but, is the experience of using software as a service, is it less desirable than the kind that you buy and run yourself, or is it just about as good?

Gianpaolo:   Well, it really depends on many aspects, but I can walk you through some of the impact from a buyer perspective of going with software-as-a-service offering, as opposed to on-premise. First of all, to the impacts. One of the impacts is on the purchase, how you buy the software. That different basis small those around software as a service, one of which is subscription. As opposed to buying it with a large upfront licensing cost, then you put [it] into your books and amortize over time, and what have you. It's much more in operating cost. You pay an amount every month to basically get access to that environment kind of [a] bit like electricity or rent and things like that. Also, because the software does not need to be deployed in-house, there is no real deployment-and-implementation phase. There are many "software as a service" vendors that allow you to try the software before you buy it. And, if you ask many enterprises if they would have loved to have tried the big man of business applications they are using before buying them, you would have got a lot of people saying, "Yes," they would have loved that. So, that makes the purchasing sort of aspect of software quite appealing. Second aspect is, really, the operation of it. Instead of having an in-house department and having the large IT environment to operate and maintain that software, you basically offset that to the vendor, which is very different as an approach. So, instead of managing the people and resources, you manage business relationships, you manage service-level agreements, and things like that. So, for smaller and medium businesses, it's actually quite appealing, because they don't have access to an internal pool of IT that is required to run complex applications. So, smaller enterprises potentially can get access to software that was historically only allowed or only capable to be run by large enterprises. That's why we see a lot of intake of SaaS in the small and medium business. And, from the large enterprise corporation, which basically have the potential of running large business applications, there is a… I wouldn't say a conflict, but there is a lot of discussion mainly between the business side and IT side, what would be the best approach to run software. There is a difference in the purchasing of the software. There is an impact on the operation of the software. And, obviously, when you provide such software, there is a big impact in the architecture of the software. If your software is meant to be used and deployed every time in each of the enterprises that uses it, it's very different than if you design a software that is meant to be used by many, many companies at the same time.

Ron:   Yeah. OK. So, you mentioned something there that's kind of a terminology that's used in this business world. So, you mentioned like that tenant; so, if I am customer, I subscribe to your service, let's say I am a tenant, right, I am somebody using your service, and so from my point of view, what you do, what server is my application runs on, you know, how many servers and all that's opaque to me, I don't know and probably I don't want to know. All I want to know is that it's running 24/7, I can use [it] whenever I want. So, I am relying [on] you to do [what] you have to do to make that happen. Now, but from the provider side of the architecture, there's got to be challenges about how am I going to make that work. I mean, I don't want to provision box for every single customer. And how do I make that work?

Gianpaolo:   OK. I will start with that and, Fred, you can complement. As you said, from a provider prospective, you only see yourself, so you want to be seen as if you were the only one. So, you want to be the best customer of your provider, which is acceptable. From the provider side is now, how can I make all my tenants or my customers as if they are the only one, while maximizing the infrastructure that I have put in place? How can I make an economy of scales, while pretending or making believe that everyone is itself alone on my environment? That's the challenge that architects have to solve. This is what we call single-instance multitenancy. So, a single instance of applications will be capable of running multiple organizations, while behaving in such a way that each organization is treated as if it was [the] only one running on the infrastructure.

Ron:   Yeah. But there is gonna be some serious challenges about that. A lot of this reminds me [of] Web hosting, you know, in that Web hosters often, you know, would put several hundreds of thousands sited on one box. Yet then you worry about, well, what if one of these sites gets really, really busy and starts sucking up all the bandwidth, and other sites on that box begin to suffer, and so then they would offer, like, a dedicated server package or maybe half a server, or whatever. Do they do the same kind of things in SaaS or...?

Gianpaolo:   So, exactly, I was just describing that the issue that has to be solved, the way you solved that is, basically, we identified three main architectural topics that one has to [be] good at or master to successfully realize this. One is to be multitenant-efficient—that is, understanding how you can have a data model that allows a sharing of the database, while protecting data access to each of the tenants. Understanding how you can have service-level agreements to each of the tenants, being able to monitor and enforce service-level agreements. We can go into these details, but as right now we just want to place them in the bucket of multitenant efficiency. The second aspect one has to master—or the capability that the software has to be able to provide—is customization per each of the tenants while running a single instance. This is done through a heavy usage of metadata. So, you're gonna have to describe the UI for each of the tenants, the business process for each of the tenants, the data-model extensions for each of the tenants, in such a way that it's being inspected at the runtime, and behavior of your software will be such that by understanding who the tenant is, I will be looking at the metadata that describes to specificity of my tenant and act accordingly. While another tenant might make a similar request, but because metadata associated to the request is different, my software will have to behave differently. Which is a behavior of software that is not typical on today's on-premise applications, because you don't have to cope with several requests on a single instance of the applications with different data models, with different business processes, different UIs.

Ron:   And which is... So, I am beginning to see some things that might need to be accomplished here. So, for one, in the UI customizations, for example, it's very common for people who have done this kind of thing in the past to have, use style sheets and that sort of thing, to give [the] Web pages the brand and look-and-feel of the site they are hosting for. And then, when you get down into the business logic, it's been very difficult to make that work. But now, there is a great opportunity, because Windows Workflow Foundation, to be able to describe using a metadata form, like an XAML form of the workflow, the workflow for this customer, which is different than that customer.

Fred:   Yeah. That's absolutely true. So, if you look at how software applications are delivered today, especially the customized ones, what a lot of these systems integrators do is that they will find what your requirement is. They have a basic code base, and they will go back and modify the code, and they recompile it and deploy it for you. That method of delivering software has to change in [the] software-as-a-service world, where the mentality has to be about minimizing, so you write your application once and hopefully it caters to all the needs of your tenants. And what Gianpaolo has mentioned earlier on about metadata, that's really the key for delivering the software as a service, because data… Metadata is basically data about data. It needs to describe what your tenants want to see, and your application has to be written in a way that at runtime it knows—based on user contracts and what tenants you are—that [it's] able to load to right metadata for you, to cause the applications to run the correct way. And [it] goes for business logic, it goes for any extension that you make to your form, as well, because the schema is different [for] every tenant now. Your PO looks different from mine. And how do I know that your PO has an extra field?

Ron:   Yeah, and that was the, always been a big problem and often, you know... What the CRM companies I worked for did was, they would have a number of extra fields, you know, just kind of what we called user-defined fields, right, and they would just be a big, you know, 255 characters varchar in database, right, and put whatever you want in there, and the UI would keep these fields invisible. And you actually wanted to use them, and so [it] kind of was a cheap and easy way to extend the schema to support these. But as I was thinking about this, I was imagining a scenario, let's say that I purchased your service, I have some extra fields that you don't have normally in your schema, and then I have [a] legacy system that I want to integrate with your system. So, now I am gonna need a Web service that I can call, and [the] Web service has to support these extra data elements. So, maybe you have kind of standard Web service, and anybody call to access your thing, but mine is going to need to be a little different, it will have a different contract, because, you know, it will have these extra data elements that the other ones do not have. Would you then... Can you create a special Web service endpoint [for] me versus other people, or how would you handle that?

Fred:   I think that there is a different sort of… We can talk in terms of the data-integration part from different maturity levels perspective. So, I think that today's… For the most of the "software as a service" provider, when they look at data integration, the kind of maturity level that we look at in this case may be bootstrapping, you know, the data for the customer would be… It could be as simple as maybe, like, an Excel spreadsheet or something like that. You give me the spreadsheet in a certain format that I want to see, and then I have a system in the back end that knows about the back end, and based on the, what have given me in the, your Excel spreadsheet, I am able to create the data-model extension for you and populate the data for you. I think we get to the Web service type of discussion, and I've actually definitely seen one customer in Singapore that actually has customized Web service for every tenant. I think this is one approach [to] doing it. I am not convinced that is the most scalable approach, because we're still talking about customization for each tenant here. You have to actually go and create new Web service to take the data. I think that there is probably a better way to do this that's still the, sort of the ongoing part of our architecture guidance that we are looking to provide in the future.

Gianpaolo:   And, Ron, this is [a] perfect example, where you have this conflict between isolating versus sharing. So, you can either take the isolating approach, so each of the customers will have isolated Web service access to your environment, or you have to find the technique that through metadata, through configuration you basically can construct dynamically the interface or the contract that is required for the particular tenant, so that you can share the Web service access among all those customers. So there, you can architect your system, so that you optimize for sharing by adding some, some tricks, if you will. Mostly related to metadata manipulation and consumption at runtime, or you can solve some of those through isolation by basically separating each of your customers at [a] certain level, at [the] Web services level, at [the] data level, or at the business-logic level. By isolating, you simplify some of your concerns, but you minimize your opportunity to have an economy of scale. It's going to cost [you] more to provide an isolated model, because of more machines, more to manage, more to maintain, more to upgrade. And, on the other hand, by architecting this sharing environments so that you can offer a single instance to all customers, you will be "complexi-fying" the architecture, so to speak, but you will be reducing the overall cost, because you have less to maintain, less to run, and easier upgrade cycles and things like this. So, how to choose and what to use when, this is the architect's job. It will depend on other constraints. It will depend on the business model, depends on customers, will depend on so many other constraints that I cannot give the definite answer. But that's the trade-off—or one of the trade, major trade-offs—in software as a service, is this extension between isolation and sharing.

Ron:   Yeah. So, I can imagine that you could build your contract so that there is an area for extensibility, where you're gonna send some random XML that's sort of self-describing, right, when the... for each customer, see, I have one endpoint, l have this extra area for customization, which is actually a pattern I don't like very much. But I can see it might be very necessary in that kind of environment, if you want to have one endpoint to be able to serve [a] lot of customers that had slightly different customizations from metadata or maybe, [on] the other hand, you can just charge a lot for customization and say, "If you want it, we are going to charge a lot more, because it's going to increase our cost."

Gianpaolo:   Correct. So, from a Web services–contract perspective, it's a very, very delicate issue, and there is a lot of debate around that. And, to be honest, I am not sure we have definite answers to this. But you have to apply that thinking to all the layers. You mentioned before Workflow Foundation helping out in customization of business processes per tenant. This is something we have more information about, we have been thinking more about is… You are right. The fact that you can describe your business process in an external format as, such as XAML, and be able to construct at runtime the specific workflow required for a particular tenant, this is [a] huge benefit of a platform in approaching those issues. So, having in a metadata service is [a] new thing, you will have to have in your architecture, in the SaaS environment, the delta definition of your workflow, so that when you get the context of the caller, you identify who the caller is, you retrieve from the context the metadata associated to the business process and construct dynamically the workflow that has to be applied for that particular customer, is a typical example of [what] one has to do to evolve their architecture to be multitenant-aware. There might be some performance issues you have to care about and cope with. So, those all [of] those aspects [one] has to think about and as, in fact mentioned earlier, the same thing applies [to] the data model. You mentioned, a technique of applying a fix, fixed the sets of custom columns, extension columns that's the technique that is acceptable .You will have your data model that is defined, and then you have maybe two, three, five extra columns that are varchar or whatever, that are extension columns. You will then be in a potential environment where you have a hollow table, because not many will use all the fields, so you might potentially have issues in terms of indexing and performance, whatever you saw. There is another technique where, in addition to [having] your tenant ID column that defines who's the owner of each row, you have a column that defines the extension ID, and you basically reference to an extension table. And in that particular extension table, you have value pair of extension and things like this. Those techniques have been described in one of the white papers published in MSDN. Please go and have a look, and actually also complementing the guidance with follow-up papers. But [to] summarize this big bumbling is that there are techniques to achieve this customization and this multitenancy-aware. There is actually [a] wide range of techniques and, based on how much you want to invest in the architecture—as opposed [to] into the operational cost or isolation cost—then you will end up with different patterns.

Fred:   Yeah. Just in case it is not clear, I just also want to add that customization, the ability to customize is not [a] binary thing. It's not so much as, there is customization or no customization. Because there is a degree of customization and there, for example, the one that Gianpaolo mentioned was canned sets of extensions. So, we allow three extensions and no more than that. And you can call them anything you want, and this is easy to manage. Well, we can say that, "Oh, yeah, you can do anything you want, and it is time for the extension." It is [a] trade-off between how much you are willing to invest and how much the customer is really asking for that extensibility.

Ron:   OK. You know, one thing we didn't touch on yet, and I am sure is a concern to lots of people, is the issue of the security. Because, you know, larger organizations, they have employees coming and going all the time. They worry about, well, you know, "We just fired the guy yesterday; today, he can still access the external CRM site, because, you know, you guys took a long time to take him out of the system" or whatever. How do you manage? What are some of the security problems?

Fred:   Yeah. So, security is the, definitely [the] biggest issue that I think all potential customers of software as a service raise that they have concerns, and it comes at different levels. So, Ron, the one that you mentioned, which is access, is one level. The other area would be data privacy. So, how do I prevent one tenant from looking at the other tenants' data is the other one. So, regarding access, I think it all relates to issue of provisioning, it has [a] very close relationship with that. So, you know, Microsoft today, you know, we offer a set of CRM software services, and Contoso is one of our customers. So, one of the models that we allow them to… their users to have access is by doing this thing… by… called delegated administration. Which is essentially saying that, "Yes, today, since you paid [us] 100 dollars a month, we will create an admin user for you. And responsibility of who within your organization that's allowed to access the application is your responsibility." So, with the admin account, you can go and create the user and change the permissions to different parts of the application; that's your responsibility. And we provide a feature for you to do that. A more advanced software-as-a-service provider may have an automated way for them to do it. Instead of having to login and do it manually, they could potentially import some script or some data from customers and do it automatically. Now, that's only provisioning. But the provisioning is just [as] important. Someone gets fired, whatever, you know, you want to try and reduce minimize the window of that employee's going back and changing the data. [Ron: He's erasing all the customers and…] Exactly. Again, I think there are [a] couple of models. One is, back to delegated admin, you have to make sure the customer's admin is on top of the things and go back and change make sure that user is deleted from the account from accessing the applications. The other way is, instead of doing delegated administration, there is the technique called identity federation, which means that there is a trust relationship between [the] software-as-a-service provider and [the] tenant's organization, you know, through X501 or PKI or something like that. But fundamentally, what's happening here is that the management of the users, the infrastructure that is require to managing the users does not actually, is not directly that resides on software-service-provider side, but instead it could be like an Active Directory or an LDAP store that is already in the customer's organization. So, they may already have some sort de-provisioning process employees, something that happens very fast. Employees get fired and the system gets notified and user is deleted. Which means that user can no longer login to their systems. If they can't login to their own system, they can't login to have access to the SaaS app. So, that's the other way [of] doings things. [Ron: OK. So, I… I… Go ahead.]

Gianpaolo:   Yes. Just want to add something here. Because what we basically have just heard are issues that are very seen in SOA type of applications. So, one thing I want to point [out], because I have been asked many times, is, well, SaaS and software as a service isn't just same thing as SOA. We could spend 20 ARCasts just on the topic. [Ron: laughs And we should. Yeah. OK. Now, let's go.]. But at the high level, I think there are very… There are some sort of principles that they are very similar. So, the fact that you are experienced in delivering line-of-business applications in the enterprise space, the fact that you understand the issue of service orientation, the fact that you understand what the impact of identity is in this type of system will help you being a good SaaS architect. And a typical example here, in fact of myself, I've been involved the… heavily, in last few years, in working, in designing and, you know, SOA applications. So, we realized that a lot of that experience is applicable to SaaS. They said there are some specific architectural concerns and a new architectural patterns that have to be created and identified for the specificity of software as service in the customization area is one of them and the multitenancy is one of them. There is [a] wealth of knowledge and wealth of experience out there that is directly applicable into that space. Does that make sense?

Ron:   Yeah. Oh, yeah .So, I totally agree, because I think if you get service orientation, then you are going to already be aware of a lot of these issues, but providing the same service to multiple customers, very brings a new wrinkle on that. But let me... another question, because I think this is another big concern people have, you know, if... Let's say I try CRM vendor A, and so we have been using them for a year and it's been working OK, but we are not super-happy, and we go, "You know what, we are gonna go to their competitor, CRM vendor B," and the CRM vendor A says, "Well, OK, fine, but we are not gonna give [you] your data." You know, you are stuck. It's in the contract, in the fine print; it says that the data really belongs to us, because it lives on our servers, or something like that. And what happens then?

Gianpaolo:   I actually… funny, because I heard this conversion through long go, and my answer was the data belong to who has the best layer, and obviously it's kind of [a] joke there. But it basically elevates to something that is important that there is a need, whether we like it or not, of a legal framework around this relationship that exists between your provider and yourself. So, when you are doing everything in-house in a SOA and you are [a] large enterprise, you don't have this type of issue, because the data is yours, it's stored in your servers, there is no issue there. When you start having a data that belongs to you—at least, it is created by you in someone else's servers—then, obviously, I don't know what [the] law would say about this, but what I do know is that a contract has to be put in place to clarify that. And, to be honest, there are actually some "software as a service" companies, and I can name even without naming them, there are some even e-mail companies that offer, though over the Web, that there will be a wizard looking at your data. So, the ad you will be getting is based on the e-mail content that you receive. Come on, are they allowed to do that? While most likely in the User… you know, the EULA, that says they are allowed to.

Ron:   Oh, you mean that thing that I don't read and I just click Accept. It says something in there, right?

Gianpaolo:   Correct, correct. There is an element of that is of interest, but definitely understanding data ownership is critical. But even beyond the, their ownership aspect from legal perspective—what's my data, your data—there is another element there [is] more technical in nature is, how do I migrate the data that is out there to this new provider. Is the… Even the provider [is] capable of extracting the data for me to reuse. Maybe the best [I] can do is, give me a zip file with a select * from all the tables where tenant ID [is] equal to tenant ID, give all the bunch of [it] back and say, "Deal with it." [Ron: Yeah.] Or maybe they've provided some sort of APIs that allows to access the business entity to move them around. On one hand the provider, may not have an incentive to provide an easy migration out of their environment. But maybe the industry will require that to happen to move them around; otherwise, they would not have customers. Typically, if I am a customer and want to purchase software from my provider, I want to make sure that I am clear on how I can get the data out, not because necessarily I want to change the provider, but what if the provider disappears, like it's a startup and goes away bankrupt. I am not, I don't want going to die with that.

Fred:   So, that brings up another thought. For the industry-standard group, if SaaS is truly successful, maybe the new mantra for this industry group will be on data-migration standards rather than protocol standards.

Ron:   Well. You know, when you think about, I mean, you can have terabytes of data to get migrated from point A to point B, that's not, like... You are not going to make a Web service call to get that, you know, you are not going to burn it on DVD and FedEx it to me. I mean...

Fred:   I don't know what would you do? But it's going to be big problem.

You ship the machine or some thing. [Laughs] Then again, going back to something we discussed earlier. This concept of isolation versus sharing. If you're in a purely isolated environment, your data will sit in a box that belongs to you, and actually, quite rightly, you can go and get the box. And the data would be in the box. If now you're in an environment where data is co-located with everybody else, and you are the only one wanting the data to out, it's going to be different to, you know… That process to get data out is going to be very different if you are in a shared environment or isolated. So, you might have benefited of a different cost of structure, because you are buying your environment in a shared environment, and the provider might have benefited from a cost perspective to sharing a lot of their environments. But they would be paying, at some point, if they need to extract specific elements out of database.

Ron:   You know, it also brings up an issue about disaster recovery, backup and restore. Let's say, for example, you know, that we find out that somebody in our company has been intentionally, you know, destroying the records, and so we call the vendor, we say, "We need to restore from the beginning of this month. Just us, not any other tenant. Just us."

Gianpaolo:   The current maturities of the industry in the software-industry space and with all the people we talk to, none of them are capable of doing that in the shared environment. It's not that it's not possible. It's because the choice is made in architecture. The investment they have made in evolving to that model, made them either isolate the database; or, if you want backup, then you need to go in to these isolated space. If you go in the shared environment, then we are not capable of giving you a backup or recovery, you know, per customer, per tenant. My claim is, once our guidance is out, they would be able to do that. Because the evolution of the provider will make sort of… maturity level will increase, and they will be architecting their environment in such a way that even though shared environment, there are co-locating the data, they are capable of extracting and doing backup and recovery per tenant that will require, as I said, some specific ways [of] handling of data, storing the data, of tagging the data, and again go back to the metadata service to allow this. Today, we don't see much of that; it's just because also the maturity is quite low into real advanced features. But certainly over the next few months, years, or whatever, this would be a critical to have.

Ron:   Yeah. I can imagine that, you know. If this was really [a] mission-critical process, I might want to have to deal with the service provider, where they, you know, maybe once a month they send me a set of DVDs of backed-up data from their side, even so that if they had [a] big earthquake at their data center or some kind of, who knows, whatever, right? I mean, these are some kinds of things I might actually want to do.

Gianpaolo:   Actually, getting your data is something that they have already. So, getting a backup of your data on [a] daily basis, weekly basic, I have seen that happening often. Basically, it's a zip file that is stored in a CD and shipped off-site or whatever. But I was talking was to restore [the] data back in to the operational environment, which is a different process than backup-ing it. So, backup of each tenant, this is, no one could offer service, if the backup is not possible. It's the per-tenant restore that today is not available.

Ron:   OK. Well, I am definitely looking forward to seeing what kind of solutions you come up with. Well, I can imagine some ideas, but I mean that's the great thing about our team here is that, you know, you guys can sit down with some architects from the SQL team , talk to them about these problems. [Gianpaolo: We've got one in-house now.] That's right, we do. Yeah. We can say, "Hey, Roger, what should we do here?" And that's Roger Walter, our colleague, who is formerly from the SQL team now and on our team. This is going to be great stuff. You are writing up some guide and putting it up on the MSDN architecture developer center, and so people can look it up there. And we will have a URL for folks to look at, I hope.

Super!

Fred:   In fact, the first paper is already out. We may want to include a link for the Web cast announcement.

Ron:   Super. Alright. Well, thanks to you guys for joining. Thanks. [Gianpaolo, Fred: Thanks, Ron, it was fun.]

Fred Chong and Gianpaolo Carraro, ladies and gentlemen. Hey! Thinking about software as a service, you know, the more you open this book, the more you think about all these issues that are going on. If you want to be on service-provider side or even you if you are on consuming side, some questions you ought to be asking of your service provider. Like that old thing about, could you restore just my data? or could you backup just my data? And what am I going to do when I get sick of you as a provider and I want to go to somebody else? I mean, there are so many questions here. And everybody is grappling with what's the right thing [to] do, and so Fred and Gianpaolo are thinking about these issues. They have [an] article in our .NET Architecture Journal. And, so, you might want to take a look at that. And we'll see you next time here on ARCast.

[Music]

Show:
© 2014 Microsoft