 Hello everyone and thank you for joining us on this webinar about dynamic observability and the quest for real-time data in job-making applications. My name is Odette and this is Shavon and we are happy to have you with us. So who are we? Shavon is our director of product marketing here at Rookout. She likes to practice yoga and makes sure not to take life too seriously. Odette is our video product here at Rookout and he's a true believer in having fun while working together and he's also the founder of the TLV Board Game Media Group. Before we are going to start the quest for real-time data, code-level data and dynamic observability, I want to take a step back and see where we are today. So organizations are trying to reduce cost, to optimize cost. They are looking for agility. They are looking for elasticity and this is why they're moving their applications and infrastructure to the cloud. Adoption of cloud-native applications and technologies such as microservices, containers, dynamic orchestration, DevOps are booming and we expect to see in 2024 that 70% out of all applications are going to be cloud-native. In 2020, it used to be only 10% cloud-native applications and this is according to 2021 IDC. So these big trends bring many challenges together with it and we see and hear from our customers that the most common challenges are optimizing costs, modernizing application, breaking down monoliths, rebuilding them as microservices and adopting new tools and new methodologies to support this entire new ecosystem. So we invest a lot of development power and money and we face those challenges but still we find ourselves worried, worried from outages just like the recent log for Shell one. Those kind of outages can be devastated for organization and we're trying to avoid or at least minimize as much as possible and this is why we find ourselves investing more and more in observability. So the state of observability VMware 2021 state that over third both organizations already invested in observability solutions. In addition, we see that another third is going to adapt and maintain observability pipeline in the near future and although those numbers are pretty high it's not surprising at all and this is because cloud-native applications are very very dynamic and complex and the only way to maintain their quality is to be able to get clouds, traces, metrics on the fly and in any time and if possible to visualize them so you can have instant understanding of the state of your application. So further highlighting the interest around observability we see here that Galtman stated 2021 as the year of observability and we see again they highlight the fact that observability is not equal equal monitoring meaning it's so much more and we're going to see and discuss it in the next few slides. So observability it's in the title of the webinar and it's the title of this slide and I probably said too many times observability but it's really important that we are all in the same page of what is the definition of observability so I'm going to hand over to you then so you can share with us. So what is observability? Observability is defined as our ability to see and understand inside the application. When the application is having a problem we want to be notified about it we want to be alerted and we want to be able to travel shoot and get to the root cause of the problem as quickly as possible. Traditionally the observability tools are divided into three pillars although of course as you will see on some of the levels of this page many of them solve problems that are in more than one page. These tools need to provide logs, collect logs, deliver them to developers and let them see what happened as the application was running. They need to collect traces which give us additional context and tell us which of the dozens or hundreds of microservices or serverless functions were involved in a specific flow and the interconnection between them and they need to collect an aggregate metrics that allow us to measure quantifiable data over time and understand the behavior of our application. Now these tools are very popular, most companies who develop cloud native applications use at least one of them but these tools also have some key mutations that we need to be able to identify and address. The first limitation of traditional observability is context. When you only collect logs without context you can understand that something happened and you may have all of the local variables that tell you what was going on at the time but you need the context in order to be able to understand what happened just a minute before that, just a millisecond before that and also if you're running a complex and distributed application with hundreds or thousands of nearly identical services you need to be able to understand which one of them was involved, which one of them was seeing that special condition in order to get the full picture of what was going on. And displaying that full picture means printing additional logs and collecting additional data which brings us to another challenge. Yes indeed you're right today. Context is the number one problem but in context printing more log lines bring us to the second one, second highest line which is super high cost. When we lack context we find ourselves adding code, wait for another redeployment so for sure we're wasting developer time but in addition to that we're also paying a lot of money. We're paying for log collection, we're paying for log aggregation, we're paying for log ingestion and we're paying for log services and on top of all that we're also paying in application performance because when we're printing more log lines the application performance is dropping. So paying all around is never good companies are in constant strive to reduce costs to optimize costs because they want to be competitive. Okay so let's look at a very strange phenomena from business perspective. On one hand side you see that we lose 3.4 million dollars this is the average annual cost of limiting the log data. Where is it coming from? So first of all when we have an issue and we don't know where it's coming from then we need to reproduce it. To reproduce it we need to set up in place and this setup is usually very expensive so this is one time. Second time if we're not solving the issue fast enough then we have a problem where we have our customer experience dropping we have a problem of losing actual money transition that are not there if the application is done. So this is second time and third time we have our developers that we're shifting their original task which is to build code with new features instead they're occupied with finding bugs resolving those issues and unfortunately these tasks can take days and sometimes even weeks. So this is one time when we're not logging enough. On the other side we see that the average annual cost of collecting log data that is not being used is a loss of 1.8 million dollars. Where is this coming from? It's coming from logging formal fear of missing out and I think we can all relate that developers are in fear that when the need is there they will not have the debug data that they need so they're pushing for storing the highest log velocity possible and those logs are accumulate to high volume and obviously to very high expensive so losing on one side losing on the other side there must be a better way. And the third challenge we face as we try to use traditional observability tools is the challenge of the black box. Traditional observability tools ask us to add more code and to change the application every time we want to fetch additional logs and the engineers want to see the code and want to add code dynamically so that they can get a look into the black box. When we work with our customers they try to address this challenge using some traditional methods. Some of them try local debugging or command line debugging which is basically seeing the code on your own desktop and running it in a way that will stop whenever the application hits a breakpoint and then you get to see a full view of the local variables which is what's happening inside the box. But in cloud native applications you are not always able to reduce the issue or to run the same application locally on your desktop and even if you do in an application that is supposed to run in dozens or hundreds of microservices stopping everything or stopping one microservice we just not help you reproduce the same issue. Other customers rely on logging and tracing and then they face the challenges that we've already mentioned in this presentation, the lack of context and the need to pay a lot of money for storing and ingesting logs and of course there is a performance here that the application suffers when printing too many log lines and collecting too many traces and this all returns to the root cause where printing those additional logs adding more traces means changing code waiting for the application to build and redeploy again waiting for a restart and it means waiting for a significant time before you get to see additional data. Some customers try remote debugging which is between a challenge and a completely impossible task when you are trying to debug things like Kubernetes and AWS Lambda and similar technologies and too many of our customers fall back to crossing fingers praying and deploying to production blindly which means that you know there will be a bug the following day you know you will need to deliver a whole fix or rollback and have a lot of trouble and and inefficiency. So this situation is just not good enough. Traditional observability tools help us see inside the application and help us solve problems but there has to be a better more efficient way and happily there is if you've heard about tools that describe themselves as production debugging tools or live debugging tools you may have already heard about this technology and we are here to dig deeper into these new methods and describe dynamic observability. So introducing dynamic observability. Traditional observability is a way to ask questions we set and pre-define in advance a few parameters that we care about and we're going to get beautiful dashboards and alerts when something happens with them but it's not real time if something that is not there wasn't defined in advance we're not going to get it. With dynamic observability we ask questions in real time and we get answers in real time so the magic the mechanism behind dynamic observability is what we call non-breaking break points. Non-breaking break points are disruptive technology that allow developers to get traces logs and metrics on the fly they can instrument a log line switch it on they can get a debug snapshot with local variables with stack traces and with that they can really change their workflow they don't need to wait anymore it's instantly there for them. So this is dynamic observability. Now this dynamic instrumentation powered by bytecode manipulation is happening with the code it's running with the code and this is why it's instantly this is why you don't need to wait this is why the data is in real time and it is there for you. Once we have this new debug data we can pipeline it to a set of observability tools that are already there your favorite tool you can choose and analyze it all together. So in a way if you think about it dynamic observability helps you close the gap between black box debugging and white box debugging or from another perspective it helps you close the gap between dev and DevOps. On the left hand side we see the way in which a developer would want to debug a developer would want to see the code to work in dev environment to print logs and to see what's going on as the application is running. On the right hand side you see a DevOps engineer who wants to look at the application from the outside who wants to see a dashboard of graphs and metrics to tell him what's going on and dynamic observability actually lets these two specialists use the same tool and each of them benefit from the other specialist's work. A developer can work can look at the application from the outside and see dashboards and metrics and actually debugging production which is something that not many of the developers even there to think about and on the flip side a DevOps engineer can have the benefits of seeing the code of working in context of working locally without the impact of hurting the application while actually running on a live environment and in the middle of those you will find workout and you would find dynamic observability as a way to to make these two worlds meet. So let's recap what we've seen as the value of dynamic observability. Denying make observability gives engineers context in real time without waiting without changing the app without restarting. It means that you can solve bugs much much faster even in very dangerous and then complex environments such as cloud native production environment and when you solve problems faster you get happier customers and you have more time to deliver more business value which increases your efficiency and the efficiency of your team. You can do that without paying too much for additional logs and traces without paying more money for storage and ingestion without suffering the performance hit and the bottom line and I think that's the part we all here at Bucca really care about. You get happier developers, happier DevOps engineers who are more satisfied, who can solve problems faster, who can work on the interesting business impact rather than debugging unsolvable problems. So we hope you found this interesting and you're now curious to try dynamic observability for yourself. Thank you for watching this webinar and if you have any further questions or comments feel free to reach out. We're happy to get from you.