Micha Hernandez van Leuffen, Fiberplane | KubeCon + CloudNativeCon Europe 2023

This is texturing TV. Hello and welcome back to kubecon plus Cloud nativecon Europe. I'm Mike bizard and we're with Misha vanluffin, and we're from fiber plane and we're talking about collaboration and devops and how to make people more productive and efficient Misha.

Welcome the show. Thanks for having me. Welcome to my city.

Thank you or one of my cities. All right. You guys make essentially the equivalent of a notebook that is familiar to folks maybe who are data scientists as a concept but kind of new yeah as a concept devops teams and devops world.

So explain if you would a little bit what is an exactly the notebook does and kind of you know, one of the use cases and how does it really Drive productivity, right? Sure. Yeah, so it's very much inspired by data science.

So Jupiter notebooks for those familiar with that. We completely build it from scratch. So it's around notebook form factor and we've done a few interesting things.

So one is collaboration is built in so similar to a notion or a figma you see each other like real-time typing all of that and then in terms of making it devopsy what we've done is we've created this provider model effectively plugins that connects to notebook to different observability tools. So this could connect to elastic search Loki for logs. It could connect to Prometheus for metrics.

all sorts of something for tracing all sorts of Integrations Those are the Fairly obvious ones, but then on top of that you could connect to for instance GitHub to sort of have some visibility on your ci/cd and GitHub actions and Version Control. So stop there and that sort of that's where we're at. All right, and then more recently you added an open source set a metrics or libraries for collecting metrics essentially and how does that plug into the environment?

And what can I do with that? I previously was unable to do or might have had a harder time doing yes great question. So something that we've sort of realized through customer Discovery and talking to users is that it's effectively there's no sort of on-ramp for observability.

I would I would say it's quite hard to get started with it and it's quite labor intensive. So in terms of metrics what you need to do you need to like write instrumentation code to actually generate some metrics subsequently you need to obviously store those metrics somewhere and then you need to start Trading queries to analyze your metric data, then you want to sort of create alerting rules on top of that. You know, some threshold gets hit you want an alert to be fired off.

so some those elements were the things that people struggle with so we went back and sort of thought that how can we sort of revision sort of metrics? So we've created this project called Autometrics. It's a framework implemented in different programming languages.

So rust typescript go and python are sort of the the four additions. The rust version is I would say is the flagship Edition because we were a rush shop ourself. So that's the most advanced one.

But effectively what it does is you can annotate your handlers your API handlers. So your functions with the autometrix decorator or a macro or whatever meta programming primitive you have in your programming language of choice and it will generate for you the four golden signals for metrics. So we'll give you error rate request rate response times all of that out of the box, so For instance in vs code, which studio code if you're in in that in your IDE, you've got your your code base you hover over that function.

You've imported the automatic Library you hover over that function you get a tool tip that says, hey Emily see the the request rate the response time for this function, and it will take you. Could take you to Prometheus to visualize those metrics to take you to fiber plane to a fire plane notebook. Of course also to explore that data or grafana dashboard as well.

Is there a disconnect between the metrics that developers see and what the it operations team sees and how do I kind of align those because the it Ops team is typically using something like a New Relic or whatever and they have all these dashboards and then the developers and the sres have something else sometimes. So how do we kind of standardize and agree what it is that we're all going to collect and kind of get ourselves to you know. Look at the metrics.

Yeah, I think it's a great question. I think I do think we've automatics the benefit that it has is that it's it meets developers where they are, right you're writing this service, you're building up these functions. You have a clear mental model of how your application behaves and what it looks like and it makes sense to attach the metrics to those functions.

So I think that's a great starting point. Of course, it operations also have metrics around CPU utilization. Right?

Like how is the actual infrastructure performing and those do need to be for related? Of course? The other issue with observability in particular is people go.

Well, this is fabulous. I can query this stuff and I can figure out maybe there's an anomaly or whatever but upon further review basically look at them and they go I have no idea what questions to ask. So how do we kind of make people smarter enough to use the tool to get the answers that are in there more that are hidden in all the data and the metadata?

Yeah. Yeah. That's a good point asking better questions.

All right. Yeah. So I think you know it starts off giving at least sensible defaults right again, these these four golden signals make a lot of sense to track.

Yeah, what else? Do you think then that maybe we'll be using machine learning algorithms and things like that to launch the queries and maybe we'll only need to launch the queries in the rare moments when things are overly complex, but I guess how smart can smart get when in terms of the metrics that we surface. Yeah, I think there's definitely a role around Ai and I don't don't want to be another AI person but along the line like help me explain this alert, right?

So this thing went off, What do I need to investigate? What is this really mean? What should I be looking into in order to get to the root cause of this of this issue?

I think there's a role for AI there I think. I think we've been talking about the promise of ml Ops for a long time. I have seen yet that sort of materialized to be honest.

Auto remediation and like rolling back a service. I think developers and Ops people. Do 10th and wanna have exercise certain control?

Over what gets rolled back and and whatnot and like deploying a previous version. So I think that that part is still tricky. As we go along you guys just are relatively young in this whole effort.

What's next for you guys. What else can go into a notebook? How does the notebook evolve in your mind?

Yeah. So on the automatic front it's a very interested in getting feedback on it and sort of new ideas around the framework new features that we need to build out. You know, it's it can generate grafana dashboards.

It can generate fiber plane. Notebooks. It generates the alert definitions for you very interested to hear from the community like where to take that further.

And then in terms of private plane itself, of course not that's going to be the best place to visualize the automatics data and analyze on that so stuff that you can expect is around, you know, visualizing the function dependencies and how to metrics across the different functions behave definitely something around alerting and making that actionable service level objectives is another thing that we're investigating. So those are some areas that we that we're exploring you mentioned the learning Times you talk to a lot of folks and there's too many alerts. They know it's too much going on and they get a little Intuit to the whole thing.

And then they stop paying attention you get numb, right? Yeah. So how do we make it easier to streamline the alerts so that you know, they serve the function that we Invision for them without overwhelming people.

Yeah, I think that starts off with writing good alerts and slos, right. You want to track the right metrics? So again, like automatrics does help with at least some sensible defaults around that and but then you need to attach certain objectives to that that makes sense and don't have your alerting system go off all the time, right?

So It might not be a problem that a certain API Handler does not respond in a in a certain amount of time. Right or it could be Mission critical and I think centers around defining these slos in a in a good way that the entire team agrees upon. So, you know what to expect when that alert goes off and it's not just, you know, another slack channel that you can ignore.

We have now seen. I don't know how many customers you have. But you've seen a number of them deploy.

fiber plane and the whole notebook. How did it change the way they operate or function? What's been the downstream impact that you see in these organizations?

What's the before and after? Yeah, so I think there's a couple of use cases that we're now seeing emerge, right? So there's definitely there's the the post incident review something happens.

We need to sort of codify that knowledge and build up that that system of record and acknowledge base such that we're prepared for the future. That's sort of one use case that we're seeing like sort of is knowledge sharing is a big part of that also because what you see in organizations that always there's a few people that have either tribal knowledge or they're sort of muscle memory and being able to capture that knowledge across the organization such that other team members benefit from that as well. I think that's a that's a big piece of that.

There's other use cases around runbooks, right? So automating actually sort of that's how we use private plane internally also codified a runbook when we do a new deploy the steps that people need to take to deploy new version of a specific service in our in our infrastructure. We're here a lot about devops bottlenecks and that this is a you know, a process issue, but I have to wonder ultimately is this just a failure to communicate and maybe you know, we need to think about this differently and say hey guys, it is about sharing the tribal knowledge and all that soft knowledge more so than it is, you know just adding yet another devops platformer tool.

Yeah, I think and also think on top of that there's a lot of tools fatigue, right? There's so much to install so many things to try out and indeed to your point, maybe it starts off with, you know, having better communication and making the knowledge also a bit more the information and intelligence actionable knowledge sharing and you know, we at least think that fiber playing as a spot in that in that domain. All right, folks.

Well, like they say sharing is caring so start sharing meet you thanks for being like Pleasure. All right guys, we'll be back in a minute.