Hi SkyWalking team I have submitted the v9 core discussion on the GitHub https://github.com/apache/skywalking/discussions/8241
----------------------- The complete text of the proposal is as following # SkyWalking OAP server v9 Core After the SkyWalking OAP 8.9.0 released, which is the last feature version of 8.x, I am glad to introduce the v9 core, including the new concept and plans. ## Why v9 is being introduced? SkyWalking core concepts have been designed back to 2018, which are service, instance, endpoint, with dependencies and topology amon them. This is the key value of the whole SkyWalking ecosytem, and also why we are successful. With 3 years, we have evoluted from an agent-based tracing minitoring system to a full-stack(VM to agent, covering logs/trace/metrics/events). But meaningwhile, we noticed with more levels of infrastructure being added, such as vm-monitoring, k8s monitoring, service mesh observability, incoming serverless(FAAS), our services get mixed, and unclear about the boundaries. Also, we have plans to adopt more ways to obserse, most importantly **ebpf**. So, a new core with new concepts must be introduced ## New concept The most important concept in v9 core is **LAYER**. Layer represents an abstract framework in the computer science, such as operation system(VM layer), Kubernetes(k8s layer), Service Mesh(typical Isto+Envoy layer) This kind of layer would be owners of different services detected from different technology. In the older 8.x branch, we have a `group` concept added to resolve this kind of mixing issue temporarily, but clearly, a new `layer` concept is much better. Also, `group` concept is going to be kept, as it is important inside each `layer`. At this time, group would be designed for end users to group their service internal. With `no group`, it would be in the default group. The name of layer is a string, but we would reserve some for visualization(UI) - os-linux - k8s - general(agent-installed) - faas - mesh - database - cache (SkyWalking community holds all rights to add new reserved layer name without extra notification) ## What We Should Change Accordingly? ### Service Service should still be treated as unique globally like today, even across `layer`. Layer is an attachment attribute, so it wouldn't be added in the name. The layer of a service registered in the first time, it would be saved, but never would be overrided in the future(unless the TTL passed, it goes the 2nd time registration). ### Query Protocol GraphQL metadata.graphqls would be expired, a new v2 would be designed by myself as the next step of this proposal. Generally, all query(s) are according to service's layer, but would not do query to different kinds of service(Service, Browser, Database). All legacy query to Service, Browser, Database would be bridged into `layer`-based query. ### How to Determine Layer All the engine(OAL, MAL, LAL) should provide core level mechanis to make receivers or analysis scripts could set `layer`. The default layer is `general`, which is like old-days `agent-installed` services. Agent analysis(traces) would add `general` layer through OAL engine. Linux monitoring would use `MAL` engine exposed(TODO) way in MAL script to set `os-linux` as the layer. ## Visualization With this new concept adding, the visualization clearly would face big evolution too. @Fine0830 and I are going to propose a new UI implementation, named `skywalking-booster`(repo name), to the whole community. In there, we have all monitoring type(layer) of objects as top level menu, tracing/metrics/logs would be a second level menu, and only be showing up if SkyWalking has upstream adopted features. Of course, consider requirements of custom metrics, we are still providing custom setup mechanism like we did in RocketBot. Meanwhile, I want to notify DaoCloud team, PMC member @TinyAllen and @JaredTan95, rocketbot UI(https://github.com/apache/skywalking-rocketbot-ui) is going to be expired too with the first v9 releasing. `skywalking-booster` could become the new recommended UI for the next generation. And I would like to express sincere thanks be behalf of the whole SkyWalking community. RocketBot UI helps the project to reach today's level. And from tech perspective, some key features, like topology map, is going to be moved into booster UI. ## Timeline In SkyWalking iteration, we don't provide the timeline about when this version is planned to release official. We are going to keep this tradition. So, within the first 9.0.0 iteration, if some critical issues(serious bugs and/or CVEs) are reported/fixed, PMC could cherry-pick commits or accept patches on 8.9.x branch, and initialize 8.9.x release. Notice, we should have no plan to keep features being added into 8.9.x. Sheng Wu 吴晟 Twitter, wusheng1108
