Choosing PaaS for a New .NET Web App Without Sacrificing Control or Future Portability

A team is preparing to launch a new .NET booking application. The first proposal is to create virtual machines, install the operating system, configure the web server, deploy SQL Server, and manage the complete environment. The plan offers control, but it also gives the team responsibility for work that does not directly improve the booking experience.

Another proposal is to deploy the web application and database as managed cloud services. That reduces infrastructure work and shortens the path to release, but some developers worry that the application will become tied permanently to one provider.

The correct decision is not simply "cloud versus on-premises." The real choice is how much of the technology stack the team should operate itself, how much customization the application requires, how quickly it must reach users, how unpredictable the workload is, and which security responsibilities the team is prepared to own.

The Application and Its Constraints

Assume the booking platform contains these responsibilities:

• An ASP.NET Core web application for customers and staff
• A relational database for bookings, customers, and prices
• A background process that sends campaign emails during irregular traffic peaks
• A document feature that must read restricted files stored inside a customer's private network
• A small development team that must release an initial version quickly
• Business rules that are important enough to justify custom software

The team needs to choose among five deployment approaches:

• Infrastructure as a Service, or IaaS
• Platform as a Service, or PaaS
• Software as a Service, or SaaS
• Function as a Service, or FaaS, often called serverless
• A hybrid design that combines cloud and on-premises components

The decision should be made per responsibility, not necessarily once for the entire system.

Customer Browser
       |
       v
Custom Booking Application
       |
       +--> Booking Database
       |
       +--> Campaign Email Processing
       |
       +--> Restricted Document Connector

Each component has a different workload, customization need, and security boundary. Forcing all of them into the same hosting model can create unnecessary cost or complexity.

Why Starting with Virtual Machines Can Be the Wrong Default

IaaS provides computing infrastructure such as virtual machines while leaving the operating system and application environment under the customer's control.

That control is useful when the application depends on a specific operating system setup, legacy software, unusual network configuration, or direct access to the host. It is also a common route for moving an existing on-premises system to the cloud with minimal architectural change.

For a new application, however, control has a price.

With IaaS, the team remains responsible for areas such as:

• Operating system configuration
• Operating system updates
• User and privilege management
• Web server setup
• Runtime installation
• Application deployment
• Application and data security
• Capacity planning
• Ongoing infrastructure maintenance

The cloud provider protects the underlying cloud infrastructure, but it does not automatically secure everything inside the virtual machine. Treating an IaaS deployment as fully managed can leave important responsibilities without a clear owner.

IaaS is a strong candidate when full infrastructure control has higher priority than delivery speed and maintenance reduction. It is a weak default when a small team is building a standard web application from scratch.

Why PaaS Fits the Main Booking Application

PaaS provides a managed application platform. The team deploys the application and manages its data, while the provider handles more of the operating system, runtime environment, and infrastructure.

For the booking system, Azure Web Apps can host the web application without requiring the team to build and maintain the complete server environment. Azure SQL Database can provide relational storage without requiring the team to install and operate a full database server.

The responsibility boundary becomes narrower:

Team responsibilities
  - Application code
  - Business rules
  - Application configuration
  - Data
  - Application users and permissions

Managed by the platform
  - Physical infrastructure
  - Host operating system
  - Much of the runtime environment
  - Platform availability features
  - Managed database operations such as backups

This is valuable because the team can spend more time on booking behavior and less time on operating systems and database servers.

PaaS also has limitations. The team does not receive full control over the host operating system, and direct access may be unavailable. That can make certain forms of debugging or specialized configuration more difficult.

The decision is therefore not that PaaS is always better. It is that PaaS is usually a better starting point when:

• The application is new
• Rapid delivery matters
• Standard web hosting is sufficient
• The team wants managed scaling and platform operations
• Direct operating system control is not a core requirement

Preventing PaaS from Becoming an Architectural Trap

A managed platform should not become a dependency inside the business model.

The application can reduce future migration cost by isolating cloud-specific behavior behind interfaces and adapters. The booking rules should not need to know whether data is stored in a managed cloud database, a database on a virtual machine, or another compatible persistence service.

Booking Domain
      |
      v
Application Interfaces
      |
      +--> Azure Database Adapter
      |
      +--> Alternative Database Adapter
      |
      +--> On-Premises Document Adapter

This design follows the dependency direction used by Onion Architecture:

1. Business rules remain at the center.
2. Application services depend on business abstractions.
3. Infrastructure components implement those abstractions.
4. Cloud-specific code stays near the system boundary.

For example, the domain might depend on an IBookingRepository abstraction rather than a provider-specific database client. A document service might depend on an IDocumentSource abstraction rather than assuming every file lives in cloud storage.

This does not make migration free. It prevents cloud-specific details from spreading through the entire codebase, which makes later movement to another PaaS or to IaaS more manageable.

Where SaaS Fits and Where It Does Not

SaaS provides a complete application that users can adopt rather than build.

It offers the fastest route when an existing product already satisfies the business requirement. The customer does not manage the application's infrastructure or implementation.

The booking company should first ask whether it needs to build a capability at all.

A SaaS product may be suitable for supporting functions such as lifecycle management or team collaboration. It may also replace a business system when customization is limited and the available product matches the organization's processes.

It is less suitable for the booking engine when custom pricing, reservation rules, and customer experience are central competitive capabilities.

Before adopting SaaS, evaluate:

• Whether a suitable product already exists
• Whether it can be customized and integrated sufficiently
• The complete organizational cost, not only the subscription
• Security and compliance compatibility
• Supplier reliability and support
• Future scalability
• The difficulty of changing suppliers later
• Results from a realistic trial or staging evaluation

SaaS reduces development and maintenance, but it also reduces control. The more deeply a product becomes embedded in business operations, the more difficult replacement may become.

Use FaaS for Unpredictable, Event-Driven Work

The campaign email component has a different workload from the main booking application.

Most of the time, it may do little or no work. During a campaign, demand may rise sharply. Keeping a large server or permanently scaled application tier available for occasional peaks can waste capacity.

FaaS is designed for event-driven work where execution is triggered only when needed. The platform handles scaling, and the customer is charged according to actual execution rather than continuously reserved capacity.

Campaign Event
      |
      v
Serverless Entry Function
      |
      v
Reusable Email Processing Module
      |
      v
Email Provider

This model is attractive when:

• Traffic is difficult to predict
• Work arrives in bursts
• Processing is stateless or can be organized as loosely coupled operations
• The application should scale without manual capacity management
• Low idle cost matters

FaaS also introduces tradeoffs:

• Cold starts can add latency
• Provider-specific function APIs can increase lock-in
• Stable, consistently high workloads may become less economical
• Highly fragmented functions can make migration difficult

A practical mitigation is to keep the function entry point small while placing most business logic in ordinary reusable modules. If the workload later becomes stable and moves to PaaS or IaaS, the team can replace the hosting entry point without rewriting the complete processing logic.

Build a Decision Matrix Instead of Arguing from Preference

Cloud discussions often become opinion contests. One developer prefers virtual machines because they are familiar. Another prefers serverless because it removes infrastructure work. Neither preference is enough.

Evaluate each option against the project's actual priorities.

A useful matrix includes:

Then use a repeatable process:

1. Remove models that cannot satisfy mandatory requirements.
2. Assign a weight to each remaining criterion.
3. Score each deployment model against every criterion.
4. Multiply each score by the criterion weight.
5. Compare the totals.
6. Investigate closely when two options receive similar results.
7. Validate the preferred choice with a small practical deployment.

For the booking platform, the team might give high weight to delivery speed, maintenance reduction, and customization. That would probably favor PaaS for the main application over IaaS or SaaS.

For campaign email processing, unpredictable scaling and low idle cost may dominate. That would make FaaS a stronger candidate.

The score does not replace architectural judgment. It makes the assumptions visible so the team can challenge them.

Use Hybrid Architecture When Data Cannot Move

The restricted document requirement prevents the entire solution from moving into the cloud.

Some customers may require confidential files to remain on an internal server. Rejecting the cloud completely would also reject the benefits it can provide to the rest of the application.

A hybrid design connects the cloud application to an on-premises subsystem through a dedicated adapter.

Cloud Booking Application
          |
          v
Document Source Interface
          |
          v
On-Premises Connector
          |
          v
Private Document Server

The cloud application remains responsible for the user workflow, while the private subsystem remains responsible for retrieving documents inside the customer's network.

This approach is useful when:

• Regulations or business policies restrict data location
• Existing internal systems cannot be replaced immediately
• Some workloads benefit from cloud scaling while others must remain local
• Migration must happen gradually
• Security or availability concerns require different placement for different components

Hybrid architecture should be intentional. The interface between cloud and on-premises components must be treated as a real system boundary with clear ownership, failure handling, and security requirements.

The Recommended Deployment Split

For the booking scenario, a reasonable starting architecture is:

IaaS remains available if a future component requires host control or if an existing system must be moved with minimal redesign.

The important point is that "the application is on Azure" is not a complete architectural decision. Each capability should use the model that best matches its constraints.

Common Mistakes

Choosing IaaS because it resembles the current data center

Familiarity can hide the long-term cost of operating systems, patching, privileges, web servers, and capacity. Use IaaS when control is required, not merely because the team already understands virtual machines.

Choosing SaaS based only on subscription price

The real cost includes process changes, integration, training, supplier dependency, and the difficulty of leaving later.

Choosing FaaS for a stable, heavy workload

Serverless is especially useful for uncertain and bursty workloads. When usage becomes stable and consistently high, another model may deserve reevaluation.

Assuming PaaS removes all security responsibility

The platform manages more infrastructure, but the team still owns application behavior, data protection, identities, authorization, and secure configuration.

Mixing provider APIs into business logic

Cloud-specific dependencies spread migration cost. Keep them inside adapters at the system boundary.

Treating hybrid architecture as a temporary accident

A hybrid solution may remain for years. Design its communication, ownership, and failure behavior as carefully as any external integration.

Cloud Model Checklist

• [ ] List each application capability separately
• [ ] Identify mandatory customization requirements
• [ ] Record workload stability and expected traffic variation
• [ ] Define which security layers the team must own
• [ ] Compare maintenance effort, not only hosting price
• [ ] Evaluate whether SaaS already solves non-core capabilities
• [ ] Use PaaS when managed hosting supports the required application model
• [ ] Use FaaS for suitable event-driven and difficult-to-predict workloads
• [ ] Use IaaS when host-level control or lift-and-shift migration is necessary
• [ ] Consider hybrid deployment when data or systems must remain on-premises
• [ ] Isolate provider-specific code behind interfaces and adapters
• [ ] Test the selected model with a realistic workload and environment
• [ ] Reevaluate the choice when traffic and business constraints change

Conclusion

The best cloud architecture is rarely one service model applied everywhere.

For a new .NET web application, PaaS can reduce operational work and improve time to market without forcing business logic to depend on the platform. IaaS remains valuable when infrastructure control is essential. SaaS is effective when an existing product meets the need. FaaS fits event-driven workloads with unpredictable peaks, and hybrid architecture solves cases where some systems or data must stay on-premises.

Make the choice per capability, document the tradeoffs, isolate provider-specific dependencies, and revisit the decision as the workload becomes better understood.