No man is an island. And no SaaS application sits alone, independent of networks and services that have a hand in its delivery. It doesn’t matter how elastic, containerized, and NoSQL you are; how cloudy, software-defined, and chilled your data centers, if your CDN is slow, if your DNS is hijacked, if your ISP is dropping packets, your users will be impacted—and they’ll hold you accountable. You may not control external dependencies, like the Internet, but in the eyes of your users, performance is monolithic, not attributable to any one element or provider. If you’re challenged to identify the source of performance issues (“Is it the app or the network?” “Is it an upstream ISP?” etc.), think about your customers. They simply won’t be able to distinguish between you as the source of an issue and a provider completely outside of your control. This is where the notion of troubleshooting gets dicey, because the surface area that your IT team needs to account for and manage in order to ensure a good digital experience, as well as brand reputation, dramatically expands when your application lives in the cloud and your users must traverse the networks and services of multiple parties in order to reach your application—and if your application is atomized and distributed, or leverages multiple APIs (such as payment gateways) and third-party components (such as Google adwords, etc.), then that user journey is actually a set of complex overlapping journeys that must appear as a single, unified experience.

As a SaaS application provider, you’re often at the forefront of technology adoption. Building out highly-available, API-driven, multi-cloud applications is your métier. You’re cloud-native, cloud-first, cloud-driven—and yet, unless you’re a major public cloud provider offering a direct connection to a business customer, your application delivery is largely beyond your direct control. There is no SaaS application independent of the Internet and a range of dependencies you and your users rely on for a good user experience.

Behold your acronym stew of dependencies

Even if you’re not in the IT trenches, actively managing internal systems and external providers, you’re probably aware that the number of third-party dependencies that your team manages has dramatically increased. These dependencies may include multiple Internet service providers (ISPs), one or more content delivery networks (CDNs), domain name system (DNS) providers, DDoS mitigation services, and the Internet routing protocol, border gateway protocol (BGP). Every single one of these may be involved in the delivery of every single user engagement with your application.

  • ISPs form the foundational infrastructure for your application delivery—The Internet is composed of thousands of independently operated networks, and the networks that your users traverse through is not under your direct control. When something goes wrong for your users, it can be challenging to figure out which network is responsible, since you can’t instrument networks that you don’t own.
  • CDNs are the “tip of the spear” when it comes to application experience—Unless you’ve built your own highly extensive edge, like Microsoft or Netflix, you’re likely going to need to leverage a third-party CDN provider, like Akamai, Cloudflare, or Fastly, to improve performance across a broad geographic area. Understanding how these providers are impacting performance for your users, is key to ensuring that you’re getting the level of service you expect and enables you to make better architectural and vendor decisions.
  • DNS is core to how the Internet functions. You may be hosting your own DNS servers or else you’re using one or (ideally) two managed DNS providers. DNS is a service that is vulnerable to tampering. It’s often a less guarded “side door” to service denial. Rather than attack your systems directly, DNS hijacking or cache poisoning can prevent users from reaching your service, even if from a software and systems standpoint, it’s fully available.
  • Internet routing, A.K.A, border gateway protocol (BGP) is also fundamental to how the Internet operates, yet because it’s built on an unverified chain of trust, it can leave SaaS providers vulnerable to outages, where your application is effectively erased from the Internet “map.”
  • Cloud-based DDoS mitigation services for a protective layer between your application and malicious activity designed to impact your availability or performance, but often their users have no way of validating that the service is working appropriately, when required, or if their service is suffering collateral damage from an attack on another client protected by the DDoS mitigation provider.

Managing the complex interaction of these delivery dependencies can be extremely challenging for even highly-sophisticated SaaS providers. We work with eighteen out of twenty of the largest SaaS providers in the world to ensure superior digital experiences for their users. We help them navigate an ever-shifting landscape that includes Internet service providers, DNS providers, CDN providers, DDoS protection services, and the vagaries of Internet routing. Based on our work with these large-scale, highly sophisticated providers, we’ve identified a set of organizational habits that can reorient your ability to manage these dependencies and successfully chart a good digital experience for your users. Discover the Five Operational Habits of Successful SaaS Delivery in part two of our SaaS experience series.

Subscribe to the
Network Intelligence Blog!
Subscribe
Back to ThousandEyes Blog