Thinking Beyond Infrastructure

While looking at SaaS through the lens of shared infrastructure makes it easier to understand the value of SaaS, the reality is that SaaS is much more than shared infrastructure. In fact, as we move forward, we’ll see that shared infrastructure is just one dimension of the SaaS story. There are economies of scale and agility can be achieved with SaaS–with or without shared infrastructure.

In reality, we’ll eventually see that there are actually many ways to deploy and implement your SaaS application architecture. The efficiencies that are attributed to SaaS can certainly be maximized by sharing infrastructure. However, efficiency starts with surrounding your application with constructs that can streamline the customer experience and the management/operational experience of your SaaS environment. It’s these constructs that–in concert with your SaaS application architecture–enable your SaaS business to realize its fundamental operational, growth, and agility goals.

To better understand this concept, let’s look at these additional SaaS constructs. The diagram in Figure 1-4 provides a highly simplified conceptual view of these common SaaS services.

Figure 1-4. Surrounding your application with shared services

At the center of this diagram you’ll see a placeholder for application services. This is where the various components of your SaaS application are deployed. Around these services, though, are a set of services that are needed to support the needs of our overall SaaS environment. At the top, I’ve highlighted the onboarding and identity services, which provide all the functionality to introduce a new tenant into your system. On the left, you’ll see the placeholders for the common SaaS deployment and management functionality. And, on the right, you’ll see fundamental concepts like billing, metering, metrics, and analytics.

Now, for many SaaS builders, it’s tempting to view these additional services as secondary components that are needed by your application. In fact, I have seen teams that will defer the introduction of these services, putting all their initial energy into supporting tenancy in their application services.

In reality, while getting the application services right is certainly an important part of your SaaS model, the success of your SaaS business will be heavily influenced by the capabilities of these surrounding services. These services are at the core of enabling much of the operational efficiency, growth, innovation, and agility goals that are motivating companies to adopt a SaaS model. So, these components–which are common to all SaaS environments–must be put front and center when you are building your SaaS solution. This is why I have always encouraged SaaS teams to start their SaaS development at this outer edge, defining how they will automate the introduction of tenants, how they’ll connect tenants to users, how they’ll manage your tenant infrastructure, and a host of other considerations that we’ll be covering throughout this book. It’s these building blocks–which have nothing to do with the functionality of your application–that are going to have a significant influence on the SaaS footprint of your architecture, design, code, and business.

So, if we turn our attention back to the diagram in Figure 1-4, we can see this big hole in the middle that represents where we’ll ultimately place our application services. The key takeaway here is that, no matter how we design and build what lands in that space, you’ll still need some flavor of these core shared services as part of every SaaS architecture you build.