Cisco Full-Stack Observability Platform: Rapid Development and Partner Collaboration

Collaboration was key in the development of the platform

In June 2022, Cisco announced plans to develop Cisco Full-Stack Observability (FSO) platform, expanding upon the foundations set by AppDynamics Cloud. By February 2023, during Cisco Live Europe, we introduced the tech preview of Cisco FSO Platform. In just six more months, our promise of general availability was fulfilled by Cisco Live US, and we exceeded initial expectations by releasing six innovative modules.

A significant aspect of this achievement was our collaboration with external partners. Rather than solely do the development in-house, many of these modules were built by partners trained on the FSO platform. They utilized its tools and SDKs to create these modules, which were then published on our App Exchange. Rather than having a platform land with a thud, Cisco FSO Platform launched with enthusiastic partners who helped battle test it, and whose modules offered very real, market leading value from the outset.

The modules, available now on Cisco FSO Platform App Exchange, introduce features ranging from real-time cost insights to machine learning-based Kubernetes performance optimizers.

Being open, extensible and programmable makes the platform powerful

At its core, the platform incorporates a comprehensive MELT fabric — Metrics, Events, Logs, and Traces. This system is designed to efficiently process vast amounts of data from diverse digital systems. But the real power of the platform doesn’t just stem from MELT storage and query. It derives from seven powerful features that can be programmed collectively, or individually, and a unique application packaging system for deploying these solutions to the Cisco FSO Platform exchange. From the customer point of view, this manifests in the form of subscription solutions that can provide diverse feature sets, ranging from small enhancements to full-blown applications with a specific industry focus. From a competitive point of view we can confidently say that the platform offers the most sophisticated and comprehensive approach to building cloud native full stack observability solutions.

Before we dig into the pieces of the platform and the development model, consider for a moment the challenge of what it even means to define this new category of application – the MELT app. Perhaps the best analogy for what the platform provides, is that it acts as a distributed operating system that governs the complete lifecycle of MELT data, from collection and ingestion to processing, storage, and query. This means that a MELT app is a distributed application, and the complexity could easily spiral out of control.

Consider distributed microservices based “applications.” They are themselves so complex and so distributed that in many ways they are the raison d’etre for monitoring platforms such as Cisco FSO Platform. When we approached the problem of how to enable this “MELT app” we knew that we had to embrace the concept of declarative versus imperative, applications. We had to provide a very clear framework versus a low-level free-for-all. That is to say, a Cisco FSO MELT app is a set of declarations, each declaration telling a particular piece of the platform how it should behave.

A winning, customer-centric governance model from the get-go

We also knew that the platform had to provide solid isolation primitives that would guarantee that App A and App B could safely co-exist. We took to heart the idea that the data flowing into the platform is absolutely owned by the customer, and that applications are guests that a customer grants revocable privileges to. We heard arguments that “applications ingest data” and “apps own the data.” We soundly rejected these ideas. The customer ingests their data. The customer owns their data. An application is a guest that a customer invites and allows to perform clearly articulated, non-destructive, actions on the MELT stream.

With that preamble out of the way let’s dig into the primitives that the platform exposes to solutions.

1. Dashboards and Microsites – MELT UI may be the most important and front-facing component of the platform. Dashboards are not just a way to throw charts onto a page. They are a comprehensive framework that applications can leverage to build fully interactive experiences on MELT data. When we took on the challenge of data driven visualization, we knew we couldn’t just coexist with Grafana dashboards. We had to do something game-changing and raise the bar. We aspire to be nothing less than the best MELT dashboarding platform in the industry. While we can’t explain it all in this summary, the nutshell is that we embrace an emerging standard called JSONata for the manipulation of JSON data that puts the dashboard builder radically in control of how data is transformed and manipulated so that virtually any data source can be paired with any visualization. On top of that, microsites allow our solution developers to provide containers that serve their application experiences from the backend frameworks and languages of their choice, while maintaining a consistent authn/z experiences for the user. This comprehensive approach to UI provides partners with an unequaled set of capabilities.
2. Extensible Access Control – In a dynamic digital environment, one-size-fits-all access controls are too restrictive. Our platform’s extensible access control adapts to varying application domains. Developers can easily create domain-specific roles, ensuring precise and secure access over features that they themselves provide. Customers benefit from robust, customizable roles ensuring their data is only accessed by the right personnel. Developers are unlocked to create new roles that make sense for their own verticals vs generic “admin” roles that may be too broadly scoped.
3. Cloud Collectors and Custom APIs – It would quite literally be impossible to predict the shape and variety of APIs that partners and solution developers want to integrate. The platform’s support for custom data gatherers, or “cloud collectors” allows the developer self-service over their integrations. Developers can gather data from diverse endpoints using any programming language with containerized collectors. For businesses, this means unparalleled flexibility in data integration and the capability to extend the platform’s API for unique needs.
4. Knowledge Store – The knowledge store, acting as the platform’s distributed brain, stores non-MELT related information. This can be anything from an investigation workflow, to a dashboard. The knowledge store is internally globally replicated and layered but presents as a simple store. This vastly simplifies the developer’s lifestyle. Developers can create “knowledge models” that extend the knowledge store with new types. For example, if a developer wanted to create a solution that allowed an investigation to be linked to a health rule violation, the developer is empowered to totally define the concept of an investigation through Knowledge modeling. The global, multi-region nature of the knowledge store means that developers don’t have to worry about, or even know that customers reside in multiple cells across multiple regions globally. Just push a simple knowledge model to the platform and you are good to go, regardless of how many customers around the globe subscribe to your app.
5. Serverless Workflow – Observability pipelines can be notoriously hard to wrangle. By implementing the CNCF Serverless Workflows and Cloud Events standards, Cisco FSO Platform allows third-party developers to inject both simple and intricate behaviors into the observability pipeline. This allows domain specific transformations, and even the derivation of new data off the arriving stream.
6. Entity Modeling – With roots in AppDynamics’ Application Performance Monitoring, our enhanced entity modeling organizes complex signals into intelligible insights. Developers can model domains with the Flexible MELT Modeling language, correlating signals across domains. Customers get a layered view, enabling precise problem pinpointing and resolution. The key to entity modeling is that it provides a domain specific, organizational scheme for the vast quantities of data that customers ingest. Without entity modeling, most tasks begin with just figuring out where and what a particular error came from. With deep support for entity modeling, domains can provide full stack correlation of data immediately. For example, supposing you are a metropolitan European transit agency tasked with providing on-time performance reporting in compliance with EU regulations. Entity modeling allows you to create entities representing both real physical assets such as vehicles reporting live telemetry, as well as roll-up entities such as cities and regions that monitor large-scale aggregate performance. Errors affecting turnstiles and card readers can immediately be correlated up the stack to the station and regions effected, as well as down the stack to clusters, nodes, and processes. This is full stack observability.
7. Health Rules – Health rules are a critical part of providing a full stack experience for customers. Developers can provide health rules that are integrally aware of the entity models and domains provided in the developer’s solution. Returning to the example of stations and vehicles, the definition of a station’s health depends on factors that are likely understood in great detail by the developer of the full stack transit monitoring solution. By including custom health rules, in the solution, behaviors such as linking health to on-time-performance of arriving trains and rider wait times becomes possible. By providing these out-of-the-box, the solution developer is able to provide the customer with a wealth of domain experience that wouldn’t practically be feasible to ask the customer to ‘figure out themselves’.

Share: