Bring your own infrastructure [tech]
Overview
All of us use multiple software services for a multitude of tasks like email, work applications, social applications like this blog and much more. Typically these software services are run in a SaaS model where your data (like email and contacts) are hosted by the vendor providing the service. This means that you need to trust the vendor to safeguard and protect your data.
For companies that use SaaS based services, it means that their employee or customer data is managed by the external SaaS vendor. There are multiple industries where customer data has to be strictly protected like healthcare, government and military applications. Furthermore there might also be regulations that need to be adhered to in those industries like HIPAA for the healthcare industry in the US. Broadly the number of regulations has been increasing of late in addition to the domains where privacy laws apply. Regulations are cumbersome and expensive but I favor these since data is the crux of the modern economy and without any rules, all privacy will be eroded by companies and as a proxy competing states.
In the past, most services were deployed in data centers managed by the company (client of the vendor) itself. Software vendors would provide software either as installable packages or appliances. Since network access to the datacenter was limited and controlled by the company addressing the security threat profile was simpler. The simplistic answer was to keep things locked behind the firewall. Using SaaS based services completely upends that dynamic. The data that was critical to the business is now outsourced to the SaaS vendor and guarantees about the protection of data cannot be made. You will need to trust that the SaaS company has implemented proper controls and tools. A newer class of solutions have been created to address this problem like using encryption controlled by customers and confidential computing.
But let's take a step back to look at the benefits of a SaaS based model of why it is preferred in spite of the major drawbacks from a security perspective. The major reason is Operations. Operating software requires a fair amount of investment and is complex. Scaling of services in a datacenter is also cumbersome because resources are not easily or quickly available. From a vendor's perspective, getting newer versions of software installed was always a challenge causing immense complexity in engineering. Modern SaaS services use cloud providers like aws, azure, gcp which provide much simpler solutions for scaling and also help manage harder problems like availability across regions. In the SaaS model it's simpler to experiment over data and reduce configuration sprawl since the environment can be controlled. Another major reason for using SaaS based services is also since the cost structure changes partially from capex to opex.
Changes in the software industry happen in cycles. Ideas that have been discarded in the past become relevant again and modernized for the future. The proposal below falls into that category bringing together a modern spin to the past practice of packaged software.
Bring your own Infrastructure
Bring your own Infrastructure is a new software deployment model where customers host and operate SaaS-like services created by vendors in the public cloud. The software vendor will not have network access to the data owned by the customer but would get access to high level operational information and partial administrative controls like being able to deploy software.
A customer would onboard with a new vendor by providing credentials for an admin-ish level account. The account will have privileges to create and deploy infrastructure but not view raw data. Through a software management dashboard, information like logs (maybe sanitized or minimal) and metrics will be available to the vendor for minimal operations and troubleshooting. Change control for new versions is critical. The vendor should be able to install new versions that are incremental in nature which do not break current usage (product UX or APIs). For complex changes a roll-out process can be planned but the idea is that changes should not be stalled.
In many respects, BYOI is like a shared public cloud account where the customer has the primary control and the vendor has limited secondary control.
Benefits
Data security, privacy and sovereignty become much easier since control is back with the customers.
Vendors can deploy to customers with critical data requirements while shifting a portion of the operational burden back to customers.
Engineering solutions can still utilize the operational advantages of the modern cloud technologies and gain visibility into the high level operations.
The infrastructure provided by the customer can be used across various vendors if they are related. Maybe the service has some extensions possible.
Application architectures for SaaS applications are very different compared to on-prem software. BYOI deployment model is much closer to SaaS deployments and is easier to adopt compared to forking for SaaS and on-prem.
BYOI is composable. A vendor possibly uses other vendors for its software dependencies, and hence the entire stack can run in the customers control. Negotiating contracts might also look different since a customer can then directly work with each vendor across applications.
Drawbacks
We're back to customers managing software created by other companies. However complexity is reduced since the shared abstraction is now a public cloud.
SaaS companies have lower operating costs because of the benefits of scale (like saving data from multiple customers in shared databases). A cloud per SaaS application per customer breaks that but there can be other optimizations implemented like adoption of serverless computing.
SaaS companies cannot analyze data across customers in data lakes and hence deriving insights becomes much harder.
Postscript
This idea is not completely unique. It's a derivative of other ideas, but it's something that I've not read of. AWS marketplace has deployment solutions like SaaS, AMI, Container or Data and this would possibly be a new category. Please ping me if you can find prior art or similar references.
I've used the public cloud API as an example of the baseline architecture requirement for BYOI. However the baseline abstraction can be a new multi-cloud compatible API or even kubernetes. The primary principles are similar.
This idea can be extended for privacy focussed users in personal life as well. For personal users it's likely that their usage falls within the free tiers from cloud providers.