OT - Architectural Dilemma - To the Web or not?

OT - Architectural Dilemma - To the Web or not?

Old forum URL: forums.lhotka.net/forums/t/8699.aspx


Q Johnson posted on Saturday, March 20, 2010

I've been a Windows Forms developer for a long time.  The data I handle is Accounting and Payroll information that resides in SQL Server in the local network environment of my customers (because I'm interacting with their primary accounting system written by another vendor) and they are more interested in privacy than in publishing that information.  So Windows apps have worked fine for me.  The program and its data source(s) are all in the same computing environment/LAN.  I hope it's clear that the location of the data is not something under my control here.

But I can see quite an appeal to being able to host my app on a server of my own in terms of being able to update programs for all my clients at once and on my own schedule.  And it would allow me to consider the business alternative of selling hosted service (SAAS?) for a monthly fee instead of the oh-so 90s license fee with a annual maintenance fee.  But is this a silly idea?

My admittedly-ignorant impression of the layout for most "regular" web app situations is that data and application servers run in the host's computing environment and the UI is offered to "where ever" via browser-to-app-server communication over the www.  So very little, if any, processing is really going on at the client workstation.  And most of the heavy traffic is between the app server and the data server which are local resources to one another.

But for my needs, the data and the UI are both in the customer's environment and only the server app would be on the web (my) server's environment.  

It seems to me that this would require an awful lot of web traffic to distribute virtually all the objects handled by the program since there's a whole internet between the app server and the data server in this picture.  Wouldn't the performance be dreadful?  Wouldn't my clients be better served with a click once delivery of software they purchase to take care of the update/upgrade issue and enjoy the benefit of all-local processing?  Or have I just been making excuses for ignoring the "web app party" for too long?  <g>

Thanks in advance,

 

RockfordLhotka replied on Saturday, March 20, 2010

Routing all user interaction through a non-LAN-local server sounds like a disaster.

The latency between the user and your server, and then your server and the customer's data center is likely to be a killer all by itself. Then add the bandwidth demands and it gets worse.

Then add security. Is your customer really going to open their firewall to allow your server to reach in from the Internet and talk to their database? Almost nobody is willing to poke holes to allow direct Internet connections to their database servers.

SaaS works great if you can host the data. But if you can't host the data it becomes very problematic.

Now if you want to sell an "appliance", which is a web server that you provide to your customer that they run in their data center, then you might have a better story. Basically you'd be saying you provide an "app server" that provides the UI and app processing, and then talks to the customer's database without any Internet traffic or firewall issues (well, there are always firewall issues - but these would be typical ones).

Q Johnson replied on Sunday, March 21, 2010

Thanks for the reply, Rocky.  As you can probably tell, that's what I thought.

I don't see any advantage to the "appliance" you describe here over a plain windows app (for me or for the client).  Do you? 

Typically, only one or two users need access to my programs at one customer site.  The kinds of tasks the programs perform only need to be run a few times per month.  So I've been parking the .msi file out on their server in a restricted folder and let the users just go there to get the workstation software (my program) installed when a new user or new computer is needed to run it.  It's a pretty simple environment to service compared to what most of the crowd here faces.  And I'm happy to keep it that way if there's nothing to be gained for any additional complexity incurred.

 

Copyright (c) Marimer LLC