Patterns of Enterprise Deployment – Single Shared Application source

This is part of the Patterns of Enterprise Deployment series.

Summary
The application is run from a shared location; for instance a web site or a network-accessible file store (like a shared folder). End-users must go to this location using a hyperlink/shortcut to access the application.

Difficulty
Low

Advantages

  • Simple to set up, easy to understand for developer and business users
  • Version control for an uncontrolled number of end-users is simple
  • Updates to the application are immediate for new instances of the application
  • The app can be run from anywhere, there is no need to install anything on the users machine (probably – there may still be browser issues or sometimes applications will require runtime environments like .NET framework or Java)

Disadvantages

  • Sometimes not scalable in the case of a shared file, or a simple web site
  • maybe performance issues for users who are accessing over the internet from another country
  • updating the application, while people are running it may be difficult. Some web server applications help out in the this case by controlling when the binaries are reloaded. In any case, running instances of the application will not get the update and need to restart.
  • In a shared file source, you may be unable to replace the binaries whilst an user is running the application as the file may be lock by the OS.
  • If the network is down, the application is also unavailable; this may be the case anyway, if the application ha multiple tiers. However, if the application source is on one network location and the components required to run the application are somewhere else this may be irritating to users.
  • Location variation in “standard” components — e.g., variation in behaviour of web browsers or Java versions — may cause problems

Use when

  • the application is an end-user application
  • suitable for corporate environments where you can be sure of some standard components to support your app(e.g., .NET, Microsoft Office etc)
  • you need to deploy to a changing group of users

Don’t use

  • The application source is on a network that may become inaccessible
  • If users leave the application running all the time, they won’t get new versions without restarting.

My experiences
Website applications should be the ultimate way to avoid deployment issues. A way of getting you application accessible to your users any time, any place, anywhere. The corporate net is down? Fine go to a web hot spot with your iPhone and you are back! Often, it isn’t that simple. When you require multi-browser support in a complex application you don’t get that for free. It can be a huge sink of time to work the bugs out of that. To a lesser extent you can see the same thing repeated in more homogeneous environments. For example applications that use Microsoft Office as a platform; your users may claim that they are all on the same version but relying on it is a sure way to find out that some of them aren’t.

However, this is a simple one that works well for vanilla GUI apps that need to be accessible most of the time. Especially if they are used everyday by someone, but each person only uses the app infrequently. As long as they can find the right shortcut they will get the right application without any problems.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s