Moving to the cloud is in an ever increasing demand with our clients. More and more organizations are noticing just how easy it is nowadays to obtain business computing services online without having to invest in costly hardware and ongoing maintenance.
With cloud based computing, businesses forego the need to fork out cash for local hardware, the need to hire or contract with experts to run and maintain the hardware, or the need to upgrade the hardware every few years. They also typically experience a higher uptime, and enjoy a license based payment model with low predictable monthly costs.
FileMaker has obviously seen this trend and has been investing a lot in the last several years in making its product line and business model more cloud friendly – by moving more of its revenue to an annual licensing model, and by introducing WebDirect, which enables end users to interact with their business system via browsers.
WebDirect was a breakthrough when it was first introduced back in 2013. It is good and keeps getting better, but still falls short of FileMaker’s client software when it comes to user experience. Which is why I guess it hasn’t caught up yet in popularity. The absolute majority of FileMaker deployments worldwide make use of FileMaker client software.
By far the most popular way for using FileMaker, FileMaker’s client software (Pro and Pro Advanced) provide end users with top notch user experience. They are however “heavy” clients, which perform many computing tasks client-side. Sorting, PDF generation and other tasks can’t be easily performed on the server.
Using FileMaker clients is great when your clients use a non-hosted solution, or where the server is on premise. Things may become problematic when the server is remote, due to the dreaded “network latency” effect.
One of our clients runs a very busy office in Toronto with multiple users. That same client also has users out west in Calgary, and dozens of service people in the field who rely on constant updates from the main office. The client’s tolerance for poor performance, not to mention unplanned downtimes is minimal to say the least.
Initially when we went live, we did so using an office based machine (an old server which was lying around). We then decided to deploy the server on Amazon Web Services. There are some great white papers around on how to do that, so I won’t be repeating the procedure here. I will only say that, while not cheap, hosting FM Servers on AWS is a great option, as you have complete scalability and can size the virtual machine dynamically to your needs without having to redeploy.
As a side note, we also make use of Amazon SES and S3 services with great success – but that will be the topic of a different blog.
With the server on Amazon, we now had to face the issue of WAN latency. The closest Amazon data centre is in Virginia, US (a new one will be deployed later this year in Montreal). The ping times from the client’s Toronto based office to the Virginia data centre were around 30ms. FileMaker in the office felt sluggish as molasses, and we obviously couldn’t cutover to Amazon without addressing that issue.
After a bit of research we found Amazon WorkSpaces – a relatively new service from Amazon which lets you deploy virtual dekstops on the Amazon cloud. Amazon WorkSpaces service is based on Windows Server 2008, and provides a Windows 7 experience to the end user. Our client team was already using Windows7 in the office, so it was a natural fit.
We therefore deployed workspaces, one for each user. The process in a nutshell is
- Create users in Amazon’s windows directory (you can also choose to connect to your on premise directory if you prefer).
- Select the workspace bundle you’re interested in (differs by CPU, memory and whether Microsoft Office comes pre-installed)
- Launch a single workspace and install your software on it (in our case, FileMaker Pro, various plugins, Acrobat Reader, Microsoft Outlook setups)
- Replicate the workspace as many times as required, and make the necessary adjustments (FileMaker user name, Outlook setups).
- Install the Amazon Workspace client on the user’s machine.
Our client now has a full cloud based environment, with great performance and uptime, while still using FileMaker’s Client-Server deployment. A win-win (pardon the pun).
Some gotchas to watch out for:
- Decent internet connectivity is required. Amazon Workspaces over dialup will probably not be ideal 🙂 However as the communication between the Workspace client and the Amazon cloud is limited to screen refreshes, we found the architecture pretty tolerant. You can probably get away with ping speeds a犀利士
s bad as 100ms before you start experiencing performance issues. - Amazon workspace does a good job of connecting to your local printers, so you can print from the virtual desktop. However if you’re using an old or obscure printer with a specialized print driver, you may have to install the print driver on the virtual machine. It’s best if you recognize that issue before replicating the workspaces so that you do all your setups once on the first workspace and then replicate it.
In summary, Amazon Workspaces proved out to be a very good solution for deploying a FileMaker client-server architecture in the cloud while maintaining performance up to snuff.
You should expect a learning curve when deploying on Amazon. Open an AWS account, deploy your server and become comfortable with managing your Amazon assets. Adding AWS workspaces should then be easy enough.
Read more here – https://aws.amazon.com/workspaces/
Good Article Guys!
Cheers
Thanks Charles 🙂
Really interesting technique, thanks for the article. What kind of latency did you see from the Amazon Workspace client to your EC2 FMS instance?
<1ms, the Workspace VMs and the Server VM are co-located on the same AWS data centre.