In our previous post, we covered some of the many Building Blocks of SaaS and how to manage their inherent risks. In today’s post, we dive into the five operational habits of successful SaaS delivery and some concrete ways you can seed these habits in your own organization. These operational habits have been gleaned from the top SaaS providers around the globe who we work with to navigate through the various dependencies that you and your customers rely on for good user experience.
These “habits of success” cover your organization’s culture, your relationship with your vendors and other third-party providers, your relationship with your customers, and your strategic decisions and operational know-how. We start with a habit that’s an inverse of one that’s almost as old as IT itself.
1. Stop Accepting the Culture of “It’s always the Network.”
If you go to your incident management system of choice and look back at the distribution of tickets across application and network over a period of time, you’re going to have a mix of both application and network issues. Yet, when it comes to troubleshooting user performance issues in your own environment, the network is usually the first target. The network team usually has to prove its innocence before the application team will mobilize. This default “blame the network” approach is not only a productivity-sucking distraction, but it can also inhibit team collaboration, which is critical to quickly identifying and resolving issues. Is it the network or the application? Getting a quick view of network health, with application context, can enable you to demolish the flamethrowing network and application silos that have historically plagued traditional IT shops.
Even if your organization supports close alignment between DevOps and NetOps, it’s critical to have a multi-layer view that correlates network performance with application experience so you can quickly identify whether it’s an application or network issue—and if it is a network issue, see which network is responsible.
2. Reframe Your Relationship with Third-Party Dependencies
Most service providers don’t have the resources to fully investigate or even acknowledge every performance-related inquiry they get each day, which can make resolving issues with them very challenging, particularly if you have no concrete data showing they’re at fault. As a result, you can easily fall into a tiring routine where you try to escalate issues and your service provider swings into the 3 D’s: deny, deflect and defer.
You may infer responsibility based on tell-tale patterns or past experience, but most providers won’t spend time troubleshooting on your behalf, particularly when they may be on the hook for a fix, or on the receiving end of an SLA penalty. This is where evidence comes in. When you live in the cloud, your troubleshooting mantra can no longer be just “find and fix,” it must also be “evidence and escalate,” where you have a proven set of steps to gather evidence (even across networks and services you don’t control) that can get you to a successful escalation.
When you’ve mastered “evidence and escalation,” you’re no longer at the mercy of external providers (both direct and indirect). You’ve gained control, and you can dramatically reduce the time it takes to resolve issues—which improves uptime, performance, and overall user digital experience.
3. When it Comes to Your Customers, Show, Don’t Tell
As a SaaS provider, it’s your job to perform “sleight of hand” and produce “SaaS magic”—a unified experience that results when every application component (many third-party), and every external network and service work seamlessly to construct and deliver your application. Every day, you work to maintain this illusion, as if nothing came between you and your users. No questionable ISPs, no compromised DNS cache, no false route advertisements, no broken API endpoints. But when something does go wrong, you need to be able to quickly attribute responsibility to the right component of user experience—not only so you can work to resolve the issue, but also you can communicate appropriately with your users.
Today’s end users demand transparency from their providers. Even if you’re certain your application is not at fault, it’s not enough to simply blame the Internet or some other external service. You need to be prepared to demonstrate the source of the issue (even that issue is external) and provide some plan or guidance to improve the customer’s experience. In particular, when you’re dealing with an enterprise customer’s IT team, you will need to provide more details then “It’s not us.” Having a clear, step-by-step view of the application delivery path from your customers all the way to your application servers is critical to understanding where and why something’s gone wrong and providing provable insight to your customers accordingly.
4. Monitor Interservice Communication that Spans External Networks and Services
Monitoring performance to your front door is an obvious way to monitor your user experience. But what about your application backend? Performance issues within your application stack can have a follow-on effect on user experience. You may have RUM-based application performance management (APM) tools that use code injection to monitor user interactions with your app, but many of your application components rely on external APIs—like payment gateways, voice and messaging, CRM database, etc.—and any one of those can impact your application and, subsequently, user experience. Anytime you leverage an external API, it becomes part of your application stack and must be managed appropriately. You may not be able to monitor them using the same tools you do for infrastructure that you own, but you should still know when and why your APIs are available and performing or not, so you can get to root cause faster, reduce MTTR, and ensure that they’re not negatively impacting user experience.
5. Embrace a Continuous Lifecycle Approach to Monitoring Your Service
It’s easy to treat monitoring solely as an operations practice, where it’s used to ensure service uptime. But having data early in your application journey can be key to making better choices around network and application architecture. For example, the choice of where to build your data centers or where to locate your workloads in public cloud providers can dramatically impact your service delivery. You’ll want to know how these choices will impact your application and users—before you deploy. Having detailed, visual, and reportable data that charts every aspect of user experience from web server, to network path, to Internet routing, before you roll out or scale out a new service can derisk your most important SaaS planning decisions.
What all of these best practices have in common is end-to-end visibility (performance transparency across every provider and every service)—not just your own. If you’re able to “see every network” and related service like it’s your own, you can radically reframe how you function internally, how you service your customers, how you manage providers, and how you build a bulletproof performance play over time.
Achieving Performance Transparency Inside and Out
How do you gain performance transparency both within and outside your infrastructure? Traditional on-premises network and application performance monitoring tools aren’t able to provide full transparency, because they require that you own or manage the infrastructure you want to monitor. In order to gain transparency outside of your “four walls,” you need to employ active monitoring techniques that not only provide visibility into your application from an outside vantage point, but also provide a granular view of the network and other aspects of user experience—from Internet routing to your enterprise customers’ internal WiFi performance.
ThousandEyes provides visibility into your application from where it really matters—the vantage points of your customers. From active agents that simulate your users from locations all over the globe to agents that can be dropped into your customer environments to monitor their experience (continuously or on-demand), you can gain a deep awareness of all of your application’s external dependencies and how they are impacting your overall digital experience. This “customer-to-front door” visibility is a critical complement to the monitoring that you already perform within your own application infrastructure today.
ThousandEyes active agents can also be used to monitor from your own sites to all application components located externally—whether they are third-party APIs or your own components located at a different site. Like any service delivered over the Internet, performance is highly complex and requires a high degree of Internet awareness to fully monitor.
Eighteen of the top twenty SaaS application providers use ThousandEyes to monitor external dependencies that impact user experience. These providers leverage industry best practices to deliver fast, highly-available service to millions of users every day. To learn more about how end-to-end visibility can help your organization adopt the habits of top achievers, download our Application Delivery White Paper, or get started with a ThousandEyes demo.