HW22: Chapter 17

03 Nov 2016

17.10
Risks when transitioning from desktop applications to SaS:

  1. Desktop applications would maintain a local copy of each document on the user's desktop computer, but a web service would maintain a single copy of a document and allow users to work together as tenants in that single file. This gets to be more complicated! The success of something like Google Docs is that each user feels like he or she owns a copy of the document, because any and all changes that are made are saved without having to think too much about it, but in reality multiple users are editing the same file at the same time and the server is doing a lot some impressive juggling to ensure a seemless editing experience for each user. Ensuring that the proper SaS architecture is available would be key to making this transition work.
  2. Desktop application instances are significantly more isolated from one another than instances of web-service applications. If one user's computer receives malware, for example, that malware would not automatically be propagated to other users' machines. By contrast, a client-server architecture has the potential to easily distribute malware from one client to all the other clients who are accessing the single server that is providing the service. In reality, security concerns are quite readily managed by the server's checks on what sorts of data it accepts from clients, but moving to the web-service model does change the security concerns and management strategies required.
  3. Reliability and availability concerns shift quite a bit when transitioning from desktop applications to web services. If one user's desktop environment fails, this failure doesn't necessarily affect other users' access to the same application. If one user is unable to get work done for a few hours, this doesn't necessarily entail other the loss of productivity for other users of the same system. By contrast, a client-server model depends on the availability of the server. If configured poorly, a server failure could knock out the service for all users at the same time. The goal of failing well is more difficult to achieve when all one's eggs are in one basket, so to speak. Again, as with security engineering, it is hopefully the case that the web service has incorporated solid reliability engineering principles to ensure that server faults do not result in system failures.