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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Being open, extensible and programmable makes the platform powerful<\/h2>\n

At its core, the platform incorporates a comprehensive MELT fabric \u2014 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\u2019t 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.<\/p>\n

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 \u2013 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.<\/p>\n

Consider distributed microservices based \u201capplications.\u201d They are themselves so complex and so distributed that in many ways they are the raison d\u2019etre for monitoring platforms such as Cisco FSO Platform. When we approached the problem of how to enable this \u201cMELT app\u201d 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.<\/p>\n

How Cisco FSO Platform works<\/p>\n

A winning, customer-centric governance model from the get-go<\/h2>\n

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 <\/em>by the customer, and that applications are guests<\/em> that a customer grants revocable<\/em> privileges to. We heard arguments that \u201capplications ingest data\u201d and \u201capps own the data.\u201d We soundly rejected these ideas. The customer ingests their <\/em>data. The customer owns their<\/em> data. An application is a guest that a customer invites and allows to perform clearly articulated, non-destructive, actions on the MELT stream.<\/p>\n

With that preamble out of the way let\u2019s dig into the primitives that the platform exposes to solutions.<\/p>\n

Dashboards and Microsites \u2013 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<\/em> can leverage to build fully interactive experiences on MELT data. When we took on the challenge of data driven visualization, we knew we couldn\u2019t 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\u2019t 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<\/em> 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.
\nExtensible Access Control \u2013 In a dynamic digital environment, one-size-fits-all access controls are too restrictive. Our platform\u2019s 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 \u201cadmin\u201d roles that may be too broadly scoped.
\nCloud Collectors and Custom APIs \u2013 It would quite literally be impossible to predict the shape and variety of APIs that partners and solution developers want to integrate. The platform\u2019s support for custom data gatherers, or \u201ccloud collectors\u201d 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\u2019s API for unique needs.
\nKnowledge Store \u2013 The knowledge store, acting as the platform\u2019s 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\u2019s lifestyle. Developers can create \u201cknowledge models\u201d 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\u2019t 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.
\nServerless Workflow \u2013 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.
\nEntity Modeling \u2013 With roots in AppDynamics\u2019 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 <\/em>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 <\/em>the stack to the station and regions effected, as well as down <\/em>the stack to clusters, nodes, and processes. This is full stack observability.
\nHealth Rules \u2013 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\u2019s solution. Returning to the example of stations and vehicles, the definition of a station\u2019s 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\u2019t practically be feasible to ask the customer to \u2018figure out themselves\u2019.<\/p>\n