When I developed my first major solution using the FileMaker platform, I spent many months building the most efficient app that I could using all my skills. And I was very proud of it too. Then it got deployed, and the users had nothing but complaints about its speed and performance.
I was horrified.
Even more so when it turned out that I didn’t make awful design decisions but that the way the solution was deployed and the network it was deployed on was the main cause for all the mayhem.
I learned a valuable lesson that day: our clients only get value out of our solutions once they are deployed. If the deployment fails or interferes with the functioning of the solution, then that value does not get delivered, and ultimately, we have failed.
Back in 2013, I wrote a blog post about this: we are good developers, but are we good deployers?
This issue continues, of course, and it is taking on some different shapes.
Ten years ago, when I wrote that article, a typical FileMaker solution did pretty much everything that the business needed. Integrations were limited. That meant that deploying the solution was largely limited to the FileMaker Pro client on workstations and FileMaker Server on a Windows or macOS box somewhere.
Skills Critical for Deployment
As a good deployer, you need Server skills to be able to make the right choices for all of the FileMaker Server settings but also to understand best practices around security hardening and avoiding third-party services and applications from affecting both performance and the health of the hosted solution.
And, of course, there is the whole network between the various clients and the server that can impact the user’s experience with your app.
Monitoring is a big part of running a solid deployment. Without knowing how the solution behaves on your server’s setup, you are flying blind, and you cannot effectively troubleshoot since you won’t know what normal and what abnormal looks like. Nor can you anticipate what hardware changes would benefit you and your users.
All these skills are still very relevant today. But more requirements have been added to the ideal skillset. Along the way, WAN deployments became more prevalent, which increase the impact of networking on the usability of the solution. SSL certificates have all but become mandatory, necessitating the need for good internal and external DNS management. Claris also started to support Linux for its server, which requires its own set of skills since the only good Linux deployment is one without a desktop.
FileMaker as a Hub
There is another more subtle shift that has been happening for a while now. A FileMaker solution is less of a complete end-to-end construct like it used to be and is more of a hub in a set of connected services.
Given how excellent the FileMaker platform is at integrating with modern APIs and given how big the ecosphere of “solved problems” services is, we almost always find ourselves integrating with one or two of these service providers.
The good news is that we don’t need to worry too much about them. If those services go down, there is little we can do – that’s clearly not our responsibility.
But by extending this drive for integrations, we are seeing more use of bespoke APIs. APIs that are custom-made either to serve as incoming webhook receivers or, because using your own microservice lets you offload processing from FileMaker, allows you to use a service provider’s prebuilt SDKs and deliver functionality more quickly. This fits into the Distributed Architecture thinking that we have been advocating for.
You can create these microservices in any major technology stack, and there are some easy visual tools like n8n and Node-RED to help you on your way. In doing so, you are introducing a dependency to the solution. That is not a bad thing; it is just something to be aware of. The same applies when you add a plugin to your solution.
When you add your own microservice, it needs an environment to run in, and that requires upkeep, its own monitoring, and decisions around how much redundancy is needed to achieve the desired uptime and load. How will you know that it fails? What kind of notification will you want when it fails? What is the consequence if it fails? Who is going to act when it fails and what is the procedure to step through to bring it back up?
By introducing the dependency, that dependency needs to be managed.
Similarly, if you have an outside system that relies on some FileMaker resources like the Data API, you need to make sure that a failure on the Data API side is caught and handled gracefully. If you have a website that relies on FileMaker data, you do not want to hear from users that the website is not working. You want to have something in place that will check periodically and send out notifications to the designated support team. And if possible, even take automated corrective action like we demonstrated in our Zabbix monitoring of the Data API process at the 2019 Devcon.
So while we think of ourselves as developers first and focus on these two areas:
- Develop
- Deploy and Update
For our clients to have the benefit of what they paid for, we also need to deliver on these:
- Secure
- Run and Scale
- Manage and Monitor
Many IT departments have the skills to handle the securing, managing, and monitoring and can help think through all the deployment considerations. And when microservices are involved, since these use technology stacks that they are more intimately familiar with, IT tends to embrace this kind of architecture.
For smaller clients without their own IT, then the responsibility falls more on you as the developer to make sure everything is in place and accounted for.
Leveraging the Cloud
Another option is to turn to the cloud and use services provided by AWS, Azure, Google Cloud Platform, and the like that can provide and manage the infrastructure and even the scaling capacity automatically. Their serverless offerings allow you to focus on the functionality and not on the infrastructure and its upkeep.
Services like AWS Lambda, AWS SQS, and AWS API Gateway can be stitched together to provide robust, highly-available, and scalable functionality. AWS CloudWatch can provide monitoring and be integrated with your desired notification channels. And while it saves you from having to have infrastructure skills, it requires you to be proficient in using these services.
It is easy to understand that developers can feel overwhelmed. However, the worst thing we can do is to forgo the ideal architecture because we’re disqualifying ourselves for lack of skills.
Identifying What You Don’t Know
So, whose responsibility is all of this? Yours, of course.
But that doesn’t mean you need to have all the skills to make it happen. We can’t all be jacks-of-all-trades, and we cannot be equally proficient in all things coding and all things DevOps, Security, and IT operations.
But you do need the awareness of where the potential failure points are, what needs monitoring and how, and how to interpret all the data that the deployment generates. And you must have the ability to guide your client through the questions around these issues.
Some of these questions fall in the category of helping our clients think through Disaster Recover and Business Continuity questions:
- What if the system is not available for an hour, a day, or a week: how will you continue to do business? What needs to be put in place to help you with that?
- And what does it take to rebuild the infrastructure and restore backups? What does the process of recovering look like?
We are not blind to the fact that the wider and deeper the FileMaker and Claris Platforms get, the wider the skills gap potentially gets between developers and deployers.
It’s one of the reasons Soliant invests in AWS skills as much as we do. 
Essential Skills: Knowledge More Than Execution
- Know the best practices around FMS
- Understand the structure and metrics captured by the various FMS logs
- Understand the available monitoring tools
- Understand the make vs. buy options when it comes to
- Uptime/availability
Moving Forward in the Claris Platform
We strive to continuously build and sustain a team of deep and wide skill sets – from developers and deployers to consultants and project managers and more. If you want to take your FileMaker application to the next level, we can provide our talented team and comprehensive services to help. Contact us to learn more.
