Why does the software your organisation uses to do its own work have to live in a vendor’s cloud?
Sometimes there is a good answer. A service may need the vendor’s network, data, or specialist operations. But often the arrangement is simply inherited: the software is a web app, so the company that wrote it runs a service, and everyone else signs in.
Moving software to the web has real advantages. People can reach it from different devices. Teams can share updates without installing a new copy on every computer. A link can take a colleague straight to the work. None of those advantages determines who must host the data.
Yet web software is commonly sold as one inseparable package: application, backend, database, and operations. The software developer defines the data model, runs the application server, and operates the database service—directly or through an infrastructure provider. The customer chooses the service, but usually not who holds the database or how it is operated.
A backend is a choice, not a browser requirement
An application server earns its place when it does application work: coordinating a complex operation, holding secrets, integrating with other services, or running scheduled jobs. But some backends mostly define HTTP routes and put an ORM in front of a database. The browser sends a request, the server turns it into database calls, and returns the result.
That arrangement is familiar and often useful. It is not the only way to divide the work. The browser can run the controller, while the database provides a deliberate interface for reading and changing data. The application can then be delivered as static files, with database changes shipped as migrations.
Software and hosting can be separate businesses
Once the database interface belongs to the database, the team that designs it does not have to host it. A software developer can write the application and its database procedures, publish both, and operate no infrastructure at all. A host can run databases for applications from many developers. A database administrator at that host decides which application migrations to trust and when to install them.
That division gives organisations choices. A central IT team can host databases for applications made by separate product teams. A department can run its own host. An outside infrastructure company can operate the database while the customer chooses which software and versions it accepts. A developer can still host the application for convenience; the point is that the roles do not have to belong to one company.
It also changes who the customer is. In the familiar SaaS arrangement, the user buys access to a service from the software vendor, and that vendor chooses the hosting arrangement. In a separated model, the user or organisation can choose the software and the host as separate offers. The infrastructure company serves the person whose data it holds, not only the software company that wrote the application.
Unbundling is not pretending there is no infrastructure
A database still needs to be hosted, backed up, and operated. A browser needs a way to reach it. The difference is that those responsibilities can belong to a host chosen for that work instead of being hidden inside every application vendor’s service.
One implementation of this idea, SPA MVC, puts the views and controllers in the browser, uses stored procedures as the application’s data interface, and connects through a WebSocket relay. That keeps the application-specific runtime small, but it asks the developer and host to work directly with database procedures and migrations. Some products need a conventional application server or managed platform. The argument is not that every app should use the same design.
The question is whether a particular product needs its software, application server, and database host to be owned and operated as one service. For internal software, the answer is often taken for granted. It deserves to be a decision.
When developers can focus on solving the user’s problem, and infrastructure providers can focus on operating infrastructure, both can do the work they understand. The user gets to choose how those pieces fit together.