The best cloud infrastructure for a software as a service (SaaS) application is the option its team can operate, nights and weekends included. For a SaaS company with no dedicated infrastructure engineer, that usually means a managed platform as a service (PaaS) or virtual machines (VMs) that a provider operates. Kubernetes earns its place when engineers are assigned to run it, or when the product depends on its ecosystem. The deciding question is who will patch the operating system, run the database and answer the alerts.
What are the infrastructure options for a SaaS application?
A SaaS team chooses between four infrastructure models: virtual machines, a managed PaaS, Kubernetes and hyperscaler-native services. Each moves a different share of the operating work to a provider.
Virtual machines. A virtual machine is a software-defined server with its own operating system. The provider runs the hardware and the virtualization layer. The customer operates everything from the operating system up: patches, runtimes, the web server, the database, backups and monitoring. A managed hosting provider can take over that work.
Managed PaaS. A platform as a service runs the application from its code or from a container image. The platform provisions runtimes, databases, load balancers and scaling, and the team does not manage the operating system. Self-serve products such as Heroku and Render follow this model. So do the application platforms that managed cloud providers operate.
Kubernetes. Kubernetes is an open-source system that schedules containers across a cluster of machines and restarts them when they fail. Managed Kubernetes services from the large public clouds run the control plane, which is the part that makes scheduling decisions. In most configurations the customer remains responsible for worker nodes, version upgrades, traffic routing, secrets, monitoring and the deployment definitions.
Hyperscaler-native services. The large public clouds, often called hyperscalers, sell serverless functions, managed container services and managed databases. The team operates few servers. In exchange, the application code is written against one vendor’s interfaces.
How do VMs, a managed PaaS and Kubernetes compare for SaaS?
The table compares the four models on the criteria that matter most to a small SaaS team.
| Criterion | Virtual machines | Managed PaaS | Kubernetes | Hyperscaler-native services |
|---|---|---|---|---|
| What your team operates | The operating system and everything above it, unless a provider is contracted | The application and its configuration | The cluster configuration, upgrades, routing, monitoring and the application | The application and the cloud account |
| Skills needed in house | System administration, security, backups | Application development | Platform engineering, plus application development | Cloud architecture, access control, cost control |
| Scaling | Resize the server or add servers, by hand unless the team builds the automation | Rules add or resize nodes, when the application tier is stateless | Automated, once the team builds and tunes it | Automated, billed by usage |
| Portability | High, a standard Linux server can be rebuilt at most providers | Depends on how standard the runtimes and images are | High across clusters, lower once cloud add-ons are used | Low, the code calls one vendor’s interfaces |
| Main risk | Nobody patches or watches the servers | Outgrowing the platform’s regions or feature set | The platform consumes the engineering time meant for the product | A bill and an account that grow without an owner |
When are virtual machines the right choice for a SaaS?
Virtual machines are the right choice when the team needs control of the server and has someone to look after it. Four conditions point to VMs.
- Someone owns the operating system. An engineer on staff patches, hardens and monitors the servers, or a provider does so under contract.
- The workload needs control at the operating system level. Licensed software, a hosting control panel or custom networking fits a server better than a platform.
- Load is steady and predictable. A larger server, or an extra server added as planned work, covers growth.
- The application holds state on the server. A monolith that writes sessions and uploads to local disk cannot yet run as several identical copies.
Virtual machines are the wrong choice when nobody patches the operating system or when deploys still happen by hand over a remote shell. They also fit poorly when traffic spikes need capacity within minutes and nobody has built automated scaling. A separate article covers whether to hire a DevOps engineer or outsource operations.
When is a managed PaaS the right choice, and when is it not?
A managed PaaS is the right choice for a small SaaS team that runs a conventional application and wants its engineers on the product. Three conditions point to a PaaS.
- The application runs on a mainstream runtime, such as PHP, Node.js, Java, Python, Go, Ruby or .NET, or ships as a container image.
- The application tier is stateless, or can be made stateless, so the platform can run several identical copies. Sessions, uploads and caches move to shared services.
- The team wants staging environments, repeatable deploys and rollback without building the tooling.
On a PaaS, scaling still needs a decision, and the knowledge base explains when to add nodes and when to resize them. A SaaS that isolates each customer faces a second choice, covered in the guide to one environment per tenant versus a shared environment.
A managed PaaS is the wrong choice in four situations.
- The product depends on the Kubernetes ecosystem. Software that is packaged for Kubernetes, or that relies on Kubernetes operators, needs a cluster.
- The workload needs specialised hardware. Ask whether the platform offers graphics processing units (GPUs) or similar hardware before assuming it does.
- The application is built on hyperscaler-native services. Serverless functions and proprietary data services do not exist on a generic application platform.
- The business needs regions the platform does not have. A platform with sites in one country cannot serve users on another continent locally.
Does a small SaaS team need Kubernetes?
A small SaaS team usually does not need Kubernetes. Kubernetes solves the problem of running many services on many machines with one consistent interface. A team with one application, a few workers and a database does not have that problem yet.
Kubernetes is the right choice under four conditions.
- Engineers are assigned to the platform. Running the cluster is part of somebody’s job description, with a second person who can cover.
- The product is many services with separate release cycles. Several teams deploy independently and need shared rules for routing, scaling and access.
- Customers install the product in their own clusters. A SaaS that also ships a self-hosted edition often standardises on Kubernetes for both.
- The stack relies on Kubernetes-native software. Some data, machine learning and networking tools assume a cluster.
Kubernetes is the wrong choice when the reason is fashion, hiring appeal or a hope that it will fix availability. A cluster adds recurring work: version upgrades on the project’s release schedule, traffic routing and certificates, secrets, network policy, monitoring and cost allocation. The knowledge base article on moving a cPanel application to Kubernetes shows how much depends on settling the database, secrets and storage first.
Should you rewrite a legacy monolith or move it to a managed platform?
Move a legacy monolith to a managed platform when the application works and the problems are operational. Outages, deploys that cannot be rolled back and slow periods under batch load are platform problems.
One example scenario shows the trade-off. A Canadian business-to-business SaaS of about twelve people ran a ten-year-old Laravel monolith on a single dedicated server. The founders had budgeted six months for a rebuild. The Laravel monolith modernization example scenario reports that, in that one example scenario, Stack Harbor advised against the rebuild. The same application moved to Stack Harbor’s managed Cloud PaaS in an eight-week migration, without a rewrite. Infrastructure cost went up 11%. It also estimates sixty hours a month of founder engineering time returned to the product. That is one result for one workload, not a typical outcome.
The same example scenario says a rebuild may be the right call when the architecture prevents the team from shipping the next product line.
What drives the cost of each option?
For a small SaaS team, the infrastructure line is rarely the largest cost difference between VMs, a managed PaaS and Kubernetes. Labour usually is.
| Cost line | Virtual machines | Managed PaaS | Kubernetes |
|---|---|---|---|
| Infrastructure resources | Server sizes, storage, bandwidth | Resources used, often plus a platform fee | Worker nodes, load balancers, and a control plane fee on some managed services |
| Operating labour | High, unless a provider is contracted | Low for the team, included in the platform or the managed scope | High, and specialised |
| Tooling | Monitoring, backups and deploy tooling bought or built | Mostly included, confirm what is in scope | Monitoring, routing, secrets and delivery tools assembled by the team |
| Migration | Low for a server-based application | Moderate, higher when the application tier must first become stateless | High, the application is containerised and its deployment redefined |
Three drivers move a quote on any option. Staging and preview environments multiply resources. A replicated database costs more than a single instance. Round-the-clock incident response costs more than business-hours coverage.
To put a number on labour, log one month of engineer hours spent on patching, deploys, incidents and cost questions. Multiply by a loaded hourly cost and add the result to each option. The article on how managed cloud hosting is priced explains the drivers behind a provider’s quote.
Which questions should a SaaS team answer before choosing a platform?
Seven questions settle most of the choice between virtual machines, a managed PaaS and Kubernetes for a SaaS application.
- Who is on call for the platform tonight? Name the person. If there is no name, buy the operations with the platform.
- How many separately deployed services exist today? Count what exists, not what the roadmap imagines.
- Can the application tier run as several identical copies? If not, list what ties it to one server.
- Which services does the code call that exist at one vendor only? A long list means the platform decision is already made.
- Where must production data and backups live, and where are the users? Regions rule options in or out quickly.
- Do customers or partners require a specific platform? A self-hosted edition or a procurement rule can settle the matter.
- What does the current setup cost each month, labour included? Without that figure, no option can be compared fairly.
A missing name at question 1 and a small count at question 2 point to a managed PaaS or to operated virtual machines. A long list at question 4 points to staying on that cloud. A separate article compares running Amazon Web Services (AWS) yourself with a managed cloud. Platform engineers on staff, many services, or a yes at question 6 point to Kubernetes.
Where Stack Harbor fits
Stack Harbor is a Canadian-owned managed cloud operations provider (MSP) for production environments, headquartered in Montréal. It works with SaaS companies, agencies and publishers. Its clients are small and mid-sized businesses (SMBs) and agencies of roughly 5 to 200 people that run production systems without a 24/7 operations team of their own. Its own Canadian infrastructure runs in two data centres in Montréal.
Stack Harbor offers two of the four models on its own infrastructure. Cloud PaaS is a managed application platform with managed runtimes for PHP, Node.js, Java, Python, Go, Ruby and .NET. It includes managed databases, blue/green and rolling deploys, and one-click cloning of production to staging. Horizontal scaling triggers on CPU, memory or custom metrics. The platform runs on the Virtuozzo application platform, and the knowledge base explains why Stack Harbor runs Virtuozzo.
Cloud Compute provides virtual machines, bare metal and private networking, with a managed scope that ranges from self-operated to fully managed. Vertical resize is live, horizontal scale-out is a planned operation, and regional cutover is a managed operation, not an automatic one.
Stack Harbor does not sell Kubernetes as a managed service. Its services page describes Cloud PaaS as the platform layer for teams that do not want to operate Kubernetes. Its high-availability (HA) clusters page calls Kubernetes useful for some workloads and overkill for most growing SMBs. A SaaS that needs the Kubernetes ecosystem, or regions beyond Stack Harbor’s own data centres, should look elsewhere. For a SaaS that belongs on AWS, managed AWS operations covers the client’s own account, and hosting with Stack Harbor is not required.
The auto-scaling solution sets the scaling rules and a hard cap on node count before go-live. In most SMB designs the database does not scale automatically. The deployment pipeline solution adds builds, tests, an approval gate and rollback.
Stack Harbor does not publish prices. Cloud PaaS pricing combines a platform fee per environment with the resources used. A fixed quote follows a scoping call, as the page on how Stack Harbor scopes and prices an engagement explains.
Before comparing platforms, a SaaS team should write down who will operate each layer once the product is live.
