Infrastructure as a Service
Provider supplies virtualized compute, storage, and networking. Customer manages everything above the hypervisor such as OS, middleware, runtime, and application. Customers rent raw virtual machines and configure them as needed. No assumption about workload type. Full control, full responsibility. Client is responsible for OS-level and application-level security configuration.
Advantages:
- Maximum flexibility — customer chooses OS, runtime, and software stack.
- No hardware procurement or maintenance.
- Pay-per-use billing with on-demand scaling.
Disadvantages:
- Customer responsible for OS patching, security hardening, and runtime management.
- Higher operational overhead compared to PaaS or SaaS.
- Requires infrastructure expertise from the customer’s team.
Common use cases: hosting custom applications, running legacy software, high-performance computing, development and test environments.
Examples: AWS EC2, Azure Virtual Machines, Google Compute Engine.
Platform as a Service
Provider manages the infrastructure and runtime environment. Customer deploys application code and data only. No OS or middleware management required.
The platform handles scaling, load balancing, patching, and availability automatically. Provider manages platform security; client controls application security configuration.
Advantages:
- Faster development
No infrastructure setup required. - Automatic scaling and patching managed by provider.
- Reduced operational overhead, freeing developers to focus on application logic.
Disadvantages:
- Less control over the underlying environment.
- Vendor lock-in — applications may be tightly coupled to provider-specific APIs.
- Limited configuration options compared to IaaS.
Common use cases: web application hosting, API backends, data processing pipelines.
Examples: AWS Elastic Beanstalk, Google App Engine, Heroku, Azure App Service.
Software as a Service
Software product runs on provider’s servers. Customers access remotely over the internet. Customers usually pay a subscription for the service. Provider handles infrastructure and security; client is responsible for user access control.
Releases are less painful because:
- Customers do not have to explicitly update the software.
- All customers are on the same version.
Provider receives regular cashflow. And they have usage analytics on how the service is being used.
Customers get multi-device access, no upfront cost, immediate updates, reduced management overhead. However there are privacy/regulation concerns, network latency constraints, security risks, loss of update control, service lock-in, data exchange friction.
SaaS Design Issues
Five primary concerns:
- Local/remote processing
Partition computation between client and server. Local execution reduces network traffic but increases client power consumption. - Authentication
Use provider-managed credentials, federated auth (delegating to the user’s employer), or third-party identity providers. - Information leakage
Multi-user systems risk cross-tenant data exposure. Requires careful security architecture. - Multi-tenant vs. multi-instance database
Fundamental architectural decision. - Customization
Business customers may require custom authentication (federated auth), branding, business rules, data schemas, and access control models. Per-company profile objects wrap the central application so users interact through their organization’s profile.
Multi-tenant System
A system where a single database instance is used which is shared by all customers. Data partitioned logically.
In the database, each record is tagged with a tenant identifier. Logical isolation is implemented at the access layer.
Easier update management and central resource management for providers.
Provider controls and optimizes all resources centrally, a single codebase needs to be patched, and a single update propagates to all tenants simultaneously.
Less customization options for tenants. 2 ways to implement customizations:
- Extension fields
Extra columns per table. Per-tenant profile maps extra columns to meanings. Does not scale well. Breaks 1NF of database. Increases query complexity. - Extension tables
Field metadata is stored in one table per tenant. Field values are stored per record in a separate table. Increases query complexity.
A breach affects all tenants simultaneously. Multi-user management logic has high potential for bugs. Single point of failure.
Tenant data could be encrypted at rest to prevent cross-tenant exposure on failure or breach.
Multi-instance System
A system where each customer has a separate application and database instance. Physical isolation.
2 types:
- VM-based multi-instance
One VM per customer. All users within that customer share one database. - Container-based multi-instance
One container set per user. Isolated database per user. Suited to low-data-sharing workloads and individual users.
No cross-tenant data leakage possible. Resource management per customer (or user). No single point of failure.
Increased cost. Each instance must be updated separately which is complex for tailored instances.