In the first post in this series, we explored some of the work that needs to be done with infrastructure and code to make research software into Software as a Service (SaaS). Here we follow up by looking briefly at operating SaaS for users – keeping it secure and maintained.
Security and Laws
Once there are multiple users from multiple organisations using SaaS, care must be taken that they are only able to access the data they should be able to see. It is also necessary to ensure that the software is resistant to deliberate attempts to unlawfully access data. A third party authentication service such as Auth0 is one option for handling the mechanics of user logins without a need to directly handle user identifiable data. However, keeping track of who can access what is a job for the software itself - for example, checks need to be built into database queries to make sure that the records returned are appropriate for the currently logged on user.
Software (and the people using and making it) are required to comply with relevant data laws such as the GDPR, which may include restrictions on where geographically data is stored and how it is encrypted. Some data might have to be stored or handled in a particular way due to IP restrictions or medical confidentiality rules. Expert advice is often needed.
Good general security practices should be adopted, including regular updating of software and correct server configuration - for example only exposing the minimum means of accessing the software to the internet, keeping computers up to date with security patches and ensuring that people have access only to the minimum systems they need to do their jobs.
Penetration tests are typically used in the private sector to identify what changes are needed to minimise the risk of a successful attack, as the cyber security expertise required goes beyond that of a software engineering team. These cost somewhere in the range of £10,000.
User Agreements and Licensing
If third parties are using the SaaS they may need to agree to some Terms and Conditions (we all do this when we sign up for a Facebook account, for example). These might govern how much people are allowed to use the SaaS, what type of data they can upload, how long data will be stored, what quality of service they should expect, etc.
The SaaS itself will be built from many pieces of open source, or otherwise licensed software. It is important to ensure that the terms are not infringed. This applies to the research software itself.
Support and Maintenance
The research software itself will likely have a number of dependencies - other software that is required for it to work. The SaaS platform will have many more - web servers, databases, container management, etc. Some of these dependencies will be updated, sometimes in response to a security threat, or to improve performance or fix bugs. Some dependencies may be updated automatically. When the SaaS adopts an updated dependency, there is a chance the dependency will cause unexpected behaviour which will require changes to the SaaS code. If people are using the SaaS, they will identify bugs, which could be really important to fix e.g. if they could cause a security breach or unintended deletion of data. And there will often be a need for new features to be added. This means that as long as the SaaS is running, people need to be available to update, fix and support it. So as long as it is running, this will be a cost.
Closing Down
All SaaS has to be closed down eventually. People stop using it, or funding for support and maintenance ends. There should be a plan in place for informing users of the shutdown, and for making sure data is archived or securely deleted in an appropriate way, and users should be aware of this so they don’t risk data loss.
Conclusion: Aim for the stars?
“Aim for the stars, and you might just hit the moon.” This is implicit in the ethos of research: try and answer a big question and you might answer an important enough smaller, or different, question to make it worthwhile. It does not really apply to SaaS. Having a great UI which is insecure, or a valuable analysis pipeline that can only run on limited hardware, is probably not going to be that useful. So do we despair?
As we saw in the previous post, there are quite low cost ways of making research software into a service with a web interface, such as Shiny, but these have limitations. Whether this is an appealing approach, or something more complex is needed, consider the cost of turning research software into SaaS before working on turning it into SaaS. There is no such thing as too expensive, but it has to be paid for either by usage fees, investors or research funders. Don’t waste time making a SaaS that is free to use but flawed, unsupportable and ceases to work months after the end of the project due to dependency changes. Your time is too valuable.
If SaaS is being considered as an output of a research project, consider asking for funding to realise this in the funding application. If you aren’t a SaaS expert, consider asking for advice on how much it might cost. If you’re worried it will seem like a lot, you can always link to this post.