Multitenancy in SRS Applications

Over the past few years, SRS has been undergoing an intense technological evolution. A fundamental part of this evolution is the mental transition from being entirely application-centric to instead embrace the principles of SOA and SaaS.

This transition has not been easy and has often lead to confusion. One of the most difficult concepts for us to grok has been that of multitenancy.

Question: What is multitenancy?
Answer: Multitenancy is a software architecture where a single instance of an application serves multiple customers (tenants) simultaneously.

While this concept seems straightforward, many teams have struggled to correctly identify their project’s customer (tenant).

Question: Who is the customer (tenant) for my project?
Answer:For all current SRS projects, there are two possible answers:

  1. For external-facing projects, your customer (tenant) is a shop.
  2. For internal-facing products, your customer (tenant) is a project.

Once we have correctly identified our customer, our entire product must be built around that tenant. Our product must protect each tenant by safeguarding their data from any other tenant.


  • In Direct-Hit, one shop may not access another shop’s customer data.
  • In SRSWP Logger, one project should not have access another project’s log files.

Every SRS project must be architected to support multitenancy. I acknowledge that there are circumstances where defining the tenant may seem subjective. If your project has any doubt about whether the tenant has been correct identified, please ask. Any of the architects will be happy to assist.

The success of our SRS platform (including EDGE, Direct-Hit, etc.) hinges on every project correctly implementing multitenancy.

zVision is the future!

This internal memo was sent to SRS Software this morning. The points are important enough that I wanted to cross-post here.


I know there has been a lot of frustration over the last year as we have been working on zVision, the web platform, and ReEn. The shift we are making takes us from creating products to the creation of a platform.

So far, most have only felt the pain of the transition and have not seen the advantages. I promise you that this transition will be worth the pain and frustration. We are on the cusp of realizing a payout and it will be huge!

A guy who worked at Amazon and is currently at Google recently posted what was intended to be an internal memo on this topic. Everyone should take time to study the attached memo ( and understand the points that are made.

Here are a couple of threads where people are discussing Stevey’s memo that you may find useful:

I will continue to do everything I can to clearly communicate the amazing direction we are headed.

  • zVision puts us at the forefront of the technology industry!
  • zVision is the platform we need to carry us for the next 10+ years!
  • zVision will give SRS the flexibility and agility to dominate in our chosen market!

You are welcome to send me questions or comments privately. Alternatively, I have cross-posted this to my blog and you are also welcome to publically comment there.

– Nate

Nate Zobrist | VP of Software Architecture
Service Repair Solutions, Inc. — Revolutionizing the Delivery of Service and Repair™

770 East Technology Avenue, Building F | Orem, Utah 84097
Phone: (801) 437-5846 | Fax: (801) 437-5899 | Cell: (801) 788-4789

Contract Definition and Stability

In my first zVision presentation that was recently given at each of the SRS offices, I identified one of Engineering’s current problems as an “absence of trust” between teams. This phrase caused some confusion that I would like to clarify.

Let’s say I want to write an app that integrates with the bookmarking service. My application will be reliant on their public API. So, for this venture to be successful:

The API’s Contract Definition is essential:

  • Method descriptions, examples, limitations and assumptions are all necessary and are included as part of the API documentation.

The API’s Contract Stability is essential:

  • Breaking changes should be very rare. Even with a disclaimer stating that it may change at any time, there is an implied level of stability in any published API.
  • When a breaking change to the API is necessary, backwards compatibility will be provided. That’s why their APIs all have “v1” in them!

Within SRS we should think about cross-project integration similarly to integrating with external services like Except in very rare situations, touch points between products are limited to APIs (i.e. massively-versioned web services).

When I referred to “absence of trust” in zVision, I call attention to the fact that we do not yet have the requisite level of Contract Definition and Contract Stability in our APIs. Without both definition and stability, I could not trust the API enough to base my app on it. The same is true for building on SRS-internally produced services.

Since the end of 2010 and through 2012 we are making a large investment in re-architecting our products based on principles of SOA and SaaS. Absolutely essential to success are APIs which are both well defined and stable. Once we have those things, we can trust the services provided by other SRS teams as much as we would trust