There has been a SaaS (Software as a Service) component to the solutions I’ve helped to sell for more than a decade now.  I’ve gotten to see some of the “gotchas” (often with competitors) where companies get taken advantage of with SaaS solutions.  From a professional perspective SaaS has made converting a firm to my solution easier.  I’d like to share some of these areas that critical to research when picking a SaaS solution.  Since I spent a few years working at Fastly, and they check many of the boxes, I’ve used them for many of the examples here.  Disclaimer, I own Fastly stock and I don’t think that influenced my opinions and thoughts here.

Documentation

Some solutions will be a “turnkey” solution where the vendor handles all configuration and maintenance.   First off, be aware there is a higher cost to services like this.  At times you aren’t working with “Professional Services”, rather you might want to think of them as “Expert Services.”  They’ve done it multiple times and have direct connections to Engineering and Product for help.

But if the solution is positioned that you’ll be able to maintain and add/improve certain features on your own, make sure you get access to the documentation before you sign on the dotted line.  If no documentation is available, be more cautious.  “We’ll show you how” can be challenging to arrange once the ink is dry on the contract.

Fastly has had solid documentation for years.  And as a Fastly user I’ve found it very easy to find useful examples clearly documented that I could leverage.

Training

It is a big plus if the firm offers self-paced training and certification free.  If you can have your staff go through the process before making a purchase you’ll be more prepared and have fewer unknowns.  At times good documentation is enough here.  All depends on the complexity of the solution.  In fact I’d say make sure documentation is there and adequate.  But if timing is urgent, training can make a big difference.

APIs

This won’t apply to all SaaS solutions.  But if you are integrating it into your own solution or will be making frequent changes, then Automation is King.   Bonus points if the solution is “API First” – that is to say that their entire UI runs on top of their API.  When built this way, you know that the provider is building a better product.  It will be more stable because they are not maintaining two different ways to accomplish something.  Think about it this way – every API is tested both when used as an API call as well as when called from their web UI.  And yes, Fastly is API First.

Any part of your Application Delivery Chain that is manual opens you to “fat finger” mistakes.  You don’t want a typo taking down your company.  This also brings us to Version Control . . .

Version Control

When you make changes, how can you track what changed when?  When something goes wrong, how do you know what changed?  The answer is in Version Control.  This is another Fastly excelled.  Every configuration has a version.  The version control is a bare minimum to look for.  Bonus points if there are built in features to compare versions.

This is another feature Fastly has built in.  You can compare various versions, plus roll back in seconds.  This type of visibility and control is critical if your organization depends on an application.  It is also very important that the system tracks who changed what when.  If not, you are setting yourself up for a world of hurt.  Do not expect your employees to all be disciplined and never make mistakes.  This of course brings us to RBAC . . .

RBAC

RBAC stands for Role Based Access Control. This is a way to define different roles and what permissions they have. What they can see, what they can change. I’ll use Fastly’s RBAC as an example to make it easier to understand. The key concept is that you can create Roles, like Billing or a regular User. This is from the Fastly documentation:

• User. View stats and analytics for all services on an account.
• Billing. View billing information about an account. View stats and analytics information for all services on an account.
• Engineer. View configuration details, issue purge requests, and make configuration changes, including activating new service versions. Some of these abilities may be restricted on a per service basis.
• Superuser. Full account access, including service configuration, user access and control, and account management capabilities for an account. Superusers cannot close or cancel an account unless they are also the account owner.

So just one person, or a few people, have Superuser abilities.  I suggest 2 or more of course as a best practice.  People forget passwords, leave jobs, and have laptops die.  Then there will be other people that end up as Engineers, Users or Billing.  A good SaaS system will have RBAC if it is relevant to a company and their processes around Access and Authorization.

Transparent Pricing

I remember working for a firm that did User Experience Management.  Their solution could track a user and the performance of the web pages they pull up on a site.  The problem was that they billed per “visit” and the visit was “all the activity that happened without more than a 4 hour break.”  A firm can quantify how many web page hits they get.  But can you quantify how many unique users happen per month where being “unique” resets after 4 hours go by?

Another area to be careful of is a firm that pushes hard for a 3 year contract.  True, it helps their “numbers” when looking for future investment – since they have “guaranteed” income coming in. But if their solution is not yet mature, it makes it near impossible for you to drop them as a vendor.   If things go bad 1 or 2 months in, they have years to try and smooth things over.  You’re locked in.

Fastly pricing is very clear.  You can sign up, test them out, see how the first month or two goes before you commit to a contract.  All that keeps you from leaving is a DNS change and having something else to switch to.  And don’t take the web facing pricing calculators to seriously.  They are accurate for month to month costs.  Often you can negotiate something much better.  Imagine how relaxing that would be after having used the service for a few months in Production?

Support

Support is an interesting one.  An area where I have a bias is on getting by with, or actually preferring, just chat and email support.  There are older practitioners/firms that require a phone number.  They still practice the old fire drill of a phone bridge with lots of people on it when there is an unexpected incident.

There are some huge disadvantages to this process:

• Every time a new person gets on the bridge, they have to be updated.
• If anyone steps away (bio break, etc.) they have to be updated when they return.
• People are not disciplined about muting when not speaking.
• People will talk over each other.
• Multiple “threads” are near impossible.
• This is very expensive to maintain staffing and a phone system for how seldom it is used.

I’d argue that having a system like Slack or Rocket.Chat is much better for the following reason:

• When people join the channel, they can scroll back and see what they have missed.
• Each person can set their own notification preferences.
• You can thread different topics and have multiple discussions going on at once.
• There is a record of what was discussed and when.  Actions can be documented there too.  This makes post-mortems so much easier and accurate to complete.
• You’ll find that people in other time zones are more likely to get on and monitor.  If you’ve built the right corporate culture your customers will be so impressed by how they are cared for.

The chat systems reduce burnout, are more effective and allow employees a better way to help.  If your revenue depends on this SaaS solution, you probably should do the analysis of the different support levels and their costs.  I got to see Fastly support firsthand, behind the scenes.  Much respect for their team and pride of ownership.

No Lock In

When you work with a SaaS solution there will often be work and data invested into the system.  You want to be sure that if you leave you can export your data.  You also want to be sure that you are not locked into a limited number of other systems that you can integrate with.

Fastly has a few areas that are good examples of being a more open system:

• They are “origin agnostic”.  You can use the cloud provider of your choice.  Heck, you can have multiple ones and migrate traffic in seconds based on performance and pricing.
• The logging data is your data.  Pick from more than 2 dozen providers and stream details on everything that happens at the edge.  Near real time, every request, as part of their standard package.  And if you don’t see your log provider listed, I’d bet they can output Syslog.
• You can export your configuration as VCL.  VCL is the domain specific language they use.

Check to make sure that whatever the system exports it is something you can use.  If it is compressed and locked, then you are effectively locked out.

Hands On Test Drive

Don’t buy without experiencing a true test drive.  It might be positioned as a Proof of Concept or Proof of Value.  But if your team can’t log in and try things out then it is time to be skeptical.  This was another item that is handled well at Fastly.  Anyone can sign up for a developers account.  And this account has most of the features that paid accounts – as well as runs on the same equipment/network with the same quality as paying customers get.  If you need to try out Image Optimization or TLS, just reach out to Sales and they can help you get those enabled.

Status Page

This one is hard to quantify the true value of.  Many firms have a status page like https://status.fastly.com/.  The challenge is in knowing how much you can trust this page since they are almost always are maintained by the firm.

There are a few warning flags to watch for:

• If a firm does not have one, this is a big red flag.
• If you have time, search the news to see how the firm was impacted by major Cloud provider outages or telecom provider outages.  I remember a competitor of Fastly was frequently throwing different transit providers under the bus.  My bet is that Fastly also used these same providers – but had redundancy.  Their competitor would be in the news for all the sites that got impacted.  No mention of Fastly.  The impact was far less because Fastly was quicker to detect and route around these provider outages.  The joy of finding a good deal wears off quickly when you understand the real value of what you’ve signed up for.

In Summary

There are lots of facets to a SaaS solution and much to consider.  Make sure you understand what you are buying into.

Got a good story to tell about a solution you purchased that was missing one or more of these?  Any that I am missing?  Add your thoughts to the comments.

Photo by ThisisEngineering RAEng on Unsplash, modified by author.