A challenge for SaaS providers is that demand is not known in advance. Their system must have enough slack to be able to handle all users without turning any away, but without paying for too many resources that will be unnecessary. If resources are static, they are guaranteed to be wasted during non-peak time. Sometimes cheaper off-peak rates are offered to balance the load and reduce waste. The expectation for continuous service is so high that outages in SaaS software are often reported in the news. There are no specific
software development practices that differentiate SaaS from other types of application development. SaaS products are often released early and often to take advantage of the flexibility of the SaaS delivery model.
Agile software development is commonly used to support this release schedule. Many SaaS developers use
test-driven development, or otherwise emphasize frequent
software testing, because of the need to ensure availability of their service and rapid deployment.
Domain-driven design, in which business goals drive development, is popular because SaaS products must sell themselves to the customer by being useful. SaaS developers do not know in advance which devices customers will try to access the product from—such as a desktop computer, tablet, or smartphone—and supporting a wide range of devices is often an important concern for the
front-end development team.
Progressive web applications allow some functionality to be available even if the device is offline. SaaS applications predominantly offer integration protocols and
application programming interfaces (APIs) that operate over a
wide area network.
Architecture SaaS architecture varies significantly from product to product. Nevertheless, most SaaS providers offer a
multi-tenant architecture. With this model, a single
version of the application, with a single
configuration (
hardware,
network,
operating system), is used for all customers ("tenants"). This means that the company does not need to support multiple versions and configurations. The architectural shift from each customer running their own version of the software on their own hardware affects many aspects of the application's design and security features. In a multi-tenant architecture, many
resources can be used by different tenants or shared between multiple tenants. The structure of a typical SaaS application can be separated into application and control planes. SaaS products differ in how these planes are separated, which might be closely integrated or loosely coupled in an event- or message-driven model. The control plane is in charge of directing the system and covers functionality such as tenant onboarding, billing, and metrics, as well as the system used by the SaaS provider to configure, manage, and operate the service. Many SaaS products are offered at different levels of service for different prices, called
tiering. This can also affect the architecture for both planes, although it is commonly placed in the control plane. Unlike the application plane, the services in the control plane are not designed for multitenancy. The application plane—which varies a great deal depending on the nature of the product—implements the core functionality of the SaaS product. Key design issues include separating different tenants so they cannot view or change other tenants' data or resources. Except for the simplest SaaS applications, some
microservices and other resources are allocated on a per-tenant basis, rather than shared between all tenants. Routing functionality is necessary to direct tenant requests to the appropriate services. deployment to other tenants |upright=2|center Some SaaS products do not share any resources between tenants—called siloing. Although this negates many of the efficiency benefits of SaaS, it makes it easier to migrate
legacy software to SaaS and is sometimes offered as a premium offering at a higher price. Pooling all resources might make it possible to achieve higher efficiency, but an outage affects all customers so availability must be prioritized to a greater extent. Many systems use a combination of both approaches, pooling some resources and siloing others. Other companies group multiple tenants into pods and share resources between them. SaaS architecture typically allows users to access applications through a web browser without installing software on their local devices. This approach simplifies software maintenance and updates, as service providers can manage the application centrally. It also enables organizations to scale services easily according to their needs. ==Legal issues==