I currently am paying a hosting company for hosting on an AWS server. They do an excellent job, and I’m happy with their service. However, I’m considering buying a server and hosting my files on premise.
Are there significant pitfalls involved? My major concern is the time associated with maintaining the server and FMS. Frankly, I’d rather spend my time as a developer, and not a system admin.
A big benefit of on premises hosting is if your clients are also local, this can greatly reduce latency (ping time). A typical Colocation server or hosting company might have 20-50msec pings, whereas local clients on your gigabit (or faster) ethernet may have under 1msec pings.
FileMaker Server is a very "chatty" protocol, with lots of round-trip messages being sent, and thus can be very latency sensitive. Speedups of 3x to 100x are not uncommon when running on LAN vs WAN.
For some situations, I've found that advantage to outweigh the disadvantages of self hosting.
You are definitely going to have to spend more time as a sysadmin when you have an on-premise server. It's uptime will be your responsibility. 
I'd also look into the accounting. This includes not only the time you spend administering the server but also the cost of purchasing and maintaining the server AND the complexity of managing the accounting on these costs. Where I am (Canada), a computer purchase is a capital cost whereas a hosting service is an operational cost. Accounting for both costs is very different.
I'd also look at the knowledge required to administer a server, from the hardware stack to the software stack to the data centres to the internet. I am currently being onboarded to the fmcloud.fm hosting team. It is taking a lot longer than I anticipated because there is so much to learn and, despite the team's knowledge, there are still surprises that forces us to keep discovering new stuff.
I prefer on-premises configurations, partly for the latency issues described by @xochi and partly for localized control.
@Malcolm makes a great point, as the responsibility shifts entirely to whomever maintains the server, but depending on your organization size, security and privacy requirements, etc. this can be pretty trivial once one is comfortable with the process.
If you're a medical clinic following HIPAA rules, or a company owned by a Sovereign Wealth Fund, it's likely you'll have more work to do to keep up with requirements. If, on the other hand you're a mercantile business with <70 users (random number picked from the air) it may be very easy to maintain.
My suggestion, if managing a server yourself for a modest-sized organization, avoid the latest and greatest updates of FM, FMS, and the server OS and things will likely percolate along nicely.
Honestly, I've had more issues with bad cables/ethernet wiring causing network communication hiccups (especially with complex scripts) than any other issue.
If you need off-site, remote access, this can be a challenge with on-premise deployments, depending on the location of server vis-a-vis the remote user(s), etc.
In recent years, I’ve seen far too many poorly configured on-premise solutions maintained by FileMaker developers. On-premise hosting requires a deep understanding of network infrastructure and servers. If your internet connection is slow, on-premise is usually the right choice.
@xochi Ping times largely depend on the location of the data center. You can also look for a hosting provider nearby to minimize latency.
I've read lots of stores about people moving away from "The Cloud" (that is, someone else's computer).
At first the "Cloud", the idea anyway, seems great, but the costs keep adding up. Another symptom is that if a company has lots of Cloud sites, they tend to shut down the sites that aren't being used that much until needed. That arbitrary shut down would almost never happen with on premises servers.
I was on AWS for years, but have abandoned it for PRIVACY, COST, and other reasons.
Of course it's more work to do things yourself, but like using GrapheneOS (privacy-based Android OS) on a Pixel phone instead of the default Android software, it can be worth it.
re-patriation - the process of moving back off the cloud to on-premise - is gaining significant momentum. The cost of the cloud hosting is not so much as issue, as the cloud provider's liability on data loss, typically constrained to the last months hosting fee. So if you have a "business extinction event" the hosting company refunds a few hundred bucks. Thanks loads.
I've had Macs running as FMS machine without intervention for a 10+ years. If you want to keep up to releases, you do have to upgrade both OS and FMS regularly, but unlike the Microsoft weekly "Patch Tuesday" that is both risky and a time sink on Windows. Macs and Linux boxes are lower support costs.
For on premise, a local DNS server is almost mandatory (over editing etc/hosts files on every desktop). NAMO is a $20 DNS option for MacOS that I have on all my on-premise MacOS FMS boxes. The router DNS table points to the NAMO/FMS IP address and FQDNs resolve internally.
If you are downtime concerned, Mirrorsync can keep two FMS machines in near real-time sync ($1600).
Control of external storage is far easier on on-premise solutions. Cloud backups are all well and good, but time-to-recover over a WAN connection can take a company offline for many hours/days. Local storage is faster, but it would still be prudent to have an offsite storage, in case of fire/theft of the on-premise equipment.
Also of note; most cable based broadband connections are asymmetrical - fast down, slower up, so hosting on-premise with external users can be a performance bottleneck.
Also, static IP addresses are often not offered, or offered at a premium. Using a service like DYNU.com's free DDNS service is a solid workaround to avoid that cost.
Port forwarding and associated rules on your in-house router is also needed for external access. Alternatively you can install the free-for-25 connection ZeroTier product and provide VPN like services without dealing with router configs.
Another great option: host your own mini on MacMiniVault for $50 a month. I've got a few servers there, and they are pretty awesome. The $99 a month they want for a firewall is exhorbitant, but using MURUS on MacOS, allows extreme control of the vary cable PF firewall built into MacOS.
I ran some latency tests a while back that may be relevant for this discussion: Low latency switches and Filemaker - #8 by xochi
I had a Client who had FileMaker hosted at a server about three hours away from their offices. We bought a $1,000 Mac mini and moved it onsite for them and I ran my tests on normal page loads and their main interactions got between 6 and 10 times faster (some pages showed bigger gains than others).
It's been VERY easy to maintain, they can restart it or I can. We have to update the OS and Filemaker Server every so often, but otherwise it's great.
They did lose the ability to log in from offsite, which is a VERY minor inconvenience for them.
We tried various VPNs, but because of how Filemaker packets work with both their old and new Firewall it's unusable from offsite.
In order for me to get in and make changes we set up a screen sharing app, and I connect directly to the Mac mini and run a local copy of Filemaker on it to make coding changes.
If we had to keep a port open for web connections it would have been another step, but they don't need that for any reason.
I thought about hosting another of my clients at my home office because they are currently hosted 20 hours away on the nearest AWS through a provider and suffer from chronic speed issues, but I travel enough that I don't want to be responsible for that.
Does the client also have a valid SSL certificate? This often requires an internal DNS server to ensure proper internal resolving. At this point, most clients feel overwhelmed.
I honestly don’t remember if we just ignored it since it was all internal traffic or did a self issued one or had Their network guy set it up.
Some routers support "hairpinning" which is a bit easier than setting up a local DNS server (e.g.Raspberry Pi + Piehole). Worth looking into if you ever face the issue.
That is no longer a hurdle. Current versions of FMS include the facility to use Let's Encrypt Certificates. This provides "out-of-the-box" SSL for free.
If the client already has an SSL certificate and wants to tie their services together they may need to be modified to include the subdomain of the FMS server, or they may already have a wildcard certificate.
As @daleallyn mentioned, ensuring you have sufficiently fast traffic out is important.
Using VPN helps somewhat when you have a bottleneck on outbound traffic because the overhead of updating the screen image is minimal. However what we mostly see is that systems are which were designed for the LAN need some refactoring before they perform well on WAN.
WebDirect is a surprisingly easy way to get a system online, though you must provision the server and the network to support it. That cost could be much smaller than other web facing code rewrites.
That’s not entirely correct: Let’s Encrypt verifies that the server is accessible under the specified domain. It must be ensured that the FileMaker server is reachable from both the external network and the internal network using the FQDN. Most attacks originate from within the internal network, which makes encryption and server authentication of most importance in this context.
Jan
@janhagemeister, what is the connection between having an SSL certificate and preventing attacks that originate within the internal network?
@malcolm Most people believe the danger lies beyond the firewall. In reality, most attacks originate from within the internal network. In many networks, a single infected device is enough to intercept network traffic. If the FileMaker Server does not use SSL internally, data is not encrypted, and traffic can be intercepted. Additionally, there is a risk of MITM (Man-in-the-Middle) attacks because the server cannot authenticate itself, and clients might connect to the wrong endpoint.
Sometimes you can setup CertBot to use plugins to create certificates - we use certbot-dns-route53.
Cheers
Keith
Certbot solves the problem of creating the certificate but does not address the issue that, without an internal DNS server, the FQDN of the FileMaker server cannot be resolved within the internal network.
Cheers
Jan