1. SaaS
A practical example of a real-world SaaS application done with LEAN
software development.
• Stuart Williams, Principal Lead, Magenic SF
2. Why? We needed a demo
• We really can’t show most of our project to potential customers and at
community events because the things we do are confidential. We wanted
– to make a real SaaS product with the latest stable technology
– the milieu to be understandable by anyone
– to be able to give the parts of the code away
– to give sales a “killer demo”
– to show off what we thought were good patterns and practices in all of
the technology areas that are part of the demo
– to leverage some of the services in windows and azure service bus
• So, we thought about it as a group and decided that what we would do
would be a real project treated like a product, made with high quality,
and delivered the same way we would deliver it for a real customer
3. Why SaaS?
• Because we want economies of scale
– Shared infrastructure will lower the per user cost
• Because we want one version of our product
– Everyone benefits from an upgrade with new features or fixes
– Cost of developing new features defrayed across multiple tenants
• Because we want to have a per user/per month pricing model
– That way cost to tenants is predictable and scales smoothly
• Tenants can start using the product very quickly
– Nothing to install, just some configuration and data and off they go
• Easy to debug tenant issues as opposed to premise
– we have full access to the infrastructure and inspect as needed
4. The What: Generic Supply Chain Application
• Focusing on B2B delivery of goods and services
• Examples:
– Cleaning Supplies
– Cleaning Services
– Linen Service
– Specialized Office Supplies
– Appliance Parts
– Etc.
• The portal we are building will be for the benefit of the employees of the
company who we are providing software for (AKA the TENANT) who is
the client of the SaaS company (Magenic)
• SaaS means that on the same infrastructure we can support multiple
Tenants each with their own business
6. Major Entities
• Tenant • Sales Orders
– One instance for a specific – Customer buys products and
client services
– Also used for refunds and
• Company
adjustments
– All kinds: Customers, Vendors,
• Purchase orders
Others
– Client (Tenant) buys stuff to sell
• Contact
• Delivery/Shipment
– People of all kinds – Covers deliveries and shipments
– People belong to Companies • Payments
• Products – Client get paid from their
– Stuff to sell customers
– Includes services • Transactions
– Record of all transactions
Lots of other smaller tables like notes, etc.
7. SaaS Pricing Models
• Free
– Open source projects that rely on contributions (rare)
– More commonly buy-up to better features, extra services
• Extras billed as used
• Per user/per month
– Most common, predictable, easy to understand
• Usually monthly billing with pre-pay discounts for multi-month
• Extra charges itemized on each invoice
– Usually with some sort of limits on transactions or storage
• Per XXXX
– Per transaction or event
• Usually instant billing
– Good for services people will only want occasionally
8. SaaS: Costing
• The nuance of course is figuring out how much a SaaS offering on a
platform will cost. For cloud this is especially tricky as there is a fair
amount of variable cost possible e.g. they bill you like a Taxi, typically you
bill your customers like a magazine subscription. The question is of course
is, do you make more than it costs?
• To really model the cost You MUST
– Have a pretty good idea of your architecture and what services etc.
your application are using
– Have a solid visualization of the actual usage patterns of your
customers e.g. how many users per tenant, how much storage,
transactions, uploads, etc.
– Monitor the ACTUAL resource usage of your customers to make sure
you did not over or worse under estimate their usage
• Magenic’s cloud group can help organizations build models for SaaS
offerings working with IT and Finance
9. SaaS Cost + Pricing
• The problem is that even if the resource usage scales linearly with users,
the infrastructure cost is generally stair step or sinusoidal
– So up to a point adding additional users does not change the cost
model, but then to comply with the expectations of the users you will
have to add an aliquot of capacity which is in larger whole units, from
then on until a new break even point is reached you are paying for
infrastructure you are not using but are paying for
– More subtly, adding a new customer (not just more users) may have
start up costs of its own, such as a need for another SQL instance,
another set of storage keys, etc. This makes the stair step even more
jagged.
– Again working with Finance is key, as they may have other
considerations such as CAPX vs. OPX, etc. they want have considered.
• Of course you need to pay to develop it, operate it, and of course make
money.
10. The Stair Step
Is this line above
(good) below (bad) or
on the stairs?
$$$$
Subscribers
11. Typical Costing vs. Pricing Calculator (Excel)
Basic Facts
Sizing and Frequency
based on data model,
expectations of usage,
frequency of updates,
etc.
One Tenant Cost
# Tenants (projected)
Additional fixed and
variable costs
Pricing Models
12. SaaS: Key Requirements To Think About
• Capture user events for billing and analysis
– Logins
– Transactions
– Data Storage (GB)
– Uploads/Downloads (KB)
• Use these to make sure your projection of cost agrees with what you
planned so as to validate your pricing model
• Make sure you keep track per tenant the invoicing events, you can insert
these as events into an events table along with the other events
• Even if you plan to offer it free, keep track anyway
• Instrumentation can be hard to add in later, so plan for it from the start
13. SaaS: Tenant Separation
• Prospective tenants will be anxious about how we will go about keeping
their data separate from everyone else
• This is the single most important issue for both business and architects
• Strategies:
– Database
• For all entity tables make sure that the tenant ID is a required FK
• For queries, test, test, test, make sure that tenant separation tests are P0 fails
• Sadly, instance/tenant is not economical
– Storage
• Use providers container mechanisms to keep them logically separate
• Make tenant Id part of storage path or key
– Web site
• Make tenant id or alias part of path (MVC is good at this)
• Make sure pages fail if no tenant or if record requested does not belong to tenant
• TEST TEST TEST
• Even one tenant separation failure Very bad news
14. SaaS: Tech support considerations
• Do we allow tech support to impersonate the tenant admin and look at
the tenant’s data?
– If so, how much of it?
• Could be scary and risky
– If not
• then some sort of screen/session sharing is essential
• Can avoid having to deal with user login issues if using FI (More about this later)
• Tenant Administrator (Superuser) can do basic stuff to tenant like re-issuing the
invitation for the Company Admin to link up FI or enabling/disabling tenants
• Make good screens so Company Admin can self manage their own data and users
– Some problems are beyond tech support, so have a plan just in case
– In all cases must provide repudiation protection via logging and audit
trail
15. SaaS: How do they sign-up? Pay?
• Do you allow self signup?
– For consumer apps this is not even a question it is a MUST HAVE.
– For commercial apps, typically not, might require more setup and
configuration, not to mention hand holding
• How do they pay?
– Consumer apps
• typical e-commerce methods PayPal, credit cards
• Unless e-commerce is your core business outsource payments
– Commercial apps
• Can do credit cards if amounts are < $X
• Typically invoiced monthly
• also invoicing forces some degree of interaction with customers
16. SaaS: Provide great customer service
• SaaS (or any other web app) is not an excuse for poor customer service
• Some hallmarks:
– Decent help text, ideally on each page as they go
– FAQ focused on problem areas
– Walkthroughs of common tasks
– Provide live chat (especially for commercial apps)
– Provide easy to find e-mail help with guidance
– Solicit feedback on each page and on the site in general
– Keep help content fresh with new content driven by customer service
and customer feedback
• Great support and easy to use features == Customer Loyalty
17. SaaS and Security
• Organizations
– spend too much mental energy on if the cloud host (Azure for
example) is secure and
– far too little effort and energy on if the code of their application is
secure
• The chances that the infrastructure will let you down from a security
point of view is REMOTE compared to the risks of:
– Poor deployment
– Horrible configuration
– Bad key management
– Security holes in the code
• There is not substitute for having a Security Development Lifecycle and
building in security at all levels and processes
