Resultra is a new type of web application for project tracking. The back-end for this software is implemented entirely in Go (Golang). Go was initially promising as a systems programming language which would allow Resultra’s code base to scale and to support parallel processing for Resultra’s numerically intensive calculations. Go succeeded on both these fronts, but has also yielded other benefits.
As the application’s development proceeded, there was also experimentation with third party, proprietary web services such as Amazon S3 for attachments and Google’s Bigtable database for data storage. These services ultimately didn’t add enough value to justify their inclusion in Resultra’s technology stack. Not only do these services add another external dependency to manage in production, but they must also be integrated into the development and test environment. In other words, each external dependency adds complexity to numerous areas of product development and the product itself.
Along with minimizing external dependencies, Resultra has migrated towards a single-tenant software architecture. In other words, each customer runs their own instance of the application and has their own database.
Minimizing External Dependencies
Over time, minimizing external dependencies has become a major design goal for Resultra. Currently, the entire Resultra back-end runs as a single, statically linked executable. Some examples of functions which could have been implemented with an external web service, but have instead been directly integrated include the following:
Attachments — Instead of Amazon S3, Resultra uses Go’s native file I/O package for attachments. The attachments are simply stored as flat files.
Memcache — Instead of a service like Redis or memcached, Resultra uses an LRU cache library from Hashicorp. There’s no additional overhead of interprocess communication to cache the information and the data is stored as native Golang structs.
Map-reduce — Instead of a service like Apache Hadoop, Resultra uses goroutines and channels to implement the parallel processing necessary for its numerically intensive calculations. Even though this implementation is limited to the number of cores on the host machine and does not distribute across multiple machines, this type of implementation is more than sufficient for Resultra’s performance requirements.
Data Storage — For single-user and test configurations, Resultra integrates with SQLite. However, it does support PostgreSQL in multi-user configurations.
Authentication — Rather than integrating with Google or Facebook authentication, for example, the application uses Go’s standard cryptography package.
Given the above, 5 different external web services are not included in Resultra technology stack. This greatly simplifies the application’s runtime environment. Including the application itself, instead of up to 6 different web services, only a single, statically linked executable is needed. In multi-user configurations, the only external dependency is on PostgreSQL.
Shifting to Single Tenancy
Besides eliminating external dependencies, Resultra’s architecture and technology stack has decidedly shifted towards a single tenancy model.
A shift towards single tenancy has as much to do with an orientation towards privacy and flexibility as technology. There are many project tracking type web applications which cannot be run on-premises or only run in a multi-tenant environment. With single tenancy, Resultra can fill a niche for customers who do not want their project data to be “in the cloud”, mixed with other customer’s data, or run on servers which directly face the public internet.
Minimizing Dependencies Facilitates Single Tenancy
Minimizing external dependencies arguably facilitates a single-tenant architecture. In other words, single tenancy and minimal external dependencies go hand-in-hand.
Deployment of Resultra basically consists of copying a statically linked Golang executable to the host machine. If every installation also depended on multiple external web services, the deployment would be that much more complicated.
Is Single Tenancy Scalable?
For a web application with hundreds or thousands of customers, one can certainly begin to question whether single tenancy is scalable. However, as a counter-example, there are companies which do offer managed hosting of single-tenant web applications such as Wordpress.
Of course, there are certain types of web applications for which single tenancy is not well-suited and would not scale well. For example, if the application will have tens of thousands or millions of customers, managing all the single-tenant installations may not be practical, and the utilization of resources would not be economical. However, I’d argue that many web applications will not be used by such a large customer base (at least initially), such that multi-tenancy is overkill and adds unnecessary complexity.
Similarly, the computing workloads for certain applications are also suited to having distributed and interchangeable “worker nodes”, as opposed to a dedicated node per tenant. In these applications, it is more economical to share the worker nodes amongst multiple tenants.
In Resultra’s case, if there is strong demand, migrating to a multi-tenant architecture with more dependencies on external web services is certainly possible. However, starting with a single-tenant architecture offers flexibility to scale up and offer different configurations based upon demand from different types of customers.
Flexible Configurations for Different Types of Customers
Later in the project, eliminating external dependencies and moving to a single-tenant architecture has had an unexpected benefit. In particular, it was possible to initially release Resultra as a single-user configuration for individuals. This configuration can be downloaded as a standalone Windows or Mac OS application. Resultra’s single-user configuration is intended as an entry point for people to try Resultra or use it for personal projects.
This single-user configuration also achieves a goal to provide a “private and self-contained workspace” for project tracking. With an installation of Resultra installed locally on customer’s computer and the applications data also stored locally and behind a firewall, the application is suited for storing confidential and proprietary project information.
Resultra is still fully scalable to multi-user configurations. For these configurations, PostgreSQL is used instead of SQLite and the application is hosted as a web application instead of being run as an Electron app. However, since there are still no external dependencies on proprietary web services such as Amazon S3 or Google Bigtable database, there is flexibility to host the application on customers’ own servers or behind a firewall. If the application is hosted for a customer, it can be run on a standard-issue Linux virtual machine, such as those offered by Amazon’s Lightsail or Digital Ocean.
Conclusions and Recommendations
Resultra is an interesting case study for a single-tenant web application architecture with minimal external dependencies. This type of software architecture results in a simplified development and test environment which requires minimal setup and configuration. There is also flexibility to deploy Resultra as a single-user application, an on-premises installation, or in a managed hosting environment where each customer’s data is segregated. Although the initial version of Resultra is for individual users, depending on demand, the intent is to provide customers with other types of configurations.
Each web application serves a different function and has a different type of customer base. These these factors must be taken under consideration when determining which external dependencies are needed for the application’s technology stack, and whether a single or multi-tenant architecture is appropriate. However, to the extent external dependencies can be minimized and a single-tenant architecture is appropriate, benefits can include a simplified development and test environment, simplified deployments, and flexible configurations for different customers.
Further Reading
Multi-tenant vs Single-tenant Cloud Adoption