Everything as a Service

4 min read Last updated Tue Jun 09 2026 03:05:56 GMT+0000 (Coordinated Universal Time)

Infrastructure as a Service

Provider supplies virtualized compute, storage, and networking. Customer manages everything above the hypervisor: OS, middleware, runtime, and application. 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.

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 it remotely over the internet, usually via a subscription. Provider handles infrastructure and security. Client is responsible for user access control.

Customers receive updates automatically. All customers are on the same version simultaneously.

Provider benefits:

  • Regular cashflow.
  • Usage analytics on how the service is used.

Customer advantages:

  • Multi-device access.
  • No upfront cost.
  • Immediate updates.
  • Reduced management overhead.

Customer disadvantages:

  • Privacy and 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, 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

Single database instance shared by all customers. Data partitioned logically. Each record tagged with a tenant identifier. Logical isolation implemented at the access layer.

Provider advantages:

  • Easier update management.
  • Central resource management.
  • Single codebase to patch.
  • Single update propagates to all tenants simultaneously.

Disadvantages:

  • Less customization options for tenants.
  • A breach affects all tenants simultaneously.
  • Single point of failure.
  • Multi-user management logic has high potential for bugs.

Two ways to implement tenant 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 stored in one table per tenant. Field values stored per record in a separate table. Increases query complexity.

Tenant data can be encrypted at rest to prevent cross-tenant exposure on failure or breach.

Multi-instance System

Each customer has a separate application and database instance. Physical isolation.

Two types:

  • VM-based
    One VM per customer. All users within that customer share one database.
  • Container-based
    One container set per user. Isolated database per user. Suited to low-data-sharing workloads and individual users.

Advantages:

  • No cross-tenant data leakage possible.
  • Resource management per customer.
  • No single point of failure.

Disadvantages:

  • Increased cost.
  • Each instance must be updated separately, which is complex for tailored instances.
Was this helpful?