How to Design Self-service Network Analytics into Your Services
Summary
If you are a service provider or enterprise providing your customers with traffic visibility into their networks, there are things you must consider. In this post, we will look into design considerations for self-service network analytics portals.
We recently blogged on why network insight is essential for communications service consumers, including why self-service portals are increasingly important for today’s network and network operators. In that blog post, we looked at self-service portals from an end-user standpoint.
At Kentik, we believe in curated, actionable insight catering to different user personas across organizations. So, in this post, we will look into these portals in terms of design considerations for service providers.
If you are a service provider or enterprise and have decided to provide your customers with traffic visibility into their networks, amongst many other decisions you may find yourself thinking about:
- Differentiation
- Speed of delivery and deployment
Differentiation
Differentiation is the outcome of identifying what precise service(s) you are offering to your customers. It may also refer to the different tiers of customers to whom you are offering a similar service.
One level of differentiation is categorizing the customers (i.e. customer-oriented). I refer to “customer” in the modern network sense, where a customer can be, and oftentimes is, an internal service organization or cost center accountable for internal chargebacks. For instance, in an internal IT environment, the IT team may be responsible for the upkeep of internal networks. It is not uncommon for the same team to also be accountable for the application issues to the application owners. In this case, differentiation is separating out these entities over on the network to be able to monitor and manage them individually based on business requirements. In another example, a managed service provider (MSP) may be offering multiple services to customers, such as the visibility of traffic to/from your datacenters, satellite offices monitoring, or clean-pipe services. In any case, the essence of such differentiation is being able to tag the identified business context by looking at network traffic. The crucial aspect here is for the technology stack to be able to support this business logic correlation with network traffic in real-time and at scale.
The other type of differentiation is service-level oriented. That is, looking at how to offer the same type of service in different tiers. For instance, not every DDoS protection customer will need traffic scrubbing. Some, for cost reasons, might prefer to blackhole the traffic while others need a comprehensive mitigation solution with advanced post-mortem reporting. Or, you want to slice the visibility reports into tiers for customers paying differently.
Often times, the challenge here is to come up with a product offering which can be sliced into premium- vs. basic-like tiers via offered content and the way of delivery. Regardless of how easy or complex the required setup is, it is important that the underlying technology stack is inherently multi-tenant. This allows developers and ops teams to reutilize a set of services for similar customers without having to build a separate copy of the application for each instance.
Speed of Delivery and Deployment
Kentik is built with a highly scalable and distributed backend architecture which can ingest millions of flows per second and correlate with business logic in near real-time. Now, My Kentik can offer multi-tenancy over the same backend (for nerd-approval rating, it is sub-multi-tenancy, as Kentik by itself is a multi-tenant SaaS offering). You can think of My Kentik as a framework which allows for multi-tenancy (tenants, in this case, are the different customers) over the data we store with full retention. This allows us to avoid unnecessary replication of the data while still offering a per-tenant instance with full cardinality.
Another aspect of offering customers’ visibility is the ease and speed of onboarding new customers. Deployment at-scale can come with its own challenges — for instance, allowing a Parent-Admin to be able to spoof into per-tenant views without creating unique logins for the same person on all tenant environments; or edits on one visualization not carrying over into all other tenant views.
How does Kentik solve this problem? At the admin level, Kentik holds a central repository or library of alert policies, views, reports, and dashboards. A group of these can be put together as a library package and can be deployed to tenants in just one click. Editing or augmenting a dashboard can be (optionally) designed to be auto-deployed for other tenant instances, too. This means the lead time for onboarding new customers is very minimal, and system-wide upgrades for a multi-tenant application are mostly hassle-free.
There are a few more challenges which come with offering self-service portals beyond the technical architecture selection. In the next blog, we will explore more about the actual content that is reported, Kentik’s approach to tiering, and the operational pieces of such a service offering.
For more information, please see the My Kentik Portal topic in the Kentik Knowledge Base.
My Kentik is available now for all Kentik customers, with a limited number of tenants. For additional details about pricing packages for additional tenants, please contact your Kentik account team or email sales@kentik.com.
