The more prospects I talk to, the more I hear about the dreaded SaaS downtime. Downtime isn’t just an inconvenience. Organizations count on SaaS vendors to ensure certain levels of uptime, so that the organizations themselves can continue to run their business.
So, what is a responsible SaaS downtime?
Using the 99.999% standard, you’re looking at 26 seconds of downtime monthly, or 5 minutes and 13 seconds of downtime yearly. This is a great when it’s achieved. However, many vendors are having issues making this a reality. In fact, two other leading ZTNA SaaS vendors have had multiple, unscheduled outages over the last month. One vendor was down about 30 minutes each time. The other vendor had six outages in one month. You can find out about scheduled and unscheduled outages when you go to their status sites. We’ve had multiple prospects come to us for help with this problem.
Are all outages equal in the world of SaaS downtime?
No. Planned, scheduled maintenance periods are announced ahead of time and are usually on the weekends, early in the morning. All of your favorite SaaS applications do this and you probably have never noticed. The ones you do notice are the problem. Moreover, when the SaaS solution has multiple components, the vendors are sometimes not acknowledging the issue which leaves IT teams running in circles. Business productivity suffers, and the blame goes to the IT folks that rely on the vendor.
What do these two vendors have in common?
A few things that they have in common may be resulting in the frequent outages:
- Both run their own point of presences (PoPs)
- While the idea of having your own global PoPs makes some sense, the reality is that there are never enough, and most vendors don’t know how to build them properly or keep them running properly. This is evident by all the frequent outages.
- Both rely on traffic coming to their PoPs, becoming a Man in the Middle (MitM)
- If the traffic flow from an end-user to a resource involves going to the PoP and the PoP is down, the end user cannot do their job or be productive. These vendors using a “tunnel stitching” model where the end user and the resource both need to connect to the vendors cloud. This isn’t just a problem from a data privacy perspective, but also a problem from a single point of failure perspective. This MitM architecture is typical with vendors that got their start as a Cloud Access Security Broker (CASB) or Secure Web Gateway (SWG). They built their solution to centralize all customer traffic for inspection and then layered on some access functionality.
How is Banyan Security different?
Many ways but we’ll address three:
- Banyan started as a ZTNA vendor first and we’re serious about security. This means we don’t act as a MitM who decrypts, inspects, and re-encrypts traffic. This also means that traffic doesn’t need to come to us which results in better performance, lower latency, and your data is not going to stop flowing even during our scheduled maintenance windows. You deploy the data plane in your own data center and/or cloud service provider (CSP) and are in total control of your organizations data and data flow.
- No PoPs. Our solution is built to run everywhere, and we have customers that do exactly that. This means that our PoPs can’t go down. The solution is mainly run in GCP but has disaster recovery (DR) sites deployed everywhere. We aren’t going down because GCP or AWS are down. Instances are running in many places and connections are diverted to systems in your region. Our business is ensuring that your business is secure and productive.
- Flexible deployment options. Unlike other vendors, we give you options for how and where to deploy. We also don’t charge for connectors or gateways which means you are free to deploy as many as you like, wherever you like – on-premises, CSPs, laptops, and even on a Raspberry Pi.
To learn more about how Banyan helps with business continuity and schedule a demo, visit https://www.banyansecurity.io.
