Are you ready to begin using your new custom-made web app and not sure where to host it? I’d love to help! Here I analyze some pros and cons of serving your business’s web application remotely versus within your own office.
Given that many offices already have a dedicated application server (or even just a robust workstation), it is trivial to serve a web application internally. The real question is: should you?
The first issue to consider is security. I believe that there are serious security issues involved that are not always taken into account. These overlooked issues can cause many business owners to see this question as more imbalanced (IE, believing internal hosting is dramatically more secure than external hosting) than it is in practice.
Any modern router can be easily configured to allow and, more importantly, block requests for web pages served by internal web servers. What reasons would a business owner give for doing so? The common answer: it is not at all unheard of that an application bug or server security hole can allow access to sensitive application data (for instance, the contents of the app’s database records). Disallowing public access to an internal web app can easily offset this possibility.
Then again, there are plenty of security issues associated with serving an application on a computer already in use. A dedicated application server, such as file server, may not have user roles properly setup to prevent your app data from being read by other server applications. Additionally, if a software crash (or even a malicious intrusion) occurs for one application, other applications and their data on the same machine are at risk. A dedicated computer serving your web app would be able to avoid taking on these new security concerns.
Another option would be to serve your web app from a workstation. Compared with an in-house server, this can be seen as an option to reduce hardware and electricity costs. Frankly though, considering the risk of acquiring a computer virus or the employee accidentally destroying/sharing local data, I would have a difficult time recommending this option to any business–or even individual.
Additionally, one should keep in mind that all the best laid security plans for security go out the window if a malicious individual has physical access to your computer. When you have your server in your office you must be concerned about keeping it safely behind a locked door, especially from employees who might inadvertently open security holes on the server. Providing a physical layer of separation between your server and unauthorized persons is what web hosting providers most likely do better than you.
It should be noted that all web app developers have concerns of security in mind. It is well understood that a data breach, and loss of sensitive data is irreversible and catastrophic. Some tools, such as those providing SQL injection & DDoS prevention by CloudFlare, make the task of securing remote apps even simpler.
Security Summary: To fully realize the security benefits of an internal web server, you would need to place a dedicated web app server behind lock & key. You would also need to block requests from outside your building to it. Otherwise, you are not gaining any overall security for your web app any more than placing some simple code (such as IP filtering) on it and serving it remotely.
Hosting your web app involves having a reliable computer and electricity, and the costs of both shouldn’t be ignored.
Some GUI-based operating systems (Windows and OSX) put you at a slight disadvantage when it comes to hardware. GUI-optional operating systems, such as Linux, are able to make do with less hardware resources to accomplish the same tasks. This advantage is used to greatest effect when utilizing virtualized machines (VMs), or better yet PaaS containers, for specific tasks. You should expect half the hardware requirements to run a terminal-only OS vs its GUI counterpart (one example in practice).
By separating each application into a separate VM you can be confident that a “noisy neighbor” app cannot hog resources or overstep into a neighbor’s data. Single-app hosting makes it less troublesome when hiring software developers to work on a single app without providing access to unrelated company data.
The resource (and monetary) costs of separating apps into distinct Windows VMs add up fast. I believe this is the main reason why the benefits of VM and PaaS is often unknown to Windows users.
Additionally, all hardware will eventual fail, become obsolete, or too slow for upgraded software tasks. Upgrade and replacement hardware costs can be pricey, especially when you are not able to utilize economies of scale to purchase & upgrade hardware, as companies such as Amazon enjoy for their EC2 cloud hosting service. Remote hosts can also take care of hardware migrations internally, which saves their users considerable time.
And of course there are electricity costs. A typical SOHO server in my best guesstimate will be eating up an average of 100W/h. Using some rough math (assuming cost of $0.10 per kWh) if your server is running 24/7 you should expect a monthly bill of $7.20 ($86.40/year). If you choose to run multiple such servers, and attached peripherals, then the costs become noticeable.
Hardware Costs Summary: Hosting your application internally sets up a business owner to be “on the hook” for upgrade and electricity costs which larger hosting companies are able to mitigate much easier. At the same time, cramming applications on the same host without virtualization, whether due to resource limitations or desire to save on electricity costs, can cause app overlap problems.
Although not as apparent as monetary costs, employee time costs are just as important. A good application solution should be easy to upgrade & monitor for productive use.
Maintaining server updates is not always straight-forward. Applying package & kernel updates as they are issued by Microsoft, Apple, or your *nix distribution can be automated, but there are tricky issues that still remain. Should the operating system be upgraded, or simply patched? Should optional updates be applied? Who will monitor the updates the make sure they didn’t disrupt the app–and do you have a plan in case they did?
A managed server (more expensive) or a shared hosting environment (less private, less flexible) eliminates much of the worry here, as the hosting company’s engineers are tasked with keeping these hosts up-to-date. A private cloud with root access, a VPS , is not as simple as it requires the administrator decided how and when to apply updates. Essentially, a VPS does not have less software upgrading/maintaining worries than an in-house server.
A new model of remote hosting, Platform as a Service (PaaS), combines the privacy & scalability of a VPS with effortless software updating of a shared host. PaaS lets you focus completely on your app, and forget about software maintenance headaches. More on PaaS and comparisons here.
Time cost summary: To realize the most time cost savings, think again about hosting your web app locally, or even on a VPS server. A shared host or a PaaS server can provide you piece of mind without the maintenance costs associated with managing your own server.
Here is where the distinction is pretty obvious in the local vs remote hosting debate. If your office has intermittent Internet connectivity, then having a locally hosted web app would set itself apart fairly quickly. There are new techniques in HTML5 apps to make better use of persistent browser storage and even with synchronizing this storage with the web app’s database. Even so, this is new territory and so cannot be seen as a true “fix” to intermittent Internet connectivity–yet.
Of course, one must try to keep things in perspective here. Each year Internet connectivity becomes faster, cheaper, easier (think of ad-hoc mobile phone Wi-Fi hotspots), and more important to daily business. Email, cloud files, cloud calendars, VoIP, and various other web sites used in daily business are increasingly important for getting work done. In the same sense as lighting, heating, cooling, or water; one can easily see Internet connectivity as just another utility that must be maintained–another “cost of doing business”.
Internet connectivity summary: It is best for a business to be more resilient and not be tied to a utility that could be disrupted–a benefit given by a local web server. On the other hand, gaining this modicum of resiliency can come at the cost of other benefits (mobile access, maintenance costs, etc).
To use a web app, a user must connect with a web browser. Unless newer HTML5 appcache methods are used, this means that the user must have HTTP access to the web app server each time the app is used.
If your users are only using your app during traditional work hours, and are simultaneously at the workplace, then a firewalled web server is not a problem. Then again, if users are working from home, or via a mobile phone connection, this can pose a tricky problem to companies hosting their web app internally.
As telecommuting grows, having remote access to workplace data from all locations becomes more important. Web applications are naturally suited to fulfilling this need. With responsive web design quickly becoming the standard approach to new web development, users are able to truly enjoy the benefits of a single web app serving all browsers, no matter the screen size.
Additionally, there is a non-trivial likelihood that you may want client access to your web app, even if it is not intended to function as such at the present moment. For example, I use Freshbooks for sending invoices. Aside from sending invoices via email to my clients, I use this web app for my internal record keeping. One could imagine that my account be completely separated from clients, and could disallow all access to my area. Fortunately, the sharp minded folks at Freshbooks have incorporated a way for each of my clients to login to my area and review their past & present invoices, and other related information. In short, this accounting app allows my clients to also be users. My clients can review their historical data without having to ask for my time. It is a win/win for all involved.
Location availability summary: Limiting your users’ access to a web application based on their location or time is a true handicap. Productivity, client access, and the bottom line will most likely be affected negatively by firewalling your web app inside an internal network.
While not a major concern, web developer access to a production app is an important consideration. I say it is not “major“, as on-site installations are commonly performed for desktop applications and can be done for web applications as well. Even so, preventing a web developer from accessing the host (IE, because it is behind a company firewall) makes it difficult and slightly more expensive to perform modifications.
The lifecycle of a web applications should be seen as fluid. The wants of web app user are infinite so, ipso facto, the potential modifications & extensions to a web app are as well. Web applications have an important benefit of being easily modified and this variability is often incorporated into the app lifetime, extending development time into longer beta phases. So having simple access for a web developer to perform work on an application is real a consideration.
App Development Summary: While one of the lesser concerns, it should be noted development on your app can be slowed if you host it internally.
It is impossible to rate remote or local hosting as the “best” because no two applications will have the same requirements. Some requirements for a web apps do tend to be more popular than others, but an uncommon requirement is a requirement nonetheless. If fail-proof security is absolutely required, and other benefits (such as external access and cost) are not a concern, then serving a web app internally (from a dedicated server in a locked room) can be justified.
Although like all things, one should seek to maximize the total benefits without breaking any requirement. One should not focus on one factor at the expense of all others.
Even so, a web application (as its name implies) performs best when hosted on a publicly available web server. My hope is that after reading this post that you are leaning towards hosting your application on a remote host, unless there are unusual circumstances involved.
And finally, the decision doesn’t have to be permanent. A huge benefit any web application is that it can quickly be moved to an offsite server–or back…
Please don’t hesitate to contact me if you’d like to discuss creating, modifying, or moving your office application.